If you are standing up a fab or an assembly and test plant, you will at some point discover that a semiconductor production tool does not speak anything your IT department recognises. Not REST. Not MQTT. Not OPC-UA, in most cases. It speaks SECS/GEM, a family of SEMI standards that predates the web and is still, three decades later, how essentially every tool on a production floor reports what it is doing.
This post is the explanation we end up giving in most first conversations. It assumes you are technical but not a SEMI specialist.
The stack, from the wire upward
Four standards do most of the work, and they sit on top of one another.
E37 — HSMS, the transport
HSMS (High-Speed SECS Message Services) carries messages over TCP/IP. One side listens and one side connects: in SEMI terms, passive and active mode. Which side is which is a configuration decision, and getting it wrong is one of the most common reasons a first connection attempt sits there doing nothing.
HSMS also defines a set of timers — T3 for a reply, T5 before a reconnect attempt, T6 for control transactions, T7 for the select handshake, T8 for inter-byte gaps. These matter more than they sound. A tool that appears to "drop out randomly" is very often a T3 or T7 mismatch between the two ends rather than a network fault.
E4 — SECS-I, the older transport
Before TCP/IP, SECS ran over RS-232 serial. Plenty of working 150mm and 200mm equipment still does. Serial tools generally need a converter or a gateway to reach a modern network, and they cannot be treated as a drop-in equivalent of an HSMS tool.
E5 — SECS-II, the message content
E5 is the grammar. Messages are identified as SxFy — stream x, function y. Odd function numbers are requests, even numbers are the replies. So S1F1 is "are you there", S1F2 is the answer; S5F1 is an alarm report; S6F11 is an event report.
Inside a message, data is a nested tree of typed items: lists, ASCII, binary, signed and unsigned integers of several widths, floats, booleans. The type is on the wire as a format code, which means two implementations can disagree about whether a field is a binary byte or a one-byte unsigned integer and produce messages that look right in a log and fail to parse.
E30 — GEM, the behaviour
E30 is where it becomes a model rather than a message format. GEM says what a compliant tool must actually do: which state machines it maintains, how it reports events, how the host takes control.
The pieces you will care about:
- Communication state — whether the host and tool have established a session at all
- Control state — offline, online-local, or online-remote. A tool in online-local will happily report data and refuse your commands, which surprises people
- Status variables (SVIDs) — values you can ask for at any time: temperatures, pressures, positions, counters
- Data variables (DVIDs) — values that are only meaningful attached to an event
- Collection events (CEIDs) — the tool tells you something happened, and you choose which ones you want and what data rides along
- Equipment constants (ECIDs) — settings you can read and sometimes write
- Alarms — set and cleared, with an identifier and text
- Remote commands — start, stop, and whatever else the vendor exposed
- Recipe management — upload, download, delete, and the question of who owns the master copy
What "GEM compliant" on a datasheet does not tell you
This is the single most expensive misunderstanding in equipment connectivity, so it is worth being blunt.
GEM defines a set of capabilities, some mandatory and many optional. A tool can be genuinely, honestly GEM compliant and still not do the thing you assumed it would. Compliance says the tool implements the standard correctly where it implements it. It does not say the tool implements the parts you need.
In practice, the things that vary tool to tool are:
- Which SVIDs exist at all. Two etchers from the same vendor, different generations, will expose different variable sets. There is no universal list
- Whether remote commands are enabled. Sometimes they are a licensed option you did not buy
- Whether recipe download is supported, and whether the tool will accept a recipe it did not originate
- Whether trace data collection is implemented. Periodic sampling is an optional GEM capability, not a given
- Which GEM300 standards are present — see the separate post on that
None of this is discoverable from a brochure. It comes from the tool's SECS/GEM interface manual, which the vendor will provide, and which is the single most useful document in an integration project.
Why the timing catches teams out
Here is the part that has commercial consequences.
Connectivity gets decided during tool installation and qualification, not afterwards. Once a tool is connected, its data flowing, its recipes managed and its qualification signed off, nobody wants to touch that interface again. It works, and the cost of revisiting it is measured in production risk rather than engineering hours.
That means the window in which you can make good connectivity decisions is short, it opens when the tools arrive, and it is not aligned with when most organisations start thinking about MES integration. Teams that begin the conversation after the tools are running are not choosing an architecture — they are inheriting one.
The practical consequence: the connectivity questions belong in the equipment purchasing conversation, before the PO. We wrote a checklist for exactly that.
Where a connectivity layer fits
You have tools speaking SECS/GEM, and you have an MES, a data historian, an analytics platform and probably a few homegrown systems that speak modern APIs. Something has to sit between them.
That something is not your MES. Most MES platforms can talk SECS/GEM, but doing it inside the MES means the protocol layer is coupled to a system you cannot easily change, and every other consumer of equipment data has to go through the MES to get it.
The alternative is a dedicated connectivity layer: it holds the SECS/GEM conversation with each tool, and exposes what it learns over an interface the rest of your estate already understands. The MES becomes one consumer among several rather than the gatekeeper.
That is the layer FabConnect is. Nothing is installed on the tool, and no recipe or firmware change is required — the tool is talking to something on the network, which is what its SECS interface is for.
What to do next
If you are early: get the SECS/GEM interface manual for every tool you are buying, before you buy it. If the vendor is slow to produce one, that is information.
If you are mid-install: inventory what is actually connectable today versus what needs work, tool by tool. The answer is usually less uniform than expected.
If you are already running: the interfaces you have are the interfaces you have, and the useful question is what data you are not collecting that you could be.