SCADA Things

← Articles
LangEN한국어
SECS/GEM/6 min read/— views

An ACKC5 0 From S5F3 Does Not Mean That ALID Exists

How a GEM host turns alarms on with S5F3, byte by byte, and a socket capture where disabling an ALID the tool has never heard of still acked 0.

SECS/GEMAlarmsMESSCADATroubleshootingChecklists

Second day on the tool. S6F11 arrives fine. Not one alarm has come in. There is a red banner on the equipment screen and no S5F1 anywhere in the host log. This is not the link and it is not the communication gate. Nobody ever asked the tool to send alarms. The message that asks is S5F3, and its body is two items. One ALED, one ALID. To switch every alarm on at once you send the ALID as a zero-length item.

The 7-byte S5F3 body: L,2 then a one-byte ALED of 80, then a zero-length ALID that means all alarms S5F3 body — enable all alarms, 7 bytes 10-byte header not shown L,2 ALED ALID 0102 210180 B100 012 3456 21 = BB1 = U4 zero length — all alarms

The capture

I opened a socket straight at the simulator's passive listener. A socket, not the HTTP API. A frame only counts if the equipment side logged it as RX.

TX Select.req   00 00 00 0A 00 0B 00 00 00 01 00 00 02 01
RX Select.rsp   00 00 00 0A 00 0B 00 00 00 02 00 00 02 01

Byte 3 is 00 — that is Select Status. The session is SELECTED.

TX S1F13 W      00 00 00 17 00 0B 81 0D 00 00 00 00 02 02
                01 02 41 04 48 4F 53 54 41 03 31 2E 30
RX S1F14        00 00 00 37 00 0B 01 0E 00 00 00 00 02 02
                01 02 21 01 00
                01 02 41 15 56 58 2D 39 30 30 30 20 50 6C 61 73 6D 61 20 45 74 63 68 65 72
                41 0D 53 45 43 53 47 45 4D 2D 31 2E 34 2E 31

21 01 00 is B[1] 0, COMMACK 0. The E30 communication gate is open. Skip this and the S5F3 below never gets as far as alarms — it comes back S5F0. That path has its own article.

TX S5F3 W       00 00 00 11 00 0B 85 03 00 00 00 00 02 03 01 02 21 01 80 B1 00
RX S5F4         00 00 00 0D 00 0B 05 04 00 00 00 00 02 03 21 01 00

Byte 2 is 85. The top bit is the W-bit and the rest is Stream 5. Byte 3 03 is function 3.

Split the 7-byte body. 01 02 is an L with two elements. 21 has 8 in its top six bits — format B — and 1 in the low two, so one length byte, which is 01, so one data byte. That byte is 80. This is ALED. Then B1: top six bits are 44, format U4. Its length byte is 00 — zero length. An item carrying no data at all. In SEMI E5, an empty ALID in S5F3 means every alarm.

The reply is 21 01 00, B[1] 0. ACKC5 0. Received.

TX S5F3 W       00 00 00 15 00 0B 85 03 00 00 00 00 02 04 01 02 21 01 00 B1 04 00 00 03 EC
RX S5F4         00 00 00 0D 00 0B 05 04 00 00 00 00 02 04 21 01 00

The second one flips ALED to 00 and names one ALID. B1 04 00 00 03 EC — U4, four bytes, value 1004. "Disable ALID 1004 only."

Here is the trap

ALID 1004 does not exist on this tool. The listener owns exactly two alarms and they are 5001 and 5002. I made 1004 up.

The reply is 21 01 00. The same ACKC5 0.

disable a nonexistent ALID 1004  ->  ACKC5 0
enable every alarm               ->  ACKC5 0

Nothing separates them. If your host code records "S5F4 came back 0, so the alarm config took", one typo in an ALID slips through silently. Integration test green, that one alarm missing in the fab, debugging starts a few months later.

An ACKC5 0 guarantees one thing: the equipment received that frame and parsed it. Whether the ALID exists, and whether it is now enabled or disabled, it tells you nothing about.

What the host should do instead

  • Never invent an ALID — fetch them. S5F5 asks for the tool's alarm list and S5F6 returns it. Then no number in your S5F3 is one you typed. ALCD and the set/clear bit are in the alarm mapping article.
  • Enable everything in one shot. A zero-length ALID has no number to get wrong. Filtering alarms back down is a later problem.
  • Resend on every reconnect. Nothing guarantees the enabled state survives a session. A fixed S5F3 right after S1F13 is cheap.
  • When alarms are missing, check S5F3 first. Before the link, the gate, and the report links. Grepping the host log for "did we ever enable alarms" takes a minute.

What I did not verify

This capture did not verify what the ALED value means. The listener never reads that byte — 80 and 00 get the same ACKC5 0. The S5F3 definition in E5 has ALED 0 as disable and non-zero as enable, and the field uses 80, but I did not re-read that clause against a copy of the standard this run.

That a zero-length ALID means all alarms is also from E5, not something I proved with bytes. This listener has no alarm filtering at all, so there is no enable/disable result to look at.

I also did not verify whether GEM equipment ships with alarms on or off. Treat it as tool-dependent and have the host enable them explicitly.

Every frame above came off a socket opened against the passive listener of the public SECS/GEM simulator. Put one nonexistent ALID into an S5F3 from your own host stack and watch how it records the ACKC5 0. That is where you find out whether the trap above is in your code.