無償購読申込・変更
Email Newsletter登録
記事検索

検索方法の詳細



2005年9月号
SEMIのInterface A規格の詳細が決定
Brian Rubow
米Cimetrix社
www.cimetrix.com
 Interface Aに関する基本事項に関して述べられている。Interface AはSEMIの新しい装置インターフェイス規格であり、Interface Aを使用すれば製造ラインのオペレータは詳細なプロセスや計測、その他のデータにアクセスすることが可能になる。
* * * *
 半導体業界の多くの専門家が、製造装置にInterface Aを装備すれば半導体製造ラインの生産性を上げられると期待している。それは、APC/AEC(Advanced Process/Equipment Control)やe-diagnosticを含め、生産現場のEES(Equipment Engineering System)アプリケーションを実行するのに必要なものと考えられているためだ。数年前からInterface A規格が具体化してきたため、EESアプリケーションが品質改善やプロセスのばらつき低減、装置全体の稼働率の向上させることができる重要な要素であると考えている。Interface Aポートを使って、製造ラインのオペレータは、詳細なプロセスや計測、その他のデータにアクセスできるようになる。従来のSECS/GEMデータポートを備えている製造装置では、大量のデータを扱うのに制限があり、APC/AECを実行するのに遅れが生じていた。
Advertisement
 多くの変数がInterface Aのパフォーマンスに影響を及ぼす可能性がある。米Cimetrix社は、2003年にNIST(米国標準規格局)および米AMD社とのパイロットプロジェクトでInterface Aに取り組んだ経験がある。また、2004年から2005年の初めにかけて製造装置メーカーと米ISMI(International SEMATECH Manufacturing Initiative)によるInterface Aのプロトタイプの開発に参加した経験もある。さらに、2005年第2四半期には別の生産ラインでパイロットプロジェクトが計画されている。

Interface Aとは何か

 Interface AポートにはSEMI規格のE120、 E125、 E132および E134が実装されている。Interface Aによりデータ収集ソフトウェアと各製造装置との通信を容易にすることが可能になるが、もともとはEDA(Equipment Data Acquisition)から派生したものである。Interface AはHTTPまたはHTTPS接続を使ってSOAP/XMLメッセージ通信を行う。Interface Aにより複数のクライアント(装置データのソフトウェア)がデータ収集のアクセスを行うことができるようになる。しかし、これはSEMI規格や300mm規格を装置制御の構成に対する規格に置き換えるものではない。Interface Aは他の要求インターフェイスも含めて対応しなければならない(図1)。Interface Aは、Interface BやInterface Cとはまた異なるものである。これらはアプリケーション間でデータ共有を簡便にするためのSEMI規格群である。例えば、Interface Bは統計的プロセス管理やRun-to-Run解析、Interface Cの場合は主に異常診断やメンテナンスを目的とした装置データのリモートアクセスの規格になっている。
 長期的に見れば、Interface Aが他のデータ供給の全てのインターフェイスに取って代わるものになるだろう。実際、当初のInterface Aは、SECS/GEM インターフェイスに比べて若干多いデータ量を扱っていたのみだったが、最終的に製品改善や装置メンテナンス、装置の稼働状況の解析を行うために、プロセス情報やセンサーのフィードバック、アクチュエータステータス、その他の重要データなどの大量な情報量を扱うことができるようになった。さらに、Interface Aは、SECS/GEMのデータ収集アプリケーションよりも高頻度にデータ収集を行うことが可能になるであろう。
図1 Interface Aにより複数のクライアントがデータ収集を行うことができる。これはSEMI規格や300mm規格に取って代わるものなのではない
 Interface Aに関する話題の中には、「装置」が装置メーカーによって製造されたハードウェアとソフトウェアの双方に参照する問題がある。装置ソフトウェアは基本的に装置内部のコンピュータにインストールされ、完全に装置システム内に組み込まれている。装置ソフトウェアが外付けコンピュータにインストールされている場合もある。これは装置が後付され組み込むことができない場合に行われる。
 Interface Aを使って高品質のデータと高い生産効率を得るためには、最小限のハードウェアとソフトウェアであらゆる種類のデータを収集し、できるだけ時間の同期をとらなければならない。所望するデータをすべて使えるようにするためには、装置ハードウェアとソフトウェアの中には内部の構造やアーキテクチャを変更しなければならないものもある。

表1 SEMI E120のクラス階層
クラス
記述
装置
装置全般をモデル化している。マテリアルロケーションやモジュール、サブシステム、I/Oデバイスを含む
モジュール
プロセスチャンバや検査チャンバなどマテリアルを処理することができる装置の主要サブシステムをモデル化するものである。マテリアルロケーションやサブシステム、I/Oデバイスを含む場合がある
サブシステム
ロードポートやプリアライメントなどマテリアルを処理することができない装置の主要サブシステムをモデル化するものである。マテリアルロケーションやサブシステム、I/Oデバイスを含む場合がある
I/Oデバイス
センサーやアクチュエータ、統合アクチュエータ、センサーデバイスをモデル化したものである
マテリアルロケーション
装置コンポーネントのマテリアル保持能力やキャリア/基板/プロセス消耗品などマテリアルの種類を特定化する能力をモデル化したものである
有形/無形クラス
ソフトウェアモジュール
装置上または装置コンポーネント上で使用されているソフトウェアの有無、バージョンを記述したもの。ソフトウェアは装置業者またはサードパーティより供給される。属性は業者、バージョン、種類に帰属する
装置要素
無形モジュール、サブシステム、I/Oデバイスといった各ハードウェアコンポーネントに対する基本情報。装置メーカー、メイク、役割、リビジョン、(適用できる場合)シリアルナンバーに帰属する
無形
モジュール
マテリアルを処理できる装置構成部分をモデル化する装置要素のサブクラス。いわゆるモジュール、装置のことである。測定、プロセス、ストレージ、移送、レシピタイプ特定に属する
命名
固有のIDまたは各コンポーネントに記述を与えるための各クラスのルート
拡張子
CEMを拡張するため他の規格を有効にし、特殊な実行を行う能力を提供する

パーツ共通装置モデル

 E120は装置の外観構成を表す一般的なオブジェクトモデルに関するものである。そのモデルは表1に示すように、ローカル階層中に分かれているさまざまなクラスから成っている。完全に実装したモデルでは、主要な装置のハードウェアとソフトウェアをまとめている。CEM(Common Equipment Model)に関するSEMI規格E120.1 XMLスキーマ(XMLドキュメントの構造や内容、プログラム動作を規定したもの)を使って、E120規格を特定のXMLの実行に適用している(図2)。
図2 SEMI規格E120.1は、装置の外観構成を表す一般オブジェクトモデルに関するものであり、構造、内容、XMLドキュメントの規定を行っている。CEM(Common Equipment Model)はE120規格を特殊XMLの実行に取り入れている

装置のセルフディスクリプション

 E125規格を使えば、パラメータ(例えば特殊データ、単位、種類)、イベント、例外処理、装置状態、SEMIのE39オブジェクトデータサービスおよび物理構成などのデータ収集に使えるすべての情報について有用な記述をクライアントから要求することができる。全ての利用できる情報はE120 CEMオブジェクト階層に組み込まれる。ESDS(Equipment Self-Description)に関してSOAP Bonding暫定仕様であるSEMI規格E125.1により、E125規格を特定のSOAP/XMLの実行に適用している。(注:ここでは各XMLスキーマに使用される図表についてすべて説明できません。直接、E125規格を参照するか著者に問い合わせして下さい。)

表2 E125オペレーション及び装置メタデータ
オペレーション
記述
Get units
全ての利用できるユニットの規定情報の読み出し
Get type definition
全ての利用できるタイプの規定情報の読み出し
Get stare machine
全ての利用できるマシン情報及び関連イベントの状態の読み出し
Get SEMI object type
全ての利用できるSEMI規格 E39の情報の読み出し
Get exceptions
全ての例外処理情報の読み出し
Get equipment structure
全てのSEMI E120 CEM情報の読み出し。装置の各コンポーネントは単一のノードになっている
Get equipment node description
関連するマシンの状態、SEMI E39情報、例外処理、パラメータを含む、一つ以上の装置ノード記述の読み出し。パラメータは収集されるデータの要素を示す。属性にはその意味、どう数値が変化したか、単位及び種類(integer, real, tring, array, enumeration, その他合成タイプ)が現されている
Get latest revision
日付、時間など有効なメタデータの変更情報の読み出し
Notify on revisions
メタデータの有効性が変化した場合、装置に報告を送るように命令する
コンシューマクライアントのオペレーション
Metadata revised
「レビジョン変更通知」が有効になっている場合、装置モード中のメタデータが変更されたことをクライアントに通知する

 E125により、エンドユーザーは装置のドキュメントに全く頼らなくても、取得したデータやコンテキスト(例えばプロセスチェンバ#1または#2など)の情報にアクセスすることができる。Interface Aのクライアントはプラグインプレイで計測を開始することができ、装置のインターフェイスが変更された場合でも即座に新しい情報を自動的に利用することができる。データが予期せぬ事態で利用することが出来ななくなった場合には表2のように速やかにエラー復帰を実行することができる。

装置クライアント認証及び承認

 E132はInterface Aメッセージのセキュリティ関連で2つ規定している。装置クライアント認証及び承認(ECA: Equipment Client Authentication/Authorization)である。クライアント認証は証明書の発行を行い、表3に示すようにクライアントが初期状態で承認したオペレーションメッセージを送信できるようにするため、どのようにセッションを確立するかを規定している。クライアント承認はクライアントの許可と、セッションが確立された後のアクセス権が管理されているかどうかの確認を行う。装置を設置した後にECAをセットアップできるように、装置に管理構成のユーティリティである「Security Admin」を持たせなければならない。ECAに関してSOAP Bonding暫定仕様であるSEMI規格132.1により、E132規格を特定のSOAP/XMLの実行に適用されている。

表3 セッションの動作
クラス
記述
セッションの維持
装置にシャットダウンを行った場合でもセッションを維持するように要求する
セッションのping
装置が稼動しているかどうかの検査
セッションの終了
セッションを終了するように要求する
セッションの確立
新しい認証セッションを確立するように要求し、装置からの通知を受信できるようにクライアントにエンドポイントおよびコンシューマの設定を行う

 Interface Aクライアントは、E125やE134サービスリクエストを使用してセッションを確立するために、クライアントは証明書の発行や認証を行わなければならない。また、装置は「セッション確立許可」の状態になっていなければならない。証明書の発行には、クライアントIDや暗号セッションかぎ、暗号クライアントID認証かぎが使用される。ECAは認証前のサービスの使用を一切受け付けない。セッションが確立されると、クライアントの証明書の発行に基づいてクライアント承認が有効になる。
 クライアントにセッション確立する許可を与えるためには、Interface Aサーバーは予め設定しておかなければならない。半導体工場にあるInterface Aクライアントは、通常、Interface Aの専門家からなるサードパーティによって開発されている。装置の診断情報取得の場合のように、装置メーカーもInterface Aクライアントを開発するためにサードパーティを使っている。
 クライアント認証にはACL(Access Control List)を使って行われる。ACLではクライアントセッションの承認/拒否および特定のInterface Aにクライアントのアクセスを制限について詳細に決めることができる。
 E132規格には「principal(ACLで規定されるクライアント)」と「privilege(特定のデータの使用またはアクセスが許可されたクライアント)」という用語が使われている。実際に、ACLを最も簡単に設定する方法は、E132の中で「role(役割)」と呼ばれているものを規定し、クライアントに1つ以上の役割を持たせることである。例えば、「operator」「technician」「manufacturer」といった役割を規定すると都合がよくなる。その後Interface Aアプリケーションに役割の割りあてを行えば、適切なアクセスレベルでアクセスできるようになる。
 クライアントが特別なE125またはE134のサービスリクエストを送信するたびに、装置はクライアントの承認を毎回行わなければならない。クライアントに割り当てられたACLにより、実施できるE125、E132およびE134のオペレーション、利用できるメタデータならびに他のクライアントで定義されたデータコレクションプランへのアクセスレベルが決められる(メタデータとはデータを説明した情報のこと。例えば、イベントの発生やパラメータの数値に解釈が必要な場合に使用する)。

データ収集管理

 E134規格はInterface AがE125情報により記述されたデータを取得するための方法をいくつか規定したものである。クライアントはその場でデータをリクエストすることが可能で、リクエストされたデータは即座に応答される。しかし、通常クライアントは所望のデータの収集や設定を行うのにDCP(Data Collection Plan)を定義するだろう。DCPが有効になると、装置は「fire-and-forget」モード(送信メッセージに応答しない)で動作するようになり、連続的にデータを収集しDCR(Data Collection Report)に出力する。
 データ転送効率を最適化するために、DCRはオプションで装置に格納することが可能で、ある特定の間隔でデータを転送する。ACLで許可されていれば、クライアントは他のクライアントで作成されたDCPを有効にすることができる。E134では装置またはクライアントがシャットダウンした場合、どのようにDCPを管理しデータ抽出を維持するかという規定も決められている。
 DCM(Data Collection Management)に関してSOAP Binding暫定仕様であるSEMI規格E134.1により、E134規格を特定のSOAP/XML実行に適用されている。DCPがいつ有効になったのかを報告するために、DCPにはトレースデータやイベント、例外処理などのあらゆる番号や組み合わせ情報が含まれている。
 トレースデータは、連続的または間欠的にデータをポーリングするのに有用な構造になっている。トレースの規定にはデータ収集の周期やE125データの収集が含まれている。データコレクションが開始/終了した時にデータ収集を開始/終了するように規定されている。あるいは、トレースデータはデータコレクションが有効になった瞬間からデータ収集が開始され、データコレクションが無効またはある一定のレポートがたまり送信された時に終了するようになっている。
 E125の装置状態の移行によりイベントを発生させる。何か重大なことが発生し、状況に応じて所望のデータが収集された場合通知を受信することができるため、イベントは便利なメカニズムになっている。クライアントが選択したE125のパラメータをイベントのDCRに含めている。その後はイベントが発生するたびに、DCRが収集され送信される。
 例外処理はエラーが発生した場合、装置上に警告や警報が発生していることをクライアントに通知する。例外処理報告にはデータもあるが、そのデータは各装置業者の装置モデルにより決められている。イベントの場合と同様に、クライアントは添付されているパラメータを選択することはできない。
 有効になっているDCPのリストの中に含まれていないトレース、イベントおよび例外処理がクライアントに送信されることはない。装置メーカーはどれくらいの量が使用できるかを決定しているが、クライアントはどれくらいの量のデータを収集し報告するのかを決定している。必要なバンド幅は、クライアントの数、有効になっているDCPの数、イベントの数、各DCPの例外処理とトレース、各イベントとトレースに定義されているパラメータ、有効になっているイベントと例外処理の頻度、トレースデータ収集の頻度によって異なる。
 Interface Aに必要なバンド幅を決めるのは難しい。クライアントは潜在的に多くのデータコレクションリクエストを行っており、装置のコンピュータをオーバーロードさせスループットに影響を及ぼす可能性を持っている。したがって、コンシューマにオーバーロードの状態を通知し、ある1部のDCPまたはすべてのデータコレクションを中止するなどの適切なアクションをとってパフォーマンス状態を調整する手段がE134に規定されている。
 クライアントにはマネージャとコンシューマの2種類がある。アプリケーションは双方の役割を担うこともある。マネージャのクライアントは、規定や有効/無効、DCPの削除などの要求-応答作業を実行する。コンシューマのクライアントは装置からDCRを受け取る。装置のパフォーマンスが低下すると警告を発生する。装置の1部がシャットダウンし、1つ以上のDCPが休止状態になるとDCPの休止状態の報告が行われる。

Interface Aの稼動

図3 SEMI規格のE120、 E125、 E132および E134を組み合わせ場合のInterface Aのオペレーションフロー

 SEMI規格のE120、 E125、 E132および E134を組み合わせるとInterface Aのオペレーションフローは図3のようになる。
 簡単に述べると、各クライアントは初期状態で安全な承認セッションを確立する。次にクライアントは装置モデルのメタデータ情報の問い合わせを行い、Interface Aを通じてどのデータが有効であるのかを検証する。この情報をもとに、クライアントはDCPを規定し、有効にする。装置はクライアントがデータコレクションプランを無効、またはデータコレクションプランそのものが使用不可になるまでDCRを発生し続ける。クライアントはInterface Aを通じてセッションを閉じる。

流れに乗る

 ここからどう進むべきだろうか?Interface AはAPCなどEESのアプリケーションに直接関連していて、しかもそれらアプリケーションが最先端の半導体製造の生産性を維持するために非常に重要なものであるため、製造装置メーカーと半導体メーカーにとってSEMI規格のE120、E125、E132、E134およびInterface Aを機能的に進化させていくことが非常に重要なのである。装置にInterface Aポートを搭載し、さらに現場で進化したEESアプリケーションを生産に取り入れていくといった具合に、仕様が進化し続けていくことは疑いのないところである。近い将来、ほとんどの装置(仮にすべてでなくても)にInterface Aが搭載されるようになるため、この流れに乗るために積極的な取り組みが行われるようになるだろう。
 また、社内の専門家がInterface Aを推進していく一方で、サードパーティのソフトウェア専門家やプロバイダーと密接に協力していけば、Interface AやEESアプリケーションの新しい需要を開発していくことが可能になるであろう。そして、今後SEMI規格会議や業界のフォーラムの話題にたびたび取り上げられることであろう。
* * * *
Brian L. Rubowは、1993年6月より米Cimetrix社の主席エンジニア。また1988年からソフトウェアプログラマとして勤務。1995年よりSEMI通信規格に携わる。米ブリガハム ヤング大学の生産工学修士号を取得。
E-mail: brian.rubow@cimetrix.com

HOME | SI(日本版)について | 無償配付申込・変更 | サイトマップ | お問い合わせ | 広告掲載について | 関連サイト