Comments
Description
Transcript
装置エンジニアリングデータ収集 装置エンジニアリングデータ収集 機能
装置エンジニアリングデータ収集 機能要求仕様書 Equipment Engineering System Data collection Capability Requirement Document (DCRD) Version 2.0 [2003/09/30] 株式会社 半導体先端テクノロジーズ EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 Table of Contents 1. 序論 ..............................................................................................................................................1 1.1. 本仕様書の目的.....................................................................................................................1 1.1.1. 適用範囲.........................................................................................................................1 1.1.2. 機能概要.........................................................................................................................1 1.1.3. ベースドキュメント ......................................................................................................3 1.1.4. 関連ドキュメント ..........................................................................................................4 1.1.5. その他参照すべき資料...................................................................................................4 1.2. 装置エンジニアリングシステム（EES）の目的..................................................................5 1.3. 装置エンジニアリングシステムとデータのオープン性.......................................................6 1.4. 装置エンジニアリングシステムの必要性.............................................................................8 1.4.1. 装置機能性能の検証 ......................................................................................................8 1.4.2. 装置納入前での EES 活用.............................................................................................8 1.4.3. 装置納入後の EES の活用.............................................................................................9 1.4.4. 装置引渡し後の EES 活用.............................................................................................9 1.4.5. 装置メンテナンス後、修理後、改造後、調整後、人手作業後.....................................9 1.4.6. 装置故障原因の追求 ....................................................................................................10 1.4.7. 装置動作経緯の電子化.................................................................................................10 1.4.8. 外部センサデータの紐付け .........................................................................................10 2. 装置データ収集 .......................................................................................................................... 11 2.1. データの運用....................................................................................................................... 11 2.1.1. 装置界面の定義............................................................................................................ 11 2.1.2. データライフサイクル.................................................................................................12 2.1.3. データ保持期間............................................................................................................12 2.1.4. データ公開の範囲 ........................................................................................................13 2.2. 装置エンジニアリングデータの種類 ..................................................................................14 2.2.1. イベントデータ............................................................................................................14 2.2.2. トレース・データ ........................................................................................................16 2.2.3. コンテキスト・データ（装置構成、設定情報）.........................................................17 2.2.4. 装置エンジニアリングデータの種類のまとめ ............................................................19 2.3. 装置エンジニアリングデータ送出方法 ..............................................................................20 2.3.1. 装置から TDI へ ..........................................................................................................20 2.3.2. TDI 界面から F-EES DB、アプリケーションへ........................................................21 2.4. 装置構成定義.......................................................................................................................23 2.4.1. 装置構成モデル............................................................................................................23 2.5. 階層によるジョブと履歴 ....................................................................................................24 2.6. SEMI スタンダードとの関連性.........................................................................................25 3. 装置エンジニアリング業務に必要なアプリケーション ............................................................26 3.1. データハンドリング関連アプリケーション .......................................................................26 3.2. EE 業務アプリケーション..................................................................................................27 3.2.1. 装置運転管理に関する機能 .........................................................................................27 3.2.2. 保守作業支援機能 ........................................................................................................27 3.2.3. レシピ管理...................................................................................................................28 3.3. SEMI スタンダードとの関連性.........................................................................................29 4. セキュリティ対策.......................................................................................................................30 4.1. デバイスメーカ側のセキュリティ対策の方針 ...................................................................30 4.1.1. 機密保持契約 ...............................................................................................................30 4.1.2. アクセスコントロール.................................................................................................30 © 2002/2003 Selete i EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 4.1.3. 認証 ............................................................................................................................. 31 4.1.4. 暗号化.......................................................................................................................... 31 4.2. 装置サプライヤ殿のセキュリティ対策に対する要望 ........................................................ 32 4.2.1. FAB 内の環境におけるセキュリティ対策.................................................................. 32 4.2.2. ファイヤーウォール経由による遠隔アクセスに対するセキュリティ対策................ 32 4.3. SEMI スタンダードとの関連性 ........................................................................................ 33 5. 仕様準拠表................................................................................................................................. 34 6. Selete 提案仕様 ......................................................................................................................... 35 7. 付録............................................................................................................................................ 36 7.1. データのオープン性 ........................................................................................................... 36 7.1.1. 装置エンジニアリングデータオープン化の有用性 .................................................... 36 7.2. データライフサイクルの例 ................................................................................................ 38 7.2.1. TDI を想定したデータライフサイクル ...................................................................... 38 7.3. 装置エンジニアリングデータの例 ..................................................................................... 39 7.3.1. マルチチャンバ真空装置構成例 ................................................................................. 39 7.3.2. マルチチャンバ真空装置プロセスユニット構成例 .................................................... 40 7.3.3. 真空装置データ収集項目例......................................................................................... 41 7.3.4. その他の装置詳細ステータスデータ .......................................................................... 44 7.4. データ通信方式 .................................................................................................................. 46 7.4.1. Selete 推奨仕様に準拠する場合 ................................................................................. 46 7.4.2. SEMI スタンダード（PR8）に準拠する場合 ............................................................ 49 7.5. EES の類似例／実施例 ...................................................................................................... 53 7.5.1. エキシマレーザ光源における類似例 .......................................................................... 53 7.5.2. CD（測長）-SEM における類似例 ............................................................................ 53 7.5.3. クラスタ型 PVD 装置における実施例........................................................................ 54 7.5.4. CMP 装置における実施例 .......................................................................................... 54 List of Tables 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 表 2-1．インタフェース界面定義 ...................................................................................................11 2-2．データライフサイクルの EE データの動作 ........................................................................ 12 2-3．データ保持期間.............................................................................................................. 13 2-4．装置エンジニアリングデータの種類（例）.......................................................................... 19 2-5．SEMI スタンダードとの関連性 ........................................................................................ 25 3-1．SEMI スタンダードとの関連性 ........................................................................................ 29 4-1．SEMI スタンダードとの関連性 ........................................................................................ 33 7-1．DEE の例 ....................................................................................................................... 42 7-2．トレース・データの例 ....................................................................................................... 43 7-3．コンテキスト・データの例.................................................................................................. 44 7-4．TDI で管理すべきデータ ................................................................................................ 46 7-5．イベントスキーマ ............................................................................................................. 48 7-6．トレーススキーマ ............................................................................................................. 49 7-8．Message structure ............................................................................................................ 49 7-9．Message Header .............................................................................................................. 50 7-10．Event Message Body...................................................................................................... 50 7-11．Exception Message Body ............................................................................................... 50 7-12．Parameter Elements ....................................................................................................... 50 7-13．データ定義の記載項目 ................................................................................................. 51 © 2002/2003 Selete ii EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 List of Figures 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 図 1-1 生産制御視点と装置視点情報の分離収集 .........................................................................2 1-2 本仕様書の位置づけ .........................................................................................................3 1-3 一般的な、工場内設備の実行稼働率..................................................................................5 1-4 従来の MES 系との考え方の違い.......................................................................................6 1-5 データ構造とインタフェースのオープン性 ...........................................................................7 2-1 インタフェース界面定義の図 ............................................................................................ 11 2-2 データライフサイクル .........................................................................................................12 2-3 EES で扱うデータの範囲...................................................................................................13 2-4 イベントデータ（DEE 含む）の例........................................................................................14 2-5 上位からの作業の流れとイベント ......................................................................................15 2-6 DEE データの相関モデル ...............................................................................................16 2-7 トレース・データの例.........................................................................................................17 2-8 Job の処理ステップに従って発生するコンテキスト・データの例 ...........................................18 2-9 装置エンジニアリングデータ送出インタフェースの差異......................................................20 2-10 装置構成物の論理モデル ...............................................................................................23 2-11 Job 構成要素の論理モデル.............................................................................................24 4-1 ルーティング機能やフィルタリング機能によるアクセス制御のイメージ..................................30 4-2 ファイヤーウォール経由による遠隔アクセスのイメージ........................................................32 6-1 Selete 提案システム...........................................................................................................35 7-1 Photo litho 工程の塗布⇒露光間搬送のイベントの例 .........................................................36 7-2 EE データのオープン化による OEE 向上アプリケーション例...............................................37 7-3 TDI を想定したデータのライフサイクル例 ..........................................................................38 7-4 真空装置（PVD）の構成例................................................................................................39 7-5 真空装置（PVD）の装置モデル例 .....................................................................................39 7-6 プロセスユニットの構成例.................................................................................................40 7-7 プロセスユニットのモデル例..............................................................................................41 7-8 EDA 界面から上がる EE データ ........................................................................................42 7-9 ガス流量による間接的なバルブ動作監視の例 ..................................................................45 改訂履歴 このドキュメントの著者 版 初版（ASPLA ASPLA 向け暫定版） 初版（ 1.1 版（Selete 版（Selete 正式版） 2.0 版 日付 6/13/2002 10/31/2002 9/30/2003 著者 藤田 藤田 藤田 総ページ数 このドキュメントは 60 ページから成る。タイトルページを 2 ページ（表と裏）とし、全ての前付と本文ならびに 付録を数えることで、正しいページ数を得ることができるようになっている。 © 2002/2003 Selete iii EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 1. 序論 本暫定仕様書（以降「本仕様書」）は、装置エンジニアリングシステムをプロトタイプ評価などで早期に実 装することが必要になった場合を想定し、装置エンジニアリングデータを収集するために必要な最低限の 機能の要求をまとめたものである。 なお、記載されている各インタフェースに関しては現在スタンダード化が進められているが、必ずしも確 定した物ではない。 1.1. 本仕様書の目的 本仕様書の目的は、以下に示す 2 点の項目を満たす装置の EES 請け仕様書を当該装置サプライヤ殿 に作成願うことにある。 ①当該装置に於ける装置エンジニアリング（EE）データの発信／収集／蓄積を行う機能。 ②当該装置に於ける本仕様書 3 章に記載する範囲の EE アプリケーション。（オプション） なお、①のデータ発信／収集／蓄積に関しては必須の機能とし、EE データは 2.2 章に記載されている 3 種類のカテゴリ全てを対象とする。また、②の EE アプリケーションに関しては、装置のカテゴリや用途で実 現手法や内容が異なるため、本仕様書の 3 章に記載されている範囲を対象として、どのような物を実装する か、実装する装置サプライヤとして請仕様の形で提案願いたい。 その際参考にして頂くために本仕様書には、具体的なシステム仕様の例として Selete の提案シス テム仕様を記述した。本仕様に関してさらに詳細な実装仕様を必要とされる場合は、各委託者殿に お問い合わせを頂きたい。 なお、本仕様書は第 1.1.3 章 ベースドキュメントに記載されている各仕様書、解説書、ガイドラインと 密接な関係がある。 特に、装置エンジニアリングシステム ユーザ要求書（EES-URD）は本書の上位に位置する物であるため、 併せて参照願いたい。 また、本仕様書に追随する形で後述の装置データ・インタフェース（Tool Data Interface =TDI：一般公開 予定）とデータベース構造に関する仕様書（非公開なので、Selete クライアント各社より個別に入手する必要 有り）も開発中であるため、それらも併せて参照願いたい。 1.1.1. 適用範囲 本仕様書は、φ200mm、φ300mm等のウェーハ口径を問わず全ての半導体製造装置に適用される。 1.1.2. 機能概要 本仕様書で記述する機能の要求は EEC（Equipment Engineering Capability）ガイドラインに基づくもの である。 1.1.2.1. 要求項目 ①概要 現状、装置からはいろいろな情報を収集しているが、実際に EES 観点でシステムとして活用している のは装置生産能力の追跡、メンテナンス管理など一部に留まっている。EES 観点では、装置エンジニア リング情報は、MES 情報と独立されて収集されなければならない。 この装置エンジニアリング情報を送出するデータポート（EDA ポート）に関して、EEC ガイドラインでは 論理的に分離することを要求している。実装する上では、扱うデータが大量になり負荷も大きくなるため、 MES 系の進捗管理機能に支障を与えないように下図のように物理的にも別ポートにする必要がある。 1 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 〈従来〉 EE EE System System EE情報 情報 EE情報 情報 EEEE 情 情 報 報 MES情報と装置エンジ 情報と装置エンジ MES情報と装置エンジ 情報と装置エンジ ニアリング情報の混在 ニアリング情報の混在 MES情報 情報 MES情報 情報 Legacy Legacy Factory Factory Host Host MES情報と装置エンジ 情報と装置エンジ MES情報と装置エンジ 情報と装置エンジ ニアリング情報の分離 ニアリング情報の分離 〈今後〉 製造装置 製造装置 図 1-1 生産制御視点と装置視点情報の分離収集 従来の MES 系でも装置エンジニアリング系のデータ収集はある程度行われていたが、インタフェース 仕様やプロトコル、バンド幅の制約で非常に粗い粒度であるうえに、装置がオンライン状態でのデータし か収集出来ず、稼働率計算などの極限られた用途にしか活用が出来なかった。 今回提案し実装をお願いする EE データを収集するポートは、従来の MES 系のポートとは別にするこ とにより、装置のオンライン／オフラインに関係なくデータを収集し、更にバンド幅を大きくとる事により従 来の MES 系よりも広範囲で粒度の細かい大量のデータを扱うことを前提としている。 装置から装置の外に送出されるデータには第 2.2 章に記載されているイベントデータ、トレース・データ、 コンテキスト・データの 3 種類が必要となる。 EDA ポートからは、I/O ポートステータス（リモート I/O のビットマップ等）のような加工されていない直接 的なデータや、統計値のような加工され整理された情報までの粒度が異なるデータが混在して送出され る。 以下にこれらのデータを装置から収集し活用できる形で提供するために装置側で必要となる機能及 びその実装方法を述べる。 ②データ規定 データの種類／カテゴリ、フォーマット等は装置サプライヤ殿の設計ポリシーや装置運用モデルに依 存するため、そのデータ項目の詳細は装置サプライヤ殿により提供いただく。 データ項目例として、付録に真空装置の例を添付するので、そちらを参照されたい。 データの収集方法の定義に必要な下記項目については、装置サプライヤ殿において選択いただき、 詳細を決定する。 １）データ項目 ２）プロトコル ３）データコレクションプラン （DCP） ４）データ定義 ５）データフォーマット ただし DCP は搭載するアプリケーションによって必要となる機能である。DCP の装置への搭載に関し て否定はしないが、本仕様書ではアプリケーションの機能仕様については規定しないため、要求対象外 とする。 なお、DCP を装置サプライヤ殿で独自に検討いただき、装置に搭載する場合は、請仕様書のドキュメ ントにその仕様が明示されている必要がある。 2 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 ③データ・セキュリティ 装置データ収集界面におけるセキュリティ対策として、デバイスメーカが装置サプライヤ殿に対して特 別に要求する項目は特にない（ただし、デバイスメーカのファイヤーウォールを経由した遠隔アクセスを 実施することがある場合、そのセキュリティ対策に関しては別途検討が必要：第 4.2.2 章を参照）。 機密情報の保護に関してはシステム上の仕組みによるデータの保護（アクセス制御、認証、暗号化な ど）が必要とされるケースも存在するが、その適用にあたっては各デバイスメーカのセキュリティポリシー やセキュリティ管理運用によって異なり、一律に定義することはできない。したがって、具体的なセキュリ ティ対策の適用にあったては、装置サプライヤとデバイスメーカとの間で協議の上決定されるのものとす る。セキュリティ対策に関するデバイスメーカ側の基本的な方針は第 4 章に記載する。 1.1.3. ベースドキュメント 本書のベースドキュメントとして、下記の 4 つの仕様書が参照されている。 １） 装置エンジニアリング機能 EEC ガイドライン（フェイズ 2.5） URL は下記の通り 日本語版：http://www.selete.co.jp/SeleteHPJ1/Data/0209a01.pdf 英語版 ：http://www.selete.co.jp/SeleteHPJ1/Data/0207b01.pdf ２） EES Implementation Requirement Document （IRD） Version 1.7 現状は日本語版のみで URL は下記の通り 日本語版：http://www.selete.co.jp/SeleteHPJ1/Data/0210e01.pdf ３） EES User System Analysis Document （USAD） Version 1.5 現状は日本語版のみで URL は下記の通り 日本語版：http://www.selete.co.jp/SeleteHPJ1/Data/?????（TBD） ４） 装置エンジニアリングシステム ユーザ要求書 EES User Requirement Document （URD） 1.0 現状は日本語版のみで URL は下記の通り 日本語版：http://www.selete.co.jp/SeleteHPJ1/Data/?????（TBD） ※上記のドキュメントは全て随時アップデートされるため、最新版は Selete Web サイトで確認願いたい。 EES関連公開仕様書の参照関係 検 討 フ ェ イ ズ 実 現 ／ 実 装 フ ェ イ ズ 検討段階のバック グラウンド仕様書類 ユーザシステム分析書 User System Analysis Document（USAD） 実装要求仕様書 Implementation Requirement Document（IRD） ユーザ要求書 User Requirement Document（URD） ユーザシステム要求仕様書 User System Requirement Document（USRD） データ収集機能要求仕様書 Data collection Capability Requirement Document（DCRD） TDI機能要求仕様書 Tool Data Interface Capability Requirement Document（TDI） その他 図 1-2 本仕様書の位置づけ 本仕様書の位置づけ © 2002/2003 Selete 3 本書 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 1.1.4. 関連ドキュメント 開発中の本書との関連ドキュメントは以下のとおり。 １） 装置エンジニアリングシステム TDI（Tool Data Interface）機能仕様書 ２） 装置エンジニアリングシステム 工場内 EES（F-EES）データベース要求仕様書（仮称）（※） （※一般公開していないため、必要な場合は Selete クライアント各社より個別に入手願いたい） 1.1.5. その他参照すべき資料 上記ベースドュメントの他に以下の SEMI Workshop 予稿集が参照できる SEMI Workshop on e-Manufacturing and APC/FDC 予稿集 2001 年 2 月 23 日 東京コンファレンスセンター SEMI e-Manufacturing Workshop 予稿集 2001 年 6 月 7 日 主婦会館 SEMI e-Manufacturing Workshop 予稿集（CD-ROM） 2001 年 12 月 4 日 ホテル・ルポール麹町 SEAJ 「EES ビジネスモデルについて-e-Manufacturing 時代に向けたビジネス展開-」 SEAJ EES 委員会 2002 年度活動報告書 JEITA/SEAJ/Selete e-Manufacturing ビジネスへの始動 セミナー予稿集（CD-ROM） 2003 年 6 月 13 日 東京商工会議所 国際会議室 © 2002/2003 Selete 4 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 1.2. 装置エンジニアリングシステム（EES）の目的 装置エンジニアリングシステム（ ）の目的 半導体製造装置は、その時代の微細化と大口径化の要求に応えるべく、常に新規開発が行われて来た が、その先進性故に必ずしも OEE（設備全体の実行稼働率）は高いものとはなっていない。 下図は、現状の FAB 内装置での OEE（設備全体の実行稼働率）を示したチャートで、工場全体では右 上の部分約 40％しか装置がウェーハに付加価値を高める処理をしていないことを示している。そのほかは NPW（Non Product Wafer = 非製品ウェーハ）を使った準備作業やメンテ作業、装置停止、待機などで付 加価値を生み出す作業をしていないことが分かる。 FAB 内での作業内訳 非製品ウェーハ処理、 非製品ウェーハ処理、 段取り業務等 段取り業務等 OEE（ OEE（設備全体の実行稼働率） は４０％しかなく 実際には付加価値の無い 作業が多い Equipment Adding value is only 40%! Unscheduled Unscheduled downs downs Scheduled Scheduled downs downs OEEの の UPが が急務 Idle/ Idle/ Waiting Waiting OEE:Overall Equipment Effectiveness Source - SEMATECH 図 1-3 一般的な、工場内設備の実行稼働率 装置エンジニアリングシステム（EES）を“工場システム”に追加する目的は、装置から装置エンジニアリン グ（EE）・データを収集し、そのデータを活用するアプリケーションを駆使することにより、上図（図 1-3）中で 合計すると FAB 内での作業内訳の約半分を占める生産寄与に対する阻害要因の排除あるいは縮減、す なわち ①Scheduled Down Time の最適化 ②Unscheduled Down Time の最小化 ③NPW 処理、段取り時間の最適化 を実施し、装置本来の生産寄与時間（Value Added Time）を向上させ、装置の実効稼働率（OEE）を改善し 工場全体の生産性／投資効率／投資回転率を向上することにある。 また、図 1-4 に示すとおり、装置サプライヤ、デバイスメーカ双方が合意の上でお互いが利用するデータ の範囲を取り決め、お互いが EES のユーザとして各々の目的でシステムを活用する。この場合、デバイスメ ーカが利用するデータ範囲やレベルと装置サプライヤが利用するデータの範囲やレベルは、一致するとは 限らない。 このため、従来のデバイスメーカ視点のみの MES 系の自動化とは考え方から大きく異なる。 © 2002/2003 Selete 5 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 デバイスメーカ 機密情報なので、 データは渡せない 装置メーカ 生産進捗管理 物流制御 プロセス制御 ＭＥＳ 品質管理 デバイスメーカ 開示範囲を合意の上で データを積極利用 装置メーカ OEE向上 OEE向上 装置管理 プロセス管理 顧客満足度向上 ＥＥＳ 装置完成度向上 サービス品質向上 生産効率向上 開発効率向上 ・責任の切り分け ・市販の技術やアプリケーションの導入 アウトソーシング 図 1-4 従来の MES 系との考え方の違い 1.3. 装置エンジニアリングシステムとデータのオープン性 先に述べたように EES はデバイスメーカと装置サプライヤの双方が利用するため、扱う EE データは標準 化されたインタフェースを経て装置外部へ出されて、装置外部で自由に加工／利用できることが必要であ る。そのため、データ利用の環境を構築するインタフェース（本仕様書では第 2.1.1 章に記載する）およびデ ータ構造は標準化されオープン化される必要がある。 インタフェースやデータ構造がオープン化されることにより、デバイスメーカ、装置サプライヤ双方の構造 改革に加えてサードパーティが参入し、半導体装置産業の産業構造のパラダイムシフトが創出され、以下 のような業務革新が期待できる。 ①デバイスメーカ側の業務の変化 デバイスメーカ必須／固有の業務の分解 －装置運用技術がデバイスメーカ固有のものではなくなる ・EES 導入により、運用技術を装置サプライヤと分担し双方の責任分担を明確化し、装置運用向上 に繋げる －データ構造の標準化により、装置管理技術や APC 等のプロセス運用技術も市販技術となる 6 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 ・プロセス制御モデルも充分な EE データがあれば完成可能であり、市販アプリケーション化が可能 ・装置管理技術では、メンテナンス時期を予測する予防保全アプリケーションや、稼働状態をモニタ リングするための NPW 投入時期の判断を行うアプリケーション、品質不良の装置側要因を解析 するアプリケーションなど広い応用範囲への展開も可能 装置サプライヤとデバイスメーカ共同での装置の垂直立上げ －装置サプライヤとデバイスメーカの責任を明確に分担する事により、効率の良い立上げが可能（第 1.4 章を参照） ②装置サプライヤ側の業務の変化 装置サプライヤの運用ノウハウを販売する事業の出現が予測できる（装置サプライヤのみならず、サー ドパーティの出現も予測できる → サードパーティの参入） －サプライヤ間の協業が容易化 －プロセス性能開発にリソースを集中できる －サービス品質の向上やサービスのアウトソーシングも可能 → サードパーティの参入 ③サードパーティの参入 ソフトウェア・サプライヤやメンテナンス専門会社等のサードパーティの参入／出現が予測できる －前述したノウハウをパッケージ化したサービスやソフトウェアを専門に扱うサードパーティ企業が出現 する －サービスのアウトソーシングにより、業務を装置カテゴリやプロセスに特化した企業も出現する可能 性がある 装 置 装 置 データ保存（ＥＥＳサーバ） データ保存（ＥＥＳサーバ） 装置エンジニアリングデータインタフェース EESアプリ アプリ EESアプリ アプリ ケーション１ ケーション１ EESアプリ アプリ EESアプリ アプリ ケーション２ ケーション２ EESアプリ アプリ EESアプリ アプリ ケーション３ ケーション３ 図 1-5 データ構造とインタフェースのオープン性 図 1-5 は、オープン化されたインタフェース上にアプリケーションが搭載されるイメージ図である。ここで 搭載されるアプリケーション 1～3 は装置サプライヤが開発する場合、デバイスメーカが開発する場合、サー ドベンダが開発し、装置サプライヤもしくはデバイスメーカが購入する場合が考えられるが、自由で容易な © 2002/2003 Selete 7 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 EES アプリケーションの搭載にはインタフェースが標準化され、そこから出力されるデータの構造がオープ ン化され標準化される必要がある。 しかし、「インタフェース A」（後述の表 2-1 参照）が深く関与し協調してアプリケーションに利用される場 合もあり得るし、一部装置サプライヤが開発したりサードパーティから購入したりして「インタフェース B」上で 実現する装置組み込みアプリケーションもあり得る。 なお、本章ではデータを装置から外に出力するという機能を持つインタフェースをインタフェース A、アプ リケーションを接続するためのインタフェース機能をインタフェース B と呼び区別している。 1.4. 装置エンジニアリングシステムの必要性 装置エンジニアリングシステムの必要性 1.4.1. 装置機能性能の検証 装置動作には、大きく分けて装置の基本機能の動作と、装置のプロセス機能の動作がある。プロセス動 作と、基本機能動作との厳密な区別が存在する訳ではないが、ウェーハをプロセスチャンバの正しい位置 に載置して、その後、所定のタイミングで、必要なガスを所定のプロファイルで流す、等のプロセスが生起す るために必要な状態を出現させる、いわばお膳立てを行う機能を、本仕様書では基本機能と考えている。 更に例を挙げれば、真空装置であれば所定の真空排気速度が得られること、所定のガス流量にてガスを 流せること、加熱処理について言えば、ウェーハを加熱するための、例えばヒートブロックが正しく温調でき ること、更に一般的な機能では、ウェーハのハンドリングが正しく制御され、また動作が正確であること等で ある。 これに対して、プロセス機能性能は、プロセス中のウェーハへの異物付着が規定数以下である着工期間 の長さ、反応速度、エッチングでは選択比、反応分布（膜厚分布、エッチングレート分布、選択比分布）、エ ッチング異方性、成膜被服特性、抵抗値分布、等である。 上記のように装置機能を比べると、お膳立て機能については、十分に良く制御することができるが、プロ セス機能性能は、お膳立ての範囲を越える不明あるいは、不随意のファクタが介在し、所定の性能を長期 間維持することが難しいなどの問題となって出現する。このようなお膳立てから一歩実際にウェーハ表面で 生起している反応に迫るためには、しばしば In-Situ モニタリング等のセンサの組み込みによって、直接反 応からの情報を得ようと努力がなされるのが一般である。しかしながら一般的には、そのような反応の直接 のモニタリングは容易ではなく、またはそのような技術が開発されていることは稀である。十分に良好な特性 を有する In-Situ モニタが開発されていると、そのモニタ技術によって、不随意の要素は、制御可能なパラメ ータとして装置によって制御されることになる。 本仕様書では、概略プロセス性能に関連する情報の発信については、現在プロセス装置に要求されて いるのと同等以上のものが備わっていることを要求しているが、特に従来から十分に注意が払われていな かった装置の基本機能の監視に必要なデータの発信機能も、同じく重要であることを強調しておく。 1.4.2. 装置納入前での EES 活用 装置が設計通り動作していることを確認することは、確実な動作を行う装置を完成させる大前提である。 特に開発機から初号機までには、装置開発の効率化が重要であり、合理的で正確な装置動作の検証方法 を使用することは重要である。 装置サプライヤは、上記 2 つの装置の機能性能について、設計値或いは、正常値を明確に示し、そして その値の検証を行うに必要十分な監視機能を提供するべきである。本仕様書で要求している DEE データ を取得する機能は、その中でも最もシンプルな装置基本性能の検証機能である。 開発機のデバッグに EE データの発信機能と外部の EE 機能は有用であるが、更に納入装置の出荷前 検査にとっても有用である。 装置の機能性能に不具合が無いことを十分に確認してから納入することは言うまでもなく重要であるが、 その確認方法が経験的で、科学的でない場合が多い。納入前に 2,000 枚の動作試験を行うことは大事で あるが、その際に、本仕様書が要求しているように装置の基本機能性能の確認と再現性、あるいは、不具 合の発見、機能部品の個性の認識、初期性能の科学的な確認、を実施することができると、装置納入後の 8 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 故障率あるいは故障によるダウンタイムの縮減に効果があることは疑いを入れない。 ごくあたりまえのことであるが、装置の故障は、いくつかの部品の不具合が競合脱線的に発展して装置を 停止させ修理を行わなければならないような発生の仕方は稀であり、単一の部品の不具合で、十分に決定 的な装置停止に至る故障を起こしえる。換言すれば、できるだけ広い範囲で装置内構成要素の監視を行 い、できるだけ早い時点で、不具合の発生を察知すること以外に、故障修理時間の縮減する方法は無い。 従って装置納入前に、単に 2,000 枚のウェーハが無事流れたという結果のみを以ってではなく、最低限本 仕様書で要求している装置基本機能の確認をデータベースで科学的に行うことが、OEE の根本的な改善 には必要である。 このことは特に初号機から 10 号機くらいまでの納入には重要である。装置の生産工程の習熟度が十分 でない、また多く改善と改良とが行われながら生産されることが想定されるからである。 1.4.3. 装置納入後の EES の活用 装置納入後には、現場での装置インストールから調整、性能確認、そして引渡しというシナリオが一般的 である。この装置性能の確認中には多くの基本機能のデータが取得でき、引渡し以降の基準データとして 活用される。即ち、引渡し時の基本特性を最良の値として用い、これ以降の性能劣化の判定に使用する。 ここで注意しなければいけないことは、種々の動作時間などを細かく観察できることがあっても、装置にと って重要な劣化がどこであるかということは、我々デバイスメーカは勿論、装置サプライヤも現状では EES 実装の実績がないために、熟知しているとは言えない事であり、データの解釈には我々は十分な経験をつ んでいないことを認識すべきである。 1.4.4. 装置引渡し後の EES 活用 装置の多くの基本機能の性能については、常時モニタがなされるべきである。装置の基本機能の劣化は 通常、緩慢な進行をするので、リアルタイムでのモニタリングは必要が無い。例えば、装置基本機能性能の データを数秒に一回送信し、装置外部の EE 機能によって、いわば数秒分のバッチ処理を行い、常時監視 を行うシナリオが考えられる。 装置の基本機能の確認は、実行されるプロセスによって影響を受けない診断方法を採用することが重要 である。具体的な例を示すと、ウェーハ搬送は、ロードロックチャンバにウェーハがはいってから、目的とす る｢第一プロセスチャンバ｣に入るまでの時間を測定して、ベースデータと比較するなどは、基本機能の監視 として殆ど実用となりえない。 ロードロックの排気の時間は、変化するので、排気に要した時間と純粋に搬送に要した時間とを分離する 必要がある。 また、「第一チャンバ」にどのウェーハも行くわけではなく、プロセスレシピによっては、違うウェーハの経 路である場合がある。従って、装置内のウェーハ移動の各単一動作のレベルで、移動時間を取得し、比較 することが良い方法である。このようなデータ取得の注意点を十分に検討し、データ数もたくさん集まり、正 確な比較ができる刻みに動作を分け監視する必要がある。 上記したダイナミックにデータが発生し、そのデータを逐次検査するという業務があるが、一方スタティッ クな装置定数とも言うべきデータの監視業務も重要である。 そのような例としては、装置に組み込まれている種々のインターロックの閾値を装置の外部から読み、有 るべき値との比較をする、またインターロックの動作が停止されているものはないか監視するという業務があ る。このような閾値の設定が本来の値でないと装置の不具合の検出そのものができなくなることがある。また 非常にしばしばインターロック機能を停止させたまま装置を稼動させ、不良な処理を行ってしまった例は枚 挙に暇が無い。 1.4.5. 装置メンテナンス後、修理後、改造後、調整後、人手作業後 装置メンテナンス後、修理後、改造後、調整後、人手作業後 装置メンテナンス後、修理後、改造後、調整後には十分な装置の性能確認を行わなければならないし、 またソフトウェアのバージョンアップ後などでは、かえって不具合を作りこむ可能性も非常に高い。従ってプ ロセス機能の性能が復帰した等の確認とともに装置基本機能性能の確認もきわめて重要である。このような © 2002/2003 Selete 9 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 装置基本機能性能の確認は 従来作業者が行っているが、到底作業者には性能確認は容易ではなく、定 型化、自動化的な手法を準備し、装置の製造への復帰を確実で迅速なものにする強いニーズがある。 作業者が確実な装置調整を行ったかを数値的に迅速に確認することも重要である。定量性のある把握 をせず行う装置調整は、プロセス機能の性能調整程度として、装置の基本機能に関わる性能については 定量化の手段をもつことが、現場での装置の間違いの無い保守を実現することに直接繋がる重要な要求 であり、そのような機能を本仕様書では要求する変わりに装置側には、本事項に関連する有用なデータの 装置からの送出を要求している。 作業者の作業内の結果をシステムが知ることができることは、今までには殆ど不可能なこととしてあきらめ られていた事項である。しかし DEE データを使い、また他の装置基本機能の性能を知る手段をあわせ用い ることで、人手作業の幾ばくかを自動的に記録としてロギングできる。このことは作業者のモラルの向上にも 繋がる効果も予想できる、きわめて重要な EES の機能である。 1.4.6. 装置故障原因の追求 種々の装置故障が有り、その原因も様々である。EES 対応の装置では、装置の詳細な稼動データが記 録されているので、故障が発生した場合に、従来よりもはるかに容易に、故障の原因を同定することができ る可能性が高い。また逆に、故障と見える装置動作が、実はその部位の故障ではなく、他の部位との関連 で、通常とおりの動作を行わなかったなどの状況を知ることもできる。 このような機能は、通常装置に装備されている故障アラームとは大きく異なるものであり、故障からの回復 時間を短縮するのに有効である。 また装置の詳細な稼動記録が装置外部に出力されているために、故障原因を同定するためのソフト機能 も、随時より便利で、正確なものに置き換える、あるいは、バージョンアップをすることも可能である。ノウハウ を蓄積することで、当然複雑な診断機能のアプリケーションに成長させえることも EES の大きな特徴である。 1.4.7. 装置動作経緯の電子化 プロセス装置にとっての一番単純で重要な経緯は、処理枚数来歴である。多くの装置では、装置が着工 していない時間が暫く続くと、その無着工時間後に初めてくるウェーハの処理性能が、連続着工時と異なる ことが観測される。その原因は、ウェーハの温度に違いが出るためだったり、プロセスチャンバ内のガス分 圧が異なるためであったり、多くの要因がある。 このようなプロセス性能の変動に対して何らかの装置内状態の補正や、単にエッチング時間を延長、ある いは、短縮する等の対抗処置を取る場合、無着工時間の長さ、無着工時間後からの処理枚数などが重要 な指標となる。例えば CMP などでは ダミーを処理したのか、またその研磨膜厚、枚数、製品、製品の研磨 量、これらをあるモデルに従って、無着工時間からの処理全体の影響を計算し、対抗する処置を立てること になる。 EES では装置からの経緯データが得られることを要求しており、必要であれば処理内容を参照することが できるので、上記した計算を実施することが可能である。このように装置の事情を反映した APC を適用する ことができるので、EES で扱うデータは、プロセスの安定化に貢献することができる。 1.4.8. 外部センサデータの紐付け EES では装置からの詳細なステータス情報が得られることを前提としており、装置に後から取り付けられ たモニタセンサからのデータと、その装置詳細ステータスデータとを合わせて用いることで、モニタセンサが 意味のある信号を出力し始めたタイミングをステータスの変化（通常は何らかのプロセスの開始タイミング） から知ることができる。 更に装置外部のアプリケーションによって、データの切り出しと、その切り出したデータが、どのようなプロ セスと、どのようなプロセス条件を狙った設定条件の元で、モニタしたものであるということが同定できる。 このようにすることで外付けセンサのデータの活用が大きく便利になる。 © 2002/2003 Selete 10 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2. 装置データ収集 2.1. データの運用 2.1.1. 装置界面の定義 装置界面として次の 3 つを定義する。図 2-1 はその 3 つの界面を模式図として示した物である。 図 2-1 インタフェース界面定義の図 表 2-1 は図 2-1 に示す界面の定義を示したものである。 表 2-1．インタフェース界面定義 ．インタフェース界面定義 界面 インタフェース A インタフェース B インタフェース C 説明 装置から随時に、データを送出するための通信 I/F でありデータ保管機能を有することも可能な I/F データ保管機能があり、EE データを利用する際、 より高度に整理されたデータを検索可能な I/F 装置サプライヤが e-Diagnostics を実現するために インターネット経由を前提にした I/F。セキュリティ 機能が必須 © 2002/2003 Selete 11 本仕様書での要求度 EDA 界面がインタフェース A に相当する。本仕様 書では対象外。 ただし、構造上必須であるため、存在は明示する。 データベース間の接続になるため、必須となる。 本仕様書では対象外。装置サプライヤ殿からの提 供は拒まない。 接続方法は別途打合せ。 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.1.2. データライフサイクル データの生成からエンドユーザでデータが消費されるまでの期間をデータのライフサイクルと呼ぶものと する。 データライフサイクルは、大きく「データを提供する側」と「データを利用する側」に分けて考え、下図 （図 2-2）に示すパターンにて表現される。 なお、図 2-2 中にて使用している生成、整理 1/2、保存、報告の定義に関しては表 2-2 を参照のこと。 SEMI Standard PR8準拠 整理 整理11 生成 生成 整理 整理2 シナリオ1 シナリオ2 整理 整理11 生成 生成 シナリオ3 インタフェースA (EDA) (EDA) インタフェースA 整理 整理2 整理11 整理 生成 生成 データハンドリング関連 アプリケーション 整理 整理2 整理 整理11 整理 整理2 生成 生成 保存 保存 保存 シナリオ4 ODBC接続 インタフェースA (EDA) (EDA) インタフェースB（DB to DB） インタフェースA Tool Data Interface (TDI) 装置コア データ提供側 データハンドリング関連 アプリケーション シナリオ1' 保存 保存 シナリオ2' 整理 整理22 シナリオ3' 保存 保存 シナリオ4' 整理 整理22 シナリオ4'' インタフェースB（アプリケーション利用界面） プロセス装置 Factory EES(F-EES) EE業務 アプリケーション 整理 整理22 報告 報告 保存 保存 整理 整理22 報告 報告 データ利用側 図 2-2 データライフサイクル 表 2-2．データライフサイクルの ．データライフサイクルの EE データの動作 区分 生成 整理 1 整理 2 保存 報告 説明 装置によりイベント、アナログ・トレース等の報告可能なデータが生成されること 生成されたデータを EE データとして必要最低限のハンドリングが行えるよう、データに名称／インデックス／タイ ムスタンプなどの基本的な付加情報を、付加する 収集したデータを他のアプリケーションが容易に検索することが可能となる関連付けを行う また付加価値のついた情報の追加を行う（最大／最小／区間平均等） EE データを一定期間保存し、上位のアプリケーションなどからの検索要求に対して、結果をデータとして渡す機 能を持つ 整理 2 によって付加価値が高められた情報のデータの保存も含む あるアプリケーションが介在し、最終的な Viewer への画面出力や、ファイル出力等を行う なお、図 2-2 では、一般的に言う「装置本体部分」のみを対象としたモデル図を示しているが、ポンプや 外付けの電源、温調機器、ガス供給機器などの補器類も同様の扱いとなる。ただし、SEMI スタンダードで は補器類に関しての EDA ポートの要求は無いため、図 2-2 中のシナリオ 3 もしくは 4 と同様の TDI 上に 中継の DB を持つ形態を想定している。 また、この場合のデータ授受のインタフェースは、装置サプライヤ各社の事情により独自仕様に成ること は妨げるものではないが、センサー・アクチュエータ・バスの標準仕様（DeviceNet や Profibus、CC Link 等） の使用を推奨する。 2.1.3. データ保持期間 データ保持期間については装置メーカの設計ポリシーや運用に依存するため一律に定義することは困 難である。従って適切な保持期間は装置サプライヤ・デバイスメーカ間で協議の上決定される物とする。 下表はその保持期間の目安を示す。 © 2002/2003 Selete 12 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 表 2-3．データ保持期間 ．データ保持期間 装置機能 装置データ保管機能無し 装置データ保管機能有り 最短保持期間 通信エラー発生時に復旧するのに必要なバッファーサイズ 最大 3 ヶ月程度を想定 界面 A（EDA）界面 B 界面 2.1.4. データ公開の範囲 TDI 上でデバイスメーカに公開されるデータは、装置がもつすべてのデータの部分集合となる。 またデ バイスメーカはデバイスメーカのために公開されたデータの中から必要なデータを選択してデータを収集 するであろう。従って全体的なデータの関係は下図のようになる。 装置が持っている全てのデータの範囲 TDI 上でデバイスメーカに公開するデータ の範囲 デバイスメーカが選択して 収集するデータ範囲 図 2-3 EES で扱うデータの範囲 © 2002/2003 Selete 13 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.2. 装置エンジニアリングデータの種類 装置から出力される EE データには次の３種類を想定している。 1. イベントデータ（DEE 含む） 2. トレース・データ 3. コンテキスト・データ（装置構成、設定情報） なお、本章で扱う 3 つのカテゴリに分類されるデータの名称の統一やカタログ化、フォーマットなどの定義 に関しては重要な懸念事項であるが、別途 TDI 要求仕様書および F-EES データベース要求仕様書（※） に詳細を記述するため、そちらを参照願いたい。 ※：F-EES データベース要求仕様書は一般公開しないため、必要な場合は Selete クライアント各社より個別に入手願いたい。 2.2.1. イベントデータ 以下に装置詳細イベントデータ（DEE）を含むイベントデータの例を示す。 これらのデータの一部は、リモート I/O などを用いて扱われる場合もある。 1. 2. 3. 4. 5. 6. シーケンス開始／終了イベント（装置本体だけではなく、ロードポートや補器の動作シーケンスも含む） アラームの発生／収束イベント ジョブ開始／終了イベント レシピステップ実行開始／終了イベント 人間の装置操作によって発生するイベント ※これらのデータは、SEMI Standard 準拠の Host イベントと同一の物であってもかまわないが、充分に 事象を表現できる解像度があることが望ましい。 センサ・アクチュエータステータス変化イベント イベントの分類 ※1～5 迄のイベントが収集できなくてもこれによって代替可能な場合がある。 A ‥プログラム・シーケンス系 B ‥装置制御シーケンス系 C ‥アクチュエータ指示 D ‥Ｉ／Ｏセンサ応答 E ‥真空センサ応答 DEE：Detailed DEE Equipment Event ※プログラム・シーケンスで発生するイベントから、センサＩ／Ｏの制御イベントまでのすべてが対象 ABCD イベント 真空引き シーケンス E C D BC D BAABC D BC D 真空・粗引き 真空・粗引き E A 真空・本引き 真空・本引き ドア・閉 ドア・閉 装置内 シーケンス 粗引きポンプＯＮ 粗引きポンプＯＮ DEEデータ データ DEE DEEデータ 粗引きバルブＯＰＥＮ 粗引きバルブＯＰＥＮ 本引きポンプＯＮ 本引きポンプＯＮ 本引きバルブＯＰＥＮ 本引きバルブＯＰＥＮ © 2002/2003 Selete 14 本引き終了 図 2-4 イベントデータ（DEE 含む）の例 イベントデータ（ 本引きＶ 開 本引きＶ 開 真空到達 本引きＰ ＯＮ 本引きＰ ＯＮ 粗引きＰ ＯＦＦ 粗引きＰ ＯＦＦ 粗引きＶ 閉 粗引きＶ 閉 粗引き終了 ＩＮ 粗引きＶ 閉 粗引きＶ 開 ＯＵＴ センサ Ｉ／Ｏ 粗引きＰ ＯＮ 粗引きＰ ＯＮ アクチュエータ ドア閉ＯＮ ドア閉ＯＮ さ ら に 詳 細 な デ ー タ BC D プロセスジョブ（コンテキストデータ、キャリアＩＤ、スロット番号 等） プロセスジョブ（コンテキストデータ、キャリアＩＤ、スロット番号 等） 生産進捗システム 従 来 提 供 デ ー タ BC D 真空到達 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 制御応答 動作応答 処理開始 真空引き チャンバドア閉 チャンバドア閉 ドア閉 粗引き開始 ポンプON ポンプON 粗引きバルブ開 バルブ開 真空バルブ バルブセンサ 真空計設定値 粗引きバルブ閉 バルブ閉 真空バルブ バルブセンサ 粗引き終了 ポンプOFF ポンプOFF 粗引き終了 T T T T T T T T T T T T T T T T T T T T T 10000101 11000101 11100101 11110101 11110111 11010101 11011101 11011111 10100101 10110101 10110111 10110110 10110100 10100101 10110101 10110111 10110110 11010101 11011101 11011111 11000101 True True True True True True True True True True True True True False False False False False False False False DEE Data 制御命令 SStt aatt uuss Jobレベル レシピレベル TTii m m eess ttaa m m EEvv pp eenn tt I IDD 上図のごとくシーケンスレベルの開始/終了も DEE データとして送出することが望ましい。これにより DEE データを装置の外で解釈することが容易になる。後述するジョブ関連情報と同等な役割を果たさせることが できる。 特に DEE データは図 2-4 およびに示すように、装置から出力可能な全てのイベントを対象とし、その総 称として使われている。この DEE データにタイムスタンプ等の適切な情報を付加することで、装置がどのよう に動いて何が起こったかを装置外で完全に再現することも可能である。 図 2-4 は真空装置でプロセス開始前の真空チャンバの粗引きから本引きまで行い、ベース真空圧まで 到達させるシーケンスを想定したもので、生産進捗システムでのマクロ・イベント以下センサ I/O の IN/OUT までを含めて DEE として扱う。 なお、この“マクロ・イベント”には、SEMI スタンダードの E5（SECSⅡ）で定義されている、EventReport （S6F11）としてホストに報告される物に相当する事象を全て包含している必要がある。 図 2-5 上位からの作業の流れとイベント 装置の設計如何により、これよりも更に細かいレベルの DEE データを出力することも可能であるが、おお むねこの粒度までの分解能を持てば、装置の動きを充分に捉えることが可能である。 図 2-5 に示すように、上位の Job レベルから末端のデバイス応答までの全てが DEE データであり、後々 の解析を考慮するとイベント ID と Status のみならず、Timestamp も重要となってくる。 DEE データに添付されている Timestamp の時刻情報から、命令に対する応答なども分析出来るので動 作解析等に活用展開が可能となっている。 また、DEE データは、アクチュエータレベルのイベントからジョブのレベルのイベントまでを全て含むが、 最低限以下のようなデータ構造とするのが望ましい。 DEE に含まれる情報（属性） －１：Timestamp ←いつ －２：Event Reporter ID ←誰が －３：Action Name ←なにをした －４：関連するリソース －５：（付帯情報、Result） ←個別情報、発生順番保証キーなど © 2002/2003 Selete 15 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 一般的な最小構成は“1”～“3”の「いつ」、「誰が」、「なにをした」で記述されるが、そのイベントが何と関 係するかを“4”の関連するリソースで、タイムスタンプによる時系列と共に上から下へ関係を紐付ける事が可 能となる。これを図示したものが、図 2-6 である。 Timestamp Event Reporter Action Name Related Resource Attendant Information Timestamp Event Reporter Action Name Related Resource Attendant Information = = = = = = = = = = XX:XX:XX.aaa Value ID OPEN_START Actuator ID, Open Sensor ID Null Timestamp Event Reporter Action Name Related Resource Attendant Information = = = = = XX:XX:XX.bbb Actuator ID ON None Null Timestamp Event Reporter Action Name Related Resource Attendant Information = = = = = XX:XX:XX.ccc Close Sensor ID OFF None Null Timestamp Event Reporter Action Name Related Resource Attendant Information = = = = = XX:XX:XX.ddd Open Sensor ID ON None Null XX:XX:XX.XXX Value ID OPEN_END Actuator ID, Close Sensor ID Null 図 2-6 DEE データの相関モデル これらのイベントデータは、装置固有の機構を除けば、真空装置に限れば真空生成系、全装置に存在 する搬送系の駆動機構など共通する部分があり、共通する部分は定義を共通化しても支障がないため、可 能な範囲で標準化されることが望ましい。 なお、DEE データに関しては、付録の 7.3.3.1 に PVD 装置をモチーフにした具体的な例を示しているの で、そちらも参照願いたい。 2.2.2. トレース・データ トレース・データは、機能の状態や処理の状態を示すモニタデータである。 トレース・データには、真空特性や加熱推移など、装置の状態を把握するために常に収集する基本機能 のトレース・データと、プロセス圧力、プロセス温度など、プロセス処理中に収集するプロセス関連のトレー ス・データの２種類がある。 収集すべきトレース・データの例を示す。 1. 2. 3. プロセス実行に関連するデータ（PVD 装置ではスパッタパワーやプラズマ強度等） プロセス実行に直接関連しないデータ（真空度、温度、ガス流量等） 装置雰囲気や装置のセットアップ状態を表すデータ。比較的サンプリング周期が低速でよいもの 環境データ（装置周りの気圧、温度、湿度等） 図 2-7 は、真空装置に於ける基本機能のトレース・データとして真空排気特性のデータを、プロセス関連 のトレース・データとしてプロセスガス流量のデータを示したものである。どちらのデータも、適切なタイミング で、適切な量だけ取得できるように設計する必要がある。 なお、トレース・データは装置カテゴリに関係なく同じ意味（真空度といった“圧力”、ガスや薬液などの © 2002/2003 Selete 16 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 “流量”、加熱系統や冷却系統の“温度”、等）を持つデータであることが多いため、定義や記述方法が標準 化されることが望ましい。 図 2-7 トレース・データの例 なお、取得すべきデータの詳細な記述の例は付録 7.3.3.2 に記述されているので、そちらも参照のこと。 2.2.3. コンテキスト・データ（ コンテキスト・データ（装置構成、設定情報） 装置構成、設定情報） コンテキスト・データは、装置の状態を示すパラメータなどで、大きく大別すると、動的に変化し、プロセス に関わりが大きい物（ダイナミック・コンテキスト）と、設定後意識的に変更をしないと変わらない静的な物（ス タティック・コンテキスト）の 2 種類カテゴリが存在する。 なお、コンテキスト・データは装置構成や設定情報などとなるため、先に述べたイベントやトレースのデー タとは異なり、装置の固有性に依存度の高いデータとなっている。 以下にこの 2 種類カテゴリに属するコンテキスト・データの内容を示す。 ①ダイナミック・コンテキスト・データ（Dynamic Context Data） －レシピ設定値：装置毎にカスタマイズされる前の標準レシピ ・データのセットは Host が行い、報告は Host からダウンロード後、処理終了までの間であればいつで もかまわない。データ・セットにはタイムスタンプも必要 －レシピ展開値：装置上で展開された、加工設定値 ・装置制御系が、外部の APC エンジン等の情報を得て展開した展開値。実行値と同時に、ステップ 毎の設定として報告する形態が理想だが、厳密には装置内で解釈、設定後、処理終了までの間で あればいつでもかまわない。データ・セットにはタイムスタンプも必要 －実行値：レシピ実行時の戻り値 ・装置が実際に処理した値。ステップ変更時、次のステップが始まるまでの間であればいつでもかま わない。タイムスタンプは特にこのデータのデータ・セットには非常に重要である また、上記以外のジョブ関連の情報は以下のように解釈し、これらもダイナミック・コンテキストの範疇とす る。 © 2002/2003 Selete 17 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 1. HOST から指示される情報 ウェーハを加工するために必要な HOST から指示されるデータであり、LOT 番号やスロット番号，レ シピ等が該当する。 2. ジョブとの関連 CONTROL JOB ID，PROCESS JOB ID を示す。 図 2-8 はクラスタ型マルチチャンバ PVD 装置でのウェーハ処理の流れに従った、コンテキスト・データの 例を示している。 図 2-8 Job の処理ステップに従って発生するコンテキスト・データの例 キャリア到着時には Lot ID や Slot Map などの Lot/Wafer 情報、レシピダウンロード時には処理プログラム 番号などのレシピ情報、他にも、表示のように JOB 関連情報、実処理情報などがある。 これ以外にも各種定数や設定値などがある。 ②スタティック・コンテキスト・データ（Static Context Data） －装置定数 ・装置構成情報や、部品情報などで、初期設定があり、装置管理者が変更。データの報告は、設定 変更時、あるいは処理実行時にレシピ展開情報に付加して報告するのが望ましい。 －装置オフセット ・個々の装置のオフセットで、装置管理者が手動設定、あるいは、APC エンジンの類のインテリジェ ント機構が自動で設定する。データ報告は、設定変更時、あるいは処理実行時にレシピ展開情報 に付加して報告するのが望ましい これらのデータは、DEE データ、トレース・データと並び、装置の処理経緯を把握するために重要なもの である。 処理をおこなうにあたっての指示値や、指示を受けて設定した値などを示すデータであるため、インター ロックのしきい値などの装置定数も、コンテキスト・データに含まれる。 なお、本データに関しても、取得すべき物の具体的な記述の例に関しては付録の 7.3.3.3 を参照願いた い。 © 2002/2003 Selete 18 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.2.4. 装置エンジニアリングデータの種類のまとめ 2.2.1 章から 2.2.3 で述べた 3 種類の装置エンジニアリングデータを表にまとめる。 DEE を含むイベントデータ、アナログ・トレース・データ、動的／静的なコンテキスト・データの 3 種類の装 置エンジニアリングデータは、更に装置タイプに依存する／しないのカテゴリ分けも可能であり、これらの分 類がデータ出力／収集機能の開発の指針に役立つと考える。 表 2-4．装置エンジニアリングデータの種類（例） ．装置エンジニアリングデータの種類（例） 種別 DEE データ データ例 Host View Event Data（GEM300） Load Prot Status Event ウェーハの装置内動線 プロセス実行遷移タイミング 主用アクチュエータ動作 Trace 人間操作関係イベント (パネル操作／装置メンテナンス関係) 排気特性データ ガス流量 チャンバ／ステージ温度 装置タイプに依存 する しない ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 用力系(電力／水／圧空／排気等) Context プロセスお膳立てデータ (レシピ・レベル/内部展開/実施結果) プロセスお膳立て裏方データ インターロック設定値 装置構成情報 © 2002/2003 Selete ○ 使用目的 装置の生産制御 EPT、FOUP/Load Port 動作監視 プロセス確認とレシピデバッグ、STS 装置基本性能監視 イベントは装置依存しないが、動作は装置依存する メンテナンスと装置稼動来歴との紐付け イベントは装置依存しないが、操作は装置依存する メンテ後の復元度判断、プロセス時の安定性確認 プロセス時の安定性確認 プロセス時の安定性確認 装置稼働環境をモニタし装置が健全に働くことが出 来るかを判断 ○ Nominal 設定値、内部指示値、装置観測値 ○ ○ ○ プロセス設定に対する応答値(装置の正常判断) レシピ(PJ)妥当性判断 レシピ(CJ)の設定ミス等の検出 19 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.3. 装置エンジニアリングデータ送出方法 装置エンジニアリングデータ送出方法 EE データの内容は装置の詳細なデータであるため、そのデータを扱うために、装置は MES との通信と は別の第 2 の通信ポートを追加する必要がある。 この通信ポートを≪EDA（Equipment Data Acquisition） ポート≫と呼ぶ。 EDA ポートは装置と TDI の間での EE データの送受信に関わる I/F であり、MES 通信ポートの ONLINE/OFFLINE に関わらず常時データを送信する必要がある。 2.3.1. 装置から TDI へ 2.3.1.1. EDA ポート・プロトコル EDA ポートはあくまで装置からデータを出力する界面であり、データ参照や、アプリケーションで利用す る為にデータを受け渡す界面は TDI になる。このため、本仕様書では EDA ポート・プロトコルは要求範囲 外としている。 SEMI スタンダードでは、ここを A 界面（Interface A）とし、SOAP/XML によるデータ出力を行う方式が暫 定スタンダード（PR8）として規定されているが、規格策定段階で頻繁に改訂される SOAP/XML によるデー タ出力方式を実装する事は現段階ではリスクが大きい。 また、TDI の上位界面を A 界面と考えれば、装置からデータを出力する界面は PR8 のカバー範囲外と なる。 このため本仕様書の基本理念としては、EDA ポートのプロトコルおよびデータフォーマットは装置サプラ イヤ独自仕様で問題ないと判断している。 2.3.1.2. SEMI スタンダード（PR8）準拠のデータ授受方式への対応 スタンダード（ ）準拠のデータ授受方式への対応 EDA ポートのプロトコルを SEMI スタンダード（PR8）に準拠させる場合（図 2-9 左）は、付録の「7.4.2 章 SEMI スタンダード（PR8）に準拠する場合」を参照のこと。なお、参照先に記載されている情報は XML のタ グにデータの意味を乗せた物であるが、データのメタ情報が提供されている場合は XML での記述を簡略 化しデータ自体を軽量化する事も可能である。 図 2-9 装置エンジニアリングデータ送出インタフェースの差異 2.3.1.3. サプライヤ独自仕様の場合（ サプライヤ独自仕様の場合（図 合（図 2-9 右） 通信プロトコルやデータフォーマットは前述のようにサプライヤ殿にお任せすることを前提とするが、後述 のデータ収集プランやデータのメタ情報を装置仕様の一部として提示願いたい。 データのメタ情報は出力するデータの内容とフォーマットの情報で、実際の装置運用に於いては必要性 が乏しいものではあるが、デバイスメーカ側としては出力されるデータ・コンテンツとしてメタ情報を活用する © 2002/2003 Selete 20 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 場合があるため、可能な範囲で提供頂く事が望ましい。 また、データ収集プランやメタ情報は出力されるデータの重みを左右する重要な取り決めでもあるため、 サプライヤとユーザの間で充分仕様を熟慮する必要もある。 また、トレース・データは一般的に、予め決められたサンプリング・レートで発生したデータを一時的に集 積し、ある一定期間で送信することが想定されているが、DEE データに関しても、一定時間あるいは一定件 数のイベントを集積してから送信する方法が考えられる。 なお、イベントデータは発生時に随時送信するのが本仕様書の考え方の前提にはなっているが、データ 管理上 DEE も集積してパケットとして送信した方がシステムとして負荷が軽減される場合は、これを妨げず むしろ積極的に推奨する。 2.3.1.4. データ収集プラン機能 本仕様書の段階ではダイナミックに使用できるデータ収集プラン（Data Collection Plan = DCP）機能を要 求しない。収集されるデータの送信を行うか否かは、装置上の MMI 等より各項目毎に設定可能であれば 充分機能を果たせる。個別のデータの設定は多岐にわたるため、変更の便宜を目的として下記のようなデ ータの集まりを示すグループを選択する方法が現時点では最も理にかなった方法と考えられる。 なお、装置自身が状態を判断してあらかじめいくつかのパターンを設定した DCP を切り替える機能も考 えられる。実際に搭載する事も技術的にはさほど困難ではないため、機能の搭載が可能であれば積極的 に推奨するものである。 <例> ①装置立上げ用データグループ 想定外の異常を検出する。全てのデータを送信する。サンプリング・レートも高い。 ②FDC 用データグループ 装置動作の解析、ある特定の異常に注目してその原因を検出できるデータを送信する。 ③予知保全用データグループ 保全に必要な最低限のデータを送信する。 ④プロセス処理管理用データグループ プロセス処理中の変動を検出するために、特定の期間だけ指定した部位のサンプリング・レートを上 げてデータを送信する。 2.3.2. TDI 界面から F-EES DB、アプリケーションへ 、アプリケーションへ 2.3.2.1. EE データ提供形式の定義 EE データの収集にあたり、その対象となる EE データの提供形式の定義が必要である。SECS/GEM によ る装置データの収集においても、その対象となるデータの提供形式はホスト通信仕様書に記載されており、 装置サプライヤ殿から予め提示いただいている。EE データの収集に関しても、同様に対象データの提供 形式を装置サプライヤ殿から提示いただきたい。以下に EE データ提供形式の定義に関する考慮事項及 び、その他補足事項を示す。 2.3.2.2. 対象データの選定 EE データの対象となるデータは、基本的には装置サプライヤ殿から提案いただく。装置エンジニアリング システムに必要となる EE データの種類を 2.2 章に記載しているので、各装置の該当するデータを選別して いただき、対象となるメタ情報としてデータ提示をしていただきたい。 2.3.2.3. Selete 推奨のデータ授受方式への対応 Selete が推奨案として想定するシステム構成では、装置から出力されるデータは一旦 TDI に報告され、 TDI 上において（装置上で可能な場合はその限りではない）アプリケーションで活用できる最低限の情報を 付加する。そして、再度蓄積を行い、ライン全体を統括する工場レベルの F-EES データベースからの要求 に対してデータを報告する、あるいは各種アプリケーションの要求に基づいてデータを提供する事を想定し © 2002/2003 Selete 21 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 ている（「6 章 Selete 提案仕様」及び「図 6-1 Selete 提案システム」参照のこと）。 この場合、データ授受に用いられるプロトコルは汎用的なデータベース間の通信方式（ODBC や JDBC 等）を想定している。 このため、装置から Push 方式で直接データを授受することを想定した通信フォーマットより、報告先のデ ータベースや EE アプリケーションがデータ利用の為に用いる View を構築する際に必要とする情報や、一 旦蓄積される中継データベースのデータ構造の方が重要となる。 なお、本件に関しては別途 TDI 要求仕様書および F-EES データベース要求仕様書（※）に詳細を記述 するため、そちらを参照願いたい。 ※：F-EES データベース要求仕様書は一般公開しないため、必要な場合は Selete クライアント各社より個別に入手願いたい。 2.3.2.4. データ送受信界面の送出データフォーマット EE データの収集にあたり、その対象となるデータが装置から送出されるときのデータフォーマットを提示 いただきたい。データフォーマットに関しては以下のケースを想定している。 ! View を介した ODBC/ＪＤＢＣ等による TDI／F-EES DB 間の直接通信のケース ※データフォーマットではなく、F-EES データベース内の格納構造とそれに対する TDI 側の対応方法が重要になる ! ! ! XML フォーマットのケース CSV フォーマットのケース 固有フォーマットのケース 以下にそれぞれのケースにおける考慮事項及び、その他補足事項を示す。 ①ODBC/JDBC による TDI／F-EES DB 間直接通信のケース 別途“Tool Data Interface (TDI)機能要求仕様書”を参照願いたい。TDI ベースのデータ授受の概要 は「7.4.1 章 Selete 推奨仕様に準拠する場合」を参照のこと。 ②XML フォーマットのケース 前述のように、XML フォーマットのケースでは基本的には XML のスキーマで提供いただきたい。 XML の定義は Web サービスの提供も踏まえて以下の定義方法を想定している。 ! ! XML Schema WSDL（Web Service が提供されるケース） この場合は EDA ポートから XML フォーマットでデータを出力する場合と同様なため、詳細は付録の 「7.4.2 章 SEMI スタンダード（PR8）に準拠する場合」を参照のこと。 ③CSV フォーマットのケース CSV フォーマットにて EE データが送出（または転送）される場合は、CSV のフォーマットを定義してい ただきたい。複数のフォーマットが存在する場合は、それぞれのフォーマットを明記していただき、前 述のデータ定義で記述されている各データの配置や、フォーマットタイプの判別方法など、データの 受信側が正確にデータを解読できるための情報をドキュメントで提示いただきたい。 ④固有フォーマットのケース 固有フォーマットでデータが送出されるケースは、そのフォーマットの構成や文法など、データの読み 込みに必要な一連の規約に関する情報をドキュメントで提示いただきたい。 ⑤通信プロトコルとの関連 本仕様書の「7.4.1 データ通信方式」ではデータフォーマットと通信プロトコルの関係に関して説明して いるが、データ転送プロトコルによって考慮すべき事項が存在する場合は、その旨の補足説明をドキ ュメントに記載していただきたい。 © 2002/2003 Selete 22 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.4. 装置構成定義 データの解析のためには、装置から送出する EE データに装置構成の情報を付加し、データの発生元を 特定する必要がある。 以下に装置構成の情報を示すための装置構成のモデルを定義する。このモデルで定義された装置構 成要素は、前章の第 2.3.2.1 章から記載されているデータ定義に含まれる事が望ましい。 2.4.1. 装置構成モデル Equipment／Module／Subsystem／IODevice の階層を持ち、以下のように構成される物とする（真空装 置の例を第 7.3.1 章、第 7.3.2 章に記載する）。 図 2-10 装置構成物の論理モデル 装置構成物の論理モデル 2.4.1.1. OBEM（ （SEMI Std. E98）適用性 ）適用性 適用可能な場合は妨げることはない。 2.4.1.2. CEM（ （SEMI Std. E120）適用性 ）適用性 適用可能な場合は妨げることはない。 © 2002/2003 Selete 23 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.5. 階層によるジョブと履歴 データの解析のためのもう一つの側面として、装置から送出する EE データにジョブ関連情報を作用させ て、データのジョブ生成履歴を特定し、F-EES 上においてアプリケーションによるデータの活用が容易にな るようにする必要がある。ジョブ関連情報は EE データと一緒に装置から送出される場合もあるし、固定的で ある場合には EE データが送出された後にジョブ関連情報を使って、装置外部で関連付ける場合もある。 以下にジョブ関連情報を得るためのジョブ階層モデルを示す。このモデルの階層にしたがってアプリケ ーションがデータを扱うことが多い。各ジョブの構成要素は、第 2.3.2.1 章に記載されているデータ定義に含 まれる事が望ましい。このジョブ関連情報は、付録の表 7-9．Event Message Body が参考になる。 但し、DEE データのように一つの TAG によって複数のセンサ情報をまとめて報告する場合などは、ジョブ 階層を付加することは難しい。従って、データユーザが EE データ解析を行う際にジョブ履歴情報を利用で きるように、装置サプライヤはジョブ関連情報を含む仕様書を予めデバイスメーカに提出する必要がある。 図 2-11 Job 構成要素の論理モデル © 2002/2003 Selete 24 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 2.6. SEMI スタンダードとの関連性 本仕様書にて規定する各項目の内容の一部には SEMI スタンダード（開発中を含む）の一部が該当若し くは関連する。第 2.1.1 章で規定するインタフェースのレベル（EDA、TDI）に対して、各々の適用要求を表 2-5 に示す。適用可能なスタンダードに関しては、本仕様書では実装を要求するものではないが、装置サプ ライヤ殿で実装可能と判断されるものに関してはこれを妨げるものではない。 表 2-5． ．SEMI スタンダードとの関連性 SEMI スタンダード #3442 （RaP） #3507 （Authentication and Authorization） #3509 （Data Collection Management） #3570 （XML Common Components） #3527A （PCS） #3571 （EDA Guide） #3731 （XML Schema for CEM） E10 （RAM）／E58 （ARAMS） E30 （GEM） E39 （OSS） E40 （Process Job） E53 （Event Reporting） E54 （Sensor/actuator Network） E88 （CMS） E90 （STS） E94 （Control Job） E98 （OBEM） E116 （EPT） E120 （Common Equipment Model） E121 （Guide for Style & Usage of XML） E125 （Equipment Self Description） E126 （EQIP） E128 （XML Message Structure） PR8 （EDA Solutions Proposed Standard） EDA 上位界面 該当せず 使用しない 参照しても良い 参照しても良い 該当せず 参照しても良い 参照しても良い 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず（※） 該当せず 該当せず 該当せず 参照しても良い 該当せず 参照しても良い 参照しても良い 参照しても良い 該当せず 参照しても良い 参照しても良い ※ PR8 準拠の EDA ポートの場合。PR8 に準拠しない場合は参照してもよい。 © 2002/2003 Selete 25 TDI 上位界面 該当せず 参照しても良い 該当せず 該当せず 参照しても良い 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 該当せず 参照しても良い 該当せず 参照しても良い 該当せず 参照しても良い 該当せず 該当せず 該当せず EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 3. 装置エンジニアリング業務に必要なアプリケーション F-EES および TDI に搭載されるアプリケーション群は、データ収集界面からのデータの収集，整理，保存 するデータハンドリングに関するベースアプリケーション群と EE 業務を遂行するための応用アプリケーショ ン群の 2 種類に大別できる。 本仕様書は、装置から出力されたデータを TDI 上で一時的にバッファリングし、上位の F-EES データベ ースからの要求に対してデータを出力したり、F-EES 上の EE アプリケーションからの要求に応じてデータを 提供したりする場合に扱うデータのハンドリングを記述範囲としているため、TDI 上には最低限以下のデー タハンドリング系アプリケーション群の実装をお願いしたい。 3.1. データハンドリング関連アプリケーション 装置上の A 界面で収集されるデータは、送出データフォーマットの意味付けが成され、そのまま EE 業務 アプリケーションで利用可能な状態の物が理想的ではあるが、識別子とタイムスタンプのみが付加されその ままでは解釈できない制御信号レベルの ON/OFF の羅列にしかすぎないデータが主流であると想定してい る。 このようなデータは、報告された時刻の情報や予め決められたデータ定義書及び補足説明（どの桁がど の部分の何の動きの ON もしくは OFF を示しているか、等）を用いて意味付けする必要が生じる。このような データの意味付けを行うアプリケーションが DEE データをハンドリングする上で重要となってくる。 本仕様書では装置メタ情報を基にデータハンドリングのアプリケーションが上記の ON/OFF の羅列レベ ルのデータを解析し意味付けることが可能であれば、装置上の A 界面からはそのままアプリケーションで使 用可能な状態まで意味付けされたデータの送信は不要と考える。 このため、TDI 上には以下の機能を満たすアプリケーションの実装が必要となる。 ・ データ収集・整理 －データを収集し、DB 等に格納する形に整形し、一時的に TDI 上に蓄積する。上記のデータの意味 付けを行うアプリケーションもこの機能に含まれる。 ・ データ保存・削除 －データを DB に格納し、予め決められたルールで圧縮移動や、間引き，削除等を行う。 ・ データ発信 －EE アプリケーションや他のコンポーネントからの要請に従い、データを発信する。e-Diagnostics など の機能の末端部分に相当する。 ・ 履歴データ管理 －装置／モジュールの稼働履歴や装置に対する作業履歴などのマクロな履歴管理。 以下の機能は上位の F-EES レベルで対応する物であるが、可能であれば実装を拒む物ではない。 ・ データ集計 －後述する EE アプリケーションで活用するために、一次統計処理等を行う。装置の稼働管理等の業 務はこのレベルで対応可能と考える。 ・ 他情報とのリンケージ －MES 系や YMS 系の情報との紐付けを行う。 個々の機能の詳細は「EES ユーザ要求システム仕様書（USRD）」を参照願いたい。 © 2002/2003 Selete 26 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 3.2. EE 業務アプリケーション EES では本仕様書で規定するデータを用いて下記する機能が使用されると想定している。詳細は「装置 エンジニアリングシステム ユーザ要求書（EES-URD）」の第 3.1 章「機能要求」中の 3.1.2 から 3.1.12 迄の 項目を参照のこと。ここで記述されているアプリケーションは装置の稼動状態を把握しその動作と装置上で 展開するプロセスの性能を保証していくために必要となる。 なお、本仕様書で記述している EE アプリケーションは、装置上に実装することは想定しておらず、デバイ スメーカのユーザが使用するために EES 上に搭載される物を想定している。しかしながら、装置サプライヤ が自分自身の装置性能を保証するために活用するアプリケーションが当然存在するため、そのアプリケー ションを装置上や TDI 上へ実装するケースもあって然るべきであり、それを拒む理由はない。むしろ、装置 性能維持のため、違った視点での装置管理をお願いする上でも積極的なアプローチを期待する。 なお、上記にあるように本仕様書での要求範囲外のアプリケーション／機能を搭載する場合で、日常の 装置管理で装置ユーザに対して公開しても差し支えないものに関しては請仕様書に記載、もしくは別途仕 様書を添付するようお願いしたい。 3.2.1. 装置運転管理に関する機能 装置運転管理に関する EES ユーザが使用するために実現されるべき機能としては以下の業務を視野に 入れている。機能の詳細は EES-URD の第 3.1 章「機能要求」中の該当項目を参照のこと。 ・ 日常監視 －装置の状態をモニタリングし、EES ユーザからの要求に応じ装置状態を報告する事までを想定して いる。（3.1 データハンドリング関連アプリケーション参照）この業務により装置の詳細な稼働経 緯の再現や稼働状態が算出できるデータも蓄積されるため、後々の装置改造や新機種設計へのフ ィードバック情報として活用することも可能である。 ・ 異常検知（一次診断）・発報 －EES 上で行う異常検知（FDC）を示す。短期間の傾向管理等から、装置自身のアラームでは検知で きないレベルの警告を出す業務を想定している。 ・ 異常解析（二次診断）・発報 －一次診断による警告発報に基づき、装置情報を解析し原因推測を行う業務部分までを想定してい る。 ・ 検査実行判断／依頼 －日常監視や異常検知／解析の結果、なんらかの検査を行う必要がある場合、EES から提案を行う。 NPW 発行依頼などの業務も視野に置く。 ・ 管理値編集機能 －上記機能の判断ロジックやしきい値の編集／メンテナンスを行う機能。 ・ インターロック管理 －装置のインターロックの設定に異常がないかを検知し記録／通知を行う機能。異常値が設定されて いないか等を検知する。装置の制御システムとして論理的に不整合（装置の運転に直接の影響は ないが、ある部位の信号が ON のままの状態であるのはおかしい、等）が有るか無いかを検知できれ ばなお良い。 なお、EES-URD ではこの章で、上記の他に「機差吸収」と「チャンバ差吸収」等の機能を列挙している が、これらはプロセス制御に深く関わる機能であるため、本仕様書では言及しない。ただし、将来的には 視野に入れるべき物であるため、搭載を拒む物ではない（搭載の場合は仕様書に明記のこと）。 3.2.2. 保守作業支援機能 保守作業支援に関する機能は以下の項目を視野に入れている。機能の詳細は EES-URD の第 3.1 章 「機能要求」中の該当項目を参照のこと。 保守作業の支援に関する機能は前項の「装置運転管理に関する機能」でもたらされた結果を基に保守 27 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 要員や装置サプライヤのフイールド・サービスのエンジニアが作業を行う際に EES のアシストを受けるべき 項目である。 ・ 作業支援 －実際の保守にあたり、故障箇所やメンテナンスの必要箇所へのナビゲーション、作業提案を電子マ ニュアル等によって実施する。なお、この機能は機能対効果の非常に大きなものであることも想定さ れるので、是非とも搭載をお願いしたい。 この機能は、本来 EES を仲介して外部からのリモート指示等もサポート範囲とする。この部分は本仕 様書では言及しないが、実装されることは拒まない。 ・ 診断解析支援 －実際の保守作業にあたり、EES から提案された推測原因等の確認作業を行う場合に装置の診断／ 解析を支援する、あるいは EES からの提案による予知保全とは別に、定期点検等を行う場合に装置 の診断を行う為に必要な機能である。 更に保守作業後の確認のための診断を行う場合にも、その作業が有効であったか否かを判断する ために必須となる機能である。 この場合 EES が具備すべき機能は異常検知や異常解析と同様であるが、保守作業の前後で必要 となる。 ・ 入力支援 －作業内容や結果を、EES を通じて入力することにより、EES の履歴データベースに紐付けされた形 で記録を残すことが出来る。そのために入力支援インタフェースを提供する。 EES で DEE データを収集することにより、装置の挙動を再現／解析できることから、保守作業の記 録を紐付ける事は、その作業により装置の挙動がどう変わったか、あるいはその作業が有効であっ たかを見極める上で、きわめて重要な項目と成るため、是非とも搭載をお願いしたい。 なお、EES-USAD（ユーザシステム分析書）ではこの章で、上記の他に「事前提案」の機能を記述して いるが、これは MES 系のスケジューラ／ディスパッチャ、資材系のシステムはもとより、人事 DB まで関わ る機能であり、直近での実現も難しいため本仕様書では言及しない。 3.2.3. レシピ管理 レシピ管理は以下のような機能を想定している。 ・ 装置のレシピ来歴管理（時系列管理等） －装置の稼働来歴や、保守来歴と照らし合わせ、その時々の最適な設定を提案できればなおよい。 ・ 同機種他号機間での横睨み監視 －同機種複数号機間でのクセを監視 ・ レシピエディタの機能を搭載 －装置のクセのデータが手元にあると、レシピの編集にも有利。 ・ レシピの妥当性評価 －装置状態／構成情報などで、実行しようとしているレシピが問題なく使えるかどうかを判断し、結果 を報告する機能 レシピ管理は EES 本来の目的としてフィーチャーされている装置の稼働管理／保証面からは異質な分 野ではあるが、コンテキスト情報としてレシピの指示値、設定値、実行値のデータを持つため、上記のような 作業を行う場合にも有用なプラットホームとなる。 EES の目的は装置の稼働状態を最適且つ一定に保つのが第一意ではあるが、装置上で実行されるレシ ピも密接な関係を持つ。このため、EES 上でレシピを管理する事は装置の状態を横目で確認しながら行え るため、最も効率的且つ効果的であると結論付けができる。 © 2002/2003 Selete 28 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 3.3. SEMI スタンダードとの関連性 本仕様書にて規定する各項目の内容の一部には SEMI スタンダード（開発中を含む）の一部が該当若し くは関連する。適用可能なスタンダードに関しては、本仕様書では実装を要求するものではないが、装置 サプライヤ殿で実装可能と判断されるものに関してはこれを妨げるものではない。 表 3-1． ．SEMI スタンダードとの関連性 SEMI スタンダード #3442 （RaP） #3507 （Authentication and Authorization） #3509 （Data Collection Management） #3527A （PCS） #3531 （XML Schema for CEM） #3570 （XML Common Components） #3571 （EDA Guide） E30 （GEM） E10 （RAM）／E58 （ARAMS） E39 （OSS） E40 （Process Job） E53 （Event Reporting） E88 （CMS） E90 （STS） E94 （Control Job） E98 （OBEM） E116 （EPT） E120 （Common Equipment Model） E121 （Guide for Style & Usage of XML） E125 （Equipment Services Description） E126 （EQIP） E128 （XML Message Structure） PR8 （EDA Proposed Standard） © 2002/2003 Selete 関連性 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 使用しない 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 参照しても良い 29 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 4. セキュリティ対策 装置データ収集界面におけるセキュリティ対策として、デバイスメーカが装置サプライヤ殿に対して特別 に要求する項目は特にない（ただし、デバイスメーカのファイヤーウォールを経由した遠隔アクセスのセキュ リティ対策に関しては別途検討：4.2.2 章を参照）。 機密情報の保護に関してはシステム上の仕組みによるデータの保護（アクセス制御、認証、暗号化など） が必要とされるケースも存在するが、その適用にあたっては各デバイスメーカのセキュリティポリシーやセキ ュリティ管理運用によって異なり、一律に定義することはできない。したがって、具体的なセキュリティ対策の 適用にあったては、装置サプライヤとデバイスメーカとの間で協議の上決定されるのものとする。 一般的なセキュリティ対策に関するデバイスメーカ側の基本的な方針を以下に示す。 4.1. デバイスメーカ側のセキュリティ対策の方針 セキュリティ対策の適用に関するデバイスメーカ側の基本的な方針を以下に示す。 4.1.1. 機密保持契約 EES で取り扱う EE データは、デバイスメーカと装置サプライヤの間（場合によってはサードパーティも含 む）で締結される機密保持契約で基本的には定義され、保護される。対象となる機密情報は機密保持契約 書に明記され、その機密情報の取り扱いに関しては両者合意の上決定されることを前提としている。 4.1.2. アクセスコントロール EES の基本的な構成においては、装置は限定されたクライアント（アプリケーション）との間で情報の受け 渡しを行うことを前提としており、不特定多数のクライアント（アプリケーション）とのコミュニケーションは想定 していない。従って、Switching HUB のルーティング機能（IP ロック）やフィルタリング機能により、アクセスの 制御、ネットワークトラフィックの制御、不正アクセスの防止及び、装置ベンダー間の情報漏洩の防止を図る こととする。 図 4-1 ルーティング機能やフィルタリング機能によるアクセス制御のイメージ © 2002/2003 Selete 30 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 4.1.3. 認証 FAB 内のクローズされたネットワーク環境においては、以下のようなセキュリティ対策が別途実施されてい ることを前提としている。したがって、運用コストなどの問題を含めて考慮すると、個々の装置と個々のクライ アント（アプリケーション）との間のセッションレベルの個別認証は、将来的には視野に入れているものの、本 仕様書の段階では導入しない方針である。 ! ! ! ! ! 装置サプライヤやサードパーティとの機密保持契約の締結（前述） ルーティング機能やフィルタリング機能によるアクセスの制御及び、装置ベンダー間の情報漏洩の防 止（前述） FAB 内への入退場管理の徹底 （FAB 内には悪意あるハッカーは入場しない前提） 外部からの持ち込み PC の FAB 内ネットワーク環境への接続制限 アクセスログの収集及び、ログの定期的な監視 4.1.4. 暗号化 FAB 内のクローズされたネットワーク環境においては、情報の暗号化は必要ないと考え、一切の暗号化 を要求しない。前述のように、ルーティング機能やフィルタリング機能によるアクセス制御で、不正アクセス の防止及び、装置ベンダー間の情報漏洩の防止を図る予定であり、データや通信情報の暗号化は必ずし も必要ではない。また、暗号化によるレスポンス低下の懸念や、運用コストなどの問題などを含めて考慮す ると、個々の装置とのコミュニケーションや情報の蓄積における情報の暗号化は導入しない方針である。 © 2002/2003 Selete 31 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 4.2. 装置サプライヤ殿のセキュリティ対策に対する要望 装置サプライヤ殿の観点で適用されるセキュリティ対策に関して、デバイスメーカ側の基本的な要望を以 下に示す。 4.2.1. FAB 内の環境におけるセキュリティ対策 前述のように、FAB 内の環境においてはルーティング機能やフィルタリング機能によるアクセス制御を基 本的なセキュリティ対策としており、その他のセキュリティ対策（認証、暗号化など）は必要ないと考えてい る。 ただし、装置サプライヤ殿が自己のデータの機密を保持するため、あるいはデバイスメーカの機密を侵 害しないために、別途セキュリティ対策を施すことに関しては、その施策を妨げるものではない。しかし、そ れらのセキュリティ対策の実施にあたっては、デバイスメーカ側の環境や運用に影響を及ぼすことも考えら れる。したがって、装置サプライヤ殿で要求されるセキュリティ対策に関しては、明確なドキュメントが事前に 提示されることとし、その適用にあたっては両者合意の上で決定されるものとする。 4.2.2. ファイヤーウォール経由による遠隔アクセスに対するセキュリティ対策 デバイスメーカのファイヤーウォール経由または、別のアクセス経路にて直接各装置に遠隔アクセスする 場合は、前述のセキュリティ対策の方針とは異なる。この場合は可能な限り強固なセキュリティ対策を施す 必要があり、公的認証、暗号化、VPN 敷設など包括的なセキュリティ対策が要求される。ただし、遠隔アク セスに関しては各デバイスメーカでセキュリティポリシーが異なるため、ここで一律に定義することはできな い。提供されるサービスの中に遠隔アクセスが含まれる場合は、その運用や個々のセキュリティ対策に関す る明確なドキュメントが事前に提示されることとし、その適用にあたっては両者合意の上で決定されるものと する。 図 4-2 ファイヤーウォール経由による遠隔アクセスのイメージ © 2002/2003 Selete 32 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 4.3. SEMI スタンダードとの関連性 本仕様書にて規定する各項目の内容の一部には SEMI スタンダード（開発中を含む）の一部が該当若し くは関連する。適用可能なスタンダードに関しては、本仕様書では実装を要求するものではないが、装置 サプライヤ殿で実装可能と判断されるものに関してはこれを妨げるものではない。 表 4-1． ．SEMI スタンダードとの関連性 SEMI スタンダード #3507（Authentication and Authorization） © 2002/2003 Selete 関連性 参照しても良い 33 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 5. 仕様準拠表 別途定める。 © 2002/2003 Selete 34 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 6. Selete 提案仕様 本章においては、これまで記述してきたシステムに関する具体的な仕様の１例として、Selete の提案 仕様に関する説明を行う。 図 6-1 に Selete 提案仕様の概略を示す。本提案におけるシステム上の特徴は、 1. 装置からの EE データの取り出しは装置データ・インタフェース（TDI）と呼ぶ専用の計算機を経由 して行う。TDI は装置の筐体へ格納するのが望ましい。 2. TDI からのデータ取り出しは、ODBC や JDBC などのオープンなデータベースアクセス手段により 工場側データベースサーバから行う。データ取得のエラー処理の制御も工場側データベースサ ーバから実施する。 3. 工場側データベースサーバは市販の DBMS を用いて構築する。 4. サプライヤ殿が準備されるアクセスコントロールなどのセキュリティ機能は TDI に実装する。また、 アプリケーションソフトも原則として TDI 上に実装するのが望ましい。 5. 開発途中のアプリケーションやデバイスメーカで準備するアプリケーションソフトはアプリケーショ ンサーバにこれを実装して評価、運用を実施していく。 図 6-1 Selete 提案システム 本提案仕様において構築したシステムは、管理するラインの規模や構成に応じてその詳細構成を 調整する必要がある。調整の範囲や方法に関しては、システムベンダや依頼元の委託者と相談の上 詳細仕様を決定して頂きたい。 © 2002/2003 Selete 35 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7. 付録 7.1. データのオープン性 7.1.1. 装置エンジニアリングデータオープン化の有用性 EE データをオープン化により OEE 向上に役立つ事を、Photo 工程の塗布⇒露光間搬送の例で示 す。 C/D C/D TR TR Req Req TR TR Ack Ack ARM ARM Ex Ex ON ON Pin Pin UP UP ON ON ARM ARM Ex Ex OFF OFF Pin Pin UP UP OFF OFF Complete Complete Chuck Chuck OP/CL OP/CL Buffer収納 収納/取出 収納 Buffer収納 収納/取出 取出 収納 取出 STP STP PI/O PI/O Handshake Handshake Robot伸縮 伸縮/回転 伸縮 Robot伸縮 伸縮/回転 回転 伸縮 回転 C/D C/DCLOCK CLOCK STP STPCLOCK CLOCK STP STP -> -> CD CD Buffer Buffer CD CD -> -> STP STP Buffer Buffer C/D(Coater/Developer) C/D(Coater/Developer) STP(Stepper) STP(Stepper) 図 7-1 Photo litho 工程の塗布⇒露光間搬送のイベントの例 上図において、①のポジションから④のポジションへの移動時間を一定にしたいという要求があったとす る。 この場合、移動時間を測定することはもちろんであるが、以下のような要求が考えられる。 ・変動した場合は、その要因を解析する必要がある。 ・可能であれば、障害となる前にメンテナンスを行いたい。 ・更に障害（アラーム）が発生した場合は、その被害を最小限にしたい。 装置にはシーケンスイベント、I/O デバイスイベント、アラームイベントなどの EE データをオープンな形で 取得する機能を搭載する。このデータを、図に示したような解析用のアプリケーションに読み込むと、要求 する機能を実現できることになる。 この例では、デバイスメーカ、塗布／現像工程の装置メーカ、露光工程の装置メーカの間で、データを 共有して協力体制をとることになる。 EE データを取得する機能を装置に搭載し、取得したデータをオープン化することにより、上記のような要 求を満たす OEE 向上アプリケーション作成が可能となる。 © 2002/2003 Selete 36 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 図 7-2 EE データのオープン化による OEE 向上アプリケーション例 装置にはシーケンスイベント、I/O デバイスイベント、アラームイベントなどの EE データをオープンな形で 取得する機能を搭載する。このデータを、図に示したような解析用のアプリケーションに読み込むと、要求 する機能を実現できることになる。 この例では、デバイスメーカ、塗布／現像工程の装置メーカ、露光工程の装置メーカの間で、データを 共有して協力体制をとることになる。 EE データを取得する機能を装置に搭載し、取得したデータをオープン化することにより、上記のような要 求を満たす OEE 向上アプリケーション作成が可能となる。 © 2002/2003 Selete 37 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7.2. データライフサイクルの例 データライフサイクルの観念から装置の実装パターン例を以下に挙げる。図中のアイテムは以下の意味 を示す。 黄色矢印 ： データの流れを表す。 赤色矢印 ： データのリクエストを表す。 以降のデータライフサイクル例で使用している区分については 2.1.2 章を参照のこと 7.2.1. TDI を想定したデータライフサイクル 装置は整理 1，整理 2 を行ったデータを送信するだけでなく、上位アプリケーション等からのデータリクエ ストにより、検索データを送信する必要がある。 図 7-3 TDI を想定したデータのライフサイクル例 データの整理 2 や保存は、装置内で行っているように見せかける場合と、物理的にＴＤＩを利用しているこ とを明示的に示す場合がある。 © 2002/2003 Selete 38 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7.3. 装置エンジニアリングデータの例 7.3.1. マルチチャンバ真空装置構成例 具体的な装置を例に、EE データの属性と、装置の構成との関連について説明する。 図 7-4 はクラスタ型マルチチャンバ PVD 装置（真空処理装置の代表例）の構成例であり、以下に示すユ ニットにより構成されている。 図 7-4 真空装置（PVD）の構成例 ）の構成例 真空装置（ この装置は真空プロセス装置としてはかなり複雑な部類に属し、一般的にメインフレームと呼ばれる搬送 チャンバを中心に配置し、ウェーハ・キャリアが装架されるウェーハ搬送ユニット（Transport Unit : Transfer Chamber, EFEM）と、搬送チャンバとはロードロック（Load Lock）で結ばれている。ウェーハを加工するプロ セスユニット（ProcessUnit : Sputtering Chamber, Etching Chamber, Heat Chamber）は搬送チャンバに接続、 配置されており、各々のユニットにはそのユニットを運転するための補機が配置され、それら全体が装置を 構成している。 図 7-5 真空装置（PVD）の装置モデル例 ）の装置モデル例 真空装置（ © 2002/2003 Selete 39 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 PVD 装置の場合、プロセスユニットにはウェーハを加熱する加熱チャンバ、成膜前にウェーハ表面から 自然酸化膜などを除去するエッチングチャンバがあり、実際に成膜を行うスパッタチャンバがある。この例で は、更にプロセスユニットのうちスパッタチャンバについて注目し、細分化を進める。 図 7-5 は、クラスタ型マルチチャンバ PVD 装置を論理的に示したものである。 PVD 装置を構成する各々のユニットは同列で解釈され、この図では一番左側に、例にとるスパッタチャン バがある。 7.3.2. マルチチャンバ真空装置プロセスユニット構成例 図 7-6 はクラスタ型マルチチャンバ PVD 装置内のプロセスユニットの構成例である。図 7-4 で示したマ ルチチャンバ PVD 装置のスパッタチャンバ部分の構成図を表示している。 スパッタチャンバに着目したため、各構成ユニットの記述粒度が一段上がる。 図 7-6 プロセスユニットの構成例 プロセスユニットの構成例 スパッタチャンバは主に成膜するための材料となるターゲット、電圧を印可し、電流を制御、スパッタリン グのための放電を発生させるスパッタ電極と、被加工物であるウェーハを載せるステージ部分から構成され ていて、それぞれサブシステム・コントローラ（SubsystemController）で制御されている。 このスパッタチャンバでウェーハを加工（この場合は成膜）するために、スパッタチャンバのサブシステム・ コントローラには電圧を印可する DC 電源制御システム（Power Supply）、ウェーハの温度を制御するための 温度制御機構（このモデルではガスでステージ温度を制御）やウェーハのチャッキングを制御するウェーハ ステージ（Wafer Stage）の制御システム、プロセスに使用するアルゴンや反応性スパッタ用の窒素ガスなど を供給するガスライン（Gasline）の制御システム、さらにチャンバの反応圧力を制御する真空（Vacuum）制御 システムが接続される。 これらのプロセスチャンバに接続される個々の機能ユニットは各々バルブや電源制御機構などの制御単 位が存在する。 EES では必要に応じてこれらのプロセスチャンバに接続されている個々の機能ユニットの、内部の制御 単位まで着目する。 図 7-7 はプロセスユニットであるスパッタチャンバに関わる装置構成要素を網羅した論理図である。 © 2002/2003 Selete 40 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 図 7-7 プロセスユニットのモデル例 プロセスユニット（この場合はスパッタチャンバ）の下には真空、電源、ガスライン、ウェーハステージを制 御するサブシステム・コントローラが配置され、そのサブシステム・コントローラの下にセンサ・アクチュエータ 部分が配置される。 また、サブシステム・コントローラはさらにいくつかのサブシステム・コントローラを持つ場合もあり、この例 ではウェーハステージの制御を行うサブシステム・コントローラの下に複数の階層に渡ってサブシステム・コ ントローラが存在することを示している。 EES では、最終段のセンサ・アクチュエータのレベルまで着目する必要がある。 EES で取得する EE データは、この装置構成要素との関係を正しく定義して使用する必要があるので、装 置メーカはこの情報を提供する必要がある。 7.3.3. 真空装置データ収集項目例 以下にクラスタ型マルチチャンバ PVD 装置をモチーフとした真空装置から得られるデータ例を記述す る。 なお、装置から得られるデータは第 2.2 章に記載されているとおり、イベントデータ（DEE 含む）、トレー ス・データ、コンテキスト・データの 3 種類である。 © 2002/2003 Selete 41 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 図 7-8 EDA 界面から上がる EE データ 7.3.3.1. DEE の例 DEE データは装置がダウンしていない場合において、頻度の大小はあるものの、処理状態、休止状態に かかわらず発生する物である。このため、プロセスデータの収集方法とは関係なく、装置サプライヤと当該 装置のユーザ間で取り決めた範囲／条件に基づき常に収集される必要がある。 通常、デバイスメーカではアクチュエータレベルの 1 つ 1 つの動作には全く気を配ることはしないので、 DEE データはデバイスメーカには無用であると誤解されることが多い。しかし、DEE データからは、装置のメ ンテナンスの経緯や、その動作監視、また装置の稼働経緯などを知ることができる。 EES が、既存のデータ収集システムと大きく違うのは、この経緯データを扱えて、正しく解釈／使用できる かどうかである。 装置の稼働履歴、材料交換やユニット交換などのメンテナンス履歴、故障／修理の履歴等の経緯デー タは、装置稼働管理だけでなくプロセス変動や製品の出来映えにも大きく影響することは周知であるので、 このような細かい DEE データがオープン化され、装置動作やメンテナンスの経緯を追えるということはきわ めて重要である。 また直接 DEE データが取得できない場合でも、DEE データ検出の工夫を行えば、取得できる DEE デー タの組合せで、目的の動作監視などができるようになる。 例えば、プロセス装置で多く使われている小型のガスバルブのデータがそれにあたる（後述： 7.3.4 章参 照）。 このように、必要な DEE データをできるだけ多く取得する工夫をお願いしたい。 以下に PVD 装置（図 7-4～図 7-7）をモチーフにした真空装置で予測される DEE データの例の一部を 記述する。 表 7-1． ．DEE の例 データ項目の具体例 ジョブ開始／終了イベント スパッタープロセスシーケンス開始／終了 真空排気シーケンス開始／終了 対象物 装置 プロセスユニット サブシステム ウェーハステージアップ／ダウン I/O デバイス （Sensor/Actuator） プロセスユニット 真空度リミットエラー © 2002/2003 Selete 42 説明 装置レベルの動作単位のイベント例 プロセスユニットレベルの動作単位のイベント例 プロセスユニットレベルに属するサブシステムレベル のイベント例 センサ・アクチュエータレベルのイベント例 アラーム発生の例 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 ここで言う対象物は以下の意味を示す。図 7-4～図 7-7 を参照のこと。 装置 ：装置本体全体を指す プロセスユニット ：ここではスパッタチャンバを指す サブシステム ：ここではスパッタチャンバの排気システムを指す I/O デバイス ：ここではウェーハチャンバのウェーハ・ステージであり、アクチュエータにより （Sensor/Actuator） 駆動される 属性は各装置のデザインに依存し、普遍的なものではない。 また、データの送信方法やそのフォーマットに関しても各装置の制御系の設計に依存するため、普遍的 な物ではない。例えば、イベントの報告はジョブレベルの物からセンサ／アクチュエータ等の I/O デバイス・ レベルの物まで発生時にその都度出力する場合も、一定間隔のタイムスライスで Bit Map として報告する場 合もあり得る。また、制御の階層によって発生都度とタイムスライスが混在している場合もあり得る。 したがって、装置からいかなるフォーマットで報告されようとも、F-EES 上ではインタフェース B 上のアプリ ケーションからの要求に対して、都度個々の状態を示すレベルまでに意味付けを行って解釈できる仕組み （翻訳アプリケーション）、あるいは何時いかなる時にインタフェース B のアプリケーションから要求が来ても、 F-EES がデータを提供できるように予め意味付けを行ってデータベースに格納しておく（データベース上に は翻訳アプリケーションを通して共通フォーマットに変換して蓄積しておく）仕組みが必要である。 更に、DEE データの主たるユーザは装置サプライヤではあるが、装置のユーザたるデバイスメーカが使 用するものもあるため、その仕組み（翻訳アプリケーション）は必ずしも装置サプライヤが供給するとは限ら ない。このため、DEE データと対になる解釈の為の情報は、装置のユーザに対しても契約の基づき公開さ れる必要がある。 7.3.3.2. トレース・データの例 トレース・データにはプロセス処理中に収集するプロセス関連のトレース・データと、装置の状態を把握す るために常に収集する基本機能のトレース・データの 2 種類がある。 表 7-2．トレース・データの例 ．トレース・データの例 データ項目の具体例 プロセスパワー プロセス電流 プロセス電圧 ガス流量 プロセス圧力 ステージ温度 真空度 説明 プロセス中の電力をトレースする。収集のためのトリガーはプロセスユニットにおけるシーケンスの開 始／終了 プロセス中の電流をトレースする。収集のためのトリガーはプロセスユニットにおけるシーケンスの開 始／終了 プロセス中の電圧をトレースする。収集のためのトリガーはプロセスユニットにおけるシーケンスの開 始／終了 プロセス中のガス流量をトレースする。収集のためのトリガーはプロセスユニットにおけるシーケンス の開始／終了 プロセス中の圧力をトレースする。収集のためのトリガーはプロセスユニットにおけるシーケンスの開 始／終了に同期されることが望ましい。ガスを導入する充分前からと、ガス導入を止めた充分後まで の収集が必要。 常時ステージ温度をトレースする。収集のためのトリガーは常時という設定が可能なことが望ましい。 プロセス中は比較的短いデータ間隔での監視が必要であり、プロセス中以外では比較的長い時間 間隔の監視で充分である。 常時真空ゲージの値をサンプリングする。収集のためのトリガーは常時という設定が可能なことが望 ましい。 プロセス中は比較的短いデータ間隔での監視が必要であり、プロセス中以外では比較的長い時間 間隔の監視で充分である。 上記例は真空装置であるが、この場合、真空度はプロセスと無関係にバックグラウンドで収集されるべき ものである。ステージ温度は真空装置に限らず、ステージ加熱系を持つ装置ではプロセスとは無関係に収 集されるべきものである。このため、この 2 つのデータはレシピに連動するデータ収集とは無関係に常時収 集されるが、装置管理者がある程度サンプル周期等を調整出来る仕組みを持つことが望ましい。 本仕様では真空装置を例にして記述しているが、装置から収集されるトレース・データにはこの 2 種類が © 2002/2003 Selete 43 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 存在する。どのデータが上記の 2 種類のいずれに相当するかは装置によって異なるため、仕様書に明記願 いたい。 また、データの報告形態に関しては、装置種別あるいは装置制御系の設計に依存するため、報告周期 や報告のブロックサイズなどは設計ポリシーを越えて普遍的ではない。しかしながら、主に装置のユーザが 使用するものであるため、データの構成情報（フォーマット）はユーザに対して公開される必要がある。 なお、上記は代表例の一部である。真空装置に関しては EES-USAD（ユーザシステム分析書）の 6.2.章 に記載されている「データ要求」に更に細かい要求項目例が記載されているので、そちらを参照願いたい。 なお、同 EES-USAD の Appendix C.に、要求データを使った真空装置での業務改善事例を記述している ので、そちらも併せて参照願いたい。 本仕様書および EES-USAD には真空装置の事例しか記述されていないが、それ以外の装置でも同レ ベルのデータが要求される。 7.3.3.3. コンテキスト・データの例 コンテキスト・データは装置のハードウェアの設定値や実行値（オフセット）、レシピ／ジョブ関連の設定時 ／実行値などの情報を指す。 表 7-3．コンテキスト・データの例 ．コンテキスト・データの例 データ項目の具体例 Lot／Wafer 情報 レシピ関連情報 レシピ展開情報 ウェーハトラッキング情報 装置定数 説明 ロット情報が Host から指示されていて、装置が認識している場合。 キャリア ID／スロット ID（GEM300 レベル）、ロット番号／ウェーハ番号（GEM200 レベル）を処理 開始のイベントと関連づけて報告する。 ジョブの情報が Host から指示されていて、装置が認識している場合（GEM300）、ジョブ（PJ,CJ とも）の情報、GEM200 レベルの場合は、Host から送信されるレシピ情報を報告する。 ジョブ（GEM300）もしくはレシピ情報（GEM200）から展開されたレシピ実行値を処理開始のイ ベント、あるいはステップ報告のイベントと関連づけて報告する。 装置がウェーハの移動情報を認識できる場合、制御シーケンスなどに関連がある場合はイベン ト情報にウェーハ ID を付加することが望ましい。 複数台の同一目的の同一機種がある場合、同一条件を実現するために個々の装置で設定さ れている設定値（オフセット情報）を報告できる事が望ましい。 上記のように、装置の EE データポートからレシピ・データ、レシピから誘導された設定データ、その結果と して装置が設定を変更したデータの全てを出力する必要がある。 なお、GEM300 対応装置は通常装置上に Lot 情報を持たないが、このように装置が認識できない MES 系のデータで必要なものがある場合は、EES が Host に対して問い合わせをして情報を入手し、タイムスタン プなどから装置上のイベントとの関連づけを行い解釈する必要がある。 ただし、本仕様書ではアプリケーションと Host の関係は規定していないため、実装する場合は装置サプ ライヤ殿とデバイスメーカの協議にて決定される。 7.3.4. その他の装置詳細ステータスデータ DEE データでステータスを常時モニタリングできるものは、主なバルブや、機構の動きである。従って当 然のことであるが DEE データは装置の基本機能の監視を行う上で、必要十分なデータではない。 例えば小型のガスバルブなどでは、その開閉についてのセンサを持っていないために、電気駆動信号を 出力した際に正常に動作が起こっているかは、DEE データで直接に知ることはできない。 プロセス装置ではプロセスガスを多く使用するために、マスフローコントローラは装置内で多用されている。 また直接プロセスを実行するために、最重要な部品の１つである。最近マスフローコントローラは機能の高 度化が進み、センサクチュエータバス上では、マスフローコントローラ自身の動作健康診断機能を持つに至 っている。このようなセンサクチュエータバス上デバイスの動作モニタデータのデータコンシューマを EES と 定めれば、装置基本機能の監視能力を高めることができる。OEE の向上、予知保全、故障の早期発見の 観点から 実装が強く望まれる。 © 2002/2003 Selete 44 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 図 7-9 ガス流量による間接的なバルブ動作監視の例 © 2002/2003 Selete 45 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7.4. データ通信方式 7.4.1. Selete 推奨仕様に準拠する場合 推奨仕様に準拠する場合 本仕様書での装置の論理モデルは、第 2.4.1 章「装置構成モデル」中の「図 2-10 装置構成物の論理モ デル」に基づいている。 TDI で扱い管理するデータはこの図 2-10 のモデル図に基づいて、データの実際の発生場所を属性とし て持つものとする。 クラスタ形式の PVD の例では ① ② ③ ④ ⑤ ProductMachine LoadPort を含む装置全体 TransportUnit 搬送チャンバ ProcessUnit プロセスチャンバ SubsystemController 真空排気ポンプシステム Sensor，Actuator バルブ，ロボットアーム，リフター 等の個々のデバイスを示す 7.4.1.1. データ収集界面の通信プロトコル EDA 界面におけるデータ通信方式は本仕様書では扱わない。TDI と上位のアプリケーション、 DB との間の通信に関しては、TDI I/F 仕様書参照のこと。 7.4.1.2. TDI で管理するデータ TDI で管理すべきデータには次のものがある 表 7-4． ．TDI で管理すべきデータ 名称 イベント トレース 例外 コンテキスト （ダイナミック） コンテキスト （スタティック） 内容 いつ（タイムスタンプ） 装置階層のどのレベルのどの位置から（ロケーション） どの対象物（オブジェクト）が 何をしたか（アクション） いつ（タイムスタンプ） 装置階層のどのレベルのどの位置から（ロケーション） どのようなデータが発生したか（トレース・データ） いつ（タイムスタンプ） 装置階層のどのレベルのどの位置から（ロケーション） どの対象物（オブジェクト）から エラーが発生／収束したか（アクション） ［ウェーハが］いつ（タイムスタンプ） 装置階層のどのレベルのどの位置から（ロケーション） どのような指示値を与えられ（ウェーハを特定する情報とレシピ）、 開始／終了したか（アクション） その結果は同であったか（プロセス結果データ） ［装置階層の］どのレベルのどの位置から（ロケーション） どの対象物（オブジェクト）が どんな設定値を持っているか（設定データ） 7.4.1.3. イベントデータ イベントはその発生元を特定して送信する。 どの階層レベルのどのモジュール（物理的に存在するモジュール名やデバイス名が必要）から発生した のかを明確にすること。 装置階層に依存して次のようなイベントが存在する。 46 © 2002/2003 Selete EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 （１）装置レベル （ａ）ロット（もしくは JOB）の開始／終了 注） ① 該当装置の処理単位がキャリア単位であれば該当するキャリアに対する処理の開始／終了 ② 枚葉処理であればウェーハに対する処理の開始／終了 （ｂ）装置レベルのシーケンスの開始／終了 （２）モジュールレベル （ａ）モジュールレベルのステップシーケンス開始／終了 例として 真空排気シーケンスの開始／終了 各チャンバ単位のプロセスシーケンスの開始／終了 （３）デバイスレベル （ａ）動作させるためのアクチュエータがあり、その動きを確認するセンサが存在する場合 ① アクチュエータ動作直前に 動作開始イベントを発報する ② その後センサの動作を確認 ③ 動作完了のためのタイマーが必要であればその時間を待つ ④ 動作終了イベントを発報する （ｂ）動作させるためのアクチュエータがあり、その動きを確認するセンサが存在しない場合 ① アクチュエータ動作直前に 動作開始イベントを発報する ② その後センサの動作を確認⇒省略 ③ 動作完了のためのタイマーが必要であればその時間を待つ ④ 動作終了イベントを発報する 7.4.1.4. トレース・データ トレースは各モジュール単位で行う。該当装置の特性により、サンプリング周期と測定データの項目を明 記すること。 7.4.1.5. 例外データ 例外はその発生元を特定して送信する。 どの階層レベルのどのモジュール（物理的に存在するモジュール名やデバイス名が必要）から発生／収 束したのかを明確にすること。 装置階層に依存して次のような例外が存在する。 （１）装置レベル （ａ）装置レベルのシーケンス内でのエラーの発生／解除 （２）モジュールレベル （ａ）モジュールレベルのステップシーケンス内でのエラーの発生／解除 （３）デバイスレベル （ａ）動作させるためのアクチュエータがあり、その動きを確認するセンサが存在する場合 ① アクチュエータ動作直前のインターロックチェックでのエラー ② 動作エラーによる所定のセンサ入力が無かった場合 （ｂ）動作させるためのアクチュエータがあり、その動きを確認するセンサが存在しない場合 ① アクチュエータ動作直前のインターロックチェックでのエラー 7.4.1.6. コンテキスト （１）ダイナミック・コンテキスト © 2002/2003 Selete 47 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 ロット（もしくは JOB）の開始／終了時に必要となる下記の情報をさす。 ① ウェーハを特定する情報 キャリア ID&スロット番号，ロット ID＆ウェーハ ID イベント報告時にパラメータとして扱っても良い ② レシピ ID イベント報告時にパラメータとして扱っても良い ③ レシピボディ 装置が持つファイル上の値ではなく実際に指定された値 特定のファイルとして保存しておいても良い （２）スタティック・コンテキスト 装置内の制御を行うために存在している設定情報。 装置内ではファイルとして管理されている場合が多い。 この設定情報が変更された際に、イベントを発生すると共にそのデータを TDI でも管理する。 特定のファイルとして保存しておいても良い 7.4.1.7. スキーマ 以下、各データを定義するスキーマの例を示す。なお、コンテキスト（スタティック／ダイナミック双方）のス キーマに関しては、検討中で現状は未定義である。 表 7-5．イベントスキーマ ．イベントスキーマ 項目名 TDI SEQ TDI Time SourceID 索引 SourceSEQ SourceTime Event ID Task ID Action ID 説明 TDI におけるデータ一貫 No TDI におけるタイムスタンプ データソースの ID 下記の複合キーとすることを推奨。 （１）EquipmentID （２）LocationObjectName データソースにおけるデータ一貫 No データソースにおけるタイムスタンプ イベント ID タスク ID アクション ID Lot ID Carrier ID Wafer ID Slot ID KeyInfo-1 ロット ID キャリア ID ウェーハ ID スロット ID キー情報 KeyInfo-2 キー情報 ○ ○ 具体例 LocationObjectName に は デ ー タ 発 生 元 と な る Module ， SubSystem などを指定する イベントを特定するためのユニークな ID デバイスやシーケンス等のタスクを指定する イベントの動作を記述する。 例） START/END など 装置サプライヤが提供するデータで検索条件として使用するこ とを推奨するデータを指定する ： KeyInfo-n Value-1 Value-2 キー情報 データソースからの収集データ値 データソースからの収集データ値 イベントに伴うデータを送信する ： ： Value-m データソースからの収集データ値 © 2002/2003 Selete 48 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 表 7-6．トレーススキーマ ．トレーススキーマ 項目名 TDI SEQ TDI Time SourceID 索引 ○ ○ SourceSEQ SourceTime Lot ID Carrier ID Wafer ID Slot ID KeyInfo-1 KeyInfo-2 説明 TDI におけるデータ一貫 No TDI におけるタイムスタンプ データソースの ID 下記の複合キーとすることを推奨。 （１）EquipmentID （２）LocationObjectName データソースにおけるデータ一貫 No データソースにおけるタイムスタンプ ロット ID キャリア ID ウェーハ ID スロット ID キー情報 具体例 LocationObjectName に は デ ー タ 発 生 元 と な る Module ， SubSystem などを指定する 装置サプライヤが提供するデータで検索条件として使用するこ とを推奨するデータを指定する キー情報 ： KeyInfo-n Value-1 Value-2 キー情報 データソースからの収集データ値 データソースからの収集データ値 トレース対象となるデータを送信する ： ： Value-m データソースからの収集データ値 7.4.2. SEMI スタンダード（PR8）に準拠する場合 ）に準拠する場合 スタンダード（ 7.4.2.1. XML による定義（TAG の定義） による定義（ XML は標準文書仕様として普及しており、また、SEMI スタンダードにおいても、近年では XML の仕様 を適用したスタンダードの制定および検討が行われている。本仕様書では SEMI スタンダード PR8 にて定 義されている XML/SOAP によるデータ通信は積極的には採用しない方針だが、排除する物ではない。 このため、XML フォーマットで EE データの定義を行う場合には、予め TAG の定義情報を提供いただき たい。 XML の定義を用いる場合は Web サービスの提供も踏まえて以下の定義方法を想定している。 ! XML Schema ! WSDL（Web Service が提供されるケース） XML による定義の場合、Namespace の考慮が必要であるが、現時点では SEMI スタンダードや IRD に おいても検討中の段階である。従って、現状では装置サプライヤ殿の環境範囲に限定したスキーマを最低 限定義していただければよい。 ここでは参考例を次に提示する。実際の仕様において対象となるデータやそのデータの定義は、基本的 にはすべて装置サプライヤ殿から提案いただきたい。 以下、データ定義の例と XML によるデータ送信の例を示す。 表 7-7． ．Message structure Tag Name Message Header Description 装置共通ヘッダー XML Datatype Complex Behavior Required Message Body 装置固有メッセージボディ Complex 1 required, M optional © 2002/2003 Selete 49 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 表 7-8． ．Message Header Tag Name Description XML Datatype Behavior Supplier Model 装置サプライヤ名称 装置型式 String String Required Required ImmutableID シリアル番号 String Required 表 7-9． ．Event Message Body Tag Name Description XML Datatype Behavior MsgType Time メッセージの区別:"Event" イベントが発生した時刻。ISO 8601 format String DateTime Required Required ObjID SerialNo イベントを発生したオブジェクト イベント番号。ユニークな番号であること String SerialNo Required Required TaskID ActionID イベントを発行したオブジェクトが、実行している（実行する）タスクの ID イベントの内容。開始／終了， on/off 等 NonNegativeInteger String Required Required Spec スペック、パラメータなど制御に必要な情報およびデータ ParentObjID イベントを発行したオブジェクトのタスクを起動したオブジェクトの ID String String Optional Optional ParentTaskID イベントを発行したオブジェクトのタスクを起動したオブジェクトのタスク ID ParentLinkID イベントを発行したオブジェクトのドメイン内で、この Event を特定すること ができるユニークな ID Parameter パラメータの集まり String String Optional Complex 0, M Optional 表 7-10． ．Exception Message Body Tag Name Description XML Datatype Behavior MsgType Time メッセージの区別:"Exception" イベントが発生した時刻。ISO 8601 format String DateTime Required Required ObjID SerialNo イベントを発生したオブジェクト イベント番号。ユニークな番号であること String SerialNo Required Required TaskID ActionID イベントを発行したオブジェクトが、実行している（実行する）タスクの ID イベントの内容。開始／終了， on/off 等 NonNegativeInteger String Required Required Spec スペック、パラメータなど制御に必要な情報およびデータ ParentObjID イベントを発行したオブジェクトのタスクを起動したオブジェクトの ID String String Optional Optional ParentTaskID イベントを発行したオブジェクトのタスクを起動したオブジェクトのタスク ID ParentLinkID イベントを発行したオブジェクトのドメイン内で、この Event を特定すること ができるユニークな ID Parameter パラメータの集まり String String Optional Complex 0, M Optional 表 7-11． ．Parameter Elements Tag Name Description XML Datatype Behavior MeasTime ParamName 計測日時 パラメータ名称 dateTime StringMaxLength=128 Optional Required ParamValue LowerWarningLimit パラメータ値 警告下限値 String String Required Optional UpperWarning Limit LowerAlarmLimit 警告上限値 警報下限値 String String Optional Optional UpperAlarm Limit 警報上限値 String Optional © 2002/2003 Selete 50 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 [上記データ定義におけるデータ送信の例（Event の場合）] <MessageHeader> <Supplier>Some Supplier</Supplier> <Model>7300</Model> <ImmutableID>AA02-7305</ImmutableID> </MessageHeader > <MessageBody> <MsgType>Event</MsgType> <Time>1999-05-31T13:20:00</Time> <ObjID>cid</ObjID> <SerialNo>cs001</SerialNo> <TaskID>ct001</TaskID> <ActionID>TaskStart</ActionID> <Spec>ppara1</Spec> <ParentObjID>pid</ParentObjID> <ParentTaskID>ptd</ParentTaskID> <ParentLinkID>pld</ParentLinkID> <Parameter> <MeasTime>1999-05-31T13:20:02</MeasTime> <ParamName>Press1</ParamName> <ParamValue>5.5e-3</ParamValue> <LowerWarningLimit>5.5e-4</LowerWarningLimit> <UpperWarningLimit>5.5e-2</UpperWarningLimit> <LowerAlarmLimit>5.5e-5</LowerAlarmLimit> <UpperAlarmLimit>5.5e-2</UpperAlarm Limit> </Parameter> <Parameter> <MeasTime>1999-05-31T13:20:03</MeasTime> <ParamName>Press2</ParamName> <ParamValue>4.5e-3</ParamValue> </Parameter> </MessageBody> 7.4.2.2. その他の形式による定義 上記のような XML の定義ではなく、別の形式で提出していただく方法も考えられる。例えば、イベントデ ータが装置サプライヤ殿の独自のフォーマットで提供されるケースや、CSV 形式で提供されるケースなどは、 別の形式でデータを定義していただき、その仕様をドキュメントとして提示していただきたい。 7.4.2.3. データ定義の記載項目 データ定義には仕様書として以下のような項目を記載していただきたい。 表 7-12．データ定義の記載項目 ．データ定義の記載項目 No Item Item Name Description 1 2 データ項目名称 データ定義または解説 DataName Description EE データとして提供されるデータの名称 データの定義または、データの解説 3 4 TAG 名称 データタイプ TAGName DataType XML で表現される場合の TAG 名称 Complex、String、NonNegativeInteger、dateTime などのデータタイプ指定 5 6 補足説明 その他 Remark Others 必要な補足説明（後述） その他、必要な説明があれば記載 7.4.2.4. 詳細項目のドキュメントによる補足 XML によるデータ定義の場合、各 TAG によって扱われるデータの定義や解説及び、そのデータの定義 域などをドキュメントとして提示していただくが、特に注意すべきデータ定義に関しては別途補足説明をお 願いしたい。例えば、DEE のデータ定義において、一つの TAG によって複数のセンサ情報がまとめて報告 される場合などは、その TAG 内で送信される DEE データの判別方法を補足説明として記載いただきたい。 以下に補足説明すべき例を示す。 © 2002/2003 Selete 51 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 <MessageHeader> <Supplier>Some Supplier</Supplier> <Model>7300</Model> <ImmutableID >AA02-7305</ImmutableID > </MessageHeader > <MessageBody> <MsgType>Event</MsgType> <Time>1999-05-31T13:20:00</Time> <ObjID>cid</ObjID> <SerialNo>cs001</SerialNo> <TaskID>SEQ001</TaskID> <ActionID>CHANGED</ActionID> <Parameter> <MeasTime>1999-05-31T13:20:02</MeasTime> <ParamName>DEE-PIO-RMT1</ParamName> <ParamValue>04 77 3F 22 04 57 88 44 33… 23 67 53 22 00 FF E6 5F…</ParamValue > </Parameter> <Parameter> <MeasTime>1999-05-31T13:20:02</MeasTime> <ParamName>DEE-PIO-RMT2</ParamName> <ParamValue>0B 73 3F 22 04 57 88 44 33… 23 67 53 22 00 FF E6 4F…</ParamValue >. </Parameter> </MessageBody> ≪TAG<ParamValue>の補足説明の例≫ PIO のビットマップデータを圧縮して送信する例を示している。 PIO の 8BIT を 1 ポートとして 16 進 2 桁のアスキー文字列でデータを送信している。 © 2002/2003 Selete 52 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7.5. EES の類似例／実施例 EES の将来像は第 7.3.3 章に記載されているような、イベントデータ（DEE 含む）、トレース・データ、コン テキスト・データの 3 種類のデータ全てを扱うことを前提としているが、装置の稼働率改善目的で開発された システムにも、これらの一部のデータを使って、EES に求められる機能を実現し、改善された EE 業務を遂 行出来るものがある。 以下にその例を述べる。 7.5.1. エキシマレーザ光源における類似例 エキシマレーザ光源における類似例 （2001 年 6 月 7 日 SEMI Japan 主催「e-Manufacturing Workshop – 実用段階に入った EES」ギガフォトン 株式会社 坂西氏 発表） エキシマレーザ光源は発振パルス数と実行パワーの推移により予め決められた明確な条件のもとでモジ ュール交換を行うため、リモートから各レーザ光源ユニットに対して稼働履歴を問い合わせるシステムが開 発された。 これは遠隔診断（e-Diagnostics）の例であり、EE データとしてはレーザの発振パルス数と実行パワーを参 照している。これらのデータによりリモートでメンテナンス時期の予測とサービス要員の配置スケジューリング （予防保全の最適化）を行い、MTTR、MTOL の改善による稼働率の向上に結びつけている。 このエキシマレーザ光源の EE システムが本仕様書に記載されているものと異なる点は、データサーバが レーザ光源近傍にあるのではなく、レーザ光源に接続された PC が定期的にサポート・センターのサーバに 対して診断レポートのデータをプッシュして報告／記録する方式をとっている部分である。各サービス拠点 はこのサポート・センターのサーバにデータを問い合わせるため、直接レーザ光源にはアクセスすることは 無い。このため、ユーザ・サイドにとってはセキュリティ等の安全面でも配慮された形態となっている。また、 データサーバを集約しているのでデータベース管理が容易であり、ユーザたるデバイスメーカがデータベ ース管理の煩わしさから解放されている点が優れている。 また、サーバに対する定期的な診断レポートの提出以外にアラームや特定のイベントをトリガーとして、ア ラームの発生内容やレーザ光源の状態をサービス・センターのサーバ経由で電子メールにて関係者へ警 告メールを配信するシステムも具備している。 データ量も小さく、またサブシステムであるために、監視対象とする物のモデル化も完成されていて、サ ービス業務の定型化が独立して完全にできあがっている。そのためにこのようなシステム化が可能であった 例である。 7.5.2. CD（測長） （測長）-SEM における類似例 （測長） （2001 年 6 月 7 日 SEMI Japan 主催「e-Manufacturing Workshop – 実用段階に入った EES」株式会社 日 立製作所 宇佐美氏 発表） CD-SEM は稼働率が非常に高く、アンスケジュールド・ダウンタイムは 3%程度の安定した装置である。こ のような装置でも、さらなる稼働率の向上として、原因追及が長期化し、復帰するまでの時間が長大になる 故障の対策が重要である。 日立 CD-SEM での取り組みはこれを回避するために、装置全体のアクチュエータの動作パターンを記録 してタイミング・チャート化し、正常時のタイミング・チャートのパターンとの差を顕在化させることにより、不具 合発見の迅速化と原因究明の迅速化を指向した例である。 ここで使用される、シーケンス・パターンのタイミング・チャートは DEE データより作成できるものであり、 DEE データの活用事例である。 DEE データは単純な 2 値データであるため、CD-SEM 全体のタイミング・チャートであっても長期間蓄積 することが可能である。そのため、常に記録を保存しておけばトラブル前後の動作も充分に再現することが 可能となる。その結果として、発生頻度の低いトラブルであっても、実機で再現実験せずにデータ上で原因 追求を行って追い込むことが可能となった事例についての報告があった。 現在のシステムはデータを蓄えて、事後に確認して原因解析を行うシステムとなっているが、将来的には リモートで確認し、原因解析まで実施するシステムも想定されている。 © 2002/2003 Selete 53 EES Data collection Capability Requirement Document (DCRD) Ver. 2.0 7.5.3. クラスタ型 クラスタ型 PVD 装置における実施例 （2002 年 7 月 SEMICON West, SEMI 主催 e-Manufacturing Workshop／2002 年 12 月 SEMICON Japan, SEMI 主催 e-Manufacturing Workshop／2003 年 6 月 13 日 JEITA /SEAJ /Selete 主催「e-Manufacturing ビジネスの始動」、他 株式会社アルバック 大野氏発表） 元々装置の自己診断システムとして開発されたデータサーバを用いた、EE 機能の実施例がデー タ収集機能からはじまり、サービス・ビジネスの変革までを捉えた取り組みとして発表された。 この装置の場合、本仕様書に記載している範囲を全域カバーしているとは必ずしも言えない部分 があるが、装置制御命令および動作結果をイベントとして収集できるため、かなり詳細なレベルの 装置稼働状態の経緯を把握することが出来る。 また、アナログ・トレース・データとの紐付けも独自の方法で高い分解能を有するため、枚葉レ ベルでのプロセス変動等も比較的容易に捉えることが出来る。 装置制御自体がイベント・ドリブンで行われるため、制御信号や応答をかなり容易に DEE とし て活用であり、収集すべきデータ件数に対してのサイズも充分に小さく抑えられている。 また、アナログ・トレース・データも装置の動作状態を判断し、レシピ実行時には指定したパラ メータのデータ収集サイクルの変更が可能な独自解釈の DCP も搭載している。 実際の活用事例としては、装置出荷前の検査での測定データと設計値のエラーを基にした微調整 や、検収時の装置健全性レポート、生産使用時における装置健康モニタや、故障／メンテ予測など に使用可能であることも立証されている。 現時点では理想的な EES システムを搭載している唯一の装置といえる。 7.5.4. CMP 装置における実施例 （2003 年 6 月 13 日 JEITA/SEAJ/Selete 主催「e-Manufacturing ビジネスの始動」 株式会社荏 原製作所 大石氏、株式会社明電舎 鈴木氏発表） アルバックとは逆にメモリー・マップを一定のインターバルでスキャンし、装置状態を把握する システムである。 この方式ではイベント収集の対象とする部位や信号が多くなればなるほど、データ量が増大する ことになるため、実際の運用でもデータバックアップ方法に課題が残る。 しかしながら、プロセスが不安定な CMP 装置に於いては、特定部位に対象を絞ってデータを収 集しても充分な効果が得られるため、実用化に近いレベルとなっている。 © 2002/2003 Selete 54