SEMI E170 SFORMS
“Secured Foundation of Recipe Management System”
-セキュリティ強化されたレシピ管理システム用基盤スタンダード-
2016年2月5日
Japan Chapter of Global I&C Technical Committee
Japan GEM300 Task Force
レシピは半導体製造工場に於いて装置を制御する上で最も重要な情報の一つです。
しかし、いわゆるGEM300と呼ばれるSEMIスタンダード・セットの中で参照されているレシピ管理標準であるE42 RMSおよびE139 RaPは、開発はされましたが広く実装されるには至りませんでした。
一方で、半導体製品の多様化、プロセスの複雑化に伴うレシピ数の増大、プロセス・ウィンドウの狭化に伴うAPCの導入、更には半導体工場の国際展開などによるセキュリティ問題などで、レシピの管理の強化が求められ、有効なレシピ管理スタンダード不在の中で様々な個別要求仕様が増大しています。
そこで、「レシピ管理スタンダードは根付かない」というジンクスに敢えて抗して、“SEMI E170 Secured Foundation Of Recipe Management System (SFORMS)”を開発しました。
E170 SFORMSの目的は以下にあります。
- 依然として増大する半導体工場に於けるレシピ管理課題を効果的に解決支援するために、
- 半導体工場で望まれる「RMS上でしたことが、装置上で得られること。」というレシピの集中管理を実現すべく、
- 半導体メーカに依って異なるRMS(Recipe Management System)のビジネス・ロジックの部分は使用者の階層に任せて、
- 過度にIT側面での方法論に陥らずに(E42 RMS、E139 RaPとは異なる方向性で)、
- ホストと装置との間で必要なセキュリティ強化されたレシピ基本操作を定めた「セキュリティ強化されたレシピ管理システム(RMS)用基盤の標準仕様」を提供する。
レシピの管理と言う重要な部分に手を加えることは簡単ではありませんが、複雑さを増す半導体工場でのレシピ管理のセキュリティと効率化のためにE170 SFORMSの計画的な適用が期待されます。
本稿ではこのE170 SFORMSのコンセプト、機能とその応用をご紹介致します。
Contents
1 半導体工場のレシピ管理の課題と方向性
1.1 レシピ管理関係の課題
1.2 レシピ管理の方向性
1.3 GEM300の課題
2 E170 SFORMSのコンセプト
2.1 SPORM(Single Point of Recipe Management)
2.2 Recipe Server Centric Management
2.3 Recipe Classの概念とRecipe XIDの導入
2.4 ‘What you have done on the RMS / Recipe Server’ is ‘What you will have on the equipment’
2.5 使途別の論理Recipe Spaceの導入
2.6 既存実装との互換性と段階的実装
3 E170 SFORMSの機能
3.1 Recipe XID機能
3.2 拡張メッセージ機能
3.3 Secured Recipe Space (SRS) 機能
3.4 Production Recipe Cache (PRC) 機能
3.5 Remote Access Cache機能
4 E170 SFORMSの応用
5 段階的実装
1 半導体工場のレシピ管理の課題と方向性
半導体工場に於ける装置レシピに関する課題は、表現・文法などの記法関係と、作成・保存・転送・同期などの管理関係と、APC・R2Rなどの調整関係との三つに大別される。 E170 SFORMSはこのうち管理関係課題を扱う。
1.1 レシピ管理関係の課題
半導体工場には以下のようなレシピ管理関係の課題がある。
- Security
✓レシピの工場外への漏洩や盗難
- Safety
✓ 非権限者によるレシピの不用意な変更
✓ レシピ更新後も同レシピ名を用いる場合の、RMS上と装置上とでの同名レシピの内容同一性の保証
- Operability
✓ クリーン・ルーム内でのレシピ作業の不効率さ
✓ 品種の増加やプロセス・ステップの増加による工場内のレシピ数の増加に伴う作業増
✓ 装置数増加による各号機へのレシピ反映作業の増大
- Efficiency
✓ ホストから装置へのレシピ転送頻度によるサーバやネットワークの負荷
- Cost
✓ 半導体工場ごとに異なるレシピ管理仕様への装置サプライヤの対応負荷
1.2 レシピ管理の方向性
半導体工場では一般に以下のような方向性での解決を指向している。
- 台帳管理:レシピの管理をRMSに一点集中する
- 編集承認:レシピの作業をRMS上に集約する
- 実体保存:レシピの原本をRMS下のレシピ・サーバに一ヵ所保存する
- 実行環境:レシピの写本をなるべく装置上に置かないようにして盗難を防ぐ
- 操作権限:レシピの操作を非権限者ができないように使用者の権限管理を強化する
1.3 GEM300の課題
しかし、前記のような方向性を支えるには、現行のGEM300には以下のような課題がある。
- レシピの識別子がPPIDしかない。
✓ レシピをその使途に依って異なった管理(セキュリティなど)をすることができない。
✓ 同名(同PPID)レシピのバージョン管理ができない。
- レシピのDownload、Uploadにルールがない。
✓ レシピ・サーバと装置との間でのレシピの同期保証の標準がない。
2 E170 SFORMSのコンセプト
E170 SFORMSは、前述のような状況の改善を支援するために開発され、以下のコンセプトを導入している。
2.1 SPORM(Single Point of Recipe Management)
全てのレシピの管理をRMS一点に集中させるもので、以下がポイントになる。
- RMSが認知しているレシピが工場の正式レシピである。
- RMSが認識・承認する作業が正式な作業である。 レシピの操作はRMS以外の場所で行われても良いが、その操作内容がRMSの認識・承認下にあること。
- ただし、意図的に装置でのLocal管理を許す保守や立ち上げのためのレシピは対象外である。
2.2 Recipe Server Centric Management
レシピ管理のセキュリティ強化のためにレシピの正本をRMS管理下のレシピ・サーバで一ヵ所保存する。
- RMS管理下のレシピ・サーバ上にあるレシピが正本である。
- RMS管理下のレシピ・サーバ以外の場所に極力レシピの写本を残さない。
- ただし、意図的に装置でのLocal管理を許す保守や立ち上げのためのレシピは対象外である。
2.3 Recipe Classの概念とRecipe XIDの導入
レシピに諸Classを設定可能にするために以下のID群からなるRecipe XIDを導入する。(詳細後述)
- RecipeID PPID レシピ名
- VersionID Version バージョン番号
- SecurityID Security Class セキュリティの格
- TypeID Type Class レシピの種類
- EquipmentID Equipment Class 適用装置
2.4 ‘What you have done on the RMS / Recipe Server’ is ‘What you will have on the equipment’
前述のようにE170 SFORMSの目的は「RMS上でしたことが、装置上で得られること。」の実現であり、そのために、「RMS上に装置内の実行用Recipe Space(PRC: Production Recipe Cache)の写像を用意し、その写像内で行った操作が、E170 SFORMSを通して実行時に自動的に装置のPRCに反映される」という形式を採る。
2.5 使途別の論理Recipe Spaceの導入
E170 SFORMSは使途別に4種の論理Recipe Spaceを提供する。
- Conventional OperationとConventional Recipe Space (CRS)
現行のGEM300対応のRecipe Spaceとの運用互換性を提供するためのRecipe Spaceである。
- Secured OperationとOptional Recipe Space (ORS)
Security Classを用いて作業や作業者を特定してレシピを扱うためのRecipe Spaceである。
- Production OperationとProduction Recipe Cache (PRC)
ホストからの自動生産実行のためにレシピを一時保存するためのRecipe Spaceであり、装置のオペレータから隔離されるほか、ホスト上のユーザも意識する必要がない。
- Remote Access OperationとRemote Access Cache (RAC)
RMS管理下のレシピ・サーバ内のレシピを、装置上もしくは装置サプライヤが提供するワーク・ステーション上のレシピ・アプリケーションによって操作するために一時保持するRecipe Spaceである。
Figure 1 E170 SFORMSの適用イメージ
2.6 既存実装との互換性と段階的実装
E170 SFORMSの機能は既存実装への追加機能の形をとり、段階的実装を可能にする。
3 E170 SFORMSの機能
E170 SFORMSは前記コンセプト実現のために以下の機能を提供する。
3.1 Recipe XID機能
現在実装されているGEM300スタンダード・セットでは、レシピの特定に用いられるのはRecipe ID(PPID)のみであり、バージョン、セキュリティ、対応装置個体、レシピ種など、レシピを分類管理する能力がない。 そこで、E170 SFORMSでは拡張されたRecipe IDであるRecipe XIDを導入する。Recipe XIDは以下のID群によって構成される。
- RecipeID
✓ 現行のPPID。
- VersionID
✓ 同じRecipeIDを持つレシピ群内でのユニークなVersion番号を示す。VersionIDはRMSに依って採番される。
✓ 装置がレシピを作成・加工した場合にはVersionIDはZero length(無効)に設定され、RMSにチェック・インする際に採番されて有効になる。
- SecurityID
✓ そのレシピの属するSecurity Classを示す。 Security Classはそのレシピが取り扱われるべきセキュリティの格を示し、そのレシピの使途、使用者などを限定するために使用される。
✓ レシピはそのSecurity Classに紐付けられた論理レシピ空間に保存され、そのSecurity Classに紐付けられた使用者に依って、そのSecurity Classに紐付けられた使途に使用される。
- TypeID
✓ そのレシピの種類を示す。
✓ TypeIDは変数の型のみが決められており、レシピの種類はスタンダードの使用者が自由に定義できる。
✓ 装置パラメータ・リストやレシピの実行結果などにType Classを与えることに依って広義のレシピとして管理対象とすることもできる。
- EquipmentID
✓ そのレシピが適用されるべき装置のIDを示し、そのレシピがどの装置に対応して作成調整されているかを示す。
✓ 理想装置にIDを振ることによっていわゆる「Golden Recipe」を表現することもできる。
Figure 2 Recipe XID機能
3.2 拡張メッセージ機能
E170 SFORMS用に拡張されたメッセージである。 以下の点に於いて強化されている。
- Recipe XIDの使用
Recipe XIDで与えられる分別制御が可能になる。
- レシピのリスト形式での転送機能
レシピを任意の数、リスト形式で送受することができる。これにより、処理に必要なレシピ群を一回のメッセージで転送することができるようになり、レシピの木構造での管理が楽になる。
3.3 Secured Recipe Space (SRS) 機能
レシピに与えられたSecurity IDに従って、レシピをSecurity Class(セキュリティ論理空間)で管理する機能。GEM300では、装置内のRecipe Spaceに関する規定はなく、特に規定されていない暗黙のひとつの空間として扱われており、種々の使用者からのアクセスの仕分けができない。 E170 SFORMSではRecipe Spaceのフォルダ構造などを特定することはせず、何らかの方法で論理的に区別することを要求する。
SRSには以下の種類がある。
- ‘Conventional Recipe Space (CRS)’ SecurityID= ‘Conventional’
✓ 現行のGEM300対応のRecipe Spaceと運用互換性のあるRecipe Spaceである。
✓ 現行のレシピ・メッセージ系とE170 SFORMSが定めるRecipeXIDを用いたレシピ・メッセージ系との双方に対応する。現行のレシピ・メッセージ系を用いる場合はSecurityID= ‘Conventional’のアクセスであるとみなされる。
✓ 現行のオペレーションを踏襲し、RMS内の写像との自動同期は規定しない。
- ‘Optional Recipe Space (ORS)’ SecurityID= ‘<User defined>’
✓ スタンダードの実装者が自由に定義できるSRSであり、Security Classを用いて定められたユーザに、定められた作業を許諾するために使用される。
✓ SecurityIDを予約語を避けて任意に定めて任意の個数作成することができる。
✓ RMS内の写像との自動同期は規定しない。
- ‘Production Recipe Cache (PRC)’ SecurityID= ‘Production n’
✓ ホストからレシピを実行する際にRMS内の当該レシピをCacheするために用いられるSRSである。
✓ PRCは、セキュリティと転送効率を最適に保つために「Cache Logic」によって常にレシピ・サーバ内の当該領域にあるレシピのうち必要最小限の写本を格納している。
✓ PRCは複数持つことができる。
✓ RMS内の写像との自動同期を規定する。
- ‘Remote Access Cache (RAC)’ SecurityID= ‘Remote n’
✓ 装置もしくは装置サプライヤが提供するワーク・ステーション上から、装置サプライヤが提供するレシピ・アプリケーションを用いてRMS管理下のレシピ・サーバ内のレシピを操作する際に自動的に当該レシピを装置内にCacheするために用いられるSRS。
✓ RACは複数持つことができる。
RMS内の写像との自動同期を規定し、作業終了後にはRAC内のレシピは削除される。
Figure 3 Secured Recipe Space機能
3.4 Production Recipe Cache (PRC) 機能
ホストからの指示でレシピを実行する際にRMS内の当該レシピを安全にかつ効率的にCacheするための機能である。
PRCには、保存して良いレシピの上限数を指示するMaxNumberが設定でき、PRC内にPJで指示されたレシピが見つからない場合にはRMSに当該レシピをQueryすることができ、結果として以下の4つのModeでの動作が可能になる(Modeの設定がある訳ではない)。
また、オプションで保存時間の上限を定めるMaxTimeが設定可能であり、保存時間が切れたレシピはPRCから消去される。
- Full Download Mode
✓ レシピの実行に先だってホストが毎回レシピをダウン・ロードする。
✓ レシピはPJの作成と共に消去される。
- Full Query Mode
✓ 実行に先だってホストはRecipeXIDを指示する。
✓ 装置はRMSに当該レシピを要求(Query)し、RMSが装置にレシピを提供する。
✓ 装置はPJの作成と共に当該レシピを消去する。
- Pre-Download Mode
✓ レシピの実行に先だってホストは必要数のレシピをダウン・ロードする。
✓ PJの作成後には最近使用された「n」個のレシピのみPRC内に残される。
- Cache Mode
✓ 実行に先だってホストはRecipeXIDを指示する。
✓ 装置はPRC内に当該レシピがあればそれを使用する。
✓ なければRMSに当該レシピを要求(Query)し、RMSが装置にレシピを提供し、装置は当該レシピをPRC内に記憶する。
✓ PJの作成後には最近使用された「n」個のレシピのみPRC内に残される。
Table 1 PRCの動作Mode
3.5 Remote Access Cache機能
装置もしくは装置サプライヤが提供するワーク・ステーション上から、装置サプライヤが提供するレシピ・アプリケーションを用いてRMS上のレシピを操作する機能。 装置は自動的にRMS上の当該レシピを装置内のRACにCacheし、作業終了と共に消去する。以下のようなシナリオを可能にする。
Remote Access作業を許すための設定を各デバイス・メーカのビジネス・ルールに則ってRMS上で行う。その際に、作業に用いるSecurityID、作業者、対象となるレシピ群を定めておく。
装置もしくは装置サプライヤ提供のワーク・ステーションからのログ・イン。 Remote Accessを要求されると装置はその使用者のRMS上でのOperatorIDとOperatorPasswordを要求し、RMSへのログ・インを代行する。
ログ・インが成功すると、一般的には作業のために必要なRecipeXIDListをRMSに要求し、RMSはこれに応える。
使用者は装置サプライヤ提供のアプリケーションを用いて必要なレシピ作業を行う。
作業が終了すると作業結果をRMSにPostする。
使用者がRMSからログ・アウトすると装置はRSCの内容を消去する。
ホスト上で作業結果の必要な受け入れを行う。
- ホスト上での前作業
- RMSへのログ・イン
- RecipeXIDListの要求
- 必要な作業の実行
- 作業結果のPost
- RMSからのログ・アウト
- ホスト上での後作業
4 E170 SFORMSの応用
E170 SFORMSを用いた作業シナリオの例を例示する。
- Production A
装置にレシピの写本を全く定在させないホストによる自動生産のシナリオである。
✓ まず、ワーク・ステーションからホストのRMSに入ってロットとレシピの指示などのSetup操作を行って生産を仕掛ける。
✓ ホストは毎回、装置のPRCとの間でレシピの転送を行い、生産を行う。
- Production B
装置にレシピの写本を必要数一時的に持たせたホストによる自動生産のシナリオである。
✓ まず、ワーク・ステーションからホストのRMSに入ってロットとレシピの指示などのSetup操作を行って生産を仕掛ける。
✓ ホストは装置のPRCとの間で設定した数のレシピの写本をCacheして生産を行う。
- Development A
RMS上でレシピの修正を行い自動生産環境の中にEngineering Lotとして投入するシナリオである。
✓ まず、ワーク・ステーションからホストのRMSに入ってレシピを修正し、ロットの指示などのSetup操作を行ってEngineering Lotを仕掛ける。
✓ ホストと装置とは、その時の自動生産環境(Production A or B)の設定に従ってPRC経由でレシピを受け渡してEngineering Lotを処理する。
- Development B
装置サプライヤが提供する装置上もしくはワーク・ステーション上のレシピ・アプリケーションを用いてRMS上のレシピの修正を行い自動生産環境の中にEngineering Lotとして投入するシナリオである。
✓ まず、装置もしくはワーク・ステーションからRemote Access機能を用いてRMS上のレシピを一時的にRAC内にCacheし、当該レシピ・アプリケーションを起動して修正し、RMSに戻す。
✓ 更に、ワーク・ステーションからホストのRMSに入ってロットの指示などのSetup操作を行ってEngineering Lotを仕掛ける。
✓ ホストと装置とは、その時の自動生産環境(Production A or B)の設定に従ってPRC経由でレシピを受け渡してEngineering Lotを処理する。
- Development C
装置上のOptional Recipe Spaceで管理されているレシピの修正を行い、ホストに転送して自動生産環境の中にEngineering Lotとして投入するシナリオである。
✓ まず、装置のORS内のレシピを修正し、RMSに転送する。
✓ 更に、ワーク・ステーションからホストのRMSに入ってロットの指示などのSetup操作を行ってEngineering Lotを仕掛ける。
✓ ホストと装置とは、その時の自動生産環境(Production A or B)の設定に従ってPRC経由でレシピを受け渡してEngineering Lotを処理する。
- Development D
生産状態にない装置上のConventional Recipe Spaceで管理されているレシピの修正を行い、そのままその装置上で処理を行うシナリオである。
✓ 装置のCRS内のレシピを修正し、そのまま処理を実行する。
- Maintenance A
ホストとの連携下でOptional Recipe Spaceを用いて行うメンテナンスのシナリオである。
✓ ORSに対応するRMSの領域とORSとの間で承認されたメンテナンス・レシピを共有しながらメンテナンスを行うことができる。
- Maintenance B
装置単独でConventional Recipe Spaceを用いて行うメンテナンスのシナリオである。
✓ CRS内でメンテナンス・レシピの作業を行い、メンテナンス実行を行う。
Figure 4 E170 SFORMSの応用
5 段階的実装
E170 SFORMSは機能的には現状のGEM300実装のスーパー・セットとなるように設計されているが、機能の追加に際しては内部の構造的変更を伴う場合が多く、実装には相応の負荷がある。そこで以下のような段階的な実装を許容するよう機能をブロック化している。Step 3AとStep 3Bとは独立であり、任意の順で進められる。
- Step 1 Message Set with RecipeXID
RecipeXIDを用いた拡張メッセージ・セットの基本部分の実装。この実装により、拡張メッセージが持つレシピを複数同時に転送する機能が使用可能になる。 - Step 2 SRS Management
Security IDの解釈とSecured Recipe Spaceの管理の実装。異なったSecurityIDを持つレシピを異なったSRSで管理することができ、作業種、作業者を限定することが可能になる。
- Step 3A1 PRC Space
PRMFlag機能の実装によるPJが用いるSRSの制御。Pre-Download Modeでの運用が可能になる。
- Step 3A2 PRC Operation
Cacheの動的管理機能の実装。Query機能が使えるようになり、Full Query ModeおよびCache Modeが使用可能になる。
- Step 3B RAC Operation
Remote Access機能の実装。装置サプライヤ提供のレシピ・アプリケーションを用いてRMS上のレシピにアクセスすることが可能になる。
- Step 4 All
全ての機能の実装。
Figure 5 E170 SFORMSの構成
あとがき
以上、SEMI E170 SFORMSについて解説しました。
本スタンダードの基になる提案を最初に行ったのは2009年でしたが経済状況の変化から標準化への合意形成が遅れ、結局2013年からの着手になりました。その間にもレシピの課題に対して個別の要求が出され、個別仕様の実装が進んでしまいました。そのため、部分的には既に同様な機能が異なった形で実装されているとか、このような機能拡張を意識して実装を進めて来ていないために実装に伴う構造的変更が大きいなどの実装障壁が出て来るでしょうが、生産性の追求はまだまだ続きます。
中期的な工場管理の効率化の視野に立って強固なSPORMの導入を目指して実装されることを期待しています。
お問い合わせ先:
SEMIジャパン スタンダード 柳澤智栄
jstandards@semi.org
参考文献:
- SEMI E170 Specification for Secured Foundation of Recipe Management System (SFORMS)
- SEMI E170.1 Specification for SECS-II Protocol for Secured Foundation of Recipe Management System