The One Bit That Decides Whether a SECS/GEM Alarm Is Set or Cleared
S5F1 carries ALCD, ALID and ALTX. Bit 8 of ALCD is set-versus-clear, and dropping it leaves an MES alarm list that never goes green. Plus the S5F5/S5F6 recovery after a host restart.
Three alarms sitting in the MES banner. The tool screen is clean. The operator says they cleared all of them an hour ago.
Open the log and there are six S5F1 messages. Three sets, three clears. The host received all six and recorded all six as "alarm raised", because it read ALID and ALTX and threw ALCD away.
S5F1 has three items
SEMI E5 Stream 5 is alarm and exception handling. The body of S5F1 Alarm Report Send is one list of three items.
L,3
<B ALCD> 1 byte alarm code byte
<U4 ALID> alarm identifier (format varies — see below)
<A ALTX> alarm text, max 120 characters
That is the order. ALCD comes first, not ALID. Hand-written parsers that read the first item as the ID do exist, and they fail in a way that looks like a mapping problem.
You need something to check your decoder against. What follows is not a hand-drawn example. These bytes went over a socket into an HSMS passive listener on 127.0.0.1:5501, session ID 11, and were copied back out of the equipment side's RX log. HSMS framing per SEMI E37, item headers per the E5 format-code table.
TX Select.req 00 00 00 0A 00 0B 00 00 00 01 00 00 01 01
RX Select.rsp 00 00 00 0A 00 0B 00 00 00 02 00 00 01 01
TX S5F1 set 00 00 00 2C 00 0B 85 01 00 00 00 00 0B B9
01 03 21 01 82 B1 04 00 00 13 89
41 15 43 68 61 6D 62 65 72 20 70 72 65 73 73 75 72 65 20 68 69 67 68
Byte 3 of the Select.rsp is 00, so the link is SELECTED. Cut the next frame apart and it reads like this.
00 00 00 2C length = 44 (10-byte header + 34-byte body)
00 0B session id 11
85 W-bit set (0x80) + stream 5
01 function 1
00 00 PType 0, SType 0 -> data message
00 00 0B B9 SystemBytes
01 03 L,3
21 01 82 <B 0x82> set + category 2, equipment safety
B1 04 00 00 13 89 <U4 5001> ALID
41 15 43 68 61 6D ... <A "Chamber pressure high"> 0x15 = 21 characters
The equipment side's decoder logged len 44, sessionId 11, stream 5, function 1, wbit true, systemBytes 3001 for that frame. 3001 is 0x00000BB9. When your encoder and somebody else's decoder agree on every field, the bytes are right.
The clear for the same alarm went down the same socket next.
TX S5F1 clear 00 00 00 2C 00 0B 85 01 00 00 00 00 0B BA
01 03 21 01 02 B1 04 00 00 13 89
41 15 43 68 61 6D 62 65 72 20 70 72 65 73 73 75 72 65 20 68 69 67 68
Put the two frames side by side and exactly two bytes differ: SystemBytes (0B B9 → 0B BA) and ALCD (82 → 02). Same length of 44, same ALID, same ALTX. That is why a host that skips item 1 cannot tell the two apart.
Nothing came back for any of the three frames — one second of waiting, no S5F2. This listener does not implement the host-side S5F2 at all. That is what an unanswered W-bit message looks like from the sending end: nothing happens. Real equipment would be counting T3 right now.
Byte 2 of the HSMS header being 85 rather than 05 is the W-bit. It is the equipment telling you it wants S5F2 back.
That single ALCD byte carries two things at once.
| Bit | Meaning |
|---|---|
| Bit 8 (0x80) | 1 = alarm set, 0 = alarm cleared |
| Bits 7–1 | Alarm category code |
So 0x82 above means "equipment safety alarm raised" and 0x02 means "same alarm cleared". ALID and ALTX are identical in both messages. The only difference is the top bit.
E5 defines the category codes:
| Value | Category |
|---|---|
| 1 | Personal safety |
| 2 | Equipment safety |
| 3 | Parameter control warning |
| 4 | Parameter control error |
| 5 | Irrecoverable error |
| 6 | Equipment status warning |
| 7 | Attention flags |
| 8 | Data integrity |
| 9–63 | Reserved |
| 64–127 | Equipment-supplier defined |
Anything at 64 or above sends you to the vendor manual. The standard has no answer for those.
The key is ALID, never ALTX
ALTX is a string that E5 caps at 120 characters. It exists for the operator to read, not to be a key. Upgrade the equipment software, someone fixes a typo, and the string changes — and an integration keyed on text turns that into a brand new alarm from that day on.
ALID is stable. GEM (SEMI E30) requires each alarm to have a unique, unchanging ALID. That is the primary key of your mapping table.
ALID is not always U4. E5 defines it with a numeric format, and the equipment picks which one — U1, U2, U4, U8 or the signed I1/I2/I4/I8 are all permitted. Read the item header byte, do not hard-code the width. The four unsigned ones you actually meet, as a single-length-byte item header:
| Format | Item header byte | Payload |
|---|---|---|
| U1 | A5 | 1 byte |
| U2 | A9 | 2 bytes |
| U4 | B1 | 4 bytes |
| U8 | A1 | 8 bytes |
The same alarm went down the same socket once more with nothing changed but the ALID format. These bytes came off the wire too.
TX S5F1 set (U2 ALID) 00 00 00 2A 00 0B 85 01 00 00 00 00 0B BB
01 03 21 01 82 A9 02 13 89
41 15 43 68 61 6D 62 65 72 20 70 72 65 73 73 75 72 65 20 68 69 67 68
B1 04 00 00 13 89 became A9 02 13 89, and that alone dropped the frame from 44 bytes to 42 (0x2A). The equipment decoder read it as len 42.
A host that assumes B1 — skip two header bytes, take the next four as the ID — picks up 13 89 41 15 here. Not 5001, but 327762197 (0x13894115). Every item after it is misaligned, and all the log shows is an alarm mapping miss. The bug is in the decoder, not the table.
Keep the raw ALTX anyway. During a failure investigation the tool screen, the vendor manual and the field service report all speak in the original wording. If you stored only a normalised name, nothing lines up.
What belongs in the mapping table
Fill the table in before you write code.
| Column | Why |
|---|---|
| ALID | Stable key. Set, clear, history and filtering all hang off it. |
| ALCD category | 1–8 are E5-defined, 64+ are vendor-defined. Record which. |
| Raw ALTX | Vendor wording, untouched. |
| Normalised name | For MES screens and reports. |
| Severity | Site priority, not the vendor's severity copied across. |
| Location | Chamber, module, station. |
| Linked CEID | Collection events tied to alarm set and clear. |
| Snapshot variables | SVIDs/DVIDs to capture at the alarm edge. |
| Operator response note | The first thing someone should check. |
| Test evidence | A record of actually triggering it. |
Do not leave the linked-CEID column empty. GEM ties alarms into collection event reporting as well, so the same transition can arrive twice — once as S5F1 and once as S6F11. Enable both paths without de-duplicating and one alarm appears twice in the list.
After a host restart, ask again
Any S5F1 sent while the session was down is gone. Reconnecting does not bring the state with it. You have to ask.
- S5F5 List Alarms Request — send a list of ALIDs and you get their current state back. Send a zero-length list and you get all of them. The reply is S5F6, and bit 8 of each ALCD inside it tells you whether that alarm is set right now. Active-alarm recovery after a restart is that one round trip.
- S5F7 List Enabled Alarm Request — header only, no body. S5F8 comes back with the alarms the equipment currently has enabled. This is where you catch the gap between what you believe you enabled and what the tool actually turned on.
- S5F3 Enable/Disable Alarm Send — ALED is
0x80to enable,0x00to disable. S5F4 answers with ACKC5.
If you are going to use S5F3, decide first who owns it. A host integration and a vendor tool flipping the same alarm's enable state without knowing about each other is the hardest version of this to find.
Four states is not enough
An alarm list that only appends events is not a list. It has to hold current state.
| State | When |
|---|---|
| Active | A set was received and no matching clear has arrived. |
| Cleared | A clear arrived after active. |
| Unknown | The integration restarted and has not re-queried with S5F5 yet. |
| Stale | The HSMS link is down, or the last update is too old. |
| Disabled | The equipment does not have the alarm enabled (per S5F8). |
Most implementations skip Unknown and Stale. While the link is dead the screen keeps showing the last state it saw, and that looks clean. Receiving nothing is not the same as there being no alarms. If those two look identical on your screen, the screen is wrong.
GEM has the equipment send S5F1 with the W-bit set, so the host owes an S5F2 carrying ACKC5. The deadline is the T3 reply timeout, and E37's recommended default is 45 s. ACKC5 of 0 is accepted; non-zero is an error. The whole reply is 13 bytes:
00 00 00 0D 00 0B 05 02 00 00 00 00 0B B9 21 01 00
^^ stream 5, W-bit clear
^^ function 2
^^^^^^^^^^^ SystemBytes, echoed from the S5F1
^^^^^^^^ <B 0> — ACKC5 = accepted
Echo the SystemBytes. A reply with fresh SystemBytes is not a reply, and the equipment will sit there until T3 expires. One thing to be clear about: failing to send S5F2 does not cancel the alarm. The equipment logs a T3 timeout and the alarm stays set.
Severity is an operations decision, not a vendor field
Map vendor severity one-to-one and the MES alarm view becomes a noisy copy of the tool screen.
Run the rationalization that ISA-18.2 describes, once per alarm. The questions are short.
- Does the operator have to move right now?
- Does production stop, or does availability just drop?
- Can product or equipment be damaged?
- Is it actionable from the control room, or does someone have to walk to the tool?
- Is it already handled on the local tool HMI?
EEMUA 191 puts the acceptable steady-state load at no more than one alarm per operator per 10 minutes. Promote every alarm from one tool and you have spent that whole budget on one machine.
What to actually do at commissioning
- Confirm every mapped ALID exists on the installed equipment software revision.
- Trigger representative alarms and capture the raw S5F1 bytes. Check ALCD is 0x80 or higher.
- Clear the same alarms and confirm bit 8 of ALCD comes back as 0.
- Restart the integration and verify active alarms are recovered via S5F5/S5F6.
- Drop the HSMS link and confirm the screen goes Stale. If it does not, that is the bug.
- Send the same set twice and confirm it does not appear twice in the list.
- Send a clear for an alarm that is not active and confirm state does not corrupt.
- Check ALTX encoding using an alarm with non-ASCII characters or punctuation in it.
- Pick a timestamp source — equipment clock or host receive time — and write it down.
- Find any alarm that arrives on both S5F1 and S6F11, and confirm it is de-duplicated.
The mistakes that keep showing up
- Using ALTX as the key. Upgrade day turns every alarm into a new alarm.
- Discarding ALCD and treating every S5F1 as a raise. That is the first paragraph of this article.
- Promoting every vendor warning to the same priority.
- Hiding communication loss instead of showing it.
- Storing only the ALID and losing the chamber, recipe and lot context, so nothing can be reconstructed later.
- Testing against a simulator only and never watching the real tool.
Raise and clear an alarm in the SECS/GEM simulator and you can watch the pair go by. Its default S5F1 carries ALCD 128 and ALID 5001. 128 is 0x80 — set bit on, category code zero, which is exactly the shape plenty of real tools send.
Two honest notes about that demo. Its raise appends a fourth item, a severity string, that E5 does not define; the clear sends three. Take the lesson rather than the shape: read S5F1 by position and stop at item 3, never validate on the list count. Real tools append vendor items too. And the S5F1 you see on that screen is synthesised for display, not written to the socket — the bytes in this article came from the listener instead, not from there.
Next time someone says the alarm list will not clear, do not start with the screen. Read the first item of the raw S5F1. That is usually where it ends.