SECS/GEM Host + Equipment Simulator
用 C# / .NET 8 從零實作的 SECS/GEM 設備與主機模擬器。三層協定都是自己寫的， 不是包裝現成的 SECS library。
為什麼做這個
SECS/GEM 是半導體設備的通訊標準，但公開的參考實作極少 —— 業界大多買商用套件， 把協定當黑箱用。我過去的專案也是這樣：用商用 library 做應用層，能交付， 但「協定本身怎麼運作」有一塊始終是別人幫我處理掉的。
所以我把三層都自己寫一遍。這個專案要回答的問題很具體： 如果不靠現成套件，我能不能讓一個 Host 和一台 Equipment 在真實 TCP 上完整對話完一輪 GEM 流程 —— 從連線交握、報表定義、事件回報，到警報與遠端命令。
實作了什麼
HSMS — SEMI E37
連線狀態機（NotConnected → Connected → Selected）、Select / Deselect / Separate / Linktest 控制訊息、T3–T8 逾時計時器、封包長度前綴的串流組裝。
SECS-II — SEMI E5
全格式碼（List / Binary / Boolean / ASCII / 各長度整數與浮點）編解碼，含巢狀 List。對畸形輸入做長度與格式驗證，不讓壞封包打穿上層。
GEM — SEMI E30
通訊與控制狀態模型、報表定義鏈（S2F33 定義 → S2F35 連結 → S2F37 啟用 → S6F11 事件）、設備常數讀寫、主機遠端命令、警報 S5F1、錯誤訊息 S9/S10。
架構
SecsGem.Core
協定引擎：HSMS / SECS-II / GEM 三層與狀態機，不依賴任何 SECS 商用套件。
SecsGem.Scenarios
JSON 場景 schema 與斷言引擎，把「這段對話該長什麼樣」寫成可執行的檔案，並產出 HTML 報告。
SecsGem.Verify
Headless CLI：跑完場景以結束碼回報成敗，可直接掛進 CI。
SecsGem.Web
Blazor Server 即時觀測介面：一邊跑 Host / Equipment，一邊看訊息與狀態變化。
怎麼證明它會動
協定實作最容易的自我欺騙，是「我覺得它對」。所以驗證分三層，每一層都留下可以打開來看的檔案。
1. 26 個測試，其中 15 個跑真實 TCP
11 個單元測試涵蓋編解碼與狀態機轉換；15 個整合測試不是 mock —— 它們真的開 socket，
讓 Host 與 Equipment 在 127.0.0.1 上互連，
跑完整的交握與訊息往返。mock 過得了的錯誤，真 socket 過不了。
2. 場景驗證：3 個場景、16 個步驟全數通過
場景寫成 JSON：每一步要送什麼、期待收到什麼、哪些欄位要成立，都是可執行的斷言。 跑完產出 HTML 報告，含完整訊息追蹤。下面是場景 02（報表定義與事件報表）的實際追蹤， 直接取自報告：
| 方向 | 訊息 | 說明 |
|---|---|---|
| H→E | Select.req | |
| E→H | Select.rsp | |
| H→E | S1F13 W | 建立通訊 |
| E→H | S1F14 | |
| H→E | S2F33 W | 定義報表 RPTID1 = [DVID10, SVID1] |
| E→H | S2F34 | |
| H→E | S2F35 W | 連結 CEID101 → RPTID1 |
| E→H | S2F36 | |
| H→E | S2F37 W | 啟用 CEID101 |
| E→H | S2F38 | |
| E→H | S6F11 W | 設備觸發事件，主機收到報表 |
| H→E | S6F12 | |
| H→E | Separate.req | |
| E→H | Separate.req |
3. 50 輪對抗式審核，186 項發現
我對這份程式碼跑了 50 輪刻意找碴的審查，累積 186 項發現。重點不在數字，
在於後續怎麼處理：多數「高嚴重度」發現其實是審查者誤解 SEMI 規範
（例如 Separate.req 本來就沒有回應訊息，那不是 bug）。
帳本把每一項的判定與理由都留著 —— 站得住腳的缺陷照列，站不住的也寫清楚為什麼不改。
即時觀測介面
Blazor Server 介面：Host 與 Equipment 同時跑在本機，訊息與狀態變化即時顯示。
這個專案不能證明什麼
寫得出來跟能上線是兩件事。以下是我知道的邊界：
- 這是模擬器，不是量產機台的 driver。它用來驗證協定理解與對接行為，不等於通過產線考驗。
- 沒有跑過 SEMI 官方認證測試套件。「通過驗證」指的是自己寫的場景與斷言，不是第三方認證。
- 目前沒有 CI workflow。測試與場景驗證都是本機手動觸發，報告不是自動產生的。
- 所有整合測試跑在單機 loopback（127.0.0.1），沒有跨網段、沒有真實產線的網路條件。
這是第二版
第一版是 WPF 桌面程式，只做到 SECS-II 層。做完才發現真正的難點不在編解碼， 而在「怎麼知道它是對的」—— 一個沒有自動驗證的模擬器，跟一份會動的猜測沒有差別。
所以重寫：協定引擎與 UI 拆開、場景驗證獨立成一層、加上可以掛 CI 的 headless CLI。 這一版的價值不只是多實作了 GEM，而是把「驗證」變成專案的一部分而不是事後補的。
如果你的設備要做 SECS/GEM 對接，或是想找人幫忙看現有實作哪裡不對，歡迎來信聊聊。
談談你的案子