装置のデータを細かく取りたくなったとき、SECS/GEMの回線に収集を積み増すのは筋が違う。PEER Groupのフチガミ（Albert Fuchigami）氏は講演資料で、SECS/GEMを「制御の回線」と呼び、データ収集で過負荷にしたくないと書いています。データ用にもう一本の口を定めたのがEDA（Interface A）で、その中核規格は今、SOAPバインディングとProtocol Buffers版の二つを同じ規格の中に抱えています。新しい装置を発注するなら、どの版で作られた装置なのかを仕様書に一行で書いておく。
30秒でわかるEDA（Interface A）
| 項目 | 内容 |
|---|---|
| ひとことで | 装置からデータを受け取るための、SECS/GEMとは別の通信チャネルを定めるSEMI規格群。柱はE132（認証・認可）、E125（装置の自己記述）、E134（データ収集管理） |
| 工場での意味 | 制御はSECS/GEM、FDCやAPCに回すデータはEDA、と回線を分けられる |
| なぜ今 | E134・E125・E132の現行版（いずれも1225）が、SOAPバインディング（.1）とProtocol Buffers版（.2）を下位規格として同梱している。どちらを指定するか決めずに発注すると、装置と受け側ソフトの組み合わせが宙に浮く |
| 最初の一歩 | 装置発注仕様書に、EDAのFreezeバージョンとバインディング（.1か.2か）、改訂コードを書く欄を一行足す |
| 本稿で扱わないこと | 通信方式ごとの速度比較。規格本文は有料のため、SEMIストアの公開要旨と、SEMIのサイトに掲載されたベンダー担当者の講演資料で確認できた範囲だけを書く |
「EDAはSECS/GEMの後継」ではない
EDAはSECS/GEMを置き換える規格ではありません。制御の回線を残したまま、データ用の回線をもう一本引く規格です。
「Interface A」という別名のせいで、SECS/GEMの次世代版だと受け取りたくなる。冒頭のフチガミ氏は、SEMIの規格化作業部会（北米DDAタスクフォース）で共同リーダーを務める人物です。その講演資料（2024年12月のSEMICON Japan EDAワークショップで使われ、SEMIのサイトに掲載）は、この読み方をはっきり退けています。
（EDAはSECS/GEMと競合しない。SECS/GEMは制御の回線であり、データ収集で過負荷にしたくない。EDAは装置からの別の通信チャネルである）
Albert Fuchigami（PEER Group）「Addressing Big Data Needs with EDA / Interface A」SEMICON Japan EDA Workshop、2024年12月
"EDA is not in competition with SECS/GEM" "SECS/GEM is the control channel. Don’t want to overload it with data collection." "EDA is a separate communication channel from the equipment."
よくある配置としてフチガミ氏が挙げるのは、EDAでAPC／FD向けのデータを取り、設定の微調整は制御の回線で行う形だ（原文 "Common deployment is to use EDA to get data for APC/FD, and then tweak settings through the control channel."）。データは片方の口から出て、指示はもう片方の口から入ります。
規格の側も線を引いています。EDAの認証・認可を定めるSEMI E132の公開要旨は、SEMI E30の通信・制御状態モデルが律する通信には適用しないと明記する（"It does not apply to communication that is governed by the SEMI E30 communication and control state models."）。GEMの世界とEDAの世界は、入口から別々に設計されています。
前回のSECS/GEM非対応の装置を三列に分ける記事で扱ったのは、制御の回線をどう通すかだった。今回はその隣に立つ、もう一本の回線の話です。
工場の言葉で言い換えると：入館証、目録、収集計画
EDAの柱になる三つの規格は、入館証・目録・収集計画に置き換えると掴みやすくなります。どれもSEMIストアの公開要旨に範囲が書かれている。
入館証にあたるのは、SEMI E132です。要旨によれば、この規格はクライアントに対し、以降の通信に進む前に装置への認証を求める（"requiring clients to authenticate to the equipment before proceeding with subsequent communication"）。認可の細かさは装置メーカーに委ねられ、幅はアクセス制限なしから、事前定義のロールベース、きめ細かな制御までと書かれています（"ranging from no access control restrictions, predefined role-based access control, to very fine-grained control"）。制限なしも規格の範囲内。この点は覚えておいてください。
目録にあたるのは、SEMI E125（装置の自己記述、EqSD）です。装置メーカーが、装置から取れる変数・イベント・例外・物理的な装置構成を記述する方法を定める規格だ。扱う情報は、静的な性質のものに限られます（"information that is static in nature"）。メタデータが人間にそのまま読めることも求めていません。目録は機械が読むもので、人が読むには別のアプリケーションが要る設計だ。
収集計画にあたるのは、SEMI E134（データ収集管理、DCM）です。範囲は、名前付きのデータ収集計画を使ってイベント・例外・トレースデータを取得すること（"acquire event, exception, and trace data from semiconductor equipment through the use of a named data collection plan"）。計画の外でその場限りの要求を出す手段も定めています。現場目線で見逃せないのは次の一項です。
（本仕様は、データ収集を含む装置上の活動の組み合わせによって、装置がサプライヤー定義の基準を下回る性能で動いている場合に、装置がユーザーへ通知する方法を定める）
SEMI E134-1225, 2.3（SEMI Store）
"This Specification defines a way for the equipment to notify users when the combination of activities on the equipment, including data acquisition, is causing the equipment to perform below supplier-defined criteria."
データを取りすぎて装置の足を引っ張ったら、装置の側から知らせる。収集が生産を邪魔し得ることを、規格が最初から前提に置いているのです。E134は参照規格にSEMI E5（SECS-II）とSEMI E30（GEM）も挙げており、SECS/GEMと無関係に作られた規格ではありません。
| 工場の言葉 | 規格 | 公開要旨にある範囲 |
|---|---|---|
| 入館証 | SEMI E132（認証・認可） | 通信の前に認証。認可の粒度は制限なしから細粒度まで装置メーカーが選べる |
| 目録 | SEMI E125（EqSD） | 装置から取れる変数・イベント・例外・構成を、静的な情報として記述 |
| 収集計画 | SEMI E134（DCM） | 名前付きの収集計画でイベント・例外・トレースを取得。性能低下の通知、計画外の要求も定める |
一つの規格にSOAP版とProtocol Buffers版が同居している
今SEMIストアでE134を買うと、SOAPバインディングとProtocol Buffersの下位規格が両方ついてくる。装置がどちらで作られているかは、規格番号の枝番で見分けます。
三つの規格のストアページには、いずれも「Subordinate Standards (included)」として二つの下位規格が並んでいます。枝番.1がSOAPバインディング、.2がProtocol Buffers。改訂履歴の欄を拾うと、こうなります。
| 本体（現行版） | SOAPバインディング（.1） | Protocol Buffers（.2） |
|---|---|---|
| SEMI E134-1225（データ収集管理） | E134.1-0414（初版0305） | E134.2-1225（初版1022） |
| SEMI E125-1225（装置の自己記述） | E125.1-0414（初版0305） | E125.2-1225（初版1022） |
| SEMI E132-1225（認証・認可） | 改訂履歴の最新はE132.1-1015（初版0305） | E132.2-1224、1225で再承認（初版0422） |
SOAP側の改訂履歴は0414や1015で止まっています。Protocol Buffers側は初版のあとも改訂が重ねられ、E134.2とE125.2は1225の版、E132.2は1224の版を1225で再承認。どちらに手が入り続けているかは、履歴の並びだけで読み取れます。
両者の違いは、データの包み方にあります。フチガミ氏は現行の組み合わせを"EDA Freeze 1 – HTTP/1.1 with SOAP/XML"、"EDA Freeze 2 – HTTP/1.1 with SOAP/XML"と整理し、その弱点に全データが文字列テキストで送られる点を挙げる（"all data is sent as string text"）。提案中の次の組は"Proposed EDA Freeze 3 – HTTP/2 with gRPC/Protocol Buffers"です。テキストで運んでいたものを、Protocol Buffersのバイナリで運ぶ方向です。
ここで出てきた「Freeze」が、発注の話では一番効いてくる。定義はこうです。
（EDAのFreezeバージョンは、装置サプライヤーとチップメーカーがインターフェースを実装するための統一セットとして用いる、SEMI規格とその版の特定の組を指す）
Albert Fuchigami（PEER Group）SEMICON Japan EDA Workshop、2024年12月
"EDA Freeze Versions identifies a specific set of SEMI Standards and versions that equipment suppliers and chip makers use as a unified set to implement the interface."
Freeze 1を「1105」、Freeze 2を「0710」として版の組を並べた上で、資料は注記で念を押しています。インターフェース定義の変更とSOAP 1.1から1.2への変更により、Freeze 2はFreeze 1と相互運用できない（"Freeze 2 is not inter-operable with Freeze 1 because of interface definition changes and protocol changes from SOAP 1.1 to SOAP 1.2"）。同じ「EDA対応」でも、組が違えば話が通じない。
SOAP版の装置が今日から使えなくなるわけでもありません。同じ注記によれば、.1規格の最新改訂はinactiveでも入手可能で技術的に有効、Freezeバージョンも引き続き有効です（"Although latest revisions of .1 standards are inactive, they are still available and technically valid. The Freeze versions are still active."）。
Freeze 3はどうか。資料の時点では"Finalize Freeze 3 definition"が「Coming Soon」の欄にあり、定義は"Publish in new SEMI E178 revision."とされていました。2024年12月の段階では、組はまだ確定前だった。その後の確定状況は、発注前にSEMI E178の現行版とメーカーの回答で確かめてください。
EDA規格群の関係を説明するガイドもあります。SEMI E147で、要旨によれば2007年2月にSEMIのサイトで公開され、同年9月に編集上の修正を受けた。ストアに並ぶその版（E147-0307E）の表示は「Inactive」です。ガイドの版と、手元の装置が実装している規格の版は、別々に確かめる必要がある。
現場で効く場面
FDC用のトレースを、制御の回線の外で取る
トレースは用途ごとに収集計画を分け、必要な速度は仕様書に数字で書きます。E134の収集計画は、関連するデータをグループにまとめ、まとめて有効・無効を切り替えられるように作られています。フチガミ氏は、逸脱を早く見つけるためにすぐ装置外へ出すデータと、低レベルのセンサーデータのように貯めて定期的に送るデータの釣り合いを取る、と説く。消費者が違えば計画も分ければいい（"Different consumers can have different needs (thus different DCPs)"）。
SECS側との違いにも触れています。SECSはデータ変数がどの構成要素から来たかを規定せず（"Does not specify which component is the source of a data variable."）、状態モデルのイベントのCEIDは多くの場合全インスタンス共通で、どのインスタンスの報告かはDV（データ変数）で示す、と資料は整理する。EDAではイベントの発生源ごとに別の収集計画を作れるので（"Can create separate DCPs for each possible source of the event"）、チャンバーが複数ある装置なら、発生源ごとに計画を分けて受け取る設計を選べます。
発注で揉めやすいのは速度だ。収集性能について資料は、よくある質問だがSEMI規格では明示されていない、と前置きした上で（"Frequent question - Not explicitly specified by SEMI Standards"）、参考として次の例を並べています。
| 資料に挙がった例 | 資料の表記 |
|---|---|
| SEMATECH | 10K VPS（1000 variables @ 10 Hz） |
| アジアのファブ仕様 | 20K VPS（2000 parameters per event at 10Hz sampling rate） |
| アジアのファブ仕様 | Minimum 40K VPS（4000 variables @ 10Hz）、Request 60K VPS |
その上で、性能は計算機（メモリ、CPU）、ネットワーク、収集計画の組み方に左右されるとする。規格が数字を決めていないなら、数字は仕様書に書くしかありません。
同型の装置で、目録が揃っているか確かめる
回線を二本にするなら、同型の装置で目録が揃っているか、同じ値が両方の口から同じに出るかを、稼働前に確かめておきます。Freeze 2の導入動向として資料が挙げる課題の一つが、メタデータの「copy exact」の問題だ。この2台は同じ装置型式か、アップグレード後にメタデータは変わったか、という問いです（"are these two pieces of the equipment type the same? Did the metadata change same after an upgrade?"）。もう一つがEDAのデータとSECS/GEMのデータの照合で、同じものかどうかが問われています（"Validating the EDA data against the SECS/GEM data. (Are they the same?)"）。
どちらの口の値を正とするかを決めないまま稼働させれば、FDCとMESで数字が合わない日が来る。
メタデータの共通表現を定めるSEMI E164については、統合が容易になる価値をファブが認め、購買仕様に含められつつあるそうです（"Being included in Purchase Specs because Fabs see the value of easier integration."）。E164はFreeze 2の定義の外にあるため問題になり得る、とも添えられています。
Freeze 3の計画には、SECSのVIDとの対応を1対1にする項目（"Parameters now map to a single SECS VID, instead of many VIDs."）や、別個体の装置で同じメタデータを識別する「metadata fingerprint」が並ぶ。現場の悩みが、そのまま改訂項目になっている。
誰が装置からデータを取れるかを決める
EDA対応の装置でも、暗号化と接続者の絞り込みは仕様書で別に指定します。E132の公開要旨には、見落とすと後で困る一文があります。確立済みのセッションで送るデータの暗号化は求めず、暗号化は認証プロトコルが定める範囲でのみ必要とする（"This Standard does not require data transmitted over an established session to be encrypted, encryption is only required as specified by the authentication protocol."）。先に見た通り、認可も「制限なし」まで規格の範囲に入ります。EDA対応と書いてあるだけでは、通信が暗号化され、接続者が絞られている保証にはならない。
フチガミ氏の資料では、Freeze 3の計画として、gRPCでのSSL/TLS証明書の組み込みやすさ、SessionIDとClientIDのSHA-256によるハッシュ化、ACLへのパスワード導入が挙がっています。clientIdを知っているだけではセッションを確立できなくなる（"can no longer establish a session just because you know the clientId value"）。いずれも2024年12月時点の計画で、確定した仕様としてではなく、メーカーに実装状況を尋ねる観点として使うのが安全です。装置ネットワークの守り方は、SEMI E187と既存装置の扱いを書いた記事と合わせて読むと繋がります。
選ぶのは規格ではなく「版の組」
「EDA対応ですか」と聞くだけでは、半分しか聞いていない。問うべきは、どのFreezeで、どのバインディングで作られているかです。
実装する側ですら、そこで食い違っています。フチガミ氏の資料によれば、EDAソフトウェアの実装者同士で相互接続を試す場は3回開かれ、目的は相互運用の問題を洗い出し、食い違う前提を明らかにすることだった（"work out inter-operability issues and clarify conflicting assumptions"）。見つかった課題は、SEMICON West 2022の回で24件、2024年3月の回で15件、2024年11月の回で28件です。規格に詳しい実装者が集まってもこれだけ出るなら、仕様書に版を書かずに装置とソフトを別々に買った工場で何が起きるかは、想像がつきます。
本質は、EDAが新しい技術かどうかではなく、装置メーカー、受け側のソフト、工場の三者が同じ組を指しているかどうかにある。それを文字にして残せる場所は、発注仕様書しかありません。
月曜日にやること：発注仕様書に一行足す
新規装置の発注仕様書の通信要件に、次の一行を足します。書くのは生産技術、読むのは装置メーカーと受け側ソフトの担当。
EDA（Interface A）：対応するFreezeバージョン、バインディング（SOAP：E134.1／E125.1／E132.1、Protocol Buffers：E134.2／E125.2／E132.2）とそれぞれの改訂コード、SEMI E164対応の有無、保証する収集性能を回答すること。
一行に詰めた項目を解くと、こうなります。
| 項目 | 書き方の例 | 根拠の節 |
|---|---|---|
| Freezeバージョン | 「Freeze 2」または「Freeze 3（定義確定後の版）」 | Freeze 1と2は非互換（上の「一つの規格にSOAP版とProtocol Buffers版が同居している」） |
| バインディングと改訂コード | 「E134.2-1225」のように枝番と改訂コードまで | 現行版は.1と.2を同梱（同じ節） |
| SEMI E164 | 対応の有無 | 購買仕様に入りつつある（上の「同型の装置で、目録が揃っているか確かめる」） |
| 収集性能 | 変数の数とサンプリング周期を自社の要件で | 規格に数値の明示なし（上の「FDC用のトレースを、制御の回線の外で取る」） |
| 認証・暗号化 | 認可の方式（ロールベース等）と、セッション上のデータの暗号化の有無 | セッション暗号化は必須でない（上の「誰が装置からデータを取れるかを決める」） |
すでにラインにある装置は、この表を問い合わせ票として使えます。SOAP版で作られた装置でも、.1規格は技術的に有効とされている。替える前に確かめたいのは、受け側のソフトがその組を話せるかどうか。捨てない自動化の入口は、装置の版を知ることにあります。
制御の回線を太くするのではなく、データの回線を別に引く。その工事の一本目は、仕様書の一行です。
参考資料
- SEMI E134-1225 – Specification for Data Collection Management（SEMI Store）
- SEMI E125-1225 – Specification for Equipment Self Description (EqSD)（SEMI Store）
- SEMI E132-1225 – Specification for Equipment Client Authentication and Authorization（SEMI Store）
- SEMI E147-0307E – Guide for Equipment Data Acquisition (EDA)（SEMI Store）
- Albert Fuchigami（PEER Group）「Addressing Big Data Needs with EDA / Interface A」SEMICON Japan EDA Workshop、2024年12月（SEMIサイト掲載）
- Albert Fuchigami（PEER Group）「Next-Gen SEMI EDA Standards」2018年3月1日（SEMIサイト掲載）
- SECS/GEM非対応の装置は三列に分けてMESに繋ぐ（techandchips）
