這篇部落格文章最初發表於 cimetrix.com
《Freeze 3》背景
身為北美 DDA 專案小組的共同負責人之一，我經常被問到 EDA Freeze 3 何時能準備就緒以供實施。SEMI DDA 專案小組已投入數年時間，致力於制定 EDA Freeze 3 標準。這是製造設備資料收集標準的更新版本。遺憾的是，受諸多因素影響，這項工作的進展相當緩慢。 關於「凍結版本」的更多資訊，請參閱 SEMI 標準 E178，該標準中對官方凍結版本有明確定義。
Freeze 3 狀態
截至目前為止，已完成以下投票：
| 標準（投票） | 選票狀態 |
| E138 (6336) | 發佈日期 – 2019年3月15日 |
| E120 (6434) | 發佈日期 – 2019年5月30日 |
| E145 (6436) | 發佈日期 – 2019年5月31日 |
| E178 (6300) | 發佈日期 – 2020年10月1日 |
| E179 (6803) | 發佈日期 – 2022年11月3日 |
| E132 (6719A) | 發佈日期 – 2022年4月29日 |
| E132.2 (6346F) | 發佈日期 – 2022年4月29日 |
| E125 (6718A) | 發佈日期 – 2022年4月22日 |
| E134 (6720A) | 最終出版核准。可能在 2022 年 9 月，但肯定會在 2022 年 10 月之前。 |
| E134.2 (6347A) | 最終出版核准。可能在 2022 年 9 月，但肯定會在 2022 年 10 月之前。 |
| E179 (6837) | 已核准 – 待發佈 |
| E125.2 (6345A) | 最終出版核准。可能在 2022 年 9 月，但肯定會在 2022 年 10 月之前。 |
| E125 (6891) | 最終出版核准。可能在 2022 年 9 月，但肯定會在 2022 年 10 月之前。 |
| E179 (6892) | 已核准 – 待發佈 |
| E120.2 (6908) | 最終出版核准。可能在 2022 年 9 月，但肯定會在 2022 年 10 月之前。 |
在 2022 年夏季的會議中，有三項 DDA 工作小組的表決案未能通過裁決，分別是 6927（E125、E125.2）、6928（E132、E132.2）及 6929（E134、E134.2），原因在於這些表決案存在違反 SEMI 規定的程序性錯誤。 這主要是因為先前已核准之規格的出版物積壓已久。自那時起，SEMI 便一直竭力趕上標準出版進度。
測試場次 #1
對 DDA 專案小組而言，最重要的活動是於 7 月 14 日（星期四）舉行的「供應商測試環節 #1」。主辦方向所有專案小組成員發出公開邀請，邀請他們參與 E132 測試環節。任何人都可以提交基於現行 E132 和 E179 規格所實作的客戶端和／或設備伺服器。 共有四家公司齊聚一堂，針對彼此的軟體進行互測。每位參與者將向工作小組提供一份關於 E132 和 E179 的問題清單。這是一次絕佳的機會，讓大家能共同試用 gRPC 技術，並了解在 EDA Freeze 3 完成之前，還有哪些問題需要解決。
當前選票
目前有兩項投票正在進行中。投票結果將於 11 月第二週在 SEMI 總部舉行的「北美 SEMI 秋季會議」期間進行評審（與會者亦可遠端參與）。
選票編號 6947
第 6997 號表決案是對 SEMI E179 的更新，該標準是 EDA 凍結版 3 的基礎標準，定義了如何將 gRPC 應用於相關標準及其他重要定義。本次表決案包含三項議案。
1. 修正由 Cimetrix 軟體工程團隊發現的陣列定義中的缺陷。
2. 闡明「one of」關鍵字的使用方式。
3. 針對符合 SEMI 風格手冊的要求進行相關變更。
選票第 6946 號
本次投票包含 5 項議案，其中包含幾位貢獻者的工作成果。
1. 釐清部分定義與概念。
2. 全面重寫 ACL 密碼與安全性情境。
3. 重寫 EstablishSession 與 ChangeSessionEndpoint 的功能。
4. 修正供應商測試環節 #1 中發現的部分問題。
5. 修正部分拼寫錯誤，並整理 .proto 檔案的使用方式。
ACL 密碼與安全機制的重新設計由 Cimetrix 提交。在目前的 EDA Freeze 1 和 Freeze 2 版本中，尚無僅在使用 SSL 時才會進行驗證的密碼機制。密碼機制曾在先前的一次表決中引入 E132，並已通過投票且正式發布。 此舉旨在即使未使用 SSL，仍能提供一定程度的安全保障。然而，對現行密碼實作的安全性審查顯示，其驗證機制存在若干問題。本次表決案提議引入「挑戰令牌」，使 EDA 客戶端能夠證明其知悉正確密碼，具體情境如下所述：
|
客戶會談 |
方向 |
設備伺服器 |
| 假設「客戶端會話」已知曉 equipmentId、clientId 以及明文 ACL 密碼。可透過 InterfaceDiscovery 介面取得 equipmentId。 | ||
| GetEquipmentInformationRequest (equipmentId, clientId) |
? |
|
|
|
產生一個與 equipmentId 和 clientId 相關聯的 challengeToken 值。 | |
|
? |
GetEquipmentInformationResponse (aclEntrySalt, challengeToken) |
|
| 「客戶端會話」會使用 aclEntrySalt 以及明文 ACL 密碼來產生 passwordHash。 |
|
|
| 「客戶端會話」會使用 challengeToken 和 passwordHash 來產生客戶端的 challengePasswordHash
|
|
Equipment Server 會使用 challengeToken 和 passwordHash 來產生其版本的 challengePasswordHash
|
| EstablishSessionRequest (設備 ID, 客戶端 ID, 驗證密碼雜湊)
|
? | 客戶端會話提供的 challengePasswordHash 值等同於設備伺服器版本的 challengePasswordHash
產生 sessionId。 |
| ? | EstablishSessionResponse (sessionID) |
EDA 客戶端在建立連線時，絕無任何情況下需要提供密碼或密碼雜湊值。為確保密碼安全，管理型 EDA 客戶端在新增 ACL 項目時應使用 SSL。預期此項安全性提升將促使 EDA 標準得以應用於更廣泛的領域。
已知未來選票
- E164 的更新。
- 關於 E132、E125 及 E134 的另一項更新。有人提議重新定義「客戶」和「消費者」這兩項術語。本週，工作小組決定採納此項提案。
- 採用 gRPC 後，EDA 客戶端得以透過雙向（全雙工）連線接收 NewData 訊息。在 EDA Freeze 1 和 2 中，透過 HTTP 傳輸的 SOAP 訊息僅為單向傳輸。此新的雙向使用情境模糊了「客戶端」與「消費者」的定義。 本提案將釐清「客戶端」是指啟動與「設備伺服器」通訊的實體。當「設備伺服器」經配置後，「設備伺服器」可主動啟動與「消費者」的通訊。因此，系統中可能存在消費者，也可能不存在。
- EDA Freeze 3 還引入了來自設備伺服器的三類訊息：心跳訊息、運作訊息及通知訊息。心跳訊息與運作訊息可傳送至客戶端（在雙向模式下）、傳送至消費者，或完全停用。通知訊息則可傳送至客戶端和／或消費者。
- 專案小組計畫舉辦另一場開放給所有有興趣人士參加的測試活動，屆時可一併測試 E132、E120、E125 及 E134。此活動原定於 2023 年初舉行，但目前尚未提出具體日期，且計畫可能有所延後。此次測試旨在驗證已發布的標準是否已臻完善。 專案小組負責人預期可能會發現一些問題，屆時可能需要對 E125 和 E134 進行進一步修改。若真如此，EDA 第 3 版凍結版可能要到 2024 年春季才能完成。
- 這是針對 E178《EDA 版本凍結指南》的更新。此為正式宣布 3 版凍結的最後一步驟。
總而言之，雖然 EDA Freeze 3 的完成進度不如多數人期望的那麼快，但相關工作仍在推進中。目前雖無重大障礙，但要完成已規劃的工作，仍需投入大量時間與心力。