SEMI通信 2016年12月号SEMIスタンダード情報

SEMI GEM300A スタンダード
スマート・マニュファクチャリングの流れに沿ったGEM300の拡張スタンダード群

 

Japan Chapter of Information & Control Global Technical Committee
Japan GEM300 Task Force
東京エレクトロン株式会社 浅川輝雄

 

IoT、IIoTの潮流の中でSmart Manufacturingが脚光を浴びています。高性能なLSIの提供によってこのITの世界の実現に貢献した半導体製造業では、そのProcess Step数や制御Parameterの多さや高い清浄度への要求から、当時まだ貧弱だったIT環境の中で早い時期から物と情報の自動化が行われ、常に高度な製造系を追及して来ました。

特に300mm Waferへの移行時には業界を挙げてFactory Modelの検討が行われ、GEM300系及びInterface A系などの多くのSEMI Standardsが開発されて全自動製造工程の構築に貢献しました。
その後、2007年にはDevice Manufacturerの生産技術ConsortiumであるISMIからNGF (Next Generation Fab) Guidelinesが発行され、更なる改善に向けての課題提起がなされましたが、急速に進んだ事業環境の悪化と寡占化の中で大きな活動とはならず、GEM300は以後15年以上の間、小規模な改善改良をしながら使用されて来ました。

しかし、半導体製造のGlobal化と昨今のIoT、IIoTの流れの中で、守秘性(Security)、 追跡性(Traceability)、 可視性(Visibility)、制御性(Controllability)等に於いて更にSmartな製造環境が要求され始めました。
そこで、SEMI Global Information & Control委員会のJapan Chapterでは、これら新旧の課題に対応すべく、GEM300を補強するための SEMI Standards群「GEM300A Standards」の開発を行なって参りました。

図1 生産性改善の連鎖ImageとGEM300A Standards

現在、GEM300A Standardsは以下の文書から構成されています。

  • E170 SFORMS        Secured Foundation Of Recipe Management System

    Recipeの守秘性と作業効率とを向上させるために、その保存と作業とを工場RMS(Recipe Management System)上に集中させるための、Hostと装置との間の管理基盤を提供します。 Device Manufacturersはこの基盤の上に自らのBusiness Ruleを実現するRMSを構築することができます。

    そのためにRecipeIDを拡張した以下のID群で構成されるRecipeXIDを導入します。
    - RecipeID        現行のRecipeID(PPID)
    - VersionID        同一RecipeID下でのVersionを示す。
    - SecurityID        そのRecipeが属するSecurity Classを示す。
    - TypeID        Recipe型を示す。
    - EquipmentID        そのRecipeの適用装置を示す。

    このうち、SecurityIDに依って作業者(含むHost)の権限ごとに隔離された以下の4つの操作経路と各々に専用なSRS(Secured Recipe Space)を提供します。
    - 従来のGEM300のRecipe操作経路と互換の操作経路。
    - User定義による、守秘性を強化した使用者限定のRecipe操作経路。
    - Hostによる生産実行専用の隔離された操作経路。Recipe転送の工数や計算機負荷を軽減し、「RMS上で行ったことが装置上で得られること」という操作性を確保するために、工場RMSと装置内のProduction Recipe Cacheとの間の自動同期機能を提供します。
    - 工場RMS外に置かれた装置Supplier提供のRecipe ApplicationによるRMS上のRecipeの遠隔作業のための操作経路。守秘性を確保するためにRemote Access Cacheの操作規則が規定されます。
    更に読む
     
  • E171 PCL            Predictive Carrier Logistics

    効率的なCarrier Logistics制御によって、Carrier搬送の遅れに起因する装置の空き時間を削減するために、装置からHost(Carrier Dispatcher)やAMHS(Automated Material Handling System)にCarrier Logisticsの予測情報を報告する仕組みを提供します。

    装置からの予測情報と言うと、俗に言うUnload Prediction(Unload可能になる時刻の予測)のみを考えがちですが、装置の連続稼働にとって重要なTimingはUnloadではなく、処理するWaferが無くなる前に新たなCarrierがLoadされるTimingです。 また、Unload Predictionを用いても、全体にUnloadの手配時期が早くなるだけですので、渋滞緩和のための平準化などには情報が足りません。

    そこで、E171 PCLでは装置内での「Carrierの要求から払い出し完了」までのLife CycleをModel化することにより、以下の双方を含む「装置内の全Carrierの予定表」を提供し、より確実で柔軟な搬送の最適化を支援します。
    - 装置がCarrierのUnloadを要求する予測時刻
    - 装置がCarrierのLoad完了を要求する予測時刻(Loadが完了しないと装置が空いてしまう限界時刻の予測)

    予測情報はあくまでも予測であり、その精度の保証は難しいので、実装を容易にし、かつ妥当な効果を得るために、これらの予測情報の扱いにはBest Effort方式を基本としており、予測が変わった場合には随時予測の変更をすることができますし、予測できない場合には出力しなければ、従来通りに実際に確定した段階で手配をすることになっています。

    更にE171 PCLの採用により、装置は更に以下のような情報を報告もすることができ、「装置Pull」によるCarrier Logistics制御をすることも可能になります。
    - Fixed Buffer Equipmentに於いてLoad Portを効率的に使うための空Carrierの除去と再載置の要求の予測時刻。
    - DummyやMonitorのようなNPW(Non-Product Wafer)CarrierをLoad/Unload要求する予測時刻。
    更に読む
     
  • E174 WJM            Wafer Job Management

    装置内にあるWaferを個別に枚葉で観測・制御する手法を提供します。

    Waferの処理条件の厳格化による、「Waferの処理条件を個別に、しかも実時間的に(W2W Controlなど)制御したい」と言う要求に対し、GEM300は基本的にLot指向であり、個別のWaferに関連する情報をWaferに紐付けて観測し、Waferに対して直接制御する手段を有していません。

    そこで、Wafer指向の以下のJob機能を提供することに依って、個別のWaferを指示して必要な場面で、必要なWafer dataやContext dataを直接的に観測することや、最新のParameterでの制御をすることができる手段を提供します。
    - SEMI E40のProcess JobのSub-Jobとして、装置上にある一枚のWaferを観測・制御するWJ(Wafer Job)を導入。
    - 複数存在するWafer Jobを個別またはGroupでまとめて管理するためのWFJ(Wafer Flow Job)を導入。
    → 更に読む
     
  • Document #6092 CUARAM    Centralized User Authentication and Role Authorization Management

    この計画中のStandardは、巨大な半導体工場内の多くの装置群を操作する役割や専門の異なる多くのUserの管理に関する以下の課題を解決する仕組みを提供するために提案されました。
    - 各装置上に分散されたUser管理に起因するSecurityとSafetyの脆弱性の低減。
    - 各装置上に分散されたUser管理の業務量の低減。

    そのために、以下の仕組みを検討中です。
    - User管理と認証をHost側のServer一箇所に集中させる仕組み。
    - 装置の機能の違いと操作許可(Access Permission)設定の手法の特殊性を装置側で吸収する仕組み。
    - 複数の同型装置間での操作許可設定をHost側のServer経由で共有する仕組み。

    これにより、以下のような認証の手続きを考えています。
    - 装置はUserがLoginを要求すると、Host側のServerにUserの認証(Authentication)を依頼。
    - Host側のServerは正規のUserだと認証すると、そのUserのRole(役割、守秘性を管理)、Skill(能力、作業の質と安全性を管理)などの必要なAttributeを装置に提供。
    - 装置はこれらのAttributeから許諾される操作許可をUserに付与。

    装置上での操作許可設定の軽減に関しては、以下のような方法を考えています。
    - 1台の装置上で各Roleへの操作許可設定をする。
    - その情報をHost側のServer経由で他の同型装置に展開する。
    → 更に読む

これらGEM300A Standardsは昨今要求が高まっている製造工程の可視性と制御性、製品の追跡性、諸情報の守秘性の向上などを実現するためのEnablerであり、昨今流行のBig Dataの解析などを行い、制御に反映するための下支えとなるものです。

半導体工場には、典型的な制御系として以下の3つの系があります。

  • MES(Manufacturing Execution System)
    GEM300を通して生産制御をする固い制御系。(実時間制御系)
  • YMS(Yield Management System)
    GEM300経由のProcess情報を蓄積してDeviceの出来高管理分析をする系。(事後分析系)
  • EES(Equipment Engineering System)
    Interface Aからの情報によって装置の健康管理をし、MESに情報提供して装置制御をする緩い制御系。(ゆらぎ制御系)

IoT、IIoTと言うと、「Sensorをたくさん付けて多くの情報を集めてBig Data解析をする。」という部分に目を奪われがちですが、深い制御階層を持った半導体工場の巨大な製造系に於いては、情報の収集に於いても解析結果の反映に際しても、GEM300系を通した観測と制御を行うための基盤を通過する必要があり、この経路のSmart化が必要になります。 GEM300Aはその一端を担うものです。

図2 GEM300/GEM300Aの位置づけ

巨大化した半導体工場の複雑な製造制御体系にとって、いかに現状の仕様に課題があってそれを解消するための標準化が望まれていても、新たな標準の実装障壁は思いのほか大きいものです。 しかし、インダストリアル・インターネット・コンソーシアム(IIC: International Internet Consortium)脚注1やインダストリー4.0 (Industrie 4.0)脚注2によるIoT、IIoTの潮流の中で、サービス、物流、生産などに種々の変化が起きようとしています。 このような潮の流れの中で半導体製造工程も更なるSmart化を要求されます。 300mm化の際に行ったようなFactory Modelの検討と標準化を、今度はIIoT化に向けて進める時ではないでしょうか。

各スタンダードの詳細は、以下を参照してください。

1  SEMI E170 SFORMS: Secured Foundation Of Recipe Management System

1.1  概念
Recipeの守秘性と作業効率の向上のために、Recipeの管理と作業とを工場RMS上に集中させるためのHostと装置との間の管理基盤を提供する。
そのために以下の4つの操作経路を規定する。

  • 従来のRecipe操作経路
    従来のGEM300のRecipe操作経路と互換の操作経路。
    Conventional Recipe Space(従来のRecipe Space)を用いる。
  • 守秘性を強化した操作経路
    User定義による使用者限定のRecipe操作経路。
    Optional Recipe Spaceを用いる。
  • Hostによる生産実行専用の操作経路
    Hostによる生産実行にのみ用いられる隔離された操作経路。
    Production Recipe Cacheを用いる。 Recipe転送の工数や計算機負荷を軽減するために、PRC Operationによる工場RMSとの自動同期機能を有する。
  • Equipment Supplier提供のApplicationによるRMS上のRecipeの遠隔作業のための操作経路
    装置に最適化された、装置上もしくは装置Supplier提供のWorkstation上のRecipe Applicationを用いて工場のRMS上のRecipeを操作する操作経路。
    Remote Access CacheをRecipeの一時格納域として用いる。 守秘性を確保するためのRAC Operationが規定される。

図3 SEMI E170 SFORMSの適用例

そのために、以下のように階層的に機能を提供する。 下層から以下の通り。

  • Recipe IDを拡張してVersion ID、Security ID、Type ID(Recipeの型)、Equipment ID(適用装置)を加えたRecipe XIDの定義。
  • それを用いたSECS Messageの定義。(現行のSEMI E170.1はSEMI E39 OSSを用いているが、S20Fn系を用いるよう改訂を計画中)
  • Security IDを用いた作業者(含むHost)の権限ごとのSRS(Secured Recipe Space)管理の定義。
  • Hostによる生産実行専用のProduction Recipe Cacheと工場RMSとの自動同期の仕組み。
  • Equipment Supplier提供のApplicationによる工場RMS上のRecipeの遠隔作業のための仕組み。

図4 SEMI E170 SFORMSの階層Model

1.2  RecipeXIDと拡張Message
現行のGEM300 Standardsに於けるRecipeの識別子はRecipe ID (PPID)のみで、VersionやSecurityの差、対象装置、Recipeの型などを識別することができない。 そこで、E170 SFORMSではRecipeXIDと呼ばれる拡張IDを採用する。 RecipeXIDは以下のID群で構成されている。

  • RecipeID:        従来からのRecipeID(PPID)。
  • VersionID:        そのRecipeのVersionを示す識別子。 同じRecipeIDの下でUnique。
  • SecurityID:        そのRecipeが属するSecurity Classを示す識別子。
  • TypeID:        そのRecipeの型(System Recipe, Chamber Recipeなど)を示す識別子。
  • EquipmentID:    そのRecipeの適用装置を示す識別子。

また、E170 SFORMSが提供する拡張Messageには以下の能力がある。

  • Recipe XIDを使ってのRecipe特定。
  • 一度に複数のRecipeをList構造で送る(主にLinked Recipe用)。

1.3  SRS (Secured Recipe Space)管理
E170 SFORMSはRecipeを安全に管理するためにRecipeXID内のSecurityIDで区別される複数のRecipe Spaceを管理する能力を提供する。

  • Conventional Recipe Space:    GEM300の提供するRecipe Space。
  • Optional Recipe Space:        特定なUserに割り当てられたRecipe Space。Userが定義可能。
  • Production Recipe Cache:    Hostによる生産実行に特化したRecipe Space (Cache) 。人が触れることはできない。
  • Remote Access Cache:        RMS内のRecipeを遠隔操作する際に特化したRecipe Space (Cache) 。Userが定義可能。

1.4  PRC (Production Recipe Cache)管理
OperatorによるRMSから装置へのRecipeの事前展開の手間の削減や、Recipeの通信負荷の低減のために、E170 SFORMSは装置内のProduction Recipe Cache spaceとRMSとの間でのCache Algorismを提供する。装置はE40によってProcessの指示を受けると、そのRecipeをPRC内から探し、見つかればそれを実行し、見つからない場合にはRMSにRecipeを要求する。一度使用したRecipeはMaxNumberとMaxTimeとで指示された数と時間の範囲でPRC内に保存され、不要なRecipe転送とその後のRecipeの確認、展開などの作業の重複を避ける。

1.5  RAC (Remote Access Cache)管理
Recipeは装置に依って大きく異なり、汎用の文法定義や構造定義が極めて困難な上、その作成変更には装置の物理的条件を表す図式化した画面等が用いられるため、汎用のRecipe EditorなどのApplicationの作成は極めて困難である。 そこで、E170 SFORMSは装置Supplierが提供するRecipe Applicationを用いて工場RMS上にあるRecipeを操作する為の仕組みを提供する。
戻る

2  SEMI E171 PCL: Predictive Carrier Logistics

2.1  概念
E171 PCLは装置内での「Carrierの要求から払い出し完了」までのLife CycleをModel化することにより、「装置内の全Carrierの予定表」を提供し、より確実で柔軟な搬送の最適化を支援する。
そのために、以下の仕組みを提供する。

  • CLJ (Carrier Logistics Job)を導入して装置内に於ける各々のCarrierのLogisticsの状態を管理。
  • CFJ (Carrier Flow Job)を導入して、複数のCLJの順序を管理。 何れかのCLJが変化する度にCFJはHostに全CLJの情報を実行順に並べた「予定表」を報告する。

CFJから送出される予定表から、装置上でのCarrierの交換に許される時間窓であるCEW(Carrier Exchange Window)が得られる。 各装置から得られたCEWを比較することにより、Carrier DispatcherやAMHSはCarrierの配送手配時刻や配送優先順位を最適化することができ、結果的に装置の空き時間の削減が期待される。

  • Fixed Buffer Equipmentに於いては、CEWはLoad Port上のCarrierの交換に許される時間窓になる。(装置がCarrierのUnloadを要求する予測時刻と装置がCarrierのLoad完了を要求する予測時刻とで構成される時間窓)。
  • Internal Buffer Equipmentに於いては、複数のCarrierを限られた数のInternal Bufferとの間で短時間にUnload/LoadするためのLoad Portの最適なIn/Out順序要求を伴う時間窓になる。(4 Carrierの交換であれば、Unload、Unload、Load、Unload、Load、Unload、Load、Loadなど)

更に、以下の識別子の導入により、Host主導のCarrier Flowと装置主導のCarrier Flowとを区別する、Carrierの種類を区別するなども可能とする。

  • CarrierFlowID    Carrierの流れを複数管理するための識別子
  • CLJCarrierType    Carrierの種類(製品、空、NPWなど)を示す識別子

2.2  CLJ (Carrier Logistics Job)
CLJは装置から見た1つのCarrierの生涯Modelを以下の4状態で表現する。

  • Load Queued    Carrierの受け入れ希望表明状態。
  • Load Request    Carrierの受け入れが可能な状態。
  • Carrier Valid    Carrierが装置上にあり未完な状態。
  • Unload Request    Carrierが装置上にあり完了していて搬出待ちの状態。

また、その状態の変化予測を有する。

  • Load Request Prediction    Carrierを受け入れ可能な状態になる時刻の予測。
  • Load Stagnation Prediction    Carrierが供給されないと装置が空きになる限界時刻の予測。
  • Unload Request Prediction    Carrierが搬出要求状態になる時刻の予測。
  • Unload Stagnation Prediction    Carrierが搬出されないと装置が止まってしまう限界時刻の予測。

図5 Carrier Logistics Jobの状態と予測

2.3  CFJ (Carrier Flow Job)
CFJは装置上に複数あるCLJの実行順序を管理し、CLJの順序や状態に変化があると全CLJの情報を以下のような予定表(配列)にして報告する。

図6 Carrier Flow Jobの出力

2.4  Fixed Buffer EquipmentのCEW (Carrier Exchange Window)
CFJからの報告を解釈することに依って工場側は、最短のUnload Request Predictionと最短のLoad Stagnation Predictionとから、その装置のCEWを知ることができる。 複数の装置からのCEWに対する最適な対応優先順位を算出することに依って最適なCarrierの搬送計画を作成することができる。

図7 Load Port上のCarrier Logistics JobとCarrier Exchange Window

2.5  Internal Buffer EquipmentのCEW (Carrier Exchange Window)
Internal Buffer Equipmentでは一般に一回の処理終了で複数のCarrierを入れ替えるため、複数のCLJが移載遅延のみでほぼ並列にUnload可能状態になりLoad限界時刻を迎える。 最初のUnloadから最後のLoadまでがCEWとなる。

図8 Batch処理単位でのCarrier Exchange Window

しかし、これだけではInternal BufferとLoad Portの最適な使い方を表現していないので、更に効果的な入れ替えを行うために以下のようなLoad Port上での予定に展開する。

図9 Loa Port上でのCarrier Exchange Window

戻る

3  SEMI E174 WJM: Wafer Job Management 

3.1  概念
装置内にあるWaferを枚葉で追跡管理する手法を提供するために、以下を導入する。

  • SEMI E40のProcess JobのSub-JobとなるWJ(装置上にある一枚のWaferを観測・制御するJob)を導入してWaferを枚葉管理。
  • 更に、複数のWafer Jobの種々のQueue/Group管理を可能にするためにWFJを導入し、このWFJを介してWJ群を観測・制御。

3.2  Wafer Job (WJ)
装置上にあるWaferの状況を管理するJobで、Wafer1枚ごとに生成される。
Waferの情報もしくは実体を装置が認識した時点で生成され、Waferの情報と実体との送出を装置が認識した時点で消去される。

3.3  Wafer Flow Job (WFJ)
Wafer JobのInstanceは装置内に複数存在し、その順序の管理・制御が必要になる上、時に依っては集合を形成して同時に状態遷移することもある。 複数のWJを直接操作すると相互のTimingが問題になったり、集合を扱いにくかったりするので、WFJと言う管理Jobを定義し、このWFJと言う1つの管理点経由でHostが複数のW Jの順序や集合の管理を行なうことができるようにしている。
集合には以下がある。

  • PJG(Process Job Group):    同じProcess Jobに依って作成されたWJの集合。
  • EXG(Execution Group):    同時に同じ搬送や処理を受けるWJの集合。(Optional)

装置の形態からの必要性によって自由に設定可能。
順序制御には以下がある。

  • WJFlow(Wafer Job Flow):    複数のWJもしくはWJの集合の順序を管理するQueue。(Optional)
    必要に応じて作成することができる。

 図10 WJ とWFJ

WJはE40のProcess Job生成時にそのSub-Jobとして生成され、そのPJと紐付けられた1つのPJGを構成し、WFJの管理下に置かれる。 WJは単独もしくはEXGで定義された集合として処理され、その状況はWFJ経由でHostと共有される。 当該Wafer及びその情報が装置から出力されるとWJは消去される。

 図11 WJ とWFJの位置づけ

戻る

4  SEMI Doc. #6092 CUARAM: Centralized User Authentication and Role Authorization Management 

4.1  概念
守秘性向上と作業効率改善のために、各装置上に分散されている多くの装置群とそれら装置群を操作する役割や専門の異なる多くのUserの管理を集中管理化する。 しかし、装置の機能は装置に依って大きく異なり、更にその諸機能への操作許可の記述手法にも標準化できそうな有効な方法がない。 そこで、RBAC(Role Based Access Control)の考え方を導入する。

4.2  Role Based Access Control(RBAC)
RBAC手法では、Userに装置のOperationへの操作許可を与える際に、中間にRoleを定義する。 UserにはRoleを付与し、Roleに装置Operationへの操作許可を付与する。 こうすることに依って、同じRoleの複数Userの管理や、Role変更の複数Userへの反映などの作業が効率化される。
更にSkillの概念を導入し、個々のUserが保有している危険物取扱などの免許の有無を管理し、各Operation側がこれを確認することによりRoleにOverrideする形で安全な操作を補助する。
そこで、工場と装置とで以下の分担をする。

  • 工場側にUser管理とUserへのRoleとSkillの付与を任せる。
  • 装置側に各Roleへの種々の装置Operationの操作許可の付与を任せ、更にOperationはUserのSkillを確認する。

これに依って、工場側によるUserのRole/Skill設定と認証実行の一元化と、装置によるRole/Skillに対する装置固有の操作許可管理とを両立させる。

 図12 Role Based Access Controlの応用とRoleとSkill

より具体的には、以下。

  • 工場側にUserの集中管理のためのCUARAM Serverを置き、ここに以下を集中。
  • User登録
  • UserへのRole設定(Assignment)
  • UserへのSkill認定(Qualification)
  • User認証のService
  • UserのLog
  • 同型装置間でのRole-Permission情報の共有のためのServer機能
  • 装置側に以下の機能を持たせる。
  • Roleに対する各装置Operationへの操作許可の設定とCUARAM Server経由での同型装置間共有。
  • UserからのLogin要求によるCUARAM Serverへの認証要求。
  • CUARAM ServerからのRole/Skillを参照してのUserの操作許可の実行。

4.3  User管理と認証の集中化
工場側にUser管理のためのServer(CUARAM Server)を置き、その上で装置Userの集中管理を行う。
装置はUser(LocalかRemoteかは問わない)がLoginを要求すると、UsernameとPasswordをCUARAM Serverに送ってUserの認証を依頼する。 CUARAM ServerはUser認証の結果、正規のUserであれば、そのRoleとSkillの属性を装置に提供する。 装置はこれらの属性を参照してそのRoleとSkillとから許諾される操作許可をUserに与える。 これにより、Userの管理が一ヵ所になることによって作業効率が向上すると共にその状況把握が容易になり、守秘性の向上が期待される。

図13 Userの管理と認証の集中化

4.4  Role-Permission Descriptor のServing
Roleに装置Operationへの操作許可を付与する定義体(RPD: Role-Permission Descriptor)は装置に深く依存していて標準化の対象としにくいため、#6092 CUARAMではRPDをBlack-Boxとして扱い、CUARAM Serverを通して同種の装置間で共有する仕組みを提供する。 これに依り、同種の装置に対するRole-Permission定義は、一台の装置上で行なってRPDを共有することで効率化することができる。

図14 Role-Permission Descriptor のServing

→ 戻る

お問い合わせ先:
Standard & EHS, SEMI Japan
Junko Collins jcollins@semi.org

脚注:
1 インダストリー・インターネット・コンソーシアム(IIC, Industry Internet Consortium) - アメリカのGE、IBM、インテル、シスコシステム、AT&Tが発足させた民間企業によるコンソーシアム
2 インダストリー4.0 (Industrie 4.0) - ドイツが進める国家プロジェクト。ネットワークで情報を繋ぎ、コンピュータ、人口知能を活用して生産や流通の自動化を最適なレベルまで引き上げる試み。

参考文献:
SEMI E170: Specification for Secured Foundation Of Recipe Management System (SFORMS)
SEMI E171: Specification for Predictive Carrier Logistics (PCL)
SEMI E174: Specification for Wafer Job Management (WJM)
SEMI Doc. #6092: Specification for Centralized User Authentication and Role Authorization Management (CUARAM)