90c177b7ce
GEM300 layer: SEMI E40-0705 Process Job and E94-0705 Control Job state machines, plus the E30 §6.1 communication-state machine that sits between HSMS SELECT and full GEM communication. Data-driven via data/process_job_state.yaml and data/control_job_state.yaml, mirroring the existing control_state.yaml pattern. Wire coverage: S14F9/F10 CreateObject (CJ) host -> equipment S14F11/F12 DeleteObject (CJ) host -> equipment S16F5/F6 PRJobCommand host -> equipment S16F9 PRJobAlert equipment -> host S16F11/F12 PRJobCreate (simplified body) host -> equipment S16F13/F14 PRJobDequeue host -> equipment S16F27/F28 CJobCommand host -> equipment Process Job FSM exposes 8 states matching PRJOBSTATE bytes (E40 §10.3.2); HOQ is reorder-aware (move-to-head against an insertion-order vector); Stop/Abort on a Queued PJ routes through ABORTING so the host observes PRJOBSTATE=7 on the wire (§6.3); alert_enabled is settable per-PJ for PRALERT control; FSM dispatches through ProcessJobStore::on_change_ dynamically so a late set_state_change_handler() reaches existing PJs. Hardening: loader rejects NoState (sentinel) as initial/from/to and rejects `on: created` rows; static_asserts pin enum values to wire bytes; ProcessJobStore is non-movable to keep the per-PJ this-capture safe. Server simulator cascades the full CJ -> PJ lifecycle on CJSTART so the wire trace exercises every legal state. CEIDs 400/401 fire on CJ state changes via the existing event-report pipeline. Tests: 60+ new assertions across test_process_jobs, test_control_jobs, test_communication_state, test_hsms_connection, plus loader and messages round-trip coverage. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
297 lines
22 KiB
Markdown
297 lines
22 KiB
Markdown
# SECS/GEM Compliance
|
||
|
||
A per-capability accounting against SEMI **E5 (SECS-II)**, **E30 (GEM)**,
|
||
**E37 (HSMS)**, and **GEM300 E40 / E94** (process / control jobs).
|
||
|
||
> **Status.** Every GEM Fundamental capability and every GEM Additional
|
||
> capability that E30 ties to a concrete SECS-II message set is
|
||
> implemented. See §7 for the explicit out-of-scope items (which are
|
||
> deliberate, not omissions) and §8 for what "100% GEM-compliant" can
|
||
> and cannot honestly mean about this codebase.
|
||
|
||
Legend:
|
||
|
||
- ✅ **Full** — implemented to the spec; round-trip-tested.
|
||
- 🟡 **Partial** — implemented in the demo path with a documented limitation.
|
||
- ⬜ **Out of scope** — deliberately not implemented; reason given.
|
||
|
||
---
|
||
|
||
## 1. E37 — HSMS transport
|
||
|
||
| Item | Status | Spec ref | Notes |
|
||
|---------------------------------------|--------|----------|-------|
|
||
| TCP transport | ✅ | E37 §6 | `hsms::Connection` over standalone Asio. |
|
||
| 4-byte length prefix + 10-byte header | ✅ | E37 §8.2 | `hsms::Frame::encode/decode`. |
|
||
| Session ID, byte2, byte3, PType, SType, system-bytes | ✅ | E37 §8.3 | `hsms::Header`. |
|
||
| `Select.req / .rsp` | ✅ | E37 §7.2 | `SType` 1/2; SelectStatus enum (0–3). |
|
||
| `Deselect.req / .rsp` | ✅ | E37 §7.4 | `SType` 3/4; DeselectStatus enum (0–2). |
|
||
| `Linktest.req / .rsp` | ✅ | E37 §7.5 | `SType` 5/6; periodic interval configurable. |
|
||
| `Separate.req` | ✅ | E37 §7.6 | `SType` 9; graceful close after flush. |
|
||
| `Reject.req` | ✅ | E37 §7.7 | Emitted on data-while-NOT-SELECTED. |
|
||
| Connection state machine NOT-CONNECTED → NOT-SELECTED → SELECTED | ✅ | E37 §6.3 | Both Active and Passive modes. |
|
||
| T3 reply timeout | ✅ | E37 §10 | Per-transaction `steady_timer`. |
|
||
| T5 connect separation timeout | ✅ | E37 §10 | `Client::schedule_retry`. |
|
||
| T6 control transaction timeout | ✅ | E37 §10 | One concurrent control transaction. |
|
||
| T7 not-selected timeout (passive) | ✅ | E37 §10 | Armed on connect / on Deselect.req. |
|
||
| T8 intercharacter timeout | ✅ | E37 §10 | Bounds the payload read after length prefix. |
|
||
| HSMS-SS (single-session) | ✅ | E37 §11 | The codebase is HSMS-SS only by design. |
|
||
| HSMS-GS (general-session) | ⬜ | E37 §11 | Multi-session; out of scope for this revision. |
|
||
|
||
---
|
||
|
||
## 2. E5 — SECS-II encoding
|
||
|
||
| Item | Status | Spec ref | Notes |
|
||
|---------------------------------------|--------|----------|-------|
|
||
| Format byte + 1/2/3 length bytes | ✅ | E5 §9 | `secs2::encode_into`. |
|
||
| List (`L`) | ✅ | E5 §9.3 | Recursive. |
|
||
| ASCII (`A`) | ✅ | E5 §9.5 | |
|
||
| Binary (`B`) | ✅ | E5 §9.5 | |
|
||
| Boolean (`BOOLEAN`) | ✅ | E5 §9.5 | |
|
||
| `U1, U2, U4, U8` (big-endian) | ✅ | E5 §9.5 | |
|
||
| `I1, I2, I4, I8` (big-endian, two's complement) | ✅ | E5 §9.5 | |
|
||
| `F4, F8` (IEEE 754 big-endian) | ✅ | E5 §9.5 | bit-cast round-trip. |
|
||
| JIS-8 (single-byte JIS text) | ✅ | E5 §9.5 | `Format::JIS8` (0x11); shares `std::string` storage with ASCII, disambiguated by `Format`. |
|
||
| C2 (Unicode 2-byte code points) | ✅ | E5 §9.5 | `Format::C2` (0x12); big-endian uint16_t code points. |
|
||
| SML text rendering | ✅ | E5 Annex | `secs2::to_sml`. JIS-8 prints as `<J "...">`, C2 as `<C 65 66 ...>`. |
|
||
|
||
---
|
||
|
||
## 3. E30 — GEM Fundamental capabilities (§5.2)
|
||
|
||
| Fundamental Capability | Status | Spec ref | Messages | Notes |
|
||
|---------------------------------------|--------|----------|----------|-------|
|
||
| State models | ✅ | E30 §6.2 | — | E30 control state machine (5 states) + HSMS communication state machine. |
|
||
| Equipment Processing States | ✅ | E30 §6.3 | — | The `ControlTransitionTable` engine is general; vendors load their tool-specific states (IDLE/SETUP/READY/EXECUTING/PAUSE/...) via a second YAML file using the same loader. The spec leaves the concrete states tool-specific. |
|
||
| Host-Initiated S1F13/F14 scenario | ✅ | E30 §6.5 | S1F13/F14 | |
|
||
| Event Notification | ✅ | E30 §6.6 | S6F11/F12 | Equipment-initiated, host-acknowledged. |
|
||
| On-Line Identification | ✅ | E30 §6.7 | S1F1/F2 | MDLN + SOFTREV. |
|
||
| Error Messages | ✅ | E30 §6.9 | S9F* | Auto-emission of S9F3/F5/F7/F9/F11 on the documented protocol-error conditions; S9F1/F13 in the catalog for explicit emission. |
|
||
| Documentation | ✅ | E30 §6.10| S1F19/F20, S1F21/F22 | Equipment self-reports its compliance + DVID namelist. |
|
||
| Control (Operator-Initiated) | ✅ | E30 §6.2 | — | `ControlStateMachine::operator_online/offline/local/remote`. |
|
||
|
||
---
|
||
|
||
## 4. E30 — GEM Additional capabilities (§5.3)
|
||
|
||
| Additional Capability | Status | Spec ref | Messages | Notes |
|
||
|---------------------------------------|--------|----------|----------|-------|
|
||
| Establish Communications | ✅ | E30 §6.5 | S1F13/F14 | Both directions modeled; COMMACK enum. Backed by the E30 §6.5 Communication state machine (`gem::CommunicationStateMachine`) with DISABLED / WAIT-CRA / WAIT-DELAY / COMMUNICATING substates and the T_CRA + T_DELAY retry timers, separate from HSMS connection state. |
|
||
| Dynamic Event Report Configuration | ✅ | E30 §6.6 | S2F33/F34, S2F35/F36, S2F37/F38 | Full Define-Report / Link-Event / Enable-Event pipeline with all four ack enums. |
|
||
| Variable Data Collection | ✅ | E30 §6.11| S1F21/F22 | DVID namelist + DVID values resolvable via `EquipmentDataModel::vid_value`. |
|
||
| Trace Data Collection | ✅ | E30 §6.12| S2F23/F24, S6F1/F2 | `TraceStore` keeps active TRID→TraceConfig; periodic sampling left to the application's scheduler. |
|
||
| Status Data Collection | ✅ | E30 §6.13| S1F3/F4, S1F11/F12 | |
|
||
| Alarm Management | ✅ | E30 §6.14| S5F1/F2, S5F3/F4, S5F5/F6, S5F7/F8 | Full set. ALCD bit-7 set/cleared, lower-7 category. |
|
||
| Remote Control | ✅ | E30 §6.15| S2F41/F42 | Full HCACK 7-value enum + per-parameter CPACKs. |
|
||
| Equipment Constants | ✅ | E30 §6.16| S2F13/F14, S2F15/F16, S2F29/F30 | EAC range validation against `min_str`/`max_str` for numeric ECs. |
|
||
| Process Program Management | ✅ | E30 §6.17| S7F3/F4, S7F5/F6, S7F19/F20 | Unformatted PP send/request/list — the minimum E30 GEM requires. (E42 *enhanced* PP is a separate SEMI standard; see §7.) |
|
||
| Material Movement | 🟡 | E30 §6.18| — | Process Job + Control Job lifecycle covered via E40/E94 (see §4a). Carrier (E87) and substrate (E90) still out of scope. |
|
||
| Equipment Terminal Services | ✅ | E30 §6.19| S10F1/F2, S10F3/F4, S10F5/F6 | Single-line both directions + multi-line host→equipment. S10F7 broadcast intentionally omitted (rarely used). |
|
||
| Clock | ✅ | E30 §6.20| S2F17/F18, S2F31/F32 | 16-char (`YYYYMMDDhhmmsscc`) and 14-char accepted on set. |
|
||
| Limits Monitoring | ✅ | E30 §6.21| S2F45/F46, S2F47/F48 | `LimitMonitorStore` keyed by VID with multiple `LimitDefinition` (LIMITID + upper/lower as arbitrary Items). |
|
||
| Spooling | ✅ | E30 §6.22| S2F43/F44, S6F23/F24, S6F25/F26 | Per-stream whitelist, FIFO queue, host-driven transmit/purge, S6F25 auto-emitted on re-SELECT when non-empty. |
|
||
| Control | ✅ | E30 §6.2 | — | See Fundamental. |
|
||
|
||
---
|
||
|
||
## 4a. E40 Process Jobs + E94 Control Jobs (GEM300)
|
||
|
||
The first GEM300 extension landing on the spec-as-data architecture.
|
||
Both standards are implemented the same way the E30 control state model
|
||
is: state set + legal transitions in YAML
|
||
(`data/process_job_state.yaml`, `data/control_job_state.yaml`), engine
|
||
in C++ (`gem::ProcessJobStateMachine`, `gem::ControlJobStateMachine`),
|
||
runtime collections (`ProcessJobStore`, `ControlJobStore`) wired into
|
||
the existing `EquipmentDataModel`.
|
||
|
||
| Capability | Status | Spec ref | Messages | Notes |
|
||
|---------------------------------------|--------|----------|----------|-------|
|
||
| E40 PJ state model | ✅ | E40 §6.3 | — | 8 states (Queued, SettingUp, WaitingForStart, Processing, ProcessComplete, Paused, Stopping, Aborting); state byte matches PRJOBSTATE on the wire. |
|
||
| E40 PRJobCreate | ✅ | E40 §10.2| S16F11/F12 | Body simplified to <L,3 PRJOBID PPID L,n MTRLOUTSPEC>; MF/PRRECIPEMETHOD/PRPROCESSPARAMS are documented as YAML-extension points. PPID validated against `RecipeStore`. |
|
||
| E40 PRJobDequeue | ✅ | E40 §10.2| S16F13/F14 | Only legal while PJ is QUEUED; the FSM blocks dequeue otherwise. |
|
||
| E40 PRJobCommand | ✅ | E40 §10.2| S16F5/F6 | PRCMD strings PJSTART/PJPAUSE/PJRESUME/PJSTOP/PJABORT/PJHOQ; the matching `ProcessJobEvent` is dispatched against the FSM, HCACK is `CannotDoNow` when the (state, command) pair has no row. |
|
||
| E40 PRJobAlert | ✅ | E40 §10.3| S16F9 | Equipment-initiated one-way (W=0). Fires automatically on every PJ state transition; per-PJ `alert_enabled` flag controls suppression. |
|
||
| E94 CJ state model | ✅ | E94 §6 | — | 9 states (Queued, Selected, WaitingForStart, Executing, Paused, Completed, Stopping, Aborting, NoState). CJ owns an ordered `prjobids` list. |
|
||
| E94 CreateObject (CJ) | ✅ | E94 §6.4 | S14F9/F10 | Body simplified to <L,2 CTLJOBID L,n PRJOBIDs>; full generic E14 ObjectService form is a YAML extension. OBJACK enum covers Success/Error + the four `Denied_*` cases. |
|
||
| E94 DeleteObject (CJ) | ✅ | E94 §6.4 | S14F11/F12 | |
|
||
| E94 CJobCommand | ✅ | E94 §6.4 | S16F27/F28 | CTLJOBCMD: CJSTART (cascades through Select → SetupComplete → Start as application policy), CJPAUSE / CJRESUME / CJSTOP / CJABORT. |
|
||
| E40+E94 CEID emission | ✅ | — | S6F11 | ControlJobExecuting (CEID 400) and ControlJobCompleted (CEID 401) fire on CJ state transitions via the existing event-report pipeline; PJ state changes use S16F9 (per spec). |
|
||
|
||
The demo's `run_cj_lifecycle` cascade — on CJSTART the CJ steps Queued
|
||
→ Selected → WaitingForStart → Executing and every contained PJ steps
|
||
through SettingUp → WaitingForStart → Processing → ProcessComplete —
|
||
is **application policy**, not the FSM. The FSM rules in the YAML
|
||
tables gate every individual transition; the cascade is just the
|
||
simulator playing every legal next step in sequence so the wire trace
|
||
exercises the whole lifecycle.
|
||
|
||
What's **out of scope for the E40/E94 first pass** (deliberate; all are
|
||
YAML/handler extensions, not surgery):
|
||
- Full E40 S16F11 body (MF / PRRECIPEMETHOD / RCPSPEC / PRPROCESSPARAMS).
|
||
We carry PRJOBID + PPID + MTRLOUTSPEC, which is the subset that
|
||
drives the state machine; richer body fields are a YAML edit + a
|
||
parameter map on the `ProcessJob` struct.
|
||
- S16F15/F16 PRJobCreateMultiple, S16F17/F18 PRJobMultipleDequeue.
|
||
- E14 generic ObjectService form. We use a CJ-specialized S14F9 shape;
|
||
generic ObjectService is a separate set of YAML rows.
|
||
- E87 Carrier Management and E90 Substrate Tracking — Layer 5
|
||
continues there per `implementation_plan.md`.
|
||
|
||
---
|
||
|
||
## 5. Message coverage matrix
|
||
|
||
| Pair | Direction | Status | Implemented in | Tested |
|
||
|------------------|-----------|--------|----------------|--------|
|
||
| S1F1 / S1F2 | H↔E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F3 / S1F4 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F11 / S1F12 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F13 / S1F14 | H↔E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F15 / S1F16 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F17 / S1F18 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F19 / S1F20 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S1F21 / S1F22 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F13 / S2F14 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F15 / S2F16 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S2F17 / S2F18 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F23 / S2F24 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S2F25 / S2F26 | H→E | ✅ | catalog | ✅ round-trip (loopback diagnostic) |
|
||
| S2F29 / S2F30 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F31 / S2F32 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F33 / S2F34 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F35 / S2F36 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F37 / S2F38 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F41 / S2F42 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F43 / S2F44 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S2F45 / S2F46 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S2F47 / S2F48 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S5F1 / S5F2 | E→H | ✅ | catalog | ✅ round-trip + demo |
|
||
| S5F3 / S5F4 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S5F5 / S5F6 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S5F7 / S5F8 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S5F9 / S5F10 | E→H | ✅ | catalog | ✅ round-trip (exception post) |
|
||
| S5F11 / S5F12 | E→H | ✅ | catalog | ✅ round-trip (exception clear) |
|
||
| S6F1 / S6F2 | E→H | ✅ | catalog | ✅ round-trip |
|
||
| S6F11 / S6F12 | E→H | ✅ | catalog | ✅ round-trip + demo |
|
||
| S6F23 / S6F24 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S6F25 / S6F26 | E→H | ✅ | catalog + server | ✅ round-trip + auto-emitted on re-SELECT |
|
||
| S7F3 / S7F4 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S7F5 / S7F6 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S7F19 / S7F20 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S9F1 | E↔H | ✅ | catalog | ✅ round-trip |
|
||
| S9F3 | E↔H | ✅ | catalog + Router wrapper | ✅ round-trip + auto-emitted on unknown stream |
|
||
| S9F5 | E↔H | ✅ | catalog + Router wrapper | ✅ round-trip + auto-emitted on unknown function |
|
||
| S9F7 | E↔H | ✅ | catalog + Connection | ✅ round-trip + auto-emitted on body decode |
|
||
| S9F9 | E↔H | ✅ | catalog + Connection | ✅ round-trip + auto-emitted on T3 timeout |
|
||
| S9F11 | E↔H | ✅ | catalog + Connection | ✅ round-trip + auto-emitted on oversized frame |
|
||
| S9F13 | E↔H | ✅ | catalog | ✅ round-trip |
|
||
| S10F1 / S10F2 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||
| S10F3 / S10F4 | E→H | ✅ | catalog | ✅ round-trip + demo |
|
||
| S10F5 / S10F6 | H→E | ✅ | catalog | ✅ round-trip |
|
||
| S14F9 / S14F10 | H→E | ✅ | catalog | ✅ round-trip + demo (E94 CJ create) |
|
||
| S14F11 / S14F12 | H→E | ✅ | catalog | ✅ round-trip + demo (E94 CJ delete) |
|
||
| S16F5 / S16F6 | H→E | ✅ | catalog | ✅ round-trip (E40 PRJobCommand) |
|
||
| S16F9 | E→H | ✅ | catalog + server | ✅ round-trip + auto-emitted per PJ transition (E40 PRJobAlert) |
|
||
| S16F11 / S16F12 | H→E | ✅ | catalog | ✅ round-trip + demo (E40 PRJobCreate) |
|
||
| S16F13 / S16F14 | H→E | ✅ | catalog | ✅ round-trip (E40 PRJobDequeue) |
|
||
| S16F27 / S16F28 | H→E | ✅ | catalog | ✅ round-trip + demo (E94 CJobCommand) |
|
||
|
||
---
|
||
|
||
## 6. Demo evidence
|
||
|
||
The two-container demo (`docker compose up --no-deps server client`)
|
||
walks ~20 SECS transactions end-to-end:
|
||
|
||
1. TCP connect → `Select.req` → `Select.rsp(Ok)` → SELECTED on both sides.
|
||
2. `S1F13`/`S1F14` Establish Comms.
|
||
3. `S1F17`/`S1F18` Request Online; control state transitions
|
||
`HostOffline → AttemptOnline → OnlineRemote`.
|
||
4. `S1F19`/`S1F20` host fetches the equipment's GEM-compliance self-report.
|
||
5. `S1F21`/`S1F22` DVID namelist.
|
||
6. `S1F11`/`S1F12` SVID namelist → `S1F3`/`S1F4` values read.
|
||
7. `S2F29`/`S2F30` EC namelist → `S2F13`/`S2F14` EC read.
|
||
8. `S2F17`/`S2F18` clock read.
|
||
9. `S2F33`/`S2F34` Define Report 1000 over the 3 SVIDs.
|
||
10. `S2F35`/`S2F36` Link CEIDs 200 and 300 to Report 1000.
|
||
11. `S2F37`/`S2F38` Enable CEIDs 200, 300.
|
||
12. `S2F41`/`S2F42` host command **START** → server emits
|
||
`S6F11(CEID=300)` carrying the linked Report 1000 → host acks `S6F12`.
|
||
13. `S5F5`/`S5F6` list alarm directory.
|
||
14. `S5F3`/`S5F4` enable alarm 1.
|
||
15. `S2F41`/`S2F42` host command **FAULT** → server emits
|
||
`S5F1` (ALCD=0x84) + `S6F11(CEID=200)`.
|
||
16. Spool window: `SPOOL_ON` → `START` (emission goes to spool) →
|
||
`SPOOL_OFF` → `S6F23(Transmit)` → server drains queued S6F11 to host.
|
||
17. `S7F19`/`S7F20` recipe list, `S7F5`/`S7F6` fetch RECIPE-A.
|
||
18. `S16F11`/`S16F12` create Process Job `PJ-1` with PPID `RECIPE-A`.
|
||
19. `S14F9`/`S14F10` create Control Job `CJ-1` containing `[PJ-1]`.
|
||
20. `S16F27`/`S16F28` CJSTART → equipment cascades CJ Queued → Executing
|
||
and the contained PJ through SettingUp → WaitingForStart →
|
||
Processing → ProcessComplete, emitting one `S16F9 PRJobAlert` per PJ
|
||
transition and `S6F11(CEID=400)` / `S6F11(CEID=401)` for CJ Executing
|
||
/ Completed.
|
||
21. `S14F11`/`S14F12` delete `CJ-1`.
|
||
22. `S10F1`/`S10F2` host → equipment terminal display.
|
||
23. `S1F15`/`S1F16` Request Offline.
|
||
24. `Separate.req` → clean close on both sides.
|
||
|
||
Unit tests: **148 cases / 794 assertions pass** (`docker compose run --rm tests`).
|
||
The suite includes integration tests that drive a real `hsms::Connection`
|
||
over a loopback socket pair to verify the E37 §7.2 / §7.4 / §7.7
|
||
edge cases (Select.req while already SELECTED → AlreadyActive, Deselect.req
|
||
while NOT_SELECTED → NotEstablished, Reject.req for unsupported SType /
|
||
PType, Reject.req for data while NOT_SELECTED) — not just the happy path.
|
||
The E30 §6.5 Communication state machine is unit-tested independently of
|
||
the transport (timer firings simulated via test callbacks).
|
||
|
||
---
|
||
|
||
## 7. Explicitly out of scope (with reasons)
|
||
|
||
These look like gaps but are deliberate. None of them blocks the GEM
|
||
compliance claim.
|
||
|
||
| Item | Why it's out of scope |
|
||
|---------------------------------------|----------------------|
|
||
| Material Movement (E30 §6.18) | The job-management half is now in (E40 + E94, §4a). The remaining pieces — **E87 carrier management** and **E90 substrate tracking** — are separate SEMI standards layered on top of E30 and remain Layer-5 follow-ons per `implementation_plan.md`. |
|
||
| Multi-block SECS-I transfers | Multi-block (S6F5/F6, S6F7/F8 etc.) is a **SECS-I** concept for 244-byte serial frames. HSMS allows arbitrarily large bodies (up to the codebase's 16 MiB cap), so multi-block is structurally not needed. E37-based GEM equipment does not require it. |
|
||
| HSMS-GS (multi-session) | Out of scope — modern HSMS-SS covers virtually all current GEM equipment. |
|
||
| Equipment Processing States (concrete states) | E30 §6.3 says the specific states are tool-defined. We provide the engine (`ControlTransitionTable` + the YAML loader); equipment vendors load their concrete states (IDLE / SETUP / READY / EXECUTING / PAUSE / ...) the same way `data/control_state.yaml` is loaded today. Spec-compliant either way. |
|
||
| Persistent on-disk spool | The runtime spool is in-memory; an equipment restart loses queued events. Real fab equipment would back it with a journal. Standard does not mandate persistence. |
|
||
| E42 Enhanced Process Programs (S7F23–F26) | A separate SEMI standard. E30 GEM Process Program Management only requires the unformatted set (S7F3/F5/F19), which we have. |
|
||
| S10F7 Broadcast Terminal Display | Rarely used; equipment vendors typically forgo it. Not required for the Terminal Services capability. |
|
||
|
||
---
|
||
|
||
## 8. What "100% GEM-compliant" honestly means here
|
||
|
||
Every GEM Fundamental and every GEM Additional capability that the E30
|
||
specification defines with a concrete SECS-II message set is implemented,
|
||
round-trip-tested, and demonstrated in the two-container demo. The five
|
||
remaining items in §7 are all either separate SEMI standards layered on
|
||
top of E30 (E40/E42), HSMS-irrelevant SECS-I features, or deliberate
|
||
quality-of-implementation choices (persistent spool, broadcast terminal,
|
||
JIS-8) that the spec does not require.
|
||
|
||
What this codebase does **not** demonstrate, and what a real "GEM-compliant"
|
||
marketing claim would still need:
|
||
|
||
1. **Conformance against a GEM Reference Test System (RTS) or equivalent
|
||
third-party validator**, on a representative tool. The codebase
|
||
provides the message catalog + the runtime; running a conformance
|
||
generator (Layer 4 of `implementation_plan.md`) against a real
|
||
physical or simulated tool is how compliance gets *certified*.
|
||
2. **Per-vendor application code** that connects the generic stores to
|
||
the equipment's real sensors, recipe engine, alarm sources, and
|
||
processing state model. The codebase provides the data model and
|
||
the dispatcher; the application is what makes a specific tool
|
||
GEM-compliant.
|
||
|
||
In short: this is a **GEM-conformant runtime stack** with the first
|
||
slice of GEM300 (E40 / E94), not a GEM-conformant *tool*. Pointing the
|
||
runtime at a real piece of equipment, populating the YAML files with
|
||
the tool's real SVIDs / ECIDs / alarms / capabilities / PJ + CJ
|
||
behaviour, and wiring the application callbacks completes the picture.
|