JP5992092B2 - 検査セル動作において複数のエンティティからの様々な要求を分離して管理する為の、検査機とマテリアルハンドリング装置との間のインタポーザ - Google Patents

Description

本開示は、主に自動検査装置の分野に関し、より具体的には、自動検査装置の統計的工程管理の分野に関する。

自動検査装置（ＡＴＥ）は、デバイス、半導体ウエハ、又はダイ等の検査を実施する任意の検査アセンブリであってよい。ＡＴＥアセンブリを使用することにより、自動検査を実行して、測定、検査結果の生成、及び結果の分析を素早く行うことが可能である。ＡＴＥアセンブリは、計器と結合されたコンピュータシステムから、カスタムの専用コンピュータ制御システム及び多様な検査機器を含みうる複雑な自動検査アセンブリに至る、電子部品検査、及び／又は、システムオンチップ（ＳＯＣ）検査又は集積回路検査などの半導体ウエハ検査を自動的に行うことが可能な任意のものであってよい。

ＡＴＥアセンブリから得られる検査結果を分析することにより、検査対象の電子部品を評価することが可能である。そのような、検査結果の評価は、統計的工程管理方法の一部であってよい。一例示的実施形態では、統計的工程管理方法を用いて製造工程の監視及び管理を行うことにより、製造工程において所望の製品が所望のレベルの効率並びに所望のレベルの品質で生産されるようにすることが可能である。一例示的実施形態では、所定のＡＴＥ検査の実施の完了後に、検査結果がまとめられ、統計的工程管理方法を用いて統計的に分析される。検査結果の統計的分析に基づき、その後の生産稼働において、製造工程及び／又は検査工程を変更することも可能である。

本発明の実施形態は、自動検査において統計的工程管理を実施することに伴う課題に対するソリューションを与える。具体的には、本発明の実施形態は、正しくない検査が行われているウエハ、或いは、固有の問題を抱えるウエハに対して多くの検査時間が費やされる前に、工程を修正する機会を与えることにより、合格か不合格かという結果を超える実行判断を下す為に使用されてよい。本発明の一例示的実施形態では、検査結果のリアルタイム統計分析の方法が開示される。本方法では、所定量の必要な検査結果が収集されたら、収集された検査結果の統計分析が実施されてよく、検査エラー又はウエハ欠陥が識別された場合は、これに応じて、選択されたアクションが実施されてよい。本明細書に記載されるように、アセスメント工程及びアクションは、ウエハ検査だけでなく、ウエハソート及び最終検査統計にも適用されてよい。

一例示的実施形態では、デバイスを検査する装置が開示される。本装置は、検査制御モジュール及び検査分析モジュールを含む。検査制御モジュールは、第１のプローバ及びハンドラ（ＰＨ）要求を生成してスーパバイザモジュールに送信するように動作可能である。スーパバイザモジュールは、第１のＰＨコマンドを、その実行の為に、プローバ及びハンドラに送信するように動作可能である。検査分析モジュールは、第２のＰＨ要求を生成してスーパバイザモジュールに送信するように動作可能である。スーパバイザモジュールは更に、第２のＰＨコマンドを、その実行の為に、プローバ及びハンドラに送信するように動作可能である。第２のＰＨコマンドの実行は、検査制御モジュールに対して透過的に行われる。

一例示的実施形態では、デバイスを検査する方法が開示される。本方法は、第１のプローバ及びハンドラ（ＰＨ）コマンドを生成し、実行の為にプローバ及びハンドラに送信するステップを含む。第１のＰＨコマンドは、検査制御モジュールからの第１のＰＨ要求に対する応答として生成される。本方法は更に、第２のＰＨコマンドを生成し、実行の為にプローバ及びハンドラに送信するステップを含む。第２のＰＨコマンドは、検査分析モジュールからの第１のＰＨ要求に対する応答として生成される。第２のＰＨコマンドの実行は、検査制御モジュールに対して透過的に行われる。

以下の詳細説明を、添付図面と併せて読むことにより、本発明がよりよく理解されるであろう。添付図面において、類似の参照符号は、類似の要素を指す。

統計的工程管理を実施する自動検査装置（ＡＴＥ）の一例示的簡略化ブロック図である。 統計的工程管理ルールの選択、編集、及び作成を行う為の一例示的グラフィカルユーザインタフェースを示す図である。 管理ルールの検査結果を表示する為の一例示的グラフィカルユーザインタフェースを示す図である。 本発明の一実施形態による統計的工程管理のリアルタイム管理の為の統計分析及び制御装置の一例示的ブロック図である。 本発明の一実施形態による統計分析及び制御装置の一例示的なカスタマイズ可能な状態機械コンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御装置の一例示的ロットレシピ管理コンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御装置の一例示的統計的工程管理コンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御装置の一例示的ビン管理コンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御装置の一例示的測定値モニタコンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御アーキテクチャに追加される一例示的カスタムコンポーネントを示す図である。 本発明の一実施形態による統計分析及び制御装置の一例示的工程パラメータ管理コンポーネントを示す図である。 本発明の一実施形態によるリアルタイム工程管理の分析及びアクションの方法の各ステップを示す一例示的フロー図である。 本発明の一実施形態による、検査が非アクティブな時間帯に決定木を作成して実行する方法の各ステップを示す一例示的フロー図である。 本発明の一実施形態による、検査が非アクティブな時間帯に決定木を作成して実行する方法の各ステップを示す一例示的フロー図である。 本発明の一実施形態による統計分析及び制御アーキテクチャと接続された一例示的プローバ／ハンドラスーパバイザコンポーネント及びプロキシプローバ／ハンドラドライバを示す図である。 本発明の一実施形態による、連続する自動検査の間にリアルタイムで検査を分析しアクションを実行する方法の各ステップを示す一例示的フロー図である。 現在進行中の検査を実行している検査プログラムに対して透過的なプローバ又はハンドラのコマンドを介入させる方法の各ステップを示す一例示的フロー図である。

以下では、本発明の好ましい実施形態を詳細に説明し、添付図面には、それらの実施例を示す。本発明の説明は、好ましい実施形態に関連して行われるが、好ましい実施形態は、本発明をそれらの実施形態に限定することを意図されたものではないことを理解されたい。逆に、本発明は、代替物、修正物、及び等価物を包含するものとし、これらは、添付の特許請求の範囲によって定義される本発明の趣旨及び範囲に含まれてよい。更に、以下の、本発明の実施形態の詳細説明では、本発明が十二分に理解されるように、様々な具体的詳細が記載されている。しかしながら、当業者であれば理解されるように、本発明は、それらの具体的詳細がなくても実施可能である。他の実施例では、周知の方法、手順、部品、及び回路について詳述されていないが、これは、本発明の実施形態の態様を不必要に曖昧にしない為である。本発明の実施形態を図示する各図面は、半図解的であって、縮尺が正確ではなく、具体的には、図面において、一部の寸法が、見た目のわかりやすさを指向していたり、誇張されていたりする。同様に、各図面での視線方向は、説明のしやすさの為に、ほぼ同様の向きになっているが、各図面における方向の描写は、ほとんどの要素については任意である。一般に、本発明は、任意の向きで動作可能である。

表記法及び命名法：
以下に続く詳細説明の幾つかの部分は、コンピュータメモリ内のデータビットに対する動作をシンボリックに表現した手順、ステップ、論理ブロック、処理などの形で表されている。これらの記述及び表現は、データ処理技術分野の当業者が仕事の内容を同分野の他の当業者に最も効率よく伝える為に使用する手段である。手順、コンピュータ実行ステップ、論理ブロック、プロセス等は、ここでは、且つ、一般に、所望の結果につながるステップ又は命令の首尾一貫したシーケンスであると考えられる。各ステップは、物理量の物理的操作を必要とするステップである。これらの量は、必ずしもそうでないにせよ、通常は、コンピュータシステムにおける記憶、転送、結合、比較、又は他の操作が可能な電気信号又は磁気信号の形態をとる。これらの信号をビット、値、エレメント、シンボル、文字、項、数などとして参照することは、主に共通使用の理由で便利な場合があることがわかっている。

しかしながら、これら及び同様の観点は全て、しかるべき物理量に関連付けられるべきものであり、それらの量に適用される便利なラベルに過ぎないことを念頭に置かれたい。以下の説明から明らかであるように、特に断らない限り、「処理する」又は「アクセスする」又は「実行する」又は「記憶する」又は「レンダリングする」などの用語を用いた説明は、コンピュータシステムのレジスタ及びメモリ並びに他のコンピュータ可読媒体内で物理量（電子量）として表されるデータを操作し、コンピュータシステムのメモリ又はレジスタ或いは、他のそのような情報記憶装置、情報伝送装置、又は情報表示装置内で物理量として同様に表される他のデータに変換する、コンピュータシステム又は同様の電子コンピューティング装置のアクション及び処理を指すものであることを理解されたい。あるコンポーネントが複数の実施形態に存在する場合、同じ参照符号を使用することは、そのコンポーネントが、最初の実施形態において示されたものと同じコンポーネントであることを示す。

本発明の実施形態は、自動検査において統計的工程管理を実施することに伴う課題に対するソリューションを与える。具体的には、本発明の実施形態は、正しくない検査が行われているデバイス（例えば、半導体ウエハ、システムオンチップ（ＳＯＣ）、又は集積回路等）、或いは、固有の問題を抱えるデバイスに対して多くの検査時間が費やされる前に、生産工程及び／又は検査工程を修正する機会を与えることにより、単純な合格か不合格かの結果を超える工程判断を下す為に使用されてよい。本発明の一例示的実施形態では、検査結果のリアルタイム統計分析の方法が開示される。一定量の検査結果が収集されたら、収集された検査結果の統計分析が実施されてよく、検査エラー、或いは、デバイス、半導体ウエハ、又はダイの欠陥が識別された場合は、これに応じてアクションが実行されてよい。具体的には、統計分析は、検査アクティビティが少ない時間帯に行われてよく、例えば、プローバ及びハンドリング装置の割り出し時間の間に行われてよい。更に、追加のマテリアルハンドリングコマンド（例えば、針の掃除、ｚ高さの調節、停止等）が、検査プログラムとマテリアルハンドラとの間に透過的に投入されてよい。

統計的工程管理分析：
本明細書に記載されるように、一例示的検査セル制御装置上の短ループにおいて統計的工程管理（ＳＰＣ）ルールが実行されてよい。ＳＰＣルールは、各種検査データパラメータ、例えば、パラメータ検査値、歩留まり値、及びビン結果の統計分析を経て、早期検出、通知、及び制御の各アクションを提供する。ＳＰＣルールは、ハンドラとプローブ機器との通信のような、通常の検査セル制御装置のプログラムアクティビティと同時に実行されてよい。一例示的実施形態では、ＳＰＣルールは、ロット検査工程の結果が制御されているか否かを検出することに用いられてよい。例えば、制御から外れて動いているガウス過程パラメータ分布は、平均値、又は、期待値からずれた標準偏差値で特性化されてよい。更に、例えば、ｉｄｄｑ測定値（ｉｄｄｑ検査は、集積回路の製造故障の検査方法）が通常の標準偏差より高く動いていると、これは、ダイが内部破壊により早期に故障するであろうことを示している可能性がある。これは、統計的工程ルール分析であれば識別できるが、 合格／不合格検査では見逃してしまう。これらの統計値は、ロット検査中にリアルタイムで監視することが可能であり、ＳＰＣの不適合（例えば、管理ルール違反）が識別されたら、修正又は停止のアクションをトリガすることが可能である。ＳＰＣルールの不適合を検出して、その後の検査を停止することにより、検査時間が無駄にならずに済み、識別された問題の修正が可能になり、歩留まりなどの評価指標を高めることが可能になる。

本明細書に記載されるように、ＳＰＣルール分析を用いる例示的実施形態は、故障が過度に多発したビン、他のサイトより歩留まりが低かったサイト、制御されている理想値からずれている統計値結果などの履歴結果の検出を行うことが可能である。ＳＰＣは又、合格ではあるが予想工程限界内に入らない部品についての工程課題を検出することも可能である。例えば、部品がハード限界内で合格していても、ＳＰＣルールの違反がリアルタイムで検出されたら、それらの違反をもとに、工程課題が存在し、それが対処可能であると判断することが可能である。

後で詳述されるように、検査セル制御装置上で実行される一例示的統計分析／工程管理フレームワークは、多くの利点をもたらしうる。例えば、統計結果の計算の為の測定値及びビンカウントの非侵襲的キャプチャである。検査スイートの実行は、実行入力ライブラリ呼び出し又はプローバ／ハンドラ（ＰＨ）フック関数の使用を必要とせずに同期化されることが可能である。一例示的実施形態では、検査スイートは、１つ以上の検査を定義する検査フローの一部であってよい。一例示的実施形態では、検査セル制御装置は、１つ以上の検査スイートを含む検査フローを実行してよい。

ＳＰＣルール、結果分析、及びレポートは、中央管理されてよい。ＳＰＣルールは又、アプリケーションモデルの変更を全く必要とせずに、既存の検査プログラムに組み込まれることも可能である。プローバ及びハンドラ装置は、ＳＰＣルールアクションから制御されることが可能であり、その際、必要な制御機能を有する既存のドライバがあればカスタムドライバは不要である。最後に、特定の検査環境及び特定の検査対象デバイスに対して、カスタムＳＰＣルールを作成することが可能である。表１に、幾つかの例示的ＳＰＣルールの一覧を示す。例示的ＳＰＣルールは、監視対象データの具体的なタイプ、ルール自体のタイプ、並びに、関連付けられたＳＰＣルール違反の検出時に実施されてよいアクションのタイプに対して、カスタム設計されてよい。ＳＰＣルールデータのタイプ、監視のタイプ、及びアクションは、図示されたものに限定されない。例示的ＳＰＣルールは又、他のタイプのデータの監視、並びに、分析及びアクションのタイプの追加の為の拡張を含んでよい。

表１：ルールタイプ、監視対象データ、及び実行されるアクションの例

統計分析及び工程管理が統合された検査セル：
図１に示されるように、統計的工程管理が統合された、自動検査装置１００の一例示的実施形態は、検査セル制御装置１０２、検査装置１０４、マテリアルハンドリング装置１０６、データベースサーバ１１２、及び（例えば、管理ルールのレシピ及びレポートを収容する）ウェブサーバ１１４を含む。自動検査装置１００は、検査結果のリアルタイム統計分析、並びに、検査プログラム１０３に対して透過的なプローバ又はハンドラのコマンドの挿入を行うことが可能である。一例示的実施形態では、マテリアルハンドリング装置１０６は、プローバ１０８及びハンドラ１１０を含んでよい。一例示的実施形態では、プローバ１０８は、検査対象デバイス（例えば、半導体ウエハ、ダイ等）と接触する複数のピン又は針を含むソケット又はプローブカードである。図１に示されるように、検査セル制御装置１０２は、検査プログラム１０３を含んでよい。検査プログラム１０３は、アプリケーションモデルを含んでよい。ウェブサーバ１１０は、ＳＰＣルールの入力、結果の分析、及び工程の監視に使用されてよい。ウェブサーバ１１０は又、ＳＰＣルールの作成及び編集を行うための、ウェブベースのＳＰＣエディタを含んでもよい。例示的実施形態では、ウェブサーバ１１０は、ウェブブラウザを有するデスクトップコンピュータであってよい。検査装置１０４は、検査することに加えて、ＳＰＣルールの検査に使用される検査結果値、ビンカウント、及び様々なタイプの歩留まりカウントをキャプチャしてよい。一例示的実施形態では、複数の検査装置１０４が、検査セル制御装置１０２によって制御されてよく、統計的工程管理に関して評価されてよい。

データ収集結果（ローデータ及び統計データ）及びＳＰＣルールの実行結果は、データベースサーバ１１２に格納されてよい。ウェブサーバ１１４は、後で詳述されるように、格納されたこれらの結果、並びに他のツールにアクセスしてよい。このデータベース１１２内のデータは、ＳＰＣルールの評価中に分析されてよい。一例示的実施形態では、後で詳述されるように、検査制御装置１１４は更に、検査結果を非侵襲的にキャプチャし、最小限のオーバヘッド及び小さなコードフットプリントでＳＰＣルールを検査する統計分析／工程管理フレームワークを含む。

ＳＰＣルールのウェブベースエディタ：
一例示的実施形態では、後で詳述されるように実行されるＳＰＣルールは、ウェブインタフェース（例えば、ウェブサーバ１１０）を使用して作成及び編集され、リレーショナルデータベースに格納される。ルール編集をサポートする為に、検査プログラム情報がインポートされてよい（例えば、所定の間隔、閾値、トレンドなどのような特定のパラメータ値が選択又は定義されてよい）。この情報は、ソフトウェアビン情報、ハードウェアビン情報、複数の利用可能な検査スイート、及び複数の利用可能な検査で構成されてよい。図２に示されるように、一例示的グラフィカルユーザインタフェースにおいて検査対象デバイス２０２、検査プログラム２０４、及びステージ２０６が選択されたら、ウェブインタフェースにおいて、検査対象デバイス２０２及び検査プログラム２０４に関連する様々なルールの選択、編集、及び定義が行われてよい。グラフィカルユーザインタフェースは更に、ＳＰＣルールを選択する為の選択パネルを含んでよい。検査プログラムが選択された後、選択された検査プログラムに関連するＳＰＣルールのリストが選択されてよく、これは、選択された検査プログラムから生成される検査結果の統計分析によって関連付けられる工程管理ルールの確認の為である。

図２に示されるように、一例示的実施形態では、ビンカウントルール選択パネル２１０及び検査値ルール選択パネル２１２が表示される。本明細書に記載されるように、ビンカウントルール及び検査値ルールに加えて、歩留まりルール、検査時間ルール、及びリカバリレートルールの選択パネルも利用可能であり、これらの選択パネルは、図２に示されたビンカウントルール及び検査値ルールの選択パネルと同様である。ビンカウントルール選択パネル２１０は、ルールのタイプに応じて、複数の異なる選択可能コンポーネントを含んでよい。限界監視：連続ビンカウントルール２１０ａは、以下の選択可能コンポーネント、即ち、ビンタイプ２２０、ビン番号２２２、連続数２２４、サイトごとの指定２２６、アクション２２８、及びルールを削除するオプション２３０を含んでよい。限界監視：総カウントビンカウントルール２１０ｂは、以下の選択可能コンポーネント、即ち、ビンタイプ２２０、ビン番号２２２、総カウント２３２、アクション２２８、及びルールを削除するオプション２３０を含んでよい。更に図２に示されるように、ビンカウントルール２１０は、限界監視：連続ビンカウントルール２０２ａ及び限界監視：総カウントビンカウントルール２０２ｂによって示されるように、別の様々なコンポーネント／フィールドを有して、別のルールを生成してもよい。

例示的検査値ルール選択パネル２１２は、ルールのタイプに応じて、複数の異なる選択可能コンポーネントを含んでもよい。図２に示されるように、一例示的限界監視：デフォルト検査値ルール２１２ａは、以下の選択可能コンポーネント、即ち、検査名２４０、統計２４２、間隔２４４、サンプルサイズ２４６、下限２４８、上限２５０、単位２５２、アクション２２８、及びルールを削除するオプション２３０を含んでよい。一例示的限界監視：サイト間：デフォルト検査値ルール２１２ｂは、以下の選択可能コンポーネント、即ち、検査名２４０、統計２４２、間隔２４４、サンプルサイズ２４６、サイト間の差のパーセンテージ２５２、アクション２２８、及びルールを削除するオプション２３０を含んでよい。

更に表２に示されるように、５つの異なる歩留まりルールが作成及び／又は編集されてよい。表２に示されるように、各歩留まりルールは、複数のパラメータに関連付けられてよい。一例示的実施形態では、限界監視：累積ルールは、（１つ以上の複数のサイトからの）全検査フロー実行後の総歩留まりを検証する。一例示的実施形態では、限界監視：ローリングルールは、ルールで規定される間隔で歩留まりを検証する。一例示的実施形態では、限界監視（サイト間）：累積ルールは、全検査フロー実行後のサイト間の歩留まり差を検証する。一例示的実施形態では、限界監視（サイト間）：ローリングルールは、サイト間の差のパーセントパラメータに基づいて、ルールで規定される間隔で歩留まりを検証する。最後に、一例示的実施形態では、トレンド監視：デフォルトルールは、幾つかの連続時間にわたって歩留まりが上下するかどうかを検証してよい。

表２：歩留まりルールの作成及び定義

表２に更に示されるように、ルールごとに幾つかのパラメータが定義されてよい。最小サンプルサイズパラメータは、ＳＰＣルールの検証が行われる前に検査されるデバイスの最小個数を規定してよい。下限パラメータは、下限歩留まり値を規定してよく、上限パラメータは、上限歩留まり値を規定してよい。サイトごとパラメータは、サイトごとに検証を行う場合は「はい」と規定されてよく、全てのサイトがまとめられる場合は「いいえ」と規定されてよい。シミュレーション／本番パラメータは、検査が本番データについて行われるか、シミュレーションかを規定してよい。アクションパラメータは、どのアクションが実施されるかを規定してよい（例えば、電子メール、停止、針の清掃等）。ローリング歩留まり間隔パラメータは、ＳＰＣルールの検証が行われる前に検査されるデバイスの個数を規定してよい。サイト間の差のパーセントパラメータは、任意のサイト間の最大歩留まり差を規定してよい（例えば、１０％に設定された場合は、サイト間の歩留まり差が１０％を超えると、ルールに不適合となる）。サンプルサイズパラメータは、ルールの検証が行われる前に検査されるデバイスの最小数を規定してよい。間隔パラメータは、ＳＰＣルールの検証が行われる間隔を規定してよい。トレンドタイプパラメータは、トレンドのタイプを規定してよい（例えば、ＡＳＣＥＮＤは、指定された回数にわたって歩留まりが上昇するかどうかを検証し、ＤＥＳＣＥＮＤは、指定された回数にわたって歩留まりが下降するかどうかを検証する）。トレンドカウントパラメータは、到達するとルールに不適合となるカウントを規定する。

本明細書に記載され、表３に示されるように、一例示的実施形態では、４つの異なるビンカウントルールが作成及び定義されてよい。各ビンカウントルールは、複数のパラメータに関連付けられてよい。一例示的実施形態では、限界監視：連続ルールは、連続ビン故障の数が最大数を超えたかどうかをチェックしてよい。一例示的実施形態では、限界監視：総カウントルールは、特定のハードウェアビン又はソフトウェアビンの総カウントが所定のカウントパラメータを超えないことをチェックしてよい。一例示的実施形態では、限界監視：総パーセントルールは、特定のハードウェアビン又はソフトウェアビンの総パーセンテージが所定のパーセントパラメータを超えないことをチェックしてよい。一例示的実施形態では、限界監視（サイト間）：累積ルールは、パーセンテージで表されるハードウェアビン間又はソフトウェアビン間の差がサイト間の所定の値を超えることができないことをチェックしてよい。

表３：ビンカウントルールの作成及び定義

表３に更に示されるように、ルールごとに幾つかのパラメータが定義されてよい。ビンタイプパラメータは、ビンがソフトウェアビンかハードウェアビンかを規定してよい。ビン番号パラメータは、特定のビンを規定してよい。連続パラメータは、連続ビン故障の最大数を規定してよい。サイトごとパラメータは、サイトごとに検証を行う場合は「はい」と規定されてよく、全てのサイトがまとめられる場合は「いいえ」と規定されてよい。シミュレーション／本番パラメータは、検査が本番データについて行われるか、シミュレーションかを規定してよい。アクションパラメータは、どのアクションが実施されるかを規定してよい（例えば、電子メール、停止、針の清掃等）。総カウントパラメータは、所与のハードウェアビン又はソフトウェアビンの最大カウントとして規定されてよい。サンプルサイズパラメータは、ＳＰＣルールの検証が行われる前に検査されるデバイスの最小数として規定されてよい。総パーセントパラメータは、所与のハードウェアビン又はソフトウェアビンの最大パーセンテージとして規定されてよい。最小サンプルサイズパラメータは、検証が行われる前に検査されるデバイスの最小数として規定されてよい。サイト間の差のパーセントパラメータは、任意のサイト間の最大歩留まり差を規定してよい。

本明細書に記載され、表４に示されるように、一例示的実施形態では、３つの異なるビンリカバリレートルールが作成及び定義されてよい。表４に示されるように、各ビンリカバリレートルールは、複数のパラメータに関連付けられる。一例示的実施形態では、限界監視：ビンリカバリレートルールは、第１のパスにおける全ての不適合ビンカウントの合計に基づいて、所与のビンのリカバリされた部品のパーセンテージをチェックしてよい。一例示的実施形態では、リカバリされたビンカウント／第１のパスにおける全ての不適合ビンカウントの合計×１００という式が使用される。一例示的実施形態では、限界監視：ビンリカバリレート効率ルールは、第１のパスにおけるビンカウントに基づいて、所与のビンのリカバリされた部品のパーセンテージをチェックしてよい。一例示的実施形態では、リカバリされたビンカウント／第１のパスにおけるビンカウント×１００という式が使用される。一例示的実施形態では、限界監視：全体リカバリレートルールは、第１のパスにおける全てのビンカウントの合計に基づいて、全てのビンのリカバリされた部品のパーセンテージをチェックしてよい。一例示的実施形態では、リカバリされた全てのビンカウント／第１のパスにおける全てのビンカウントの合計数×１００という式が使用される。

表４：ビンリカバリレートルールの作成及び定義

表４に更に示されるように、ルールごとに幾つかのパラメータが定義されてよい。ビンタイプパラメータは、ビンがソフトウェアビンかハードウェアビンかを規定してよい。ビン番号パラメータは、特定のビンを規定してよい。下限パーセントパラメータは、リカバリされた部品のパーセンテージの下限を規定してよい。上限パーセントパラメータは、リカバリされた部品のパーセンテージの上限を規定してよい。シミュレーション／本番パラメータは、検査が本番データについて行われるか、シミュレーションかを規定してよい。アクションパラメータは、ＳＰＣルールに不適合の場合にどのアクションが実施されるかを規定してよい（例えば、電子メール、停止、針の清掃等）。

本明細書に記載され、表５に示されるように、一例示的実施形態では、４つの異なる検査値ルールが作成及び定義されてよい。表５に示されるように、各検査値ルールは、複数のパラメータに関連付けられる。一例示的実施形態では、限界監視：デフォルトルールは、間隔パラメータで規定された一定間隔で、検査統計（例えば、平均、標準偏差、工程能力指数（ＣＰＫ）等）を上限及び下限に対して検証してよい。統計ごとにまとめられたデータは、第１の検査対象デバイスから順に累積される（最小限の数のサンプルが収集された後に任意の統計分析が実施される）。一例示的実施形態では、限界監視（サイト間）：デフォルトルールは、複数のサイトにわたって検査統計（例えば、平均、標準偏差、工程能力指数（ＣＰＫ）等）を検証してよく、間隔パラメータで規定された一定間隔で、パーセンテージ差を、サイト間の差のパーセント限界と比較してよい。統計ごとにまとめられたデータは、第１の検査対象デバイスから順に累積される（最小限の数のサンプルが収集された後に任意の統計分析が実施される）。一例示的実施形態では、トレンド監視：デフォルトルールは、幾つかの連続時間にわたって、選択された検査統計値が上下するかどうかを検証してよい。

一例示的実施形態では、マージナル監視：デフォルトルールは、間隔パラメータで規定された一定間隔で、検査の平均値を、シグマで表された高側マージン及び低側マージンに対して検証してよい。統計ごとにまとめられたデータは、第１の検査対象デバイスから順に累積される（最小限の数のサンプルが収集された後に任意の統計分析が実施される）。一例示的実施形態では、各検査は、検査限界と平均値との間の差に関して、最小サンプルサイズ、間隔、低側マージン、及び高側マージン（シグマ−標準偏差で表されたマージン）で規定されてよい。一例示的実施形態では、ランタイムで、ＳＰＣモジュールは、最小サンプルの検査の実行後にマージナルルールのチェックを開始してよい。ＳＰＣルールは、規定の間隔で（例えば、ＳＰＣルールの検証又はチェック等が行われる間隔で）周期的に実行されてよい。一例示的実施形態では、ＳＰＣモジュールは、指定された検査の下限と平均値との間の差を計算し、ルールに合格する為の低側マージンパラメータを平均値が上回るかどうかを判定してよい。指定された検査の上限と平均値との間の差も検査され、高側マージンパラメータ値を平均値が上回るかどうかもチェックされてよい。

表５：検査値ルールの作成及び定義

表５は又、ルールごとに幾つかのパラメータが定義されてよいことを示している。検査名パラメータは、どのＳＰＣ検査が監視対象として選択されるかを規定してよい。統計パラメータは、実行される特定の統計評価を規定してよい（例えば、ＭＥＡＮ、ＭＩＮ、ＭＡＸ、ＳＴＤ、ＣＰ、ＳＰＫ、ＣＰＬ、ＣＰＵ等）。間隔パラメータは、ＳＰＣルールの検証が行われる間隔を規定してよい。サンプルサイズパラメータは、ルールのチェックが初めて行われるまでに実行されなければならない検査の最小実行回数を規定してよい。下限パラメータは、選択された統計の下限を規定してよい。上限パラメータは、選択された統計の上限を規定してよい。単位パラメータは、所望の測定を規定してよい（例えば、マイクロアンペア等）。シミュレーション／本番パラメータは、検査が本番データについて行われるか、シミュレーションかを規定してよい。アクションパラメータは、どのアクションが実施されるかを規定してよい（例えば、電子メール、停止、針の清掃等）。サイト間の差のパーセントは、所与の統計において、任意のサイト間で許容される最大パーセンテージ差を規定してよい。低側マージンパラメータは、平均値と下限との間の最小シグマ差を規定してよい。高側マージンパラメータは、平均値と上限との間の最小シグマ差を規定してよい。間隔タイプパラメータは、検証が行われる間隔を規定してよい。トレンドタイプパラメータは、トレンドのタイプを規定してよい（例えば、ＡＳＣＥＮＤを選択すると、指定された回数にわたって歩留まりが上昇するかどうかが検証され、ＤＥＳＣＥＮＤを選択すると、指定された回数にわたって歩留まりが下降するかどうかが検証される）。トレンドカウントパラメータは、到達するとルールに不適合となるカウントを規定してよい。

本明細書に記載されるように、一例示的検査時間ルールの作成及び定義が行われてもよい。各検査時間ルールは、複数のパラメータに関連付けられてよい。一例示的実施形態では、検査時間ルールは、間隔パラメータで規定された一定間隔で、検査スイート検査時間の最小値、最大値、又は平均値を、上限及び下限に対して検証してよい。一例示的実施形態では、検査時間ルールに関して、幾つかのパラメータが定義されてよい。一例示的実施形態では、検査時間ルールは、以下のパラメータ、即ち、検査スイートパラメータ、統計パラメータ、サンプルサイズパラメータ、間隔パラメータ、下限パラメータ、上限パラメータ、単位パラメータ、シミュレーション／本番パラメータ、及びアクションパラメータを含む。検査スイートパラメータは、監視対象として選択されてよい１つ以上のＳＰＣ検査セルを規定してよい。統計パラメータは、選択された統計検査を規定してよい（例えば、ＭＥＡＮ、ＭＩＮ、ＭＡＸ等）。サンプルサイズパラメータは、ＳＰＣルールのチェックが初めて行われるまでの検査スイートの最小実行回数を規定してよい。間隔パラメータは、ルールの検証が行われる間隔を規定してよい。下限パラメータは、選択された統計の下限を規定してよい。上限パラメータは、選択された統計の上限を規定してよい。単位パラメータは、所望の測定を規定してよい（例えば、マイクロアンペア等）。シミュレーション／本番パラメータは、検査が本番データについて行われるか、シミュレーションかを規定してよい。アクションパラメータは、どのアクションが実施されるかを規定してよい（例えば、電子メール、停止、針の清掃等）。

図２及び表２乃至表５に示され、本明細書に記載されるように、例示的ＳＰＣルールはカスタマイズされてよい。ウェブベースエディタの例示的実施形態は、本明細書に記載されるように、複数のタイプのコンピュータで利用可能なソリューションを提供することが可能である。ルールをデータベースに格納することにより、統計分析／工程管理フレームワークの例示的実施形態は、ＳＰＣルールを独自フォーマットで保存するソリューションと異なり、他のツールでルールを利用可能にすることができ、他のツールがＳＰＣルールを作成することを可能にすることもできる。本明細書で図示及び記載されるルールは、作成及びカスタマイズが可能であるが、追加で選択可能なパラメータを定義することにより、他の管理ルールも可能である。

カスタマイズ可能な一例示的ユーティリティは、検査プログラムに関する基本情報をインポートすることが可能である。このインポートユーティリティは、検査プログラムの実行が完了するまでにどのようなビン、値、及びデータをＳＰＣルールに適用することが可能かの決定を支援することが可能である。インポートユーティリティは、このデータをキャプチャして、ウェブエディタで利用できるようにすることにより、ＳＰＣルールオプションが実際の検査対象デバイス及び使用される検査プログラムに基づくようにすることが可能である。インポートユーティリティは、検査ＩＤ、検査名、検査スイート、検査の単位及び限界、ソフトウェア／ハードウェア番号、及びビン番号の完全なリストを提供する。これらの個々の検査項目は、例示的ＳＰＣルールのセットアップの為に、ウェブエディタによって使用可能になる。

一例示的実施形態では、インポートユーティリティは、ＳＰＣルールが整うまでに、少なくとも１回検査されるデバイスのタイプに依存してよい。インポート工程は、少なくとも１回の検査フローの実行の後に発生してよい。一例示的実施形態では、この動作は、製品リリースから生産までの一環で行われてよい。従って、インポートが実施された後に、任意の所望のＳＰＣルールの作成が可能になる。一例示的ＳＰＣルールウェブベースエディタは、本明細書に記載されるように、実際の検査プログラム実行結果から検査名、検査スイート、及びビンをインポートすることを提供する。一例示的実施形態では、管理ルールの適用のされ方に関して、管理が行使されてよい。そのような管理の行使は、適正サンプルが収集されるまで総歩留まり又は他の何らかの統計的測定値が計算されないようにする為に、検査がいかに早期に行われるかを規定すべく、行われてもよい。

一例示的実施形態では、ルールに不適合となるごとに複数のアクションが指定されてよい。更に、複数のルールに不適合の場合は、アクションの実行順序が決定されてよい。一例示的統計分析／工程管理フレームワークは、個々のＳＰＣルールアクションを評価する際に、それらの厳しさを考慮に入れてよい。例えば、違反時に停止を引き起こすＳＰＣルールは、針の清掃を要求するルールより厳しい。一例示的実施形態では、本明細書に記載されるように、ビンルールは、ソフトウェアビン又はハードウェアビンのいずれかに基づいてよい。このことは、強力な管理を提供することが可能である。これは、ソフトウェアビンは、非常に特殊な検査不適合のチェックを可能にすることができ、ハードウェアビンは、複数の不適合がまとめられる場合がありうるからである。

図１に示された一例示的ウェブサーバ１１０は、ＳＰＣルールのエントリを可能にしてよく、ＳＰＣルールの実行結果の表示を提供してよい。図３に示されるように、表示窓を使用して、検査プログラム実行のＳＰＣルール結果が表示されてよい。図３に示されるように、検査対象デバイス２０２、検査プログラム２０４、及びステージ２０６が選択２０８されると、各種の検査結果が表示されてよい。図３に更に示されるように、検査対象デバイス２０２及び検査プログラム２０４が選択されていれば、特定の検査セル３０２、ルールタイプ３０４、ロットＩＤ３０６、及びウエハＩＤ３０８が選択３１０されてよい。そのような選択により、特定の検査セル３０２、ルールタイプ３０４、ロットＩＤ３０６、又はウエハＩＤ３０８についての検査結果の分析が可能になってよい。一例示的実施形態では、ウエハＩＤ３０８は、デバイスＩＤ、システムオンチップ（ＳＯＣ）ＩＤ、又は集積回路ＩＤであってよい。

図３には更に、歩留まりルールの実行の検査結果が示されている。歩留まりルール検査結果パネル３１２は、図２に示された、ＳＰＣルールエディタで定義された複数のコンポーネントを含む。図３に示されるように、一例示的実施形態では、検査結果は、開始時刻値３２０、ホスト名３２２、ロットＩＤ３２４、ウエハＩＤ３２６、最小サンプルサイズ値３２８、下限値３３０、上限値３２２、サイトごとフィールド３３４、選択されたアクション３３６、及びソートされた、検査ごとのルール結果３３８を含んでよい。図３に示されるように、個々の検査結果は、ウエハＩＤ３２６のそれぞれについて与えられてよい。

この例示的表示は、デバイス、ロット、及びソート番号でフィルタリングされてよい。この表示窓の結果は、３０秒遅れのリアルタイムであってよい。一例示的実施形態では、ＳＰＣルールの検証結果は、３０秒以内にデータベースに格納されてよい。一例示的実施形態では、新しいＳＰＣルールは、次の検査対象ロットに適用されればよい。従って、ＳＰＣルールがロットの途中で変更されることはない。後で詳述されるように、ウェブサーバ１１０は、ＳＰＣルールの実行（例えば、ルールの検証、及びルールに不適合の場合に実行されるアクション）及び最適化された工程管理を提供する統計分析／工程管理フレームワークに組み込まれてよい。後述されるように、ＳＰＣルールは、短ループ制御及び／又は長ループ制御により実行されてよい。

短ループ制御によるＳＰＣルールの実行：
後で詳述されるように、一例示的実施形態では、ＳＰＣルールの実行は、短ループ制御と長ルール制御とに分けられてよい。短ループ制御ルールは、ただちに利用可能なデータに基づく、検査セル内での工程管理を提供する。短ループ制御は、検査が減らされた時間帯に実行されてよく、例えば、ハンドリング装置１０６のプローバ１０８及びハンドラ１１０の割り出し時間の間（現在の検査フローの終了時から次の検査フローの実行開始時までの時間帯、例えば、プローブ１０８をウエハ上のあるＸＹ位置から同ウエハ上の別のＸＹ位置に位置付ける為にかかる時間）、又は、ハンドリング装置１０６（例えば、ハンドラ１１０）が次の検査対象のロット又はダイの準備をしている時間に実行されてよい。検査スイートプログラムから検査フロー完了イベントが受信されたら、状態機械がＳＰＣルールの検証をトリガしてよく、ＳＰＣルールに不適合の場合は、結果としてのアクションがとられてよい。一例示的実施形態では、短ループ制御は、表６に示されるような分析及びアクションを提供してよい。例えば、ＳＰＣルール違反に対する応答としてプローバ又はハンドラのアクションが要求された場合、状態機械は、次のデバイスが実行される前に、プローバ又はハンドラのドライバをホールド状態にしてよい。

表６：短ループ制御ルールの例

一例示的実施形態では、現在のデータ及び結果が検査セル制御装置のメモリに格納されてよく、これらのデータ及び結果に基づいて、短ループ制御が実施されてよい。この短ループは、スループットに対する影響を抑える為に、ハンドリング装置／プローバの割り出し時間（例えば、本明細書に記載される様々な理由による検査の一時停止）に同期してよい。検査フローの実行後、ただちに結果の評価が行われてよい。従って、一例示的実施形態では、直近のダイ又はパッケージの後に、検査の実行が停止されてよい。例示的実施形態は、工程管理パラメータを、現在のロットの実行に基づいて、既知の指標と比較する。例えば、ＳＰＣルールは、ｉｄｄｑ標準偏差統計結果が検査中のロットの限界を超えたかどうかを判定することが可能である。

長ループ制御によるＳＰＣルールの実行：
一例示的長ループ制御は、履歴データ（例えば、データベースに格納され、検査機間、ロット間、及び検査場所間で比較されたデータ）の分析に基づいてよい。一例示的実施形態は、中央データベースを用いて、ＳＰＣルールを長ループで実行してよい。アクションは、検査フローの実行後でも行われうるが、以前に収集されたデータに基づく。一例示的実施形態では、格納されたデータは、以前のロット又は他の検査セルからのものである。長ループ制御は、工程管理パラメータを、既知の指標及び以前の実行のデータと比較してよい。例えば、１０個の検査セルが、同じタイプのデバイス、ロット、又はダイを検査していてよい。この実施例では、統計分析により、１０個の検査セルのうちの１個の歩留まりが、他の９個の検査セルより１０％低いと判定されている。この実施例では、検査セルで不適合となった対象は、オフラインにされてよく、不適合の、チャネルカードなどのコンポーネントは、識別され、交換される。不適合のチャネルカードが交換されると、その後の統計分析により、対象の検査セルにおいて、歩留まりの測定値がただちに正常値に戻っていることが示される可能性がある。歩留まり統計は、短ループルール分析では許容範囲内であっても、長ループで以前のロットと比較すると不適合になる可能性があることに注意されたい。一例示的実施形態では、ＳＰＣルールは、検査結果を検査フロア間、検査機間、ロット間、及びウエハ間で比較する長ループで実行されてもよい。

短ループと長ループの比較：
一例示的短ループルール分析は、ユーザが、工程管理パラメータを、最大標準偏差や最小歩留まりなどの、検査対象デバイスの既知の絶対基準に照らしてチェックすることを可能にする。一例示的長ループ制御は、ユーザが、工程管理パラメータを、検査対象デバイスのタイプにおける正常値、並びに正常歩留まりなどの検査プログラムに照らしてチェックすることを可能にする。長ループルール分析は、ユーザが、ロット間（時間）、検査セル間、及びウエハ間にまたがる、検査結果の悪化を検出することを可能にする。短ループ制御及び長ループ制御は両方とも、例えば、検査機ハードウェアの不良に起因する工程管理の変更、組み立て工程における変更、不正な設定、或いは、機器、接触子、又はプローブカードの取り扱い不良の識別を支援することが可能である。一例示的短ループは、基本工程が規定の限界内に確実に収まるようにする為に使用されてよく、一方、一例示的長ループは、履歴正常工程結果と現在の結果との比較を可能にする。

統計分析／工程管理フレームワーク：
一例示的統計分析／工程管理フレームワークを、図４に示す。図４に示される各モジュールは、統計分析／工程管理フレームワークの主要コンポーネントを構成する。これらの例示的モジュールは、検査セル制御装置１０２によって同期される状態機械の指示に従って、それぞれ個別のタスクを実施してよい。一例示的実施形態では、統計分析／工程管理フレームワークの全てのモジュールが、ハンドリング装置１０６のプローバ１０８及びハンドラ１１０の割り出し時間（例えば、検査フローの実行の準備がされている間の、検査が非アクティブな時間帯）の間に発生するＣＰＵ負荷のほとんどを用いて、検査セル制御装置１０２上で動作する。検査プログラム１０３の検査アクティビティが減らされる時間帯は、後で詳述されるように、結果計算に利用可能な計算能力が増大する。

図４に示されるように、一例示的統計分析／工程管理フレームワーク４００は、ロットレシピ管理モジュール４０２、イベントモニタ４０４、状態機械４０６、統計的工程管理（ＳＰＣ）モジュール４０８、ビン管理モジュール４１０、測定値モニタ（ＭＶＭ）４１２、及びプローバ／ハンドラ（ＰＨ）スーパバイザ４１４を含む。一例示的ロットレシピ管理モジュール４０２は、状態機械４０６から要求された場合に、所望のＳＰＣルールをデータベースサーバ４１６に照会してよい。一例示的実施形態では、これは、ロットの検査の開始時に行われる。

一例示的実施形態では、統計分析／工程管理フレームワーク４００を構成する各モジュールは、検査セル通信フレームワークによって相互接続されてよい。一例示的実施形態では、アーキテクチャに依存しない共有メモリ構造及び共通セマフォ同期パターンを用いて、モジュール間コマンドが実施されてよい。一例示的実施形態では、モジュール間コマンドは、コマンド及び関連付けられたパラメータを含んでよい（例えば、コマンドパラメータは、キー値ペア、ローテキスト、又はローバイナリの辞書であってよい）。アーキテクチャに依存しない共有メモリ構造及び共通セマフォ同期パターンの使用により、相互接続された各モジュールが、コマンドの送受信、及びイベント通知の受信を、素早く効率的に行うことを可能にすることができる。一例示的実施形態では、各モジュールは、コマンドを、中央サービス経由のルーティングを行わずに、相互に直接伝達することが可能であり、イベント通知は、本明細書に記載されるように、メッセージキュー及びバッファを用いて実施されてよい。イベントは、イベントモニタ４０４などの中央ディスパッチャを経由してルーティングされてよく、中央ディスパッチャは、そのイベント通知を全てのモジュールに転送する。本明細書に記載されるように、コマンド（例えば、状態機械４０６からＳＰＣモジュール４０８へのコマンド）は、発信点から宛先モジュールに直接送信されてよく、一方、イベント通知は、発信点から、検査セル通信フレームワーク上の全てのモジュールに送信されてよい。

一例示的検査セル通信フレームワークは、イベント通知を統計分析／工程管理フレームワーク４００の各モジュールに供給してよく、これによって、各モジュールは、検査の進行状況を追跡することが可能になる。一例示的実施形態では、次に来る、利用可能な計算リソースの計算窓が予想又は予測されてよく、これは、ＳＰＣルールの実行が、検査の進行を混乱させることなく、リアルタイムで行われることを可能にする為である。イベント通知の送信は非同期で行われてよく、一方、コマンドは同期生成されてよい。

後で詳述されるように、各モジュールのアクション、例えば、状態機械４０６及びＳＰＣモジュール４０８のアクションは、検査セル内のアクティビティに関するイベント通知の受信に依存してよい。イベント通知は、どのようなイベントが発生しているか、並びに、検査セルが現在、検査フローのどこにあるかを、相互接続されている各モジュールに伝える。例えば、状態機械４０６は、イベント通知を用いて、検査が減らされる時間帯に入ったことがイベント通知によってレポートされたとき（例えば、プローバ／ハンドリング装置の割り出し時間が始まったとき、或いは、例えば、あるロット又はダイの検査が終了して、次のロット又はダイが見つけられ、検査位置まで移動しているとき、或いは、あるＸＹ位置にある現在の検査フローが完了して、プローブ１０８が新しいＸＹ位置に移動しているとき等）に、ＳＰＣモジュール４０８がＳＰＣルールの検証のラウンドに入ることをトリガすることが可能である。一実施形態では、ＳＰＣモジュール４０８は、状態機械４０６からのコマンドによって指示されるとおりにＳＰＣルールの検証を実施し、状態機械は、検査工程の状態、例えば、検査セルが検査工程中のどこにあるか、並びに、どのようなＳＰＣルールが検証されるべく待機しているか、を追跡する。一例示的実施形態では、ダイ又はロットの開始時又は終了時、或いは、針の清掃又は他の変更の後に実行されるＳＰＣルールは、受信されるイベント通知に依存してよい。例えば、ＳＰＣモジュール４０８は、特定の検査条件が満たされた時点でＳＰＣルールの検証を実施してよく、例えば、ＳＰＣルールの次の実行の前に所定数の部品が検査されたとき（例えば、間隔）、或いは、検査の開始時又は終了時に実施してよい。本明細書に記載されるように、一例示的実施形態では、ＳＰＣルールの検証は、受信されるイベント通知によって決定されたときに、状態機械４０６からのコマンドによって指示されるとおりに、ＳＰＣモジュール４０８によって実施されてよい。

図４に示されたイベントモニタ４０４は、状態機械４０６内の状態遷移を引き起こすイベントを提供してよい。これらのイベントは、他のモジュールも利用可能であってよい。イベントの例示的実施例として、ＴＥＳＴＰＲＯＧＲＡＭ＿ＥＸＥＣ＿ ＳＴＡＲＴＥＤ（検査プログラム実行開始）、ＴＥＳＴＰＲＯＧＲＡＭ ＥＸＥＣ ＣＯＭＰＬＥＴＥＤ（検査プログラム実行完了）、ＬＯＴ ＳＴＡＲＴＥＤ（ロット開始）、及びＴＥＳＴＦＬＯＷ ＥＸＥＣ ＣＯＭＰＬＥＴＥＤ（検査フロー実行完了）がある。一例示的状態機械４０６は、イベント時に遷移することにより、現在の状態を追跡してよい。これらの例示的状態遷移は、ＳＰＣルールが評価されることを引き起こすことが可能な例示的関数コールバックを実行してよい。一例示的実施形態では、状態機械４０６は、ＳＰＣルールのダウンロード、評価、アクション実行、及びレポートを同期させてよい。本明細書に記載されるように、イベントモニタ４０４によって生成されるイベント通知は、検査セル通信フレームワークを介して統計分析／工程管理フレームワーク４００の全てのモジュールに送信されてよく、これによって、状態機械４０６やＳＰＣモジュール４０８などのモジュールは、重要なイベントの発生時に通知されることが可能である。一例示的実施形態では、本明細書に記載されるように、状態機械４０６は、受信されたイベント通知に基づいて、ＳＰＣルールの検証の為のコマンドをＳＰＣモジュール４０８に送信してよい。

一例示的ＳＰＣモジュール４０８は、ロットの開始時に照会されたＳＰＣルールを使用し、状態機械４０６の制御下で、それらのルールを、要求された間隔で実行してよい。例示的統計的工程管理モジュール４０８は、ＳＰＣデータに対してビン管理モジュール４１０及びＭＶＭモジュール４１２を使用してもよい。一例示的実施形態では、ＳＰＣモジュール４０８は、ＳＰＣルールを実行する（例えば、ＳＰＣルールの全ての検証及び評価を実施する）。一例示的ビン管理４１０は、全体ビンカウント、連続ビンカウント、及び（全体及びサイトごとの）歩留まり値を追跡してよい。一例示的実施形態では、ビン管理４１０は、歩留まり値及びビニング値を追跡する。

一例示的ＭＶＭモジュール４１２は、全体及びサイトごとに、値を追跡してよく、時間統計を検査してよく、又、ローデータを３０秒間隔でキャプチャしてよい。一例示的実施形態では、ＭＶＭモジュール４１２は、検査結果を監視してよく、オンザフライ統計計算を提供してよい。一例示的プローバ／ハンドラスーパバイザ４１４は、アプリケーションモデル又は状態機械４０６からの要求に応じて、プローバ又はハンドラのドライバの実行をロード及び制御してよい。一例示的実施形態では、プローバ／ハンドラスーパバイザ４１４は、ＳＰＣルールによって開始されるアクション（例えば、針の清掃）を実行する為のプログラム可能なホールドオフ状態を提供してよい。後述されるように、ホールドオフ状態は、状態機械４０６から発行されたプローバ又はハンドラのコマンドが実行される間、検査プログラム１０３から発行されるプローバ又はハンドラのコマンドをホールドすることが可能である。そのようなホールドオフは、検査プログラム１０３に対して透過的である。

一例示的実施形態では、統計分析／工程管理フレームワーク４００は、ＳＰＣの要求データ、例えば、パラメータ検査値統計及び検査時間統計を収集することが可能なモジュールとの通信、及びこれらのモジュールの制御の効率化を可能にしてよい。そして、フレームワークは、ＳＰＣルールに不適合の場合にＳＰＣアクションが短ループで素早く透過的に実行されることを可能にしてよい。一例示的実施形態では、工程管理ルールに対する不適合が検出されると、短ループＳＰＣルールが、最小限のオーバヘッド及びアクションでチェックされ、これは素早く行われることが可能である。これを、統計分析／工程管理フレームワーク４００の例示的実施形態は、モジュール間コマンド及びイベント通知を含む非常に高速な通信を提供することによって達成することが可能である。状態機械モジュール４０６は、それらの通信を連係させてよい。従って、全てのモジュールが、非常に重要な検査セルイベント、例えば、検査フローの実行の終了や、検査セルプログラムが動作待機中であることなどを認識していることが可能である。

一例示的実施形態では、統計分析／工程管理フレームワーク４００は、固有のアクションを実施するコンポーネント（例えば、モジュール）を有するモジュール式アーキテクチャを用いる。一例示的統計分析／工程管理フレームワーク４００の心臓部は、状態機械モジュール４０６であり、状態機械モジュール４０６は、ＳＰＣルールの照会、ＳＰＣルールの実行（例えば、検証）、及び要求されたアクションの実行を連係させる。状態機械モジュール４０６は、ＳＰＣルールを評価する為に必要なモジュールのそれぞれと通信する。一例示的実施形態では、ＭＶＭモジュール４１２は、測定値及び検査スイート検査時間についてのローデータ及び統計データの両方を提供してよい。ビン管理モジュール４１０は、ビンカウント及び（全体及びサイトごとの両方の）歩留まりの両方を提供することが可能である。プローバ／ハンドラスーパバイザ４１４は、必要に応じて、更なる検査実行をホールドオフしてもよい。ＳＰＣルールが評価されている間に、次の検査フローが実行されてよい。

状態機械モジュール：
図４及び図５に示されるように、カスタマイズ可能な状態機械モジュール４０６は、全てのコンポーネントを、検査セル制御装置１０２及びマテリアルハンドリング装置１０６と同期させてよい。表駆動の状態機械モジュール４０６は、一例示的ｓｔａｔｅ＿ｍａｃｈｉｎｅ．ｘｍｌファイルで定義されてよい。他の実施形態では、他のファイルフォーマットが使用されてよい。このファイルには、イベントがいかにして、ある状態から別の状態への遷移を引き起こすか、並びに、状態変化時にどのＣ＋＋コールバック関数５０２が呼び出されるべきか、が記載されてよい。Ｃ＋＋コールバック５０２は、ＳＰＣルールのアクション（ルールの検証等）を実施してよい。このＸＭＬファイルは、可能なイベント及び現在の状態、並びに、現在の状態及びイベントに対して次の状態は何かを定義する。各遷移は、コールバック及び遷移ＩＤを有してよい。一例示的ｓｔａｔｅ＿ｍａｃｈｉｎｅ．ｘｍｌは又、全ての可能な状態を定義してよく、異なるイベントによって引き起こされる同一の遷移に対して固有のコールバックを提供してよい。個々の遷移に対して実行される各例示的コールバックは、統計分析／工程管理フレームワークの各モジュールと通信することによって、個々のアクション（例えば、ＳＰＣルールのチェックや、アクションの実行）を生成してよい。

表形式の状態機械モジュール４０６は、ハードコーディングされた状態機械に比べて理解、修正、及びサポートが容易なプログラミングコードの使用を可能にしてよい。ＳＰＣモジュール４０８は、状態機械モジュール４０６によって指示されるとおりにＳＰＣルールを実行してよい。一例示的実施形態では、状態機械モジュール４０６は、どのようなＳＰＣルールがＳＰＣモジュール４０８によって実行されるかを認識していない。言い換えると、状態機械モジュール４０６は、（例えば、効率的な処理のために、指定された間隔又は所望の計算窓を識別する）受信されたイベント通知に基づいて、ＳＰＣルールの実行を開始させるトリガをＳＰＣモジュール４０８に送信することが可能であるが、状態機械モジュール４０６は、ＳＰＣルールのトリガに対する応答としてどのようなＳＰＣルールが検証されるかを認識していない。状態機械モジュール４０６は、モジュール間の仲裁を行うことが可能であり、物理的アクション（例えば、プローバ／ハンドラスーパバイザ４１４へのコマンド）又は他の何らかのアクションを引き起こすコマンドが送信されると、状態機械モジュール４０６は、競合するコマンドが送信された場合に仲裁を行うことが可能である。

ロットレシピ管理モジュール：
図４及び図６に示されるように、一例示的ロットレシピ管理モジュール４０２は、データベースサーバ４１６とのインタフェースを提供する。ロットが開始されると、ロットレシピ管理モジュール４０２は、ＳＰＣルールを含むロットレシピをデータベースサーバ４１６からダウンロードする。一例示的実施形態では、ロットレシピ管理モジュール４０２は、現在の検査対象デバイス、検査プログラム、及び／又はソート番号に基づいて、データベース４１６にＳＰＣルールを照会する機能を提供してよい。一例示的実施形態では、これらのＳＰＣルールは、検査技術者又は製品技術者によってあらかじめ格納されていてよい。ロットレシピ管理モジュール４０２は、データベース４１６にＳＰＣルールを照会し、それらをＣ＋＋データ構造にフォーマットし、フォーマットされたものをＳＰＣモジュール４０８が使用して、各ＳＰＣルール違反について評価、実行、及びアクション決定を行う。ＳＰＣルールのダウンロードは、（受信されたイベント通知によって決定されるとおりに）新しいロットの開始時に状態機械モジュール４０６によってトリガされてよい。一例示的実施形態では、他のどのモジュールも、ＳＰＣルールの現在のセットを照会することが可能であるが、ＳＰＣルールを実行する主担当は、ＳＰＣモジュール４０８である。

統計的工程管理（ＳＰＣ）モジュール：
図４及び図７に示されるように、一例示的ＳＰＣモジュール４０８は、ＳＰＣルールの実行、並びに、アクションが必要かどうかの判断を担当してよい。一例示的実施形態では、ＳＰＣモジュール４０８は、特定の状態、例えば、プローバ／ハンドリング装置の割り出し中、ウエハの終了時、ロットの終了時等において、状態機械モジュール４０６から呼び出されてよい。一例示的実施形態では、ＳＰＣルールに不適合の場合に、ＳＰＣモジュール４０８は、その結果と、要求された／必要なアクション（あれば）とを、状態機械モジュール４０６に返してよい。一例示的実施形態では、状態機械４０６は、要求されたアクションを実行する。ＳＰＣルール結果は、３０秒以内にデータベース４１６に格納可能である。一例示的実施形態では、ＳＰＣルール結果は、構成可能なパラメータに従って、データベース４１６に格納されてよい。この構成可能なパラメータは、データがデータベース４１６に送信される間隔を設定することが可能である。例えば、５秒、１０秒、３０秒など、任意の間隔が選択されてよい。

一例示的実施形態では、ＳＰＣモジュール４０８は、ロットレシピ管理モジュール４０２からのＳＰＣルールを使用し、ＳＰＣルールの検証をいつ行うか、どのパラメータをチェックするか、並びに、ルール不適合の場合にどのようなアクションを実行するか、を決定する。一例示的実施形態では、ＳＰＣモジュール４０８は、ＳＰＣルールの評価を行うだけで、ルールアクション（例えば、ルール不適合時のアクション）は状態機械４０６にまかせる。ＳＰＣモジュール４０８は、適合／不適合ステータスとアクションとを状態機械モジュール４０６に伝達する。一例示的実施形態では、状態機械モジュール４０６は、ＳＰＣモジュール４０８を呼び出して、ＳＰＣモジュール４０８からＳＰＣルールの実行結果を受信することにより、ＳＰＣルールの評価を実行する。一例示的実施形態では、ＳＰＣルールの評価は、検査フロー評価の終了時、ウエハの終了時、又はロットの終了時に行われてよい。そのような評価は、ハンドリング装置１０６のプローバ１０８及びハンドラ１１０の割り出し時間の間に行われるように、タイミングが決定されてよい（割り出し時間は、例えば、最後の検査フローの終了から次の検査フローの実行開始までのアイドル時間であり、この間に、様々な操作が実施されてよく、例えば、デバイスの電源オフ、ビニング、ウエハ上のあるＸＹ位置から別のＸＹ位置までのプローブ１０８の移動などが実施されてよい）。

プローバ／ハンドラ（ＰＨ）スーパバイザ：
図４及び図１５に示されるように、且つ、後で詳述されるように、一例示的プローバ／ハンドラスーパバイザ４１４は、複数の発信点から複数のコマンドを受信してよく、これらのコマンドは、状態機械モジュール４０６によって指示されるとおりに、プローバ／ハンドラスーパバイザ４１４によって仲裁される。検査プログラム１０３から受信されるコマンドはホールド状態に置かれてよく、一方、状態機械モジュール４０６及びＳＰＣモジュール４０８からのコマンドは、プローバ／ハンドラスーパバイザ４１４によって実行される。プローバ又はハンドラのコマンドが完了したら、ホールドは解除されてよい。後述されるように、状態機械モジュール４０６からのプローバ又はハンドラのコマンドの介入は、検査プログラム１０３のアプリケーションモデルに対して透過的になる。例えば、検査プログラム１０３のアプリケーションモデルが新しい検査対象部品を照会する場合は、どの検査対象部品が使用可能かを調べるコマンドが検査プログラム１０３から発行されてよく、一方、バックグラウンドでは、状態機械モジュール４０６が、検査プログラム１０３からのコマンドを全て、プローバ／ハンドラスーパバイザ４１４においてホールド状態に置いて、状態機械モジュール４０６からの別の、プローバ又はハンドラのコマンドが最初に実行されることを決定してよい。

ビン管理コンポーネント：
図４及び図８に示されるように、一例示的ビン管理モジュール４１０は、ビニング値及び歩留まり値を追跡してよい。ビン管理モジュール４１０は、ＳＰＣモジュール４０８と、この情報へのアクセスを必要とする他の任意のコンポーネントとに、コマンドインタフェース（例えば、歩留まりモニタ又はウエハマップ表示）を提供することが可能である。一例示的実施形態では、ビン管理モジュール４１０は、ソフトウェアビンカウント及びハードウェアビンカウントの両方と、全体及びサイトごとの両方の歩留まりカウントとを評価してよい。一例示的ビン管理モジュール４１０は又、連続ビンカウントを追跡してよい。これらのカウント、並びに、全体及びサイトごとの歩留まりは、これらの数値を追跡するＳＰＣルールを実施する為に使用されてよい。

測定値モニタ（ＭＶＭ）モジュール：
図４及び図９に示されるように、一例示的ＭＶＭモジュール４１２は、以下の表７にリストされたアクションのうちの１つ以上を実施してよい。

一例示的実施形態では、ＭＶＭモジュール４１２は、測定値及び検査スイート検査時間をキャプチャできる、検査プログラムのイベントデータロギング（ＥＤＬ）クライアントであってよい。一実施形態では、ＥＤＬイベントストリームは、検査情報及び検査結果を収容する、検査プログラムのイベントストリームであってよい。ＭＶＭモジュール４１２は又、ＥＤＬイベントストリームの監視、及び有用なデータのキャプチャを実施してよく、これは、検査プログラム１０３の実行中にリアルタイムで行われるか、保存されたデータ収集ファイルを用いてオフラインで行われてよい。ＭＶＭモジュール４１２は、ＥＤＬイベントストリームの処理を、オンラインモード及びオフラインモードの両方で行うことが可能である。ＭＶＭモジュール４１２は、多くの検査実行からキャプチャされた値を処理して、平均値、最小値、最大値、標準偏差などの統計データをレポートする。ＭＶＭモジュール４１２は又、検査スイート検査時間をレポートできるように、各検査セル実行の開始及び完了のタイムスタンプを収集する。これらの測定値を使用して、指定された各検査スイートの開始時間の最小値、最大値、及び平均値に関する統計データを生成することが可能である。値及び検査時間の統計レポートに加えて、ＭＶＭモジュール４１２は又、ロー値のログファイルを３０秒おきに書き込むことが可能である。これらのファイルは、ウエハの検査が行われている間に値及び検査時間のウエハマップをリアルタイムで表示する機能を提供することが可能である。

ＭＶＭモジュール４１２の例示的実施形態は、ＳＰＣルールの評価に関してリアルタイムで照会されてよい。ＭＶＭモジュール４１２は又、ウエハ（例えば、検査対象デバイス）のローファイル又は統計ファイルを周期的に書いてよく、これらのファイルは、ウエハマップなどのサマリ画面を表示する為に、ウェブサーバ９０２によって使用されてよく、ウエハマップは、半導体ウエハ等に関する検査結果のマップを提供する。一例示的状態機械モジュール４０６は、監視対象検査によりＭＶＭモジュール４１２を初期化してもよく、ＳＰＣモジュール４０８は、ＳＰＣルールの評価を行うために、必要に応じて、照会を実施することが可能である。

一例示的実施形態では、全てのＭＶＭデータが、データベースサーバ４１６などのメモリに保持されてよい。そのようなメモリストレージは、照会時間の短縮が可能であり、又、統計レポートの為に大規模なデータグループを処理する際の処理時間を短縮することが可能である。一例示的実施形態では、保存が必要な任意のデータが、ウエハ検査中、或いは、ウエハ又はロットの終了時に、自動的にＸＭＬファイルに書き込まれることが可能である。一例示的実施形態では、図９に示されるように、ＭＶＭモジュール４１２は、ローカルＭＶＭクライアントのグラフィカルユーザインタフェース（ＧＵＩ）９０４によりサポートされてもよく、ＧＵＩ９０４は、直接照会、並びに、チャート、ヒストグラム、及びウエハマップの形式でのＭＶＭデータの表示を可能にする。ローカルＭＶＭクライアントのＧＵＩ９０４は、統計分析／工程管理フレームワーク４００の実行中に使用されてもよい。

統計的工程管理のカスタマイズ：
柔軟なコンポーネントフレームワークにより、ＳＰＣルールのカスタマイズが可能であり、これは、追加ルールの作成、並びに、既存のＳＰＣルールの更なる編集及び修正を行えるようにすることにより、可能である。ウェブベースＳＰＣルールエディタによる、ＳＰＣルールのそのような編集及び作成についても、本明細書において詳述される。図４及び図１０に示されるように、カスタムコンポーネント４２０が、イベント通知及びコマンドの送受信の為に、同じ検査セル通信フレームワークを共有することにより、標準コンポーネントとシームレスに統合されてよい。従って、カスタムコンポーネントは、検査セルアクティビティと同期できるように、他のモジュールと通信し、検査セルイベントを受信することが可能になる。カスタムモジュールの一例として、一例示的工程パラメータ管理（ＰＰＣ）モジュール１１０２がある。図１１に示され、本明細書に記載されるように、ＰＰＣモジュール１１０２は、ロットの開始中に状態機械モジュール４０６から呼び出されてよい。

工程パラメータ管理モジュール：
図１１に示されるように、一例示的工程パラメータ管理（ＰＰＣ）モジュール１１０２は、検査プログラム１０３の実行中に使用されてよいクリティカルなパラメータを追跡することが可能である。これらのパラメータは、検査プログラム名、プローブカードＩＤ、プローバファームウェアリビジョン、プローバドライバ構成、及び特定のプローブカードのタッチダウン数を含んでよい。ＰＰＣモジュール１１０２は、ロット実行の低歩留まり又は低スループットの原因であることが判明したクリティカルなパラメータをチェックすることが可能である。統計分析／工程管理フレームワーク４００は、これらのパラメータが適正であるようにすることにより、検査のセットアップの誤りが原因となりうる検査時間の浪費を回避することが可能である。ＰＰＣモジュール１１０２を含む統計分析／工程管理フレームワークの実施形態４００は、全てのセットアップパラメータが適正であるようにすることにより、歩留まりを改善する一方法を提供することが可能である。低歩留まりロットの多くは、プローブカードの摩耗（例えば、タッチダウン）、正しくない検査プログラム、ハンドリング装置の不調、ファームウェアの不調などのような、単純な問題に起因することが判明する可能性がある。従って、統計分析／工程管理フレームワーク４００は、ロットの開始時にこれらのパラメータをチェックすることにより、出費のかさむ検査ミスを回避することが可能である。

本明細書に記載の統計的工程管理方法は、検査工程の問題を、それらが検査セルのスループットに影響を及ぼしうる前に早期識別する効果的な方法を提供することが可能である。本明細書に記載のモジュール式フレームワークは、検査セル制御装置１０２上でウエハソート時又は最終検査時にＳＰＣルールを実施することに関連付けられた課題に対処することが可能である。モジュール式のアプローチの為、既存の検査セルと協働する機能により、要因統合及びカスタマイズにおいて高レベルの柔軟性が得られる。統計分析／工程管理フレームワーク４００の一例示的実施形態は、製造検査の監視及び制御を効果的に行うことが可能であり、又、新しい検査対象デバイスの特性化を、そのようなデバイスの増産フェーズの間に行うための、ＭＶＭモジュール４１２のようなツールを提供することも可能である。

ＳＰＣルールは、自動検査装置環境のリアルタイム制御を提供することが可能である。ＳＰＣルールは、装置の、最適レベルへの自動調整を提供することが可能である。例えば、検査結果が適合／不適合基準に適合する可能性があっても、ＳＰＣルールの下では、未だ不適合レベルには達していない、品質の下降傾向が検出されると、所望の最適レベルに達するように調整が行われることが可能である。

従って、本明細書に記載の例示的統計的工程管理方法は、単純な適合／不適合検査以上のことを行うために使用されてよい。統計分析／工程管理フレームワーク４００は、工程パラメータが正常値からどれだけ離れて動いているかを定量的に測定する方法を提供する。適合／不適合検査の場合は、単純に白か黒かの答えが得られるだけであるが、上述の統計的工程管理方法の場合は、実際に何が起こっているかについてのグレイスケールの答えが得られる。統計分析／工程管理フレームワーク４００の例示的実施形態は、上述の統計的工程管理方法を実施するのに必要なモジュールを提供し、オーバヘッドが無視できる形式でこの方法を実施する。更に、アプリケーションモデルを変更したり、カスタムのプローバ又はハンドラのドライバ、又はフック関数を書いたりすることなく、例示的リアルタイム統計的工程管理及びアクションが施されてよい。

例示的統計分析／工程管理フレームワークの、ＭＶＭモジュール４１２、ビン管理モジュール４１０、及びプローバ／ハンドラスーパバイザ４１４などのモジュールは、工学的特性化の間に、それぞれ、クリティカル値の検査、ビン結果の監視、及びインタラクティブモードでのプローバ１０８の使用の為に使用されてもよい。本明細書に記載されるように、統計分析／工程管理フレームワーク４００の実施形態は、各モジュールにアクセスする為のグラフィカルユーザインタフェース、工程管理ルール（及びそれらのパラメータ）にインタラクティブにアクセスしてカスタマイズする為のグラフィカルユーザインタフェース、並びに、ウエハ又は他の検査対象デバイスがまだ動作している間に結果をインタラクティブに照会する為のグラフィカルユーザインタフェースを提供してもよい。

検査セル制御を説明するアルゴリズム及び構造：
決定木の作成に使用されるＳＰＣルール（管理ルール及びアクション）を作成及び定義する為のアルゴリズム及び構造が提供される。一例示的実施形態では、複数のＳＰＣルールが決定木にまとめられてよく、作成され、且つ／又は、たどられるアルゴリズムは、ＳＰＣルールの検証がいつ行われるか、並びに、ＳＰＣルールに不適合の場合のアクションの実行順序を決定してよく、それによって、よりクリティカルな、又はより優先度の高いＳＰＣルールの不適合／違反に対するアクションが最初に行われる。一例示的実施形態では、決定木は、製造のトラブルシューティングの為のモデリングプロセスを最もよく記述できる複合形式で実行されてよい複数のＳＰＣルールを含んでよい。例えば、複数のＳＰＣルールが一緒に実行されてよく、これにより、連続するビン不適合のＳＰＣルールが、針の清掃、及び、その後の、既知の良好なダイの再検査と結合されてよい。

一例示的実施形態では、ＳＰＣルールの定義は、複数の目的に応えるべく、データベース４１６において集中的に格納及び管理されてよい。例えば、ＳＰＣルールは、長ループ形式又は短ループ形式で実行されてよい。一例示的長ループ形式では、ＳＰＣルール実行の履歴分析を用いて、ランタイム用の最適なＳＰＣルールセット（並びに、選択されたＳＰＣルールセットの最適順序、並びにＳＰＣルールの最適組み合わせ）が定義されてよい。一例示的実施形態では、履歴分析は、シミュレーション用のランタイム環境を正確に記述することが可能である。更に、履歴分析は、リアルタイム装置上でのランタイム実行に関連付けられたメリットの予測数値の計算を含んでよい。一例示的実施形態では、ＳＰＣルールは、履歴データがあたかもリアルタイムデータであるかのように、履歴データに対して実行されてよい。これらのシミュレーション結果に基づいて、ＳＰＣルールは、製造検査における実行が可能となるように、最適に改良されてよい。

一例示的実施形態では、ＳＰＣルールを定義及び記述する構造が使用されてよい。特定のＳＰＣルールに対する監視入力として、データソース（パラメータ）が定義されてよい。次に、それらの監視入力を使用するルール（統計及び関数）が定義されてよい。ルール結果に基づいてアサートされるアクション及びイベントが定義されてよい。一例示的実施形態では、構造は、ルール対アクションに対してソースの多対多関係を定義するように柔軟であってよい。一例示的実施形態では、決定木は、複数のＳＰＣルールを含んでよく、これらのＳＰＣルールは、最適な組み合わせでロードされてよく、ランタイムにおいて最適なシーケンスで実行されてよい。一例示的実施形態では、ＳＰＣルール違反が検出された場合に、ＳＰＣルール構造を用いて、自動アクション及び装置を正常動作にリカバリすることが行われてよく、これは、装置を正常動作に戻す試みに使用されてよい、ＳＰＣルールとアクションの最適な組み合わせを使用して行われる。

一例示的実施形態では、ＳＰＣルール構造は、ランタイムにおいて実行されてよい。そのような構造は、ランタイムにおいて実行される場合には、任意のＳＰＣルール違反の深刻度を定義してよく、且つ、ＳＰＣルール違反が発生した場合に決定される管理優先度を定義してよい。最後に、ＳＰＣルール構造は、他の制御エンティティとの競合を回避することが可能である。例えば、ＳＰＣルールは、装置メンテナンスアクションの実行をアサートしてよいが、検査セルが、要求されたメンテナンスイベントを自動スケジュールどおりに実施したばかりの場合、要求されたアクションは実施されない（これは、自動スケジュールどおりに既に実施されている為である）。

一例示的実施形態では、統計的工程管理ルールは、ハンドリング装置１０６のプローバ１０８及びハンドラ１１０に対するコマンドのスケジュールを動的に調節することにも使用されてよい。例えば、プローバの針の清掃のスケジュールを動的に調節することが可能であり、これは、針の清掃を固定的な様式で実施すること（例えば、針の清掃をダイ５０枚ごとに行うことなど）とは異なる。そのような静的なスケジュールは、最適ではない可能性がある。針の清掃が過度に頻繁に行われると、針があまりに早く摩耗するが、清掃が十分な頻度で行われないと、針の上に異物がたまるおそれがある。統計分析／工程管理による管理を行うと、針の清掃が、硬直したスケジュールに従うのではなく、最適な様式で実施可能になる。同様に、検査終了通知などのイベント通知を状態機械モジュール４０６が受信すると、状態機械モジュール４０６は、現時点がＳＰＣルールの検証を行う妥当なタイミングであると判断してよい。従って、状態機械モジュール４０６は、ＳＰＣルールトリガをＳＰＣモジュール４０８に送信してよく、その結果、ＳＰＣモジュール４０８は、ＳＰＣモジュール４０８によって受信されたイベント通知の分析によって決定されるとおりに、検証対象として選択されたＳＰＣルールを（単独で、又は組み合わせで）実行開始する。

図１２は、ＳＰＣルールを選択して決定木の形に並べ、決定木においてＳＰＣルールを（単独で、且つ、組み合わせで）実行し、ＳＰＣルールに不適合の場合にアクションを実行するプロセスの各ステップを示す。図１２のステップ１２０２で、ＳＰＣルールのリポジトリがアクセスされ、複数のＳＰＣルールが選択される。選択されたＳＰＣルールは、決定木の形に並べられてよい。選択されたＳＰＣルールは、決定木の形に並べられると、決定木の並び、及び受信されたイベント通知の分析によって決定されるとおりに実行されてよい（例えば、検証対象として選択されたＳＰＣルールは、（単独で、又は組み合わせで）検査セルイベントに基づいて選択され、最適順序で実行されてよく、各ＳＰＣルールの不適合の優先度によって決定される順序で、任意の必要なアクションが実行されてよい）。

図１２のステップ１２０４で、要求された、検査結果の統計分析が受信される。各ＳＰＣルールは、１つ以上の、検査結果の統計分析を選択してよい。要求された統計分析は、対応するＳＰＣルールの検証に関して評価される。本明細書に記載されるように、ＳＰＣルールの検証が（単独で、又は組み合わせで）行われるのは、検査結果及び受信されたイベント通知によって決定されるとおりに、検査進捗間隔が、規定された限界に達してからである。

図１２のステップ１２０６で、ＳＰＣルールは、受信された、検査結果の１つ以上の統計分析に対して、それぞれの定義された評価を実施する。例えば、測定値モニタ４１２によって実施される統計的検査は、所望の統計的検査に合わせて定義及び／又は編集されてよい。統計的検査は又、対応する間隔閾値への到達、及び／又はイベント通知の時点で、ＳＰＣルールの検証に関して行われる。本明細書に記載されるように、実施される統計的検査は、定義された、ＳＰＣルールの組み合わせに関してであってよい。

図１２のステップ１２０８で、ＳＰＣルールは、それらの１つ以上の関連付けられた統計分析の評価に応じて、実行されるべきアクションを選択してよい。例えば、本明細書に記載されるように、ＳＰＣルールの検証が行われ、不適合となった場合は、関連付けられたアクションが実施されてよい。一例示的実施形態では、複数のＳＰＣルールに不適合となった場合、優先度が最も高いＳＰＣルールのアクションが最初に実行されてよい。

検査セル制御装置の為の決定木の作成及びスケジューリング：
図１３に示されるように、検査セル制御装置１０２の一例示的実施形態では、ＳＰＣルールの実行の為の決定木が作成され、スケジュールされ、実行されてよい。一例示的実施形態では、遅延の短縮が行われてよく、これは、ＳＰＣルールの実行及びアクションを、ハンドリング装置１０６のプローバ１０８又はハンドラ１１０の動作と同期させることにより、行われてよい。図１３に示されるように、一例示的実施形態では、デバイスに対する検査１３０２の実行の合間に、検査が非アクティブな時間帯、例えば、プローバ及びハンドリング装置の割り出し時間１３０４が識別されてよい。一例示的実施形態では、割り出し時間は、４００ミリ秒から６００ミリ秒続く。ＳＰＣルールで構成される決定木の作成、スケジューリング、及び／又は実行が行われてよいのは、これらの検査が非アクティブな時間帯（例えば、割り出し時間）１３０４の間である。図１３に示されるように、ＭＶＭキャプチャ１３０６、ＳＢＣキャプチャ１３０８、ＰＰＣ及びＳＰＣルール実行１３１０、及び後続の、ＳＰＣルールによって開始されるアクション（例えば、プローバ１０８及びハンドラ１１０のアクション）１３１２が、検査が非アクティブな時間帯（例えば、割り出し時間）１３０４の間に実施されてよい。

本明細書に記載されるように、一例示的「割り出し時間」は、最後の検査フローの終了から新しい検査フローの実行開始までの間の合計時間である。この時間は、デバイスの電源オフ、ビニングなどの様々な動作を含んでよい。一例示的実施形態では、１つ１つのデバイスにおいて、ウエハソート時の割り出し時間は、プローブ１０８をウエハ上のあるＸＹ位置から同ウエハ上の別のＸＹ位置に位置付けること、並びに、次の検査実行の準備をするよう検査制御装置に伝えることの為にかかる時間である。最後の検査では、割り出し時間は、パッケージをソケットから取り外すこと、取り外したパッケージを良品／不良品トレイに入れ、新しいパッケージをソケットに挿入すること、並びに、パッケージの検査準備ができたことを検査機に伝えることの為にハンドラ１１０が費やす必要がある時間である。

一例示的実施形態では、ＳＰＣルールの実行の遅延を短縮する為の格好の計算窓が識別されてよく、これにより、低遅延、且つ、連続する検査工程に対するオーバヘッド又は検査時間の影響がほぼゼロの状態で、決定木を実行することが可能である。例えば、決定木におけるＳＰＣルールの実行は、現在の検査工程のアイドル時間の間に行われてよい。例えば、図１３に示されるように、ＳＰＣルールは、プローバ及びハンドリング装置の割り出し時間の間に実行されてよい。ＳＰＣルールの検証は、検査アクティビティが少ない時間帯に行われてよく、これによって、検査結果の分析（例えば、結果計算）は、検査監視（例えば、検査計算）が行われていない時間帯に行われてよい。計算窓の識別及び定義が行われてよく、これによって、計算窓の開閉タイミングが識別されてよい。計算窓の定義（例えば、計算窓の開始時間及び停止時間）を用いて、決定木の作成及び実行を停止させたり、遅延させたり、同期させたりしてよい。

一例示的実施形態では、計算窓の定義は、イベントスケジューリングを含む。イベントスケジューリングは、他の材料が位置的にどこにあるかについてのイベント情報を収集することにより、決定木の同期化された作成及び実行が可能な窓を決定する為に、マテリアルハンドリング装置１０６と通信することを含んでよい。一例示的実施形態では、ステッピングイベントの変動性（例えば、ウエハソート時、ウエハ終了時等におけるＸ軸対Ｙ軸のステッピングの変動性）を調べて、格好の計算窓を予測的に決定してよい。

識別された計算窓における決定木の作成及び実行は、統計分析／工程管理フレームワークの例示的実施形態の、適応検査プログラム環境を提供する能力を向上させることが可能である。この検査プログラム環境は、工程ずれの検出及び防止を行うことが可能であり、製品の流れに対してアラートしたり、停止をかけたり、自動的にアクションを引き起こしたりすることにより、「不良」製品の発生を回避することが可能である。一例示的実施形態では、動作中の生産工程内の計算窓において、診断プロシージャなどの自動メンテナンスを実行してよく、これにより、メンテナンス及び修理の工程の結果を改善することが可能である。

一例示的実施形態では、決定木の作成及び実行は、その検査セル内での他の処理と並行して行われてよい。例えば、計算窓は、上述のように、任意のプローバ／ハンドラスーパバイザ４１４によって開始されるホールドと同時に発生してよい。

図１４は、計算能力が増強される、識別された計算窓において、決定木を作成及び実行するプロセスの各ステップを示す。図１４のステップ１４０２で、計算窓が特定される。一例示的実施形態では、計算窓は、計算能力が増強される時間帯である。本明細書に記載されるように、計算能力が増強される時間帯は、プローバ／ハンドリング装置の割り出し時間などの、検査が非アクティブな時間帯と一致してよく、或いは、本明細書に記載された、他の、検査アクティビティが少なくなる時間帯にあってよい。一例示的実施形態では、計画又は予想された検査アクティビティに基づいて、計算窓が識別される。

図１４のステップ１４０４で、計算能力が増強される、識別された計算窓において、決定木が作成される。一実施形態では、計算能力が増強される時間帯は、検査アクティビティが少なくなる時間帯と一致する。

図１４のステップ１４０６で、検査アクティビティが少なくなる時間帯と一致する、計算能力が増強される、識別された計算窓において、決定木が実行される。一実施形態では、決定木の実行は、決定木が作成された計算窓と異なる計算窓において行われてよい。一例示的実施形態では、決定木の実行は、検査データの取得、検査データの統計分析、及び、検査データの統計分析を受けてのアクションの実行のうちの少なくとも１つを含む。

ＰＨスーパバイザモジュール及びプロキシＰＨドライバ：検査セルの動作を乱すことなく、制御又はデータ収集を挿入するインタポーザ：
図１５に示されるように、プローバ／ハンドラスーパバイザ４１４は、検査セルの動作にアクション又はデータ収集を挿入するインタポーザとして使用されてよい。本明細書に記載されるように、一例示的実施形態では、プローバ又はハンドラのコマンドは、生産工程に挿入されてよく、このコマンドは、検査セルを乱すことなく、シームレスに挿入される。図１５に示されるように、検査プログラム１０３は、関数呼び出しを送信し、返信として、プロキシプローバ／ハンドラドライバ１５０２から応答を受信する。関数呼び出しが受信されると、関数呼び出しは、プロキシＰＨドライバ１５０２からプローバ／ハンドラスーパバイザ４１４に転送されてよく、プローバ／ハンドラスーパバイザ４１４では、制御コマンド及び他のステータス要求通信が、カスタム又は標準のＰＨドライバライブラリ１５０４を介してマテリアルハンドリング装置１０６のプローバ１０８又はハンドラ１１０に伝達されてよい。一実施形態では、制御コマンド及びステータス要求通信は、ＧＰＩＢコマンドである。一例示的実施形態では、制御コマンド及びステータス要求通信は、ＧＰＩＢ、ＲＳ−２３２、ＬＡＮ等のようなバスを介して送信されてよい。

図１５に示されるように、状態機械４０６と検査セルＡＰＩ１５０８との間に、検査実行サーバ１５０６が置かれてよい。一例示的実施形態では、状態機械４０６は、検査実行サーバ１５０６を通して、検査セルＡＰＩ１５０８にアクセスしてよい。又、これも図１５に示されるように、アラーム及びイベントが、検査実行サーバ１５０６を通り抜けて、状態機械４０６に渡されてよい。言い換えると、検査実行サーバ１５０６は、検査セルＡＰＩ１５０８を、検査セルの各モジュールからの直接アクセスから隔離する為に使用されてよい。一例示的実施形態では、検査実行サーバ１５０６は、状態機械と検査セルＡＰＩ１５０８との間のインタフェースとしての役割を担う。検査実行サーバ１５０６によってアラーム及びイベントが受信されてよく、その後、検査実行サーバ１５０６は、それらを、状態機械４０６及び検査セルアーキテクチャ内の他のモジュールにディスパッチする。

コマンドを挿入することができない一実施形態では、検査プログラム１０３のアプリケーションモデルが、マテリアルハンドリング装置１０６（例えば、プローバ１０８又はハンドラ１１０）と直接通信するライブラリドライバを呼び出す。従って、例示的実施形態では、プロキシライブラリ１５０２が設置され、検査プログラム１０３のアプリケーションモデルが、プロキシライブラリ１５０２において、ドライバライブラリを探索する。一実施形態では、プロキシライブラリ１５０２は、検査プログラム１０３のアプリケーションモデルからは、従来型のライブラリと同様に見えるであろう。本明細書に記載されるように、プロキシライブラリ１５０２は、検査セル通信フレームワークを使用して、コマンドをアプリケーションモデルからプローバ／ハンドラスーパバイザ４１４に転送してよく、プローバ／ハンドラスーパバイザ４１４は、受信されたコマンドを、カスタム又は標準のＰＨライブラリ１５０４により実行してよい。

図１５に示されるように、（検査プログラム１０３だけではない）統計分析／工程管理フレームワーク４００のモジュールによって、追加のプローバ又はハンドラのコマンドが開始されてよい。一実施形態では、この追加のプローバ又はハンドラのコマンドは、状態機械モジュール４０６によって開始される。本明細書に記載されるように、そのような追加のプローバ又はハンドラのコマンドは、ＳＰＣルールの違反又は不適合が検出された場合にＳＰＣルールによって開始されるアクションであってよい。本明細書に記載されるように、ＳＰＣルールによって開始されるアクション、例えば、ｚ高さ調節や針の清掃は、検査動作の中に透過的に挿入されてよい。一例示的実施形態では、ＳＰＣルールによって開始されるアクションが所定の時間（例えば、次の検査対象個体を取り出すハンドラ動作の間）に実施される必要がある場合、ＰＨスーパバイザ４１４は、ＳＰＣから要求されたアクションが完了するまで、検査セル動作の中にホールドを挿入してよい。そのようなホールドは、検査プログラム１０３からの更なる何らかの関数呼び出しがマテリアルハンドリング装置１０６（例えば、プローバ１０８及び／又はハンドラ１１０）に伝達されることを防ぐ。一例示的実施形態では、検査セルが、針の清掃や、他のハンドリング装置の機能を実施する周期的なコマンドを発行してよい為、本明細書に記載されるように挿入されたコマンドは、それらを避けてスケジュールされるか、且つ／又は、コマンドのスケジューリングを考慮に入れてよく、これによって、ＳＰＣルールによって開始されるアクションが、スケジュールされた、検査セルによって開始されるコマンドを繰り返すことはない。

図１５に示されるように、一例示的ＰＨスーパバイザ４１４は、状態機械４０６を検査プログラム１０３の実行に同期させてよく、これは、アプリケーションモデルからの、プローバ又はハンドラ装置のドライバ呼び出しの実行と同期させることにより、行われてよい。状態機械モジュール４０６と検査プログラム１０３は同期されてよく、これは、状態機械４０６が、ＳＰＣルールによって開始されるアクションを実行することと、必要に応じてＰＨスーパバイザ４１４内のＰＨドライバライブラリにアクセスすることと、が可能であるように、検査プログラムによって開始されるＰＨ呼び出しをホールドすることによって行われてよい。ＰＨスーパバイザ４１４は、ＳＰＣルールによって開始されるアクションが、ｚ高さ調節、針の清掃、及びステータスの照会と制御を行うことを可能にしてよい。一例示的実施形態では、ＰＨスーパバイザ４１４は、状態機械４０６を検査プログラム１０３の実行に同期させてよく、これは、検査プログラム１０３のアプリケーションモデルからの、プローバ又はハンドラ装置のドライバ呼び出しの実行と同期させることにより、行われてよい。この同期は、状態機械４０６が、プローバ／ハンドラ割り出し時間（例えば、ハンドリング装置１０６が、ウエハソート時にプローバ１０８を再配置したり、最終検査時に次の検査対象デバイスを取り出したりすることなどによって、次の検査フローの準備をしている間の、検査が非アクティブな時間帯）の間に、ＳＰＣルールのチェック及びＳＰＣルールによって開始されるアクションを実行することを可能にしてよい。

一例示的実施形態では、一例示的ＰＨスーパバイザ４１４が、表９にリストされた機能を実施することが可能である。

図１５に示されるように、検査プログラムのアプリケーションモデルは、通常のＰＨドライバ関数を呼び出す場合と同様に、プロキシＰＨドライバ１５０２関数を呼び出してよい。言い換えると、検査プログラムのアプリケーションモデルは、そのコマンドが、ＰＨドライバライブラリ１５０４によって直接受信される代わりに、プロキシＰＨドライバ１５０２によって受信されてＰＨドライバライブラリ１５０４に渡されることを認識しない。プロキシＰＨドライバ１５０２は、ＩＰＣメッセージキューを用いて、ＰＨスーパバイザ４１４に関数実行要求を渡してよい。ほとんどの場合、ＰＨスーパバイザ４１４は、カスタム又は標準のＰＨドライバライブラリ１５０４の中の一致する呼び出しを実行してよい。一例示的実施形態では、プロキシＰＨドライバライブラリ１５０２は、アプリケーションモデルによってロードされ、ハンドラ及びプローバの両方のドライバの為の全ての関数呼び出しのスーパセットを有する。

一例示的実施形態では、ＰＨスーパバイザ４１４の動作は、検査セルの実行にオーバヘッドを追加しない。この為、プローバ又はハンドリング装置の割り出し時間のような検査一時停止中（例えば、ハンドリング装置１０６が、ウエハソート時にプローバ１０８を再配置したり、最終検査時に次の検査対象デバイスを取り出したりすることなどによって、次の検査フローの準備をしている間の、検査が非アクティブな時間帯）に、（検査プログラムからの）ＰＨ呼び出しに対するホールドが行われてよい。一例示的実施形態では、次のパッケージ又はダイをロードするＰＨドライバ呼び出しが、ホールド状態に置かれてよい。一実施形態では、ＰＨスーパバイザ４１４のオーバヘッドは、極端に小さく、例えば、１つの呼び出しにつき２００マイクロ秒のオーダーである。

物理的アクション（例えば、針の清掃等）を行う決定は、最適なタイミングで実行される必要がある。本明細書に記載されるように、要求された物理的アクションによって生産システムのパフォーマンスが最適レベルになるように、通常の検査工程は、一時的にホールド状態に置かれてよい。一例示的介入（例えば、物理的アクションの挿入）によって検査が潜在的に低速になる可能性があるが、工程を修正するか、不適正な検査、又は不良コンポーネントに対する不要な追加検査が行われないようにすることにより、その後の検査が改善される。本明細書に記載されるように、例示的実施形態の１つの目的は、生産を最適化することであり、これは、ＳＰＣルールをカスタマイズし、決定木を構築し、検査アクティビティが少なくなる所望の時間帯に決定木を実行し、且つ、プローバ及びハンドラのコマンドを透過的に挿入することによって行われ、その際、プログラミングモデルは、その装置ハンドラコマンドに対するホールドを認識していない。

図１６は、ＡＴＥ検査セルによって実行される検査フローの一例示的フロー図を示す。図１６のステップ１６０２で、デバイス検査が開始される。図１６のステップ１６０４で、次の検査対象ダイを取得するコマンドが実行される。本明細書に記載されるように、要求は、ＰＨスーパバイザ４１４に伝達され、この時点で、図１６のステップ１６０６に示されるように、プローバ又はハンドラのコマンドは、ＳＰＣルールによって開始されるアクションが実行される間は、ホールド状態に置かれてよい。ＳＰＣルールによって開始されるアクションが完了したら、ＰＨスーパバイザ４１４によってホールドが解除されてよく、ＰＨコマンドが転送され、次の要求されたダイが取り出される。図１６に示されるように、検査フローは、ステップ１６０６からステップ１６０４に戻る。図１６のステップ１６０４に戻って、ダイ取得コマンドが完了したら、図１６のステップ１６０８において検査工程が続行され、新たに配置されたダイに対して検査が開始される。図１６のステップ１６１０で、ハンドリング装置１０６のプローバ１０８及びハンドラ１１０が割り出し時間に入る。本明細書に記載されるように、割り出し中は検査アクティビティが少なくなり、それだけ利用できる計算能力が高くなるので、そのような割り出し時間を利用して、ＳＰＣルール処理が実施されてもよい。図１６のステップ１６１２で、現在のダイに対する検査が完了し、検査終了コマンドが起動され、現在のダイが次の検査対象ダイと交換されて、処理がステップ１６０２に戻る。

図１７は、検査プログラムによって開始されるプローバ又はハンドラのコマンドの中に、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドを透過的に挿入するプロセスを示す。図１７のステップ１７０２で、検査プログラムによって開始されるプローバ又はハンドラのコマンドが生成され、ＰＨスーパバイザ４１４に送信される。

図１７のステップ１７０４で、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドが生成され、ＰＨスーパバイザ４１４に送信される。一例示的実施形態では、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドは、工程管理ルールに不適合の場合（例えば、「追加の」プローバ又はハンドラのコマンドがあった場合）に、生成され、送信されてよい。

図１７のステップ１７０６で、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドの実行を予期して、検査プログラムによって開始されるプローバ又はハンドラのコマンドは、ＰＨスーパバイザ４１４によって、ホールド状態に置かれる。一例示的実施形態では、ＰＨスーパバイザ４１４によってホールド状態に置かれることは、状態機械モジュール４０６の指示によって行われる。図１７のステップ１７０８で、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドが実行される。一例示的実施形態では、ＳＰＣルールによって開始されるプローバ又はハンドラのコマンドの実行、並びに、検査プログラムによって開始されるプローバ又はハンドラのコマンドをホールド状態に置くことは、検査プログラム１０３に対して透過的である。

本明細書では特定の好ましい実施形態及び方法を開示してきたが、当業者であれば上述の開示から明らかなように、本発明の趣旨及び範囲から逸脱しない限り、そのような実施形態及び方法の変形や修正が行われてよい。本発明は、添付の特許請求の範囲並びに準拠法の規定及び原則によって要求される範囲までに限り、限定されるものとする。

Claims (20)

1. デバイスを検査する装置であって、
   第１のプローバ及びハンドラ（ＰＨ）要求を生成してスーパバイザモジュールに送信するように動作可能な検査制御モジュールであって、前記スーパバイザモジュールは、第１のＰＨコマンドをその実行の為にプローバ及びハンドラに送信するように動作可能である、前記検査制御モジュールと、
   第２のＰＨ要求を生成して前記スーパバイザモジュールに送信するように動作可能な検査分析モジュールであって、前記スーパバイザモジュールは更に、第２のＰＨコマンドをその実行の為に前記プローバ及びハンドラに送信するように動作可能であり、前記第２のＰＨコマンドの実行は、前記検査制御モジュールに対して透過的に行われる、前記検査分析モジュールと、を備え、
   前記検査制御モジュールは、前記デバイスの検査に応じた検査結果を生成するように動作可能であり、
   前記検査分析モジュールは、前記検査分析モジュールによってアクセスされた検査結果の検査分析を実施するように動作可能である、
   装置。
2. 前記第２のＰＨ要求は、前記検査結果の前記検査分析に対する応答として生成される、請求項１に記載の装置。
3. 前記第１のＰＨ要求は、１つ以上のデバイスの検査中に生成される、請求項１に記載の装置。
4. 前記スーパバイザモジュールは更に、第２のＰＨコマンドが前記プローバ及びハンドラによって実行されている間に受信された第１のＰＨ要求があれば、前記受信された第１のＰＨ要求に対してホールドを生成するように動作可能である、請求項１に記載の装置。
5. 第１のＰＨ要求に対するホールドは、新しいロットのロード、ウエハの切り替え、ダイの切り替え、ＸＹ位置の切り替え、及び検査制御モジュールによって開始される一時停止アクションのうちの少なくとも１つに対するホールドを含む、請求項４に記載の装置。
6. 前記第１のＰＨコマンドは、プローバ及びハンドラの制御コマンド、並びにステータス照会のうちの少なくとも１つを含む、請求項１に記載の装置。
7. 前記第２のＰＨコマンドは、ｚ高さ調節コマンド、針の清掃コマンド、ステータス照会、並びに、プローバ及びハンドラの制御コマンドのうちの少なくとも１つを含む、請求項１に記載の装置。
8. デバイスを検査する方法であって、
   第１のプローバ及びハンドラ（ＰＨ）コマンドを生成し、実行の為にプローバ及びハンドラに送信するステップであって、前記第１のＰＨコマンドは、検査制御モジュールであって前記デバイスの検査に応じた検査結果を生成するように動作可能な前記検査制御モジュールからの第１のＰＨ要求に対する応答として生成される、前記ステップと、
   第２のＰＨコマンドを生成し、実行の為に前記プローバ及びハンドラに送信するステップであって、前記第２のＰＨコマンドは、検査分析モジュールであって当該検査分析モジュールによってアクセスされた検査結果の検査分析を実施するように動作可能である前記検査分析モジュールからの第２のＰＨ要求に対する応答として生成され、前記第２のＰＨコマンドの実行は、前記検査制御モジュールに対して透過的に行われる、前記ステップと、
   を含む方法。
9. 前記第２のＰＨコマンドの実行は、前記検査制御モジュール及び前記検査分析モジュールと前記プローバ及びハンドラとの間に置かれたスーパバイザモジュールによって、前記検査制御モジュールに対して透過的に行われ、前記スーパバイザモジュールは、受信された第１及び第２のＰＨ要求に対する応答として第１及び第２のＰＨコマンドを送信する、請求項８に記載の方法。
10. 第２のＰＨコマンドが前記プローバ及びハンドラによって実行されている間に前記スーパバイザモジュールによって受信された第１のＰＨ要求があれば、前記受信された第１のＰＨ要求に対してホールドを生成するステップを更に含む、請求項９に記載の方法。
11. 第１のＰＨ要求に対するホールドは、新しいロットのロード、ウエハの切り替え、ダイの切り替え、ＸＹ位置の切り替え、及び検査制御モジュールによって開始される一時停止アクションのうちの少なくとも１つに対するホールドを含む、請求項１０に記載の方法。
12. 前記検査分析モジュールによってアクセスされた検査結果の検査分析を実施するステップを更に含み、前記第２のＰＨ要求は、前記検査結果の前記検査分析に対する応答として生成される、請求項８に記載の方法。
13. デバイスの検査中に検査結果を生成するステップを更に含み、前記第１のＰＨ要求は、１つ以上のデバイスの検査中に生成される、請求項８に記載の方法。
14. 前記第１のＰＨコマンドは、プローバ及びハンドラの制御コマンド、並びにステータス照会のうちの少なくとも１つを含む、請求項８に記載の方法。
15. 前記第２のＰＨコマンドは、ｚ高さ調節コマンド、針の清掃コマンド、ステータス照会、並びに、プローバ及びハンドラの制御コマンドのうちの少なくとも１つを含む、請求項８に記載の方法。
16. コンピュータで実行可能な命令が格納されたコンピュータ可読媒体であって、前記コンピュータで実行可能な命令は、
    第１のプローバ及びハンドラ（ＰＨ）コマンドを生成し、実行の為にプローバ及びハンドラに送信する命令であって、前記第１のＰＨコマンドは、検査制御モジュールであってデバイスの検査に応じた検査結果を生成するように動作可能な前記検査制御モジュールからの第１のＰＨ要求に対する応答として生成される、前記命令と、
    第２のＰＨコマンドを生成し、実行の為に前記プローバ及びハンドラに送信する命令であって、前記第２のＰＨコマンドは、検査分析モジュールであって当該検査分析モジュールによってアクセスされた検査結果の検査分析を実施するように動作可能である前記検査分析モジュールからの第２のＰＨ要求に対する応答として生成され、前記第２のＰＨコマンドの実行は、前記検査制御モジュールに対して透過的に行われる、前記命令と、
    を含む方法を含む、コンピュータ可読媒体。
17. 前記第２のＰＨコマンドの実行は、前記検査制御モジュール及び前記検査分析モジュールと前記プローバ及びハンドラとの間に置かれたスーパバイザモジュールによって、前記検査制御モジュールに対して透過的に行われ、前記スーパバイザモジュールは、受信された第１及び第２のＰＨ要求に対する応答として第１及び第２のＰＨコマンドを送信する、請求項１６に記載のコンピュータ可読媒体。
18. 前記方法は更に、第２のＰＨコマンドが前記プローバ及びハンドラによって実行されている間に前記スーパバイザモジュールによって受信された第１のＰＨ要求があれば、前記受信された第１のＰＨ要求に対してホールドを生成する命令を含み、第１のＰＨ要求に対するホールドは、新しいロットのロード、ウエハの切り替え、ダイの切り替え、ＸＹ位置の切り替え、及び検査制御モジュールによって開始される一時停止アクションのうちの少なくとも１つに対するホールドを含む、請求項１７に記載のコンピュータ可読媒体。
19. 前記方法は更に、
    前記検査分析モジュールによってアクセスされた検査結果の検査分析を実施する命令であって、前記第２のＰＨ要求は、前記検査結果の前記検査分析に対する応答として生成される、前記命令と、
    デバイスの検査中に検査結果を生成する命令であって、前記第１のＰＨ要求は、１つ以上のデバイスの検査中に生成される、前記命令と、
    を含む、請求項１６に記載のコンピュータ可読媒体。
20. 前記第１のＰＨコマンドは、プローバ及びハンドラの制御コマンド、並びにステータス照会のうちの少なくとも１つを含み、前記第２のＰＨコマンドは、ｚ高さ調節コマンド、針の清掃コマンド、ステータス照会、並びに、プローバ及びハンドラの制御コマンドのうちの少なくとも１つを含む、請求項１６に記載のコンピュータ可読媒体。

Images