SCADA Things
← Articles
LangEN한국어
SECS/GEM/10 min read/— views

Prove a Full GEM Startup Handshake Without Any Equipment

Run all ten SEMI E30 startup steps — S1F13 through S2F31 — with one npx command against a simulator, and read what each PASS proves and each FAIL means on a real tool.

SECS/GEMMESSCADATroubleshootingChecklists

The host code is written. It sends S1F13, receives S6F11, parses it, writes it to the database. The problem is that there is no equipment to point it at, and the vendor FAT is in three weeks.

Testing for the first time at FAT means debugging your host driver with four vendor engineers standing behind you. The failures that show up there are not exotic. COMMACK comes back non-zero, S2F33 is rejected outright, the tool never goes online. All of them are checkable from your desk today.

One command does it.

npx secs-gem-host connect <host>:<port> --report

The target is the HSMS passive listener behind the SECS/GEM simulator; a local instance works the same way, just point at its IP and port. With --report the tool splits SEMI E30 startup into ten steps, prints a PASS/FAIL row for each, and exits 1 if any step fails — which also means you can drop it straight into CI.

The ten E30 startup steps, from S1F13/S1F14 COMMACK to S2F31/S2F32 TIACK: what the host sends and the ack the equipment answers with HostEquipment 123 456 789 10 S1F13S1F14 · COMMACK S1F17S1F18 · ONLACK S1F3S1F4 · SV values S1F11S1F12 · SVID namelist S2F29S2F30 · EC namelist S2F33 S2F35S2F36 · LRACK S2F37S2F38 · ERACK S5F3S5F4 · ACKC5 S2F31S2F32 · TIACK S2F34 · DRACK VID mismatch → DRACK 4

The table it actually prints

This is the output of a run made just now against the simulator's listener at 127.0.0.1:5501. Nothing synthesised — these are real transactions over a socket.

Step Sent    Expect  Got     Ack  Time(ms)    Result  Note
------------------------------------------------------------------------
1    S1F13   S1F14   S1F14   0    1/45000     PASS    VX-9000 Plasma Etcher/SECSGEM-1.4.1
2    S1F17   S1F18   S1F18   0    1/45000     PASS
3    S1F3    S1F4    S1F4    -    1/45000     PASS    4 values
4    S1F11   S1F12   S1F12   -    0/45000     PASS    4 SVIDs
5    S2F29   S2F30   S2F30   -    1/45000     PASS    2 ECs
6    S2F33   S2F34   S2F34   0    2/45000     PASS
7    S2F35   S2F36   S2F36   0    1/45000     PASS
8    S2F37   S2F38   S2F38   0    0/45000     PASS
9    S5F3    S5F4    S5F4    0    1/45000     PASS
10   S2F31   S2F32   S2F32   0    0/45000     PASS
------------------------------------------------------------------------
E30 startup: 10/10 passed
flag: model VIDs not in equipment SVID list: 10001, 10002, 10003, 10004, 10005, 10006, 10007, 10008, 10009, 10010, 10011

The note on step 1, VX-9000 Plasma Etcher/SECSGEM-1.4.1, is the MDLN and SOFTREV the equipment put in its S1F14. The tool does not only check COMMACK; it checks that those two fields are actually populated.

A - in the Ack column is not a failure. S1F4, S1F12 and S2F30 carry no one-byte acknowledgement code at all. Those steps are judged on "is the body a list" and "is the namelist non-empty".

The 45000 in the Time(ms) denominator is the T3 reply timeout — the 45 seconds SEMI E37 lists as typical, which the tool uses as its default. The 1 ms is a loopback number. On real equipment, if that column climbs into seconds, that is itself worth reporting. For what each timer protects, see T3, T5, T6, T7 and T8.

What each of the ten steps proves

StepWhat a PASS provesWhat a FAIL usually means in a fab
1. S1F13 → S1F14COMMACK 0 came back and both MDLN and SOFTREV are populated. SECS-II conversation exists from here onA non-zero COMMACK means the equipment is not ready to accept this host. No reply at all is an HSMS problem, not a SECS one
2. S1F17 → S1F18The equipment accepted remote controlThe tool's panel is in LOCAL, or nobody pressed online. The most deflating failure at a FAT
3. S1F3 → S1F4Values actually come back. An empty SVID list reads as "all of them" in SEMI E5A body that is not a list means this tool never implemented S1F3, or answers with S9F5
4. S1F11 → S1F12The SVID namelist is not empty. Steps 6 to 8 are judged against what arrives hereEquipment that will not publish its own list. Every later report definition then rests on the interface manual alone
5. S2F29 → S2F30Equipment constants can be readIf the plan was to manage ECs from the host, that plan is already broken
6. S2F33 → S2F34DRACK 0. The report definitions really landed on the equipmentDRACK 4 — one of the VIDs requested does not exist. One wrong ID rejects the whole message
7. S2F35 → S2F36LRACK 0. The RPTIDs are linked to CEIDsLRACK 4 means a CEID does not exist, 5 means an RPTID does not, 3 means you appended without deleting first
8. S2F37 → S2F38ERACK 0. Events are enabled. CEED true with an empty CEID list enables all of themERACK 1, a CEID you named does not exist. Skip this step and the definitions are perfect and no S6F11 ever arrives
9. S5F3 → S5F4ACKC5 0. Alarm reporting is on. ALED with bit 7 set plus a zero-length ALID item means all alarms, not ALID 0A host that gets everything except alarms is usually a host that never sent this message
10. S2F31 → S2F32TIACK 0. The equipment took the host's time. The tool sends the 16-character YYYYMMDDhhmmsscc formThe tool refuses to have its clock set. Decide now whether event timestamps get replaced by host receive time

Step 2 has one exception. The tool passes ONLACK 2 as well as 0 — re-onlining equipment that is already online is not a failure worth flagging. Reading 2 as "already online" is not something this run verified, though; treat it as unverified.

Step 6 also does something the table does not show. Before sending the definitions, it sends one S2F33 carrying a DATAID and an empty report list — the message that deletes every report definition and event link on the equipment. That is what stops you from stacking your configuration on top of whatever the previous integrator left behind. The ack from that delete-all is noted but never counted toward the result. The full DRACK, LRACK and ERACK code tables are in defining, linking and enabling collection events.

Why a 10/10 run still raises a flag

The line under the table is the most valuable output of the run.

flag: model VIDs not in equipment SVID list: 10001, 10002, ... 10011

Just before step 6, the tool compares the S1F12 namelist it collected in step 4 against the VIDs in its own model. The simulator published four SVIDs; the tool's default model builds reports out of VIDs 10001 through 10011. Not one of them overlaps.

DRACK still came back 0. The simulator accepted VIDs it has never heard of. The score is 10/10 and only the flag records it.

Real equipment answers DRACK 4 here, and that is the failure that eats the most human time during startup. One bad VID rejects the entire S2F33, and a host driver that never inspects DRACK logs "report setup complete" and moves on. The configuration then exists only on the host, never on the tool, and stays that way for weeks.

So the flag is something to resolve, not to ignore. Put the SVIDs, CEIDs and RPTIDs from the equipment's interface manual into one JSON file and pass it with --model.

npx secs-gem-host connect <host>:<port> --report --model ./vx9000.json

Now the SVID list the equipment actually published in step 4 is checked against the IDs you intend to use, in the same run. Clearing that flag before the FAT is cheaper than meeting DRACK 4 for the first time on the day.

What this run does not prove

Worth drawing the line explicitly.

  • It is not evidence about the equipment. The simulator returning DRACK 0 for VIDs it does not know is the proof of that. What the table proves is that your host driver builds ten transactions to spec, parses the replies, and actually inspects the ack codes.
  • Timing does not reproduce. 1 ms is a loopback figure. Whether MES finishes its database write inside a 45-second T3 on real equipment is a separate question.
  • RPTID remapping during recovery, spooling, the real content of S6F11 — only equipment does those.
  • If HSMS never reaches selected, it stops at step 1. The table shows step 1 as FAIL and the rest as SKIP. That is not a SECS problem; start with selected but not communicating.

The order to work in over three weeks

  1. Run it against the simulator as-is. Anything short of 10/10 is a host driver bug you have today.
  2. Build the model JSON from the SVIDs, CEIDs and RPTIDs in the equipment's interface manual.
  3. Run again with --model and confirm the flag is gone.
  4. Wire that command into CI. The exit code is already 1/0, so there is nothing else to write.
  5. On FAT day, change <host>:<port> to the real tool and run the same command. That one table becomes the minutes of the meeting.

The tool is on npm as secs-gem-host, source at github.com/jungyoseok/secs-gem-host, MIT. Running secs-gem-host mcp exposes the same engine as an MCP server, so an AI agent can be told "connect to this tool, run startup, and explain the step that failed" and do it directly.

If you need something to connect to, the SECS/GEM simulator is up right now.

npx secs-gem-host connect <host>:<port> --report