従来、同一メインフレーム内または異なるメインフレーム間でのチャンバー構成の比較は、手作業で1日かかっていました。最近、JMP 17のワークフロービルダーを使用して自動化されたプロセスが開発されました。比較対象となるチャンバーの数に応じて個別のワークフローファイルが作成され、プロセスの効率が向上しました。ワークフローは構成設定ファイルを取得し、参照チャンバーとクエリ対象のチャンバーを比較します。このプロセスにより、構成の不一致の重大度に基づいてグラフと表を含むレポートが作成されます。
このプレゼンテーションでは、JMP 18のワークフロービルダーの新機能である条件付き機能の有効性を紹介します。この機能は、すべての比較ワークフローを1つのワークフローに統合する方法を提供します。比較対象となるチャンバーの数（ユーザーが条件付きプロンプトに入力）に応じて、ワークフローの適切なセクションが決定されます。プロンプトの入力に基づいて、関連するワークフローが選択されます。最終的な結果は以前と同じですが、ワークフローファイルを手動で選択する必要がなくなり、複数のプラットフォームタイプ間で比較レポートを1～2分で生成できるようになりました。
皆さん、こんにちは。ゲイリー・オドリスコルです。Applied Materialsという会社で働いています。本日は、ワークフロービルダーと条件付きプロンプトを使って原子層堆積法のガスラインの温度制限を監視する方法、そしてワークフロービルダーを使ってJMPブレークダウンを行う方法についてお話しします。特に、JMPブレークダウンのプロンプト、つまりアプリケーションの入力場所とJMPブレークダウンについてお話しします。
少し自己紹介をさせていただきます。先ほども申し上げた通り、ダブリンのアプライド マテリアルズで働いています。プロセスエンジニアで、もちろん複数のプロセスに携わっています。半導体業界での経験は30年近くあります。趣味はサイクリングとゴルフ、そしてカモギーのコーチです。カモギーはアイルランドのスポーツで、成人女子チームです。男子はハーリングと呼ばれています。アイルランドに行ったことのある方で、棒で打つワイルドなスポーツについて聞いたことがある方は、まさにその通りで、私はそのコーチをしています。
JSLを使っている人について、簡単なアンケートをしてみましょう。JSLとそのユーザー全体を見てみると、実際にJSLを使っている人はどれくらいいるでしょうか？2つのグループに分かれます。あなたは「はい」派で、JSLはあなたの仕事に欠かせない存在で、JSLが大好きです。私はコードのエキスパートで、毎日使っています。しかし、JSLは私の仕事には関係ありません。コードは理解していませんし、使ったこともありません。私自身は「いいえ」派です。コードの意味を本当に理解しているわけではありません。時々、少しずつ学ぼうとします。「いいえ」から「中間点」に近づき、「はい」に近づく方法があります。今日はその一部をご紹介します。
JMP 17のリリースは、ノースカロライナ州ケーリーで開催されたディスカバリーサミットで行われたことを思い出します。ワークフロービルダーが導入されました。ワークフローとは、よく考えてみれば、データ操作で何を行いたいかを記録する場所ですが、コードと出力の関係を逆転させるのに役立ちます。JSLの観点から見ると、必要な出力を得るためにコードを開発します。ワークフロービルダーを使用すると、出力があり、必要なデータを操作すると、バックグラウンドでコードが生成されます。ワークフローを使用すると、ユーザーは事前の知識がなくてもJSLコードを体験し、学習することができます。
ビルダー自体を見てみると、ビルダー内で操作から実行したいタスクを作成できることがわかります。ワークフロービルダーのステップ設定では、実行したい小さなタスクごとにバックグラウンドでコードが生成されているのがわかります。ワークフローは繰り返しのタスクに使用されます。同じ作業を何度も繰り返す必要がなくなるため、効率が大幅に向上します。ワークフローのコードは表示・編集可能です。
ワークフロービルダーを使い始めた頃、特に自分でこれをやろうとしていたら、必要なファイルを選択するだけで、実際に必要なファイルの名前もここに記載されていました。しかし、必ずしもそのファイルを使いたいとは限りません。コードの微調整はここで行えます。しかし、汎用的なファイルを選択する方法について多くのことを学んだのは、JMPコミュニティからでした。初めてコードを書くときに直面する問題は、初めて遭遇した問題ではありません。JMPコミュニティの誰かが既にこの問題を解決し、コードを共有しているのです。
さて、JMP 18のリリースについてですが、JMP 18はヨーロッパのマンチェスターで開催されたディスカバリーサミットで発表されました。そこで6つのPについてお話しました。そして、サミット後にJMP 18に追加された7つ目のPについて聞きました。そのPとは、ワークフロービルダーのプロンプト、より正確には条件付きプロンプトです。
私の役割において、プロンプトと条件付きプロンプトをどのように使用していますか？私の役割において、何を、なぜ、どのように行っているのかを説明します。何をしているかというと、原子層堆積（ALD）チャンバーガスラインの故障アラームとアラーム警告の温度設定を確認しているからです。これはおそらく予防保守タスクによるものです。なぜこれをしているかというと、アラームで検知されない温度変化は製品の廃棄につながる可能性があるためです。どのようにしているかというと、条件付きプロンプトを使用する拡張ワークフロービルダーを使用して設定を確認しているからです。
ALDについてご存じない方のためにご説明すると、ALDはあらゆる業界で多くの用途に使用されています。これは、材料を表面に直接、一度に単分子層ずつ堆積させるプロセスです。自己制御性を備え、可能な限り薄く均一な膜を生成します。業界全体でのALDの例として、研究室、化学、生物医学分野のバイアルへのコーティングが挙げられます。医療機器へのコーティング、そして半導体デバイスメーカーにおける層コーティングなども挙げられます。チップ内部にも層がある場合があります。あらゆる業界でALDが使用されているのはまさにこの点です。
半導体業界ではどのように使われているのでしょうか？他の業界と同じような使い方かもしれません。液体の薬品が入った容器があり、それをプロセスで使用します。薬品はプロセスで使用されますが、液体ではなく蒸気の状態で、容器から真空チャンバー内のポット（この場合はガスライン）を通ってチップ表面まで輸送されます。これは薬品の流れ全体の基本的な図ですが、概念を説明すると、容器からチップ表面のチャンバーまで、ポット全体に複数の温度調節パッドを配置することになります。
ここで示しているのはチップ表面ですが、半導体ではチャンバー内の1枚の基板またはウエハ上に複数のチップが配置されています。この上に堆積を行います。容器を交換するたびに、ヒートパッドのリミット設定を確認する必要があります。先ほども申し上げましたが、コールドスポットが発生するとガスが凝縮し、チップに欠陥が生じる可能性があります。ガスは冷却時に凝縮し、再び液体に戻る可能性がありますが、乾燥して固体に戻り、チップに堆積することで問題を引き起こす可能性があります。
従来の方法は、設定と複数のチャンバーの設定チェックから構成されていました。ある意味では、1つのチャンバーとして見たい場合にはワークフロービルダーを1つ用意していました。2つの異なるチャンバーを見たい場合には、別のワークフロービルダーを用意していました。同様に、上の図では最大6つのチャンバーしか表示されていませんが、実際にはさらに多くのチャンバーが存在する可能性があります。従来の方法では、使用するチャンバーの数に応じてファイルを作成し、それを選択して実行していました。
プロンプトに戻りましょう。ワークフロービルダーでは、1つを選択するだけでなく、「6つの別々のプロンプトではなく、すべてを1つにまとめる」というプロンプトを表示できるようになりました。JMP 18のワークフロービルダーには、「詳細」セクションがあります。「詳細」に入ると、別のメニューが表示されます。その中に、「if文の追加」、「else文の追加」、「return文の追加」、「for each文の追加」の4つのオプションがあります。これらはステップを分岐させるものです。1つのパスではなく、入力内容に応じて、あるパスまたは別のパスに進むことができます。これはJMP 18に実際に搭載された新機能で、ここで使用しています。
新しい方法を簡単にご説明します。フローチャートで説明すると、まず最初にプロンプトが表示されます。「1つのチャンバーを使用していますか？」と尋ねます。「はい」の場合はワークフローを実行し、レポートを取得して完了です。プロンプトが1つでない場合は、次のステップに進みます。次に「2つですか？」と尋ねます。「はい、そのチャンバーを実行できます。」そうでない場合は、次のステップに進みます。プロンプトがそれぞれ継続的にチェックされ、その番号に応じて、プロンプトに入力した内容がチェックされます。そして、一致したものがあれば、そのレポートが自動的に実行されます。新しい方法は、if else 文またはif else文をより大きなワークフロー内に埋め込むというものです。これが私の方法です。
私はオフィスエンジニアなので、JSLは分かりません。これが私がこのコンセプトを思いついた経緯と、それが私にとってどのように機能しているかです。他にも方法があるかもしれませんが、これは私の方法です。それではデモでご説明しましょう。
従来の方法だと、おそらく4つのチャンバーでチェックするでしょう。チェックでは、「ファイルをチェックしたい」と指定します。チェックしたいファイルからデータテーブルを生成し、JMPファイルとして保存します。そして、ゴールデンファイルを開きます。ゴールデンセットの限界値と比較しながら限界値をチェックします。予防保守を行う際には、限界値を広げることがあるからです。何かを冷却する場合、例えば200度の温度であれば、20度まで冷却します。
私の限界値は実際には200度に対して非常に厳しいかもしれませんが、冷却したため許容範囲外となり、常に警告が出ています。多くの人は予防保守作業中に限界値を広げます。その作業が完了したら、限界値を再び狭めることになります。これがまさに探しているものです。それはゴールデンファイルに保存されており、限界値は本当に必要な値に再設定されます。私はゴールデンファイルを持っています。それをテーブルに保存し、それらを結合します。そして、列に応じて一致させます。すべてが正しいかどうかを確認します。例えば、この場合は4つのチャンバーです。一致しない箇所は、サブセットテーブルを生成します。
そこから、大規模な分布の中で、では、どのヒートパッド、どのコントローラー、どのカテゴリーにするかを決めます。先ほど言ったように、私は複数のワークフローを用意します。1チャンバー、2チャンバー、3チャンバー、4チャンバー、5チャンバー、6チャンバーといった具合に。これらをすべて統合することで、個別に選択する必要がなくなりました。
プロンプトで行った操作、そしてここに表示されているのは、その前にこれを実行します。JMP 18でファイルを開きます。例えば、4をチェックしたいとします。「開く」を選択します。これですべて実行されます。保存形式は？「4チャンバー」とします。保存します。今持っているものを上書き保存します。ゴールデンファイルを検索すると、任意の場所に保存されます。これらのファイルを保存できます。先ほど言ったように、任意のフォルダーを選択できます。これで必要なものがすべて生成されます。
4の場合、ご覧の通り、「ヒートパッド2に2つの問題があります。すべてコントローラー2から送信されており、そのうち1つは警告限界と故障限界です」と表示されます。次に、それらの値、現在の値、そして本来あるべき状態を示すテーブルが生成され、簡単なレポートが作成されます。また、6チャンバーチェックでも同様の処理を行います。すると、条件付きプロンプトが表示されます。ご覧の通り、同じファイルです。これは、チェックファイルを開いて保存する方法と、そのように分解されたものです。CSV形式のゴールデンファイルがあります。これをJMPテーブルとして保存します。すると、プロンプトが表示されます。
ご覧の通り、プロンプト内でメッセージを入力するように指示しています。メッセージには、実際に必要なチャンバーがどれかが表示されます。つまり、答えが4ならこれを実行します。もしこれが4なら、そうでなければ次へ進みます。そして、elseの中に、1つのチャンバー用のワークフローを埋め込み、さらにelseの中に別のワークフローを埋め込みます。そして、次のワークフローへと進みます。各ワークフローが全体をタブで移動しているのがお分かりいただけると思います。最後に、チャートとレポートが表示されます。これが私の使い方です。この状態に戻るには、チェックファイルをもう一度開きます。今回は6を選択します。
「どこに保存しますか？」と聞かれるので、チェック6をここに保存したいとだけ言います。ファイルの保存方法に応じて、ツールID、マシンID、あるいはプロセス名などを入力します。テーブルが見つからなかった場合は後で保存するという選択肢が常にあるようにしておけば、すぐに保存してくれます。また6が見つかったので、はい、これをゴールデンファイルとして保存します、と答えます。
ここで「いくつのチャンバーを比較しようとしていますか？」と尋ねられます。ここでは6つと答えます。何度か実行したので、どのファイルを使用しようとしているのか尋ねられます。「6つを確認してください」と答えます。バックグラウンドで実行されています。ご覧のとおり、全体を通して、プロンプトに応じて特定のセクションをスキップし、それらを実行して「スキップしました」と表示しています。ここで確認できるのは、ここにファイルがあるということです。ここで不一致となっているファイルはここにあります。
ご覧のとおり、ここにすべての制限値を表示した表があります。基本的にはすべての行を合わせた値ですが、不一致が 2 つあります。他の行の不一致については、別の場所で処理しました。これにより、取得した情報に応じて完全なレポートが生成され、自動的に実行されます。4 つの不一致から制限値を取得して、このマシンで、ヒート パッドが正常に機能していない問題が 2 つありました。2 つあります。ヒート パッド 2 にあることはわかっています。コントローラー 2 にあることもわかっています。1 つは障害制限値で、もう 1 つは警告制限値です。それに戻ると、低い警告値、低い障害値でした。設定値がわかると思います。ここでは、おそらく 100 とマイナス 80 に設定されていると思いますが、実際にはマイナス 10 とマイナス 80 にする必要があります。
当時に戻って、その制限を修正すれば、すべてうまくいきます。
私にとっては、これは単に制限値が適切に戻っているかを確認するだけの作業です。監視されていないということではありません。多くのお客様がそうしていると思いますが、制限値を監視したくないという方が多いでしょう。温度の実際の設定値は十分にあります。私たちは大丈夫です。彼らは制限値を監視するつもりはありません。これは私自身が行うもう一つのチェックです。
これが私のデモンストレーションです。まとめると、ワークフロー条件は、複数のワークフローをプロンプト付きの1つの大きなフローにまとめるのに非常に役立ちます。プロンプトは、私の場合は数値でしたが、文字ベースのものもあります。例えば、化学業界で2つのワークフローがあるとします。1つは酸性化学物質を扱うワークフロー、もう1つはベースとなるワークフローです。プロンプトに「酸性のワークフローで作業しているのか、それともベースとなるワークフローで作業しているのか？」と入力して、確認することができます。
異なる文字を使うこともできますし、タスクに取り掛かって「これは起こりましたか？ はい、それともいいえですか？」と尋ねたり、特定の結果に基づいてレポートを作成したりすることもあります。先ほども述べたように、これはあくまで私の解決策です。ワークフローには他にも検討すべき解決策があります。このレポートを作成した後で、JSLを学習できるのは良いことですし、良い教育方法にもなります。
先ほど言ったように、実際のワークフローに戻って、もし見つけられるなら、ここに戻ってみると、先ほど言ったように、それぞれのタスクがあります。ワークフローで作成したタスクからJSLの学習を始めることができます。次のステップとしては、ワークフローの最後にプロンプトを追加することが考えられます。例えば、これは特定の数のチャンバーを備えた特定のマシン用だとします。2台目のマシン、あるいは3台目のマシンを操作しなければならないかもしれません。そこで、別のプロンプトを追加して、「まだ別のマシンを操作する必要がありますか？ はい、いいえ？」と尋ねます。「いいえ、これで終わりです」と答えたら、「はい」と答え、ワークフローの最初に戻ってループする、といった具合です。これは、私が考えているもう1つの方法です。
それでは、何かご質問がありましたら、コミュニティからお気軽にご連絡ください。ご質問は直接お送りください。先ほども申し上げましたが、私の名前はGary O'Driscoll、JMPコミュニティIDはgodriscollです。ご質問をお送りいただければ、喜んでお答えいたします。ありがとうございます。
