SCADA Things

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

SELECTED Is Not Communicating: When S1F13 Never Gets an S1F14

The HSMS session is SELECTED and S1F13 draws only a T3 timeout, while Linktest answers on the same socket in 0 ms. A capture, and two state machines.

SECS/GEMMESSCADATroubleshootingChecklists

The host screen says SELECTED. Select.rsp came back in 1 ms and Linktest keeps answering. Then you send S1F13, no S1F14 arrives, and T3 quietly expires. This is the point where people start suspecting the network — except Linktest just round-tripped in 0 ms. It isn't the link. The HSMS connection state and the GEM communication state are two different state machines, and finishing the first one does not start the second.

Three requests on one socket — Select.req answered by Select.rsp in 1ms, S1F13 with no reply after 4004ms, and Linktest.req answered by Linktest.rsp in 0ms HostEquipment Select.req Select.rsp · 1ms Linktest.req Linktest.rsp · 0ms S1F13 · W-bit no reply · 4004ms

One socket, three requests

I opened a plain socket against the passive listener and played host. Select.req, then S1F13, then Linktest.req.

TX Select.req     00 00 00 0A 00 0B 00 00 00 01 00 00 05 01
RX Select.rsp     00 00 00 0A 00 0B 00 00 00 02 00 00 05 01   (1ms)

TX S1F13          00 00 00 1A 00 0B 81 0D 00 00 00 00 05 02
                  01 02 41 07 48 4F 53 54 4D 45 53 41 03 32 2E 31
RX                (no reply, gave up after 4004ms)

TX Linktest.req   00 00 00 0A 00 0B 00 00 00 05 00 00 05 03
RX Linktest.rsp   00 00 00 0A 00 0B 00 00 00 06 00 00 05 03   (0ms)

Select finished. The Select Status byte is 00 and SystemBytes 00 00 05 01 came back unchanged, so the session is SELECTED. The next line is a data message meeting silence. The line after that gets an answer in 0 ms.

The order matters. Sending Linktest after S1F13 is what proves nothing died in between. The socket is up, the process is running, and it has capacity to answer. The silence came from a layer above.

The S1F13 header, byte by byte

00 00 00 1A   Length      26 bytes (10 header + 16 body)
00 0B         SessionID   11
81            Byte 2      W-bit 1 + Stream 1
0D            Byte 3      Function 13
00            PType       0 = SECS-II
00            SType       0 = data message
00 00 05 02   SystemBytes this transaction's id
01 02 ...     body        L,2 { A 'HOSTMES', A '2.1' }

Two places to look. SType 00 means this is a data message, not a control message, and a data message can only be sent once the session is SELECTED. The top bit of Byte 2 is the W-bit — here 81, so a reply is being demanded. Sending W-bit 0 and then waiting for an answer is its own bug, covered in header byte 2. In the body, 01 02 is a List of two elements and 41 07 is a 7-byte ASCII item; that arithmetic belongs to the item header's length bytes.

The body carries MDLN and SOFTREV. The equipment side logged all 26 bytes exactly as sent, so this is not a case of a malformed encoding being dropped.

There are two state machines

SEMI E37 manages the connection. It starts at NOT CONNECTED, reaches CONNECTED when TCP comes up, and only becomes SELECTED once Select completes. Data messages may flow from that point. That is the whole of what E37 is responsible for.

SEMI E30 (GEM) puts its communication state on top of that. It separates whether the equipment permits communication at all (DISABLED / ENABLED) from whether it is actually talking to a host (NOT COMMUNICATING / COMMUNICATING). The thing that moves it from NOT COMMUNICATING to COMMUNICATING is the S1F13 / S1F14 exchange. The first item in the S1F14 body is COMMACK, and 0 is accepted. Anything else is a refusal, and which value carries which meaning is in E30's table and in the tool's manual — I have no capture of a non-zero COMMACK from real equipment.

So SELECTED tells you the socket and the session are open, and nothing more. If the equipment has not enabled communication yet, is still starting up, or is not in a state to take this host, S1F13 goes in the bin. An MES screen that paints SELECTED as "online" is wrong exactly here.

What this capture does not prove

This listener answers control messages only. It never parses a data message body, so the silence above is the listener's own limitation, not a GEM-level refusal. It is not a capture of an S1F14 carrying a COMMACK.

What the capture does prove is two things: the 26 bytes crossed a real socket and were logged as RX on the equipment side, and Linktest on that same socket answers in 0 ms. The shape of the symptom at the host matches what real equipment gives you when it will not establish communication. That is not a claim that the cause is the same.

What to fix on the host side

  • Don't treat SELECTED as communication established. The online decision belongs after you've read COMMACK out of S1F14.
  • Don't retry S1F13 on a T3 cadence forever. GEM puts a separate delay between establish-communications attempts, and that delay is usually exposed as an equipment constant. Get its name and value from the tool's manual.
  • A Linktest that succeeds proves the link and nothing else. Hang a health check on that alone and even a session that never completed Select shows up green.
  • Read the equipment-side RX log first. If the bytes never arrived, this is a framing problem, not a GEM problem.

The place that actually burns the most time is elsewhere: a host stack that logs "T3 timeout" without recording which message died. S1F13 dying and S6F11 dying are completely different incidents, and from the log you cannot tell them apart.

Reproducing it

The capture came from a socket opened directly against the passive listener in the SECS/GEM simulator. Send the same three messages in the same order, and check the equipment-side RX hex against your own bytes before anything else.