STMicroデータの追跡DOEのアイデア<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />STMicroelectronicデータセットのための妥当なフォローアップDOEのためのいくつかのアイデアを探しています。これは「生産性の高いDOE /ホリスティックDOEを可能にするデータマイニング」のテーマになります。
データセットが添付されています。基本的に行くなら Explore / Screen / Experimentの総合的なDOEアプローチを通じて、応答に関連する重要なパラメトリックテストがいくつかあることがわかります。logBin10の失敗。情報が不足しているBootstrap Forestを使用すると、すぐに606 PTのパラメータを選択して、支配的な障害モードの存在を最もよく表すものを見つけることができます。
データセットには分割変数もあります。これは、これらのチップの製造に使用される機器の一部です。そして、あなたが見ているのは、分割が失敗にも関連しているということです。
したがって、これらのデータから、プライマリ故障BINに関連する一連のPTパラメータが得られます。これは、製造プロセスの早い段階でPTが実行され、電気ウェハのソートに失敗するチップに早期警告を発するため、エンジニアにとって役立ちます。（そして、私たちが今行ったデータマイニングのため、彼らはこれらのパラメータの4〜5の値を監視するだけで失敗の可能性をよく知ることができます）。
しかし、ここで学ぶ機会がもっとあるように思われます、そしてこのデータマイニングの練習は組織が何が起こっているのかをよりよく理解することができるもっと制御された実験にうまく導くはずです。分割が製造工程で問題を引き起こしているならば、他に何がここで働いているかもしれませんか？
データマイニングはおそらく症状に関するもので、製造プロセスの根本的な原因ではないようです。しかし、PTパラメーターを必ずしも要因として使用してフォローアップDOEを設定する必要はないでしょうか。それは、EWSの失敗を引き出すために、PT上で低または高となるチップを意図的に製造することに意味がありますか？意図的にこれらのPTを体系的に変更すると、本番データをマイニングするだけで、原因と結果を検証できます。
ブートストラップフォレストに基づいて、164と451の2つの主要なPT-EWS関係があります。
テストしたい分割と組み合わせると、カスタムデザインを設定できます。これは、2つのPTと分割に対して実行される設計です。
私は、探索する価値があるかもしれないBIN10の失敗に影響を与えているかもしれない他の多くの要因があると思います。ここでの目的は、データ駆動型のDOEの状況では意味のある妥当なフォローアップ設計を作成することです。私はその考えと感謝に感謝します。
再：STMicroデータの追跡DOEのアイデアは？ありがとう、ロバート！あなたの訴訟もまた楽しみにしています。それは私たちがすでに持っているSTのケースをうまく補完するでしょう。スコットと私は先週デンバーで最初のHolistic DOEイベントを開催しました（10月2日）。私は、このSTの訴訟について、上記のフォローアップDOEを提示しました。それはうまくいったようです（実際には、DOEを立ち上げる前に観客の誰かが言った：「私はそれがエッチなステップだと思う」
Spilledは4つの異なるマシンであるという事実には問題ないようでした。私は最も興味深く多様な反応を示したSplit 3だけに注目しました（Split 1と2はBin 10の故障が少なく、Spilled 4はすべて高い故障を持っていたので、調査すべき欠陥のあるデバイスかもしれません）。
それは完璧ではありませんが、それは観客にとってもっともらしいようでした。より多くのフィードバックを得ながら、私はまだケースをもう少し洗練したいと思います。今月開催される残りのイベントでは、その状況がどのように行われるのかがわかります。
再：STMicroデータの追跡DOEのアイデアは？
私はもう一度私のセミデモを見てきました、そして私が現在修正しようとしているそれに関するいくつかの問題があります。主な問題は、Proではなく標準のJMP機能を使用しても同じ答えが得られることです。標準のJMPを使用することは、Proを使用することほど簡単ではありませんが、Proを使用しても、信頼性の高い結果を得るためにさまざまな検証列を切り替えるスクリプトが必要でした。私のセミデモが示している重要なことは、誤検知を抑制したい場合に検証を使用することの重要性です。私がセミデモの問題を克服することに成功したら、私はそれを利用可能にするつもりです。
STのホワイトペーパーでは、S1、S2、S3、S4がどのように分割されているのかわかりません。私は彼らが違うマシンだとは思わない。彼らは、意図的に（あるいは偶然に）プロセス設定やパラメータを変えた「実験」のように思えます。
また、STのホワイトペーパーでは、451ではなく、パラメーター171を使用する最も意味のあるパラメーターとして選択していることにも気付きました。これは、パラメータ171とは何か、そしてそれがプロセス設定やデバイス性能特性にどのように関連するのかをよく理解しているためであると考えられます。彼らは特定のステップでインライン測定します。一方、451はその物理的寸法との関係が明確ではないリーク電流です。
フォローアップ実験に関しては、問題であるドライエッチングプロセスは、ほとんどの半導体のオーディエンスとうまく共鳴するでしょう。ドライエッチングプロセスはしばしば問題があるが、DoEによる調査にも適している。それらにはさまざまな要因があり、多くの場合、プロセスエンジニアはこれらの要因が相互にどのように相互作用してプロセスに影響を与えるのかについて、定量的な理解が十分ではありません。
要因としては、RF電力、バイアス電力、チャンバー圧力、チャック温度などがあります。ヘリウムBSC（裏面冷却） 私は、チャック温度とHe BSCの問題がエッチチャンバー間のキャリブレーションの違いによって引き起こされた2つの異なる歩留まりの問題を知っています。また、「良い」部屋と「悪い」部屋の両方で実験を実行することをお勧めします。
半導体の歩留まりの問題は、以下の例に示すように、STのホワイトペーパーに記載されている「笑顔」のシグネチャのように、ウェハ上に空間パターンを示すことがよくあります。これらのパターンは、問題の原因を突き止める上で、エンジニアにとって重要な手がかりになります。
再：STMicroデータの追跡DOEのアイデアは？これは大きな改善であり、半産業のバックグラウンドが深い誰かが、エッチプロセスのために提案されたDSDで使用するための要因と範囲であなたを導くことができると私は確信しています。
このデモの対象読者の一部が既存のJMPユーザーである場合は、Proで提案されたワークフローがどのように単純であり、JMPよりも優れたソリューションになるかを実証することをお勧めします。たとえば、Fit Y by Xを使用してlog（bin10）と各Xの2変量解析を行い、パラメーター推定値を結合データテーブルに出力する場合は、結合テーブルから切片の項を削除し、p値の昇順で並べ替えます。26、451、183、2、47、164の上位6つのパラメータを取得します。それで、私たちが森の中の木の数について心配する必要がないので、潜在的により簡単なワークフローでJMPと同じ結論に達することはそれほど難しくないようです。STデータを修正して、Fit Y by Xアプローチでは見逃されるがBootstrap Forestでは簡単に捕捉されるような強い相互作用の効果を引き起こす必要があるかもしれません。ターゲットオーディエンスの一部が既存のJMPユーザーである場合、私たちは彼らがJMPで簡単に解決策を再現できないことを示す準備をする必要があると思います。
あるいは、Proが最初にリリースされたときに作成されたセミデモを使用して、上記のFit Y by Xアプローチでは見逃していた3方向の相互作用効果による問題の原因をProが検出した方法を示します。その後、問題を引き起こすように相互作用していた3つの隣接するプロセスステップを中心に、フォローアップ実験を行うことができます。 私はRobertにあなたのデモを転送するように頼みます。
マルコム
再：STMicroデータの追跡DOEのアイデアは？こんにちはマルコム - 回答いただきありがとうございます。再：データテーブルは、私はイアンにそれを信用するつもりです。彼は脚本とマーケティングキャンペーンの短いビデオをまとめて素晴らしい仕事をしました。私は全体的なDOEの文脈の中でそれを単に構築しています。
あなたの特定のポイントに：
1）ランダムシード - 1,000本の木で物事が落ち着いて結果が再現可能になりました - 26、451、164、171がトップ4です。Bootstrap Forestを何度も実行しても、これらの上位4つは今も残ります。だからそれはなされるべき良い変化です。
2）164は間違った方向を向いており、26、451、171とは異なる動作をしているように思われるため、トリッキーです。私が追加するもう一つの素晴らしい追加は、変数のクラスタリングです。これは、データの変動の71％が451パラメータの平均によって説明されることを示しています。
だから私はそれら二つの問題がソートされていると思います。したがって、データマイニングの演習の結論は次のとおりです。
1）ブートストラップフォレストとPCAを使用して、最も代表的なパラメトリックテストの結果（451）とBin10の失敗との間の主要な関連性を見つけました。
2）分割変数は、故障がbin10の故障を引き起こす範囲でパラメトリックテストが高くなる原因となっている機器の一部（スプリット3とスプリット4）が原因であることを示していることもわかりました。
3）これらの事実を踏まえて、応答としてパラメトリックテスト平均を使用してエンジニアに戻り（451_Param_average）、スプリット3機器のエッチングステップを調査するためのDOEを設計できます。
データをシミュレートする限りでは、このパラメーターがどの程度の範囲に入るべきかをほぼ知っていて、451レベルでBin10の失敗率がどの程度になるかをある程度把握することができます。
それで、私はフォローアップデザインのためのもっともらしい入力とレベルのセットを必要とするだけです。
おそらく5因子DSD：
当てはめたときにシミュレートされたデータが次のようになるようにします。
それで、ここでの話は機械に関するものなら何でも - 断続的な液浸速度または平均送り速度を引き起こしている部品またはセンサーの不良または装着（仕様通りに動作している他の分割には存在しない）。高い平均10は高いbin10失敗のための繁栄を引き起こします。
この話とは結婚していませんが、この分野で私より頭の良い人がそれがもっともらしいと思うなら、うまくいく可能性があります。繰り返しになりますが、考えやコメントに感謝します。
再：STMicroデータの追跡DOEのアイデアは？こんにちはダン、
歴史的なデータ分析のためのデータテーブルはプロセスと測定タイプを説明するスクリプトでうまく文書化されて、そして私たちSEが半導体と他の産業の中で容易に複製して届けることができた素晴らしいストーリーラインを与えます。私たちはブートストラップフォレストに使用されたランダムシードが異なる解決策を与えるという通常の問題を得ます。例えば、2回目の試行でlog（Bin10）の上位予測として164_PARAM_AVERAGEを得ました。一貫した結果を得るためにこれを修正する必要があります。ブートストラップフォレスト用のスクリプトにランダムシードを設定できますが、ブートストラップフォレスト用のダイアログを表示できなくなるため、可能であればこれを回避したいと思います。それが問題を解決するのか、それともブーストされたツリーでも解決するかどうかを確認するために、フォレスト内の多数のツリーを試すことは可能ですか？
ご存じのとおり、パラメトリック検定は問題の原因ではなく症状であり、より現実的な次のDOEは、4つのパラメトリック検定の失敗それぞれに責任を持つプロセスステップに焦点を合わせることになるのだろうか。Robertはこれについてあなたを導くことができました、しかし私はそれが高いパラメトリックテスト値と高いパラメトリックテストを引き起こしている特徴の原因であるエッチングステップであるというストーリーで、より信頼できるDOEがエッチングステップの一つにある値はbin10障害を引き起こしています。
マルコム
