Files
secs-gem/README.md
T
raphael 90c177b7ce E40 Process Jobs + E94 Control Jobs + E30 communication state
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>
2026-06-07 21:00:32 +02:00

234 lines
11 KiB
Markdown

# secs-gem
A C++20 SECS-II / HSMS / GEM client and server, fully containerised, with
every behavioural rule encoded as YAML data (control state, equipment
data dictionary, SECS-II message shapes, **E40 process-job + E94
control-job state machines**).
See [COMPLIANCE.md](COMPLIANCE.md) for the per-capability E5/E30/E37/E40/E94
audit. Every GEM Fundamental and every GEM Additional capability that E30
binds to a concrete SECS-II message set is implemented and
round-trip-tested; E40 PJ and E94 CJ lifecycle messages (S16F5/F6/F9/F11/F12/F13/F14/F27/F28
and S14F9/F10/F11/F12) are wired through the same data-driven runtime.
## Quick start
Everything runs in Docker — no compiler or build tools on the host.
```bash
docker compose run --rm builder # configure + compile
docker compose run --rm tests # 148 test cases / 794 assertions
docker compose up --no-deps server client # live two-container demo
```
## Architecture
The project is "spec-as-data": the SEMI behavioural rules live in YAML;
the C++ is the engine that reads them.
```
┌──────────────────────────────────────────────────────────────┐
│ data/ │
│ messages.yaml SECS-II message catalog │
│ control_state.yaml E30 §6.2 control transition table │
│ process_job_state.yaml E40 §6 PJ transition table │
│ control_job_state.yaml E94 §6 CJ transition table │
│ equipment.yaml SVIDs / DVIDs / ECIDs / CEIDs / │
│ alarms / recipes / commands / │
│ capabilities / spool / DVID list │
└──────────────────────┬───────────────────────────────────────┘
│ (loaded at startup, codegened at build)
┌──────────────────────────────────────────────────────────────┐
│ tools/gen_messages.py │
│ reads messages.yaml -> emits generated/secsgem/gem/messages.hpp
└──────────────────────┬───────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ apps/ │
│ secs_server.cpp passive equipment │
│ secs_client.cpp active host │
│ (both use gem::Router for dispatch) │
└────────────┬───────────────────────────┬─────────────────────┘
│ │
▼ ▼
┌──────────────────────────────────────────────────────────────┐
│ secsgem::config loader.hpp: YAML -> tables + data model │
│ secsgem::gem ControlTransitionTable + ControlStateMachine,│
│ ProcessJobStateMachine (E40), │
│ ControlJobStateMachine (E94), │
│ EquipmentDataModel composing the stores: │
│ SVID, DVID, ECID, Event Subscriptions, │
│ Alarms, Recipes, Clock, Commands, Spool, │
│ Limits, Traces, ProcessJobs, ControlJobs │
│ Router (stream, function) -> handler │
│ generated messages.hpp (all 44 SxFy) │
│ secsgem::hsms Connection (Asio), Header, Frame, Timers │
│ Auto-emits S9F3/F5/F7/F9/F11 on protocol │
│ error conditions. │
│ secsgem::secs2 Item (variant), encode/decode, Message │
└──────────────────────────────────────────────────────────────┘
```
### Tree
```
secs-gem/
├── Dockerfile, docker-compose.yml # toolchain + demo
├── CMakeLists.txt
├── implementation_plan.md # 7-layer spec-as-data roadmap
├── COMPLIANCE.md # per-capability E5/E30/E37 audit
├── data/
│ ├── messages.yaml # SECS-II message catalog
│ ├── control_state.yaml # E30 control state transitions
│ └── equipment.yaml # equipment data dictionary
├── tools/
│ └── gen_messages.py # codegen (messages.yaml -> .hpp)
├── include/secsgem/
│ ├── secs2/{item,codec,message}.hpp
│ ├── hsms/{header,connection}.hpp
│ ├── gem/{control_state,communication_state,data_model,messages_helpers,router}.hpp
│ ├── gem/{process_job_state,control_job_state}.hpp # E40 / E94 FSMs
│ ├── gem/store/ # one file per focused store:
│ │ ├── status_variables.hpp # SVIDs + DVIDs
│ │ ├── equipment_constants.hpp # ECIDs + EAC range validation
│ │ ├── event_reports.hpp # CEIDs + Reports + Links
│ │ ├── alarms.hpp # alarm registry
│ │ ├── recipes.hpp # process program store
│ │ ├── clock.hpp # 16-char TIME with offset
│ │ ├── host_commands.hpp # RCMD registry
│ │ ├── spool.hpp # spool queue + state
│ │ ├── limits.hpp # variable limit definitions
│ │ ├── trace.hpp # active trace configs
│ │ ├── process_jobs.hpp # E40 PJ collection
│ │ └── control_jobs.hpp # E94 CJ collection
│ ├── config/loader.hpp
│ └── endpoint.hpp
├── src/{secs2,hsms,gem,config}/*.cpp + endpoint.cpp
├── apps/{secs_server,secs_client}.cpp
└── tests/test_*.cpp
```
## Adding a capability
The point of "spec-as-data" is that adding behaviour almost never
requires a C++ change.
### Add a new SVID
```yaml
# data/equipment.yaml
svids:
- {id: 4, name: ChamberTemp, units: "C", type: U4, value: 25}
```
Restart the server. The host sees the new SVID via S1F11/F3 immediately.
### Add a new host command with side effects
```yaml
# data/equipment.yaml
host_commands:
- {name: VENT, ack: Accept, emit_ceid: 400, set_alarm: 2}
```
### Add a new state transition
```yaml
# data/control_state.yaml
transitions:
- {from: OnlineRemote, on: host_request_offline, to: EquipmentOffline, ack: Accept}
```
### Add an E40 PJ transition (e.g. a tool-specific HOLD state)
```yaml
# data/process_job_state.yaml
transitions:
- {from: Processing, on: hold, to: OnHold}
- {from: OnHold, on: resume, to: Processing}
```
(Adding a brand-new state requires bumping the `ProcessJobState` enum
in `include/secsgem/gem/process_job_state.hpp` too — it's the wire enum
that S16F9 carries.)
### Add a new SECS-II message
```yaml
# data/messages.yaml
- id: S6F30
stream: 6
function: 30
w: true
builder: s6f30_something
parser: parse_s6f30
body:
kind: list
struct_name: Something
fields:
- {name: field_a, shape: {kind: scalar, item_type: U4}}
- {name: field_b, shape: {kind: scalar, item_type: ASCII}}
```
`docker compose run --rm builder` regenerates `messages.hpp`. The
typed builder, parser, and struct definition appear automatically.
## Demo
The two-container demo walks ~20 SECS transactions:
```
[host] -> Select.req [equip] <- Select.req
[host] == SELECTED == [equip] == SELECTED ==
[host] -> S1F13 W [equip] -> S1F14 (COMMACK=0)
[host] -> S1F17 W [equip] HostOffline -> AttemptOnline -> OnlineRemote
[host] -> S1F19 W [equip] -> S1F20 (12 capabilities)
[host] CCODE 1 Establish Communications
[host] CCODE 2 Dynamic Event Report Configuration
[host] ...
[host] CCODE 14 Spooling
[host] -> S1F21 W [equip] -> S1F22 (2 DVIDs)
[host] -> S1F11 W [equip] -> S1F12 (3 SVIDs)
[host] -> S1F3 W [equip] -> S1F4
[host] -> S2F29 W [equip] -> S2F30 (2 EC entries)
[host] -> S2F33/F35/F37 W [equip] subscribes CEIDs 200, 300
[host] -> S2F41 W START [equip] emit S6F11 CEID=300
[host] EVENT CEID=300 (1 reports)
[host] -> S5F5 W [equip] -> S5F6 (2 alarms)
[host] -> S5F3 W [equip] enables alarm 1
[host] -> S2F41 W FAULT [equip] emit S5F1 + S6F11 CEID=200
[host] ALARM SET ALID=1 cat=4 "Chiller Temp High"
[host] -> S2F41 W SPOOL_ON [equip] force_spool=true
[host] -> S2F41 W START spool: S6F11 CEID=300 queued
[host] -> S2F41 W SPOOL_OFF [equip] force_spool=false (depth=1)
[host] -> S6F23 W Transmit [equip] drains 1 spooled message
[host] EVENT CEID=300 (from spool, post-fact)
[host] -> S7F19 W [equip] -> S7F20 (2 PPIDs)
[host] -> S7F5 W RECIPE-A [equip] -> S7F6
[host] -> S16F11 W PJ-1 RECIPE-A [equip] -> S16F12 HCACK=0
[host] -> S14F9 W CJ-1 [PJ-1] [equip] -> S14F10 OBJACK=0
[host] -> S16F27 W CJ-1 CJSTART [equip] CJ Queued -> Executing
[host] <- S6F11 CEID=400 PJ Queued -> SettingUp
[host] <- S16F9 PJ-1 state=SettingUp PJ -> WaitingForStart
[host] <- S16F9 PJ-1 state=WaitingForStart PJ -> Processing
[host] <- S16F9 PJ-1 state=Processing PJ -> ProcessComplete
[host] <- S16F9 PJ-1 state=ProcessComplete CJ -> Completed
[host] <- S6F11 CEID=401
[host] -> S14F11 W CJ-1 [equip] -> S14F12 OBJACK=0
[host] -> S10F1 W [equip] TERMINAL[0] Hello equipment!
[host] -> S1F15 W [equip] OnlineRemote -> HostOffline
[host] -> Separate.req [equip] <- Separate.req
```
## Build details
The toolchain image (`Dockerfile`) is Ubuntu 24.04 with `g++-13`, CMake,
Ninja, `libasio-dev`, `libyaml-cpp-dev`, and Python 3 for the codegen.
doctest is fetched via CMake FetchContent. Build artifacts live in a
named Docker volume so the host filesystem stays clean.
Standalone Asio is used in header-only mode (`ASIO_STANDALONE`). No
Boost dependency.