SECS/GEM Protocol: The Complete Guide to Semiconductor Equipment Communication

What Is SECS/GEM and Why Does It Matter?

Walk into any advanced semiconductor fabrication facility — whether it processes 200mm legacy wafers or 300mm leading-edge devices — and every piece of equipment on the production floor speaks a common language. That language is SECS/GEM, and without it, modern fab automation would be impossible.

SECS/GEM is a family of SEMI standards that defines how semiconductor manufacturing equipment communicates with factory host computers, Manufacturing Execution Systems (MES), and automation controllers. It governs everything from how a photolithography scanner reports its current process state, to how an etch tool sends an alarm when chamber pressure drifts out of specification, to how a CMP polisher uploads a new recipe downloaded from the factory host.

The protocol family consists of three interlocking layers: the physical/transport layer (SECS-I or HSMS), the message encoding layer (SECS-II), and the behavioral model layer (GEM, defined in SEMI E30). Together these layers let equipment vendors and fab operators agree on a single integration contract without custom, proprietary interfaces for every new tool.

A Brief History of SECS/GEM

SEMI began work on the SECS standards in the late 1970s to address a painful reality: every equipment vendor had its own proprietary RS-232 interface with unique message formats, and integrating a new tool into a fab required months of custom software work. SECS-I (SEMI E4) was ratified in 1980, defining a simple serial protocol over RS-232. SECS-II (SEMI E5) followed, defining the message structure and data encoding independently of the transport layer. These two standards enabled early computer-integrated manufacturing in 4-inch and 6-inch wafer fabs.

As fabs scaled to 8-inch and then 12-inch wafers in the 1990s, RS-232 serial links became a bottleneck. SEMI responded with HSMS (High-Speed Message Services, SEMI E37) in 1994, replacing the serial physical layer with TCP/IP over Ethernet while preserving the SECS-II message layer entirely. HSMS is the de facto transport for all 300mm tools and modern 200mm upgrades.

The GEM standard (SEMI E30, Generic Equipment Model) was first published in 1992 and has been continuously revised. GEM defines not just message formats but equipment behavior: what states a tool must support, which capabilities are mandatory versus optional, and how a host system can predictably interact with any compliant tool regardless of its function. GEM300 extensions (SEMI E40, E87, E90, E94) added cluster tool support, carrier management, substrate tracking, and process job control for 300mm automation.

The Three-Layer Architecture: SECS-I, SECS-II, and HSMS

Understanding the layered architecture of SECS/GEM is essential before writing a single line of integration code. Each layer has a distinct responsibility, and the clean separation is what makes the standard so durable across 40-plus years.

SECS-I: The Serial Transport Layer (SEMI E4)

SECS-I operates over RS-232 at speeds up to 9600 baud (though higher rates were sometimes used). It defines a block-based framing protocol where each block carries up to 254 bytes of SECS-II data plus a header, length byte, and 16-bit CRC. Multi-block messages chain blocks together. SECS-I also defines a handshake discipline (RTY, T1–T4 timers) to handle line noise and equipment timeouts. While new tools are never designed with SECS-I, tens of thousands of legacy tools in 200mm fabs worldwide still use it, and any complete SECS/GEM stack must support it.

HSMS: The Ethernet Transport Layer (SEMI E37)

HSMS replaces the serial physical layer with a persistent TCP/IP connection. It defines connection procedures (active/passive modes), session establishment messages (Select.req / Select.rsp), a keep-alive mechanism (Separate.req), and a simple 10-byte message header that carries the SECS-II stream/function numbers, block flags, system bytes, and session ID. HSMS drops the block-chaining complexity of SECS-I because TCP handles framing and reliability. All 300mm tools use HSMS, and HSMS-SS (Single Session) is the standard subset used in practice.

SECS-II: The Message Encoding Layer (SEMI E5)

SECS-II sits above the transport and defines a self-describing binary encoding for all message data. Every SECS-II item begins with a format byte and length field, followed by the data. SECS-II supports a rich set of data types as shown in the table below.

SECS-II messages are identified by a Stream (1–127) and Function (0–255) number. Streams group related message categories: Stream 1 is equipment status, Stream 2 is equipment control, Stream 5 is alarms, Stream 6 is data collection, Stream 7 is process programs (recipes), and so on. Functions are always paired — odd functions are primary messages (requests or unsolicited reports), even functions are replies.

SEMI E30 GEM: The Six Core Capabilities

The GEM standard (SEMI E30) defines the behavioral model that transforms raw SECS-II messaging into a predictable equipment interface. GEM specifies mandatory capabilities that every compliant tool must implement, plus optional capabilities that tools may advertise. The six core mandatory capability groups are:

1. State Models: Equipment must implement defined state machines for Communication State (Enabled/Disabled) and Control State (Off-Line, On-Line/Local, On-Line/Remote). Hosts can query and transition these states predictably.
2. Equipment Constants: Configurable parameters (ECIDs) stored in the equipment. The host can read all constants (S2F13/S2F14), read individual constants (S2F13), and set constants (S2F15/S2F16). Typical examples include process setpoints, alarm thresholds, and integration parameters.
3. Status Variables: Dynamic real-time values (SVIDs) reported by the equipment. The host can request current values at any time (S1F3/S1F4) or configure them to appear in event reports.
4. Collection Events and Reports: Equipment defines a set of Collection Events (CEIDs) — transitions or conditions that trigger data reporting. The host links reports (RPTIDs containing SVIDs) to events and enables event reporting (S2F33–S2F37). When an event fires, the equipment sends S6F11 with the associated report data.
5. Alarms: Equipment maintains a defined alarm set (ALIDs). Alarms can be enabled/disabled by the host (S5F3), and active alarms are reported via S5F1 events. The host can query current alarms at any time (S5F5/S5F6).
6. Remote Control: In On-Line/Remote state, the host can command equipment actions via S2F41 (Remote Command Send) and send/select process programs via Stream 7 messages.

GEM also defines optional capabilities including Limits Monitoring (variable range violation alerts), Trace Data Collection (time-sampled data streams), Spooling (offline message queuing), Material Movement, and Terminal Services. Equipment GEM compliance documentation (the GEM compliance document or GCD) specifies which optional capabilities a tool supports.

Key SECS-II Messages Every Engineer Must Know

Of the hundreds of defined stream/function pairs, five messages form the backbone of 90% of all SECS/GEM integrations. Master these and you can handle most fab automation scenarios.

S1F1 / S1F2: Are You There? (Heartbeat)

Stream 1, Function 1 is the most fundamental message in SECS/GEM. A host sends S1F1 (Are You There request) to verify the equipment is alive and communicating. The equipment replies with S1F2 (On-Line Data), which carries the equipment model name (MDLN) and software revision (SOFTREV) as ASCII strings. S1F1/S1F2 exchanges are used both at connection startup and as periodic heartbeats to detect silent equipment failures. If a host sends S1F1 and receives no reply within the T3 timeout, it considers the equipment offline.

S2F13 / S2F14: Equipment Constants Request

S2F13 is sent by the host to request the current values of one or more Equipment Constants. The message body contains a list of ECIDs (Equipment Constant IDs); sending an empty list requests all constants. The equipment replies with S2F14 containing the ECID values. This is the primary mechanism for reading tool configuration — process temperatures, pressure setpoints, timing parameters, and calibration offsets. Engineers integrating a new tool should always begin with an S2F13 empty-list request to enumerate all available constants and their current values.

S6F11 / S6F12: Event Report Send (The Workhorse)

S6F11 is the most frequently transmitted message in a running fab. Equipment sends S6F11 unsolicited whenever a Collection Event fires — process start, process end, wafer transfer, alarm set/clear, lot change, and hundreds of other tool-specific events. The message body contains the CEID, a timestamp, and all the report data blocks associated with that event. The host must reply with S6F12 (acknowledgment) within T3. S6F11 is the primary data stream for real-time equipment monitoring, SPC data collection, and AI model training. A 300mm lithography scanner may generate thousands of S6F11 messages per wafer, each carrying hundreds of process variables.

S5F1 / S5F2: Alarm Report Send

When an alarm condition occurs or clears, equipment sends S5F1 to the host. The message carries the alarm ID (ALID), alarm text (ALTX), alarm code (ALCD, which encodes severity and set/clear status), and an equipment-specific alarm category byte. S5F2 is the host acknowledgment. Unlike S6F11 collection events, alarms represent abnormal conditions requiring operator or host action. A complete integration must process S5F1 reliably and route alarms to the appropriate MES, APC, or alerting system. Missing an S5F1 message because a handler was not registered is one of the most common and dangerous integration errors.

S7F3 / S7F4: Process Program Send (Recipe Download)

Stream 7 manages process programs (recipes). S7F3 is sent by the host to download a process program to the equipment. The message carries the process program ID (PPID) and the program body (PPBODY), which may be a structured SECS-II list or a binary blob depending on the equipment. S7F4 is the equipment acknowledgment with an accept/reject code. The complementary S7F5/S7F6 pair requests a process program upload from the equipment. Recipe management via Stream 7 is the backbone of run-to-run process control and is a prerequisite for connecting process programs to NeuroBox AI optimization workflows.

The GEM Equipment State Machine

One of GEM’s most important contributions is the standardized Control State model. Every GEM-compliant tool must implement the following states and transitions, giving host systems predictable control semantics regardless of equipment type.

The Communication State machine runs in parallel: equipment is either Communication Enabled (active SECS/GEM session established) or Communication Disabled (no session). The host cannot send process commands unless both the Communication State is Enabled and the Control State is On-Line/Remote. Integration code must always check both state machines before attempting to download recipes or initiate remote commands.

Equipment also implements a Processing State model specific to GEM: IDLE, EXECUTING, PAUSED, and variants. The current processing state is typically exposed as a Status Variable and included in Collection Event reports so the host always knows whether the tool is running product or waiting.

Data Variable Reports and Trace Data Collection

Configuring Collection Events and Reports is the most complex part of a SECS/GEM integration and the part most critical for AI and APC applications. The configuration workflow follows a specific sequence.

1. Query available SVIDs: Send S1F11 (Status Variable Namelist Request) with an empty list to retrieve all Status Variable IDs, names, units, and data types. This is your data dictionary.
2. Query available CEIDs: Send S2F29 (Equipment Constants Namelist Request) or consult the GEM compliance document to enumerate all Collection Event IDs and their names.
3. Define Reports: Send S2F33 (Define Report) to create RPTIDs that group SVIDs you want to collect. Each report is a named list of variable IDs.
4. Link Reports to Events: Send S2F35 (Link Event Reports) to associate RPTIDs with CEIDs. When the event fires, the linked reports are included in S6F11.
5. Enable Events: Send S2F37 (Enable/Disable Event Reports) to activate reporting for your selected CEIDs. By default, event reporting is typically disabled after power-on.

For time-sampled data independent of events, GEM’s optional Trace Data Collection capability (S2F23) allows the host to define sampling intervals and variable lists. Equipment will then send S6F1 (Trace Data Send) messages on the configured schedule. This is particularly valuable for capturing high-frequency sensor data — chamber pressure, RF power, gas flows — at rates of 1–10 Hz for AI model training and process fingerprinting.

Connecting Your First Tool: Python Code Example with MST’s Open-Source Driver

MST (迈烁集芯) maintains an open-source Python SECS/GEM driver at github.com/shensi8312/secsgem-driver that implements the full SECS-I, HSMS, SECS-II, GEM, and GEM300 stack. The following examples show how to connect to an equipment, handle events, and collect data using the MST driver’s clean three-line connection API.

Installation and Basic Connection

# Install the MST SECS/GEM driver
# pip install secsgem-driver

import secsgem

# Three-line connection setup — HSMS active mode (host initiates)
handler = secsgem.GemHostHandler("192.168.1.100", 5000)
handler.enable()
handler.waitfor_communicating(timeout=30)

# Confirm the tool is online with S1F1
response = handler.send_and_waitfor_response(
    secsgem.SecsS1F1()
)
print(f"Connected: MDLN={response.MDLN.get()}, SOFTREV={response.SOFTREV.get()}")

Querying All Status Variables

# S1F11: Request full status variable namelist
svid_list = handler.send_and_waitfor_response(
    secsgem.SecsS1F11([])  # empty list = all SVIDs
)

print("Available Status Variables:")
for sv in svid_list.SV:
    print(f"  SVID={sv.SVID.get():6d}  Name={sv.SVNAME.get():<40s}  Unit={sv.UNITS.get()}")

# S1F3: Read current values for specific SVIDs
current_values = handler.send_and_waitfor_response(
    secsgem.SecsS1F3([1001, 1002, 1003])  # chamber pressure, temp, flow
)
for item in current_values.SV:
    print(f"  Value: {item.get()}")

Setting Up Event-Driven Data Collection

# Step 1: Define a report grouping key process variables
handler.send_and_waitfor_response(
    secsgem.SecsS2F33([
        {"RPTID": 1, "VID": [1001, 1002, 1003, 1004, 1005]}
    ])
)

# Step 2: Link report to "Process End" collection event (CEID=200)
handler.send_and_waitfor_response(
    secsgem.SecsS2F35([
        {"CEID": 200, "RPTID": [1]}
    ])
)

# Step 3: Enable event reporting for CEID 200
handler.send_and_waitfor_response(
    secsgem.SecsS2F37(True, [200])
)

# Step 4: Register handler for incoming S6F11 event reports
def on_event_report(handler, packet):
    msg = secsgem.SecsS6F11.decode(packet.header, packet.data)
    ceid = msg.CEID.get()
    print(f"Event CEID={ceid} received")
    for rpt in msg.RPT:
        rptid = rpt.RPTID.get()
        for vid_value in rpt.V:
            print(f"  Report {rptid}: {vid_value.get()}")
    # Forward to NeuroBox AI pipeline
    push_to_neurobox(ceid, msg)

handler.register_callback("s6f11", on_event_report)

Alarm Handling

# Register S5F1 alarm handler — never skip this
def on_alarm(handler, packet):
    msg = secsgem.SecsS5F1.decode(packet.header, packet.data)
    alid   = msg.ALID.get()
    alcd   = msg.ALCD.get()
    altx   = msg.ALTX.get()
    is_set = bool(alcd & 0x80)   # bit 7: set=1, clear=0
    severity = alcd & 0x7F       # lower 7 bits: alarm category
    print(f"ALARM {'SET' if is_set else 'CLEAR'}: ID={alid}  [{severity}]  {altx}")
    # Route to MES alarm management
    mes_alarm_handler(alid, is_set, altx)

handler.register_callback("s5f1", on_alarm)

Common SECS/GEM Integration Mistakes

After integrating hundreds of tools across 200mm and 300mm fabs, the same errors appear repeatedly. Avoiding them saves weeks of debugging.

• Not handling S6F12 acknowledgment timing: Equipment requires an S6F12 reply within the T3 timeout (typically 45 seconds, but some tools use 10 seconds). If the host processing pipeline is slow, the equipment may declare a communication error and go offline. Always send S6F12 immediately upon receiving S6F11, before any downstream processing.
• Assuming CEID and SVID numbering is standard: GEM defines the capability; it does not standardize the actual IDs or names across vendors. Every tool has a different CEID for "wafer process complete." Always query the namelist (S1F11, S2F29) and read the GEM compliance document before hardcoding any ID.
• Forgetting to re-configure reports after equipment power cycle: Report and event link configurations (S2F33, S2F35, S2F37) are typically volatile — they reset to default (all events disabled) after power cycle. A robust integration detects the equipment re-establishing communication (S1F13/S1F14 handshake) and automatically re-sends the full configuration sequence.
• Sending S2F41 Remote Command without checking Control State: If the equipment is in On-Line/Local state, a Remote Command will be rejected. Always poll S1F3 for the control state SVID or subscribe to the Control State Change CEID before attempting remote commands.
• Ignoring block-level errors in SECS-I: Serial link noise causes block CRC failures. The SECS-I state machine requires specific RTY (retry) handling with T1 and T4 timers. Using a TCP/IP wrapper without proper SECS-I state machine implementation causes intermittent data corruption on legacy tools.
• Uploading recipes with the wrong PPBODY format: Some tools accept structured SECS-II lists for S7F3 PPBODY; others expect a raw ASCII or binary blob. Sending the wrong format results in a silent S7F4 reject with an opaque error code. Always test recipe round-trips (download S7F3, then upload S7F5) and compare byte-for-byte.

SECS/GEM vs OPC-UA for Semiconductor AI

As fabs build AI and digital twin platforms, engineers frequently debate whether to use SECS/GEM or OPC-UA (OPC Unified Architecture) as the equipment data backbone. The answer is not binary — understanding where each protocol excels shapes the right architecture.

The practical architecture for AI systems in fabs today uses SECS/GEM as the equipment-facing layer — because it is what every installed tool speaks — and bridges to a modern data platform via an adapter. MST's NeuroBox E3200 and E5200 platforms, for example, connect to equipment via the MST SECS/GEM Python driver, normalize the incoming S6F11 streams into a time-series feature store, and serve the processed data to AI inference engines over REST and MQTT. OPC-UA becomes relevant for new tool designs and for integration into enterprise IT systems that expect OPC-UA, but it cannot replace SECS/GEM for the installed base.

SEMI is working on SEMI E164 (SECS/GEM to OPC-UA mapping) to define standard translation semantics. When mature, this standard will allow a single equipment connection to serve both MES systems (via SECS/GEM semantics) and cloud AI platforms (via OPC-UA PubSub) without duplicating integration work.

SECS/GEM and MST NeuroBox: AI on Equipment Data

The value of SECS/GEM for AI lies in the richness of the data it delivers. A single etch tool running 24/7 generates millions of S6F11 data points per day — chamber pressure traces, RF forward/reflected power, gas flow rates, endpoint detection signals, wafer-level metrology values, and recipe parameter confirmations. This data is the raw material for virtual metrology, run-to-run control, predictive maintenance, and process optimization.

MST's NeuroBox E3200 (online AI for production lines) and NeuroBox E5200 (equipment qualification and Smart DOE) both use the open-source Python driver at github.com/shensi8312/secsgem-driver as their equipment connectivity layer. The driver handles all SECS-I, HSMS, and GEM state machine complexity, exposing a clean Python callback interface to the NeuroBox data pipeline. Engineers integrating new tools into NeuroBox typically write only 30–50 lines of configuration code — selecting which CEIDs to enable, which SVIDs to collect per event, and how to map equipment-specific IDs to the NeuroBox process variable schema.

For NeuroBox D, the AI design cloud platform that generates P&ID and 3D SolidWorks assemblies, SECS/GEM data from production tools provides the empirical process window information that grounds the AI design recommendations in real-world equipment behavior. A process designed in NeuroBox D inherits knowledge from thousands of hours of equipment data collected via SECS/GEM — closing the loop from design to production.

Summary and Next Steps

SECS/GEM is not a legacy protocol waiting to be replaced — it is the living nervous system of the global semiconductor manufacturing infrastructure. Every fab AI initiative, every MES integration, every APC deployment begins with a reliable SECS/GEM equipment connection. Understanding the three-layer architecture (SECS-I/HSMS + SECS-II + GEM), mastering the five core message types (S1F1, S2F13, S6F11, S5F1, S7F3), and correctly implementing the GEM state machine and event configuration workflow are the foundational skills for semiconductor automation engineers in 2025 and beyond.

The MST open-source driver at github.com/shensi8312/secsgem-driver provides a production-ready Python implementation covering SECS-I, HSMS, SECS-II, full GEM, and GEM300 extensions. It is the connectivity engine behind MST NeuroBox AI products and is available for community use and contribution. For engineers building AI systems on semiconductor equipment data, starting with a correct, complete SECS/GEM implementation is the difference between a reliable data pipeline and months of intermittent connection failures and missing data.

To learn more about how MST's NeuroBox platform uses SECS/GEM data for virtual metrology, run-to-run control, and process optimization in semiconductor fabs, visit ai-mst.com.