這篇部落格文章最初發表於 cimetrix.com
背景
英特爾的克里斯·馬洛尼（Chris Maloney）與我共同擔任北美 GEM 300 專責小組的聯合負責人。我們負責領導該專責小組所有與 GEM 技術相關的 SEMI 標準相關工作，其中涵蓋了大量 SEMI 標準。
APCSM 研討會
我最近在德州奧斯汀參加了 APCSM（先進製程控制與智慧製造）會議，並在會中講授了 GEM 標準。在我所呈現的講稿中，我列出了我所謂的「GEM 核心理念」。這些正是 GEM 技術中足以證明其應被更廣泛採用與運用的特點。這些核心理念包括：
兩種訂閱方案
設備的 GEM 介面不僅充當訊息中介，更具備多重功能。它並非僅僅是簡單的訊息訂閱（開啟／關閉）服務。 終端使用者主機擁有相當大的控制權，可決定來自設備的每則訊息內容。同一個 GEM 介面，根據各終端使用者主機所設定的資料收集配置，可能在某個終端使用者站點傳送較少且較小的訊息，而在另一個站點則傳送數量較多且較大的訊息。請將以下功能與典型的訊息中介訂閱模式進行比較：在該模式下，客戶端僅能選擇訂閱或不訂閱特定訊息，卻無法控制訊息內容或傳送頻率。
「收集事件報告」功能允許最終使用者啟用或停用收集事件訊息的通知，這是一種典型的客戶端訂閱模式。作為第二層次的訂閱，最終使用者亦可選擇這些訊息中要包含的資料。
追蹤報告允許最終使用者選擇追蹤報告訊息的發送頻率。作為第二層訂閱設定，最終使用者亦可選擇這些訊息中包含的資料內容。
警報報告可讓終端使用者啟用或停用警報訊息通知。作為第二層級的訂閱設定，終端使用者亦可獨立選擇與警報相關之資料蒐集事件的報告配置。
適應能力
任何製造設備，無論簡單或複雜，都可能具備 GEM 介面。GEM 介面的複雜程度反映了該設備的複雜程度。例如，某個 GEM 介面可能只有 15 個獨特的資料擷取事件，而另一個則可能多達 20,000 個；某台設備可能只有 10 個狀態變數，而另一台則可能超過 5,000 個。
此外，GEM 介面所採用的技術已相當成熟，因此無論是 Windows、Linux、PLC 還是任何其他作業系統，皆可在設備平台上實作 GEM 介面。 令人驚訝的是，仍有相當多的設備仍在使用較舊的軟體開發技術，例如 Visual Basic 6.0 和 Visual C++ 6.0，但這些技術依然能夠實作 GEM。沒錯，即使是完全基於 PLC 建構的設備，也能在 PLC 內部透過序列通訊或 TCP/IP 實現一個極簡的 GEM 介面。GEM 標準允許實作方根據實際需求，選擇是否實作特定功能。
可擴展性
在不影響向後相容性的情況下，可輕鬆將額外的資料擷取事件、警報及變數新增至現有的 GEM 介面。一旦新項目加入 GEM 介面後，終端使用者主機即可根據需求自行決定是否使用該資料。
此外，其目的還在於整合來自不同來源的需求，並將其彙整至單一的 GEM 介面中。進一步說明，GEM 介面的需求將來自不同的終端使用者、GEM 標準本身、設備供應商以及其他相關標準。將來自所有這些來源的需求整合至單一的 GEM 介面中，這項工作相對較為簡單。而整合後的数据收集功能，本質上可整合為可追溯報告與事件收集報告。
自上而下的互聯性
在許多情況下，讓某台設備能夠存取另一台設備的資料會很有幫助。其中一種可能的解決方案是設備之間的直接通訊。然而，在使用 GEM 時，雖然未禁止設備之間的直接連線，但通常並不會採用此方式。 相反地，GEM 採用自上而下的連線方式。這意味著終端使用者主機會透過其 GEM 介面從某台設備收集資訊，然後再將該資訊傳遞給下游設備。雖然這種間接方式看似效率較低，但這種自上而下的方法在工廠現場的整合上往往更為簡便。原因包括：
1. 這些情境可以不依賴特定設備。驗證設備間的通訊可能相當困難，而且無法輕易將某家供應商的設備替換為其他供應商的設備。每台設備只需與一個主機實體進行測試即可。
2. 這樣對設備供應商而言更容易提供技術支援。設備供應商只需支援 GEM 介面，無需支援額外的設備對設備通訊協定。
3. 這賦予了終端使用者更多的控制權。終端使用者可以精確記錄每台設備的運作狀況，必要時甚至可以對資訊進行調整。設備之間的獨立連接，在診斷問題時會造成額外的複雜性。
GEM 標準的令人振奮的變革
幾週後，針對修改 SEMI E30 GEM 標準的提案（投票案 6572C），將於秋季北美資訊與控制委員會會議中進行審議。 會議將於 2022 年 11 月 9 日在加州米爾皮塔斯的 SEMI 總部舉行。此項表決提案對 GEM 標準提出了多年來最重大的變更。由於這是針對這些變更進行的第四輪表決，這些變更極有可能獲得批准，尤其是上一輪投票結果顯示對這些變更有強烈的支持。以下是擬議變更的摘要：
流程計畫管理
針對設備配方（亦稱製程程式）的處理方式，提出數項變更建議。其中最重大的變更，是提議正式採用先前在 SEMI E5（SECS-II）標準中已獲批准的 Stream 21 SECS-II 訊息，該標準為所有標準訊息定義的函式庫。 Stream 21 訊息將使設備能夠在大小超過 16.7 MB 的情況下，仍能與設備之間傳輸未經格式化的製程程式。這是對 GEM 標準一項遲來已久的強化，該標準目前雖定義了支援大型製程程式的替代方案，但這些方案過於複雜，以致幾乎沒有任何廠商曾實際實施過。
此外，流程計畫管理部分已進行全面重組，將各項實施方案分開列出，以便更輕鬆地辨識各情境組合。例如，以下是一張彙總各情境相關訊息的新表格：
表 7 各流程計畫管理選項之 SECS-II 訊息摘要
從 GEM 標準正文中移除的每項製程程式實作方案，均已移至附錄中。
我們希望配方管理能更易於理解、更易於實施，並能以較少的精力應對流程程式規模不斷擴大的情況。
其他新訊息
提案 6572C 亦提議新增 S2F51 至 F64 之間的新訊息。這些訊息先前已獲 SEMI E5（SECS-II）標準核准，現提議納入 GEM 標準。這些訊息可為 GEM 介面增添更多透明度。以下是新訊息的簡要摘要：
| 訊息 | 說明 |
| S2F51 | 向設備發出請求，以取得所有報告識別碼的清單。 |
| S2F53 | 要求歸還一個或多個報告定義 |
| S2F55 | 向設備發出請求，以取得一個或多個收集事件所對應之關聯報告識別碼清單。 |
| S2F57 | 向設備發出請求，以取得所有已啟用報告功能的資料擷取事件識別碼清單。 |
| S2F59 | 向設備發出請求，要求其回傳在排程功能啟用時，所有將被排程的串流與函式清單。 |
| S2F61 | 向設備發出請求，要求其返回所有追蹤識別碼的清單。 |
| S2F63 | 向設備發出請求，以取得一個或多個追蹤定義的清單。 |
這些新訊息不僅讓 GEM 介面的設定與配置更加透明，還能進一步改善 GEM 介面的測試。例如，將可依照以下步驟來測試 GEM 介面：
1. 使用訊息 S2F33 定義一份報表
2. 使用新訊息 S2F51 檢查報表是否存在
3. 使用新訊息 S2F53 檢查報表定義
4. 使用訊息 S2F35 將報表與收集事件建立關聯
5. 使用新訊息 S2F55 檢查報表關聯狀態
6. 使用訊息 S2F37 啟用收集事件
7. 使用新訊息 S2F57 檢查資料擷取事件的啟用狀態
8. 與設備斷開連線並重新啟動設備
9. 使用新訊息 S2F51 檢查報告是否存在
10. 使用新訊息 S2F53 檢查報告定義
11. 使用新訊息 S2F55 檢查報告連結狀態
12. 使用新訊息 S2F57 檢查資料擷取事件的啟用狀態
如今，主機在重新連線至 GEM 介面時，通常會重新定義資料擷取設定，以確保在斷線期間（此時其他主機應用程式可能已修改資料擷取設定）資料擷取設定未被變更。主機無需重新定義資料擷取設定，而是可以驗證資料擷取設定是否仍維持不變。
設備識別
目前，設備是透過 GEM 介面，依據其軟體版本號及型號來進行識別。兩台型號相同且運行相同軟體版本的設備，難以輕易區分。
新增了幾項識別功能。
| E30設備供應商 | 這是一項用以遴選設備供應商的新提案。 |
| EqpSerialNum | 該設備的序號。這項內容多年來一直是 E5 SECS-II 標準的一部分，但 GEM 標準並未將其列為必備項目。 |
| EqpName | 由操作員或主機可指定的名稱。此項內容雖已納入 E5 SECS-II 標準多年，但 GEM 標準並未將其列為必備項目 |
改進設備識別功能應有助於先進製程控制的應用。
文件存取
使用 GEM 介面時，常見的困難之一在於難以取得設備的正確文件，以及該文件的正確版本。本投票案提議透過 GEM 介面提供兩種獲取 GEM 文件的方式。
1. 下載傳統的 GEM 文件，格式可能是 PDF 或 CSV 檔案。
2. 下載 SEDD 檔案，這是一個描述 GEM 介面的 XML 檔案。SEDD 代表 SECS 設備資料字典。
在這兩種情況下，文件都是透過 Stream 21 訊息下載的，這與用於傳輸流程程式的同種新訊息相同。
各項變更
此外，還提出了一些其他變更。SEMI 近期才通過了關於「受限偏見」術語的要求，以及針對其他帶有偏見術語的指引。雖然 GEM 標準中並未包含任何「受限偏見」術語，但確實存在一些帶有偏見的術語。本次表決所針對的，正是那些可依照 SEMI 指引加以處理的帶有偏見術語。
GEM 合規聲明亦已更新，以反映 GEM 的變更。新的合規聲明內容如下：
