SECS/GEM Protocols Everywhere, Equipment Data Collection Stuck at the IoT Gateway

1. Background

Is your FAB plant also going through this "fake smooth operation"?

SECS/GEM protocols are running. Devices are connected. Data is flowing.

But you stare at the MES dashboard, and something just doesn't feel right.

Because you know this data is a "castrated" version. The raw messages were stripped, reassembled, and dropped at the IoT gateway. Some fields don't match. Some timestamps are wrong. Some alarms that should have been pushed never made it. You don't know which data is real and which the IoT gateway "made up for you."

Even worse: you don't know when it's going to suddenly drop.

Last Wednesday afternoon, the CVD equipment's SECS connection dropped out of nowhere. The IoT gateway log showed "protocol parsing timeout," but the device side showed "connection normal." You spent forty minutes troubleshooting, only to find the IoT gateway's GEM state machine had frozen — it thought the device was disconnected, the device thought the IoT gateway was disconnected, and both sides were waiting for the other to speak first.

The line ran idle for forty minutes.

You know in your heart this isn't the first time, and it won't be the last.

SECS/GEM problems are never on the device side. They're always at the IoT gateway.

2. Why Is SECS/GEM a "Protocol Nightmare"?

SECS (SEMI Equipment Communication Standard) is the underlying protocol for semiconductor equipment communication. GEM (Generic Model for Equipment and Materials) is the equipment behavior model built on top of SECS.

In theory, all semiconductor equipment should speak the same "language."

But in reality — every vendor has gone "dialect."

Applied Materials' SECS-II and Lam Research's SECS-II don't have identical field definitions. Tokyo Electron's GEM implementation and ASML's GEM implementation differ in state machine transition logic. Even within the same vendor, SECS message formats can change across different generations of equipment.

You bought ten pieces of equipment, and you're facing seven or eight "semi-compatible" SECS/GEM variants.

The IoT gateway's job is to translate all seven or eight dialects into standard Mandarin that the MES can understand.

Here's the problem: the act of translation itself is the biggest source of failure.

3. Where Does the IoT Gateway Get Stuck? Three Pitfalls You Probably Haven't Realized

3.1 Protocol Parsing Is Not "Forwarding" — It's "Reconstruction"

Many people think the IoT gateway just moves SECS messages from the serial port to the Ethernet port, untouched.

It doesn't. SECS/GEM communication is stateful. When a device sends an S1F1 (data collection request), the IoT gateway must parse the request, locate the corresponding data point, read it from the PLC or device internals, then assemble an S1F2 (data response) and send it back. This process involves message disassembly, field mapping, state machine maintenance, and timeout management.

If any single step goes wrong, the data is wrong.

And most industrial IoT gateways use a generic SECS/GEM protocol stack, not one customized for your equipment. Field mapping relies on manual configuration. The state machine runs on default logic. The device gets a firmware upgrade, the fields change, but the IoT gateway is still using the old mapping — all the data is wrong, and you don't even know it.

3.2 The Buffer Queue Is a "Time Bomb"

SECS/GEM communication is asynchronous. When multiple devices send requests simultaneously, the IoT gateway's buffer queue builds up. When it reaches capacity, the queue overflows and old messages get discarded.

What gets dropped could be a routine data collection — or a device alarm.

You see "data normal" on the MES, but the alarm was already swallowed by the IoT gateway. By the time you find out, the equipment has already caused a quality incident.

3.3 Heartbeat Mismatch Causes "Fake Death" Connections

SECS/GEM uses heartbeat messages (S6F11/S6F12) to maintain connections. But different devices have different heartbeat intervals: some send one every 30 seconds, some every 60 seconds, some don't send heartbeats at all and rely on TCP keepalive as a fallback.

If the IoT gateway is configured with only one heartbeat policy, this happens: it receives Device A's heartbeat but not Device B's — so it declares Device B disconnected and closes the session. But Device B has no idea it got kicked. It's still sending data into a "session that no longer exists."

This is the deadlock we described earlier — both sides waiting for the other to speak first.

In FAB plants, 80% of SECS/GEM network failures are not physical link problems. They're protocol-layer problems. And protocol-layer problems all get stuck at the IoT gateway.

4. 80% Failure Rate Reduction Doesn't Come from Swapping IoT Gateways — It Comes from Changing Your Thinking

An 80% reduction doesn't come from stacking hardware — buying a more expensive IoT gateway or adding more network cards won't help. The core is three mindset shifts:

4.1 The Protocol Stack Must Be "Built Around the Device," Not "One-Size-Fits-All."

Instead of using a single generic SECS/GEM protocol stack for all devices, customize the field mapping and state machine configuration for each equipment type. When device firmware is upgraded, update the mapping tables accordingly. This isn't a one-time task — it's ongoing O&M. But 80% of failures are hidden in that "ongoing."

4.2 The Buffer Queue Must Have "Priority" — Not First-Come, First-Served.

Device alarms must have higher priority than data collection. When the queue is full, drop data collection first — protect the alarms. This one rule alone can recover the vast majority of critical information that gets "silently lost."

4.3 Heartbeat Policy Must Be "One Device, One Policy" — Not One-Size-Fits-All.

Every device's heartbeat interval, timeout duration, and reconnection strategy should be configured independently. Don't expect a single global setting to manage all devices.

Put these three in place, and the 80% failure rate drop isn't hype — it's proven data from a 12-inch FAB plant: after changing the IoT gateway's SECS/GEM configuration from "generic mode" to "one device, one policy," monthly network anomalies dropped from 23 to 4.

5. What Should You Actually Look for When Selecting an IoT Gateway?

Choosing an industrial IoT gateway for SECS/GEM scenarios is completely different from ordinary data collection. Several hard specs:

USR's M300 from PUSR has been deployed in this scenario many times. Supports SECS/GEM protocol, multi-session concurrency, auto-reconnect, wide temperature -40~75°C — the specs aren't the flashiest, but in the niche of semiconductor equipment data collection, it's a proven, mature choice.

There's no single right answer for selection. But there's one iron rule: in the world of SECS/GEM, the IoT gateway is not a pipe — it's a translator. If the translator isn't good, every piece of data on the entire line is just "hearsay."

People doing data collection in FAB plants don't fear having many devices or complex protocols most. What they fear most is seeing data flow and not daring to trust it's real.

The MES dashboard shows everything is normal, but you know the IoT gateway's buffer queue is nearly full. The device shows connection normal, but you know the heartbeat policies don't match. Alarms that should have been pushed weren't, because priority was squeezed out by data collection.

You're not doing data collection. You're gambling that the IoT gateway won't fail.

Build the protocol stack around the device. Prioritize the buffer queue by urgency. Configure heartbeat policy per device. Do these three things, and you go from "gambling" to "controlling."

The 80% failure rate reduction isn't luck. It's because you finally stopped pretending the data was reliable.