SEMI Standards Guide: Understanding E4, E5, E30, E37, and E40 Equipment Communication Protocols

If you are a semiconductor equipment engineer, MES developer, or someone who just inherited a production line data collection project, you will inevitably face one fundamental question: how does the equipment talk to the factory system?

The answer lies in the SEMI standards. SEMI (Semiconductor Equipment and Materials International) has defined a comprehensive set of equipment communication specifications that give tools from different manufacturers a common “language” for interacting with MES, EAP, and data collection systems. Among these, E4, E5, E30, E37, and E40 are the most critical standard numbers — whether your fab runs 200 mm or 300 mm wafers, these standards are silently at work behind every tool on the floor.

This article covers each standard in a reference-style format. Bookmark it for future use.

1. The SEMI Standards Landscape: Where Do the E-Series Standards Fit?

The SEMI standards ecosystem is vast, covering virtually every aspect of semiconductor manufacturing. By technical domain, the major families include:

Within the SEMI ecosystem, the E-series (Equipment Automation) standards form the foundation for equipment-to-factory information system integration. From the lowest-level physical communication (serial/Ethernet) up through message formats, equipment behavior models, and batch management, the E-series defines the complete protocol stack for equipment automation. Put simply: without E-series standards, modern semiconductor factory automation would not exist.

2. Core Communication Standards Explained

We will walk through the standards bottom-up through the protocol stack: transport layer first, then message layer, then behavior layer.

2.1 SEMI E4 — SECS-I (Serial Transport Layer)

Full name: SEMI Equipment Communications Standard 1 — Message Transfer

E4 defines how SECS messages are transmitted between equipment and Host over an RS-232 serial interface, including baud rate, data frame format, handshaking (ENQ/EOT/ACK), and retry strategy.

This is the earliest SECS transport standard, dating to the 1980s. Equipment communication back then meant a single serial cable. SECS-I’s maximum transfer rate is only 9,600 bps, and messages must be broken into blocks for transmission — extremely inefficient by modern standards.

Current status: The vast majority of new equipment no longer uses SECS-I, but you may still encounter E4 devices on legacy 200 mm lines — particularly in older fabs in Japan and Korea. If you are doing equipment retrofit or data collection on such lines, you will need RS-232 serial converters and dedicated drivers.

2.2 SEMI E5 — SECS-II (Message Format Layer)

Full name: SEMI Equipment Communications Standard 2 — Message Content

If E4/E37 solve “how messages are transmitted,” E5 solves “what goes inside the messages.”

E5 defines the universal SECS message format using a Stream/Function structure:

• Stream (S): The functional category — like a module. For example, S1 = Equipment Status, S2 = Equipment Control, S6 = Data Collection, S7 = Recipe Management.
• Function (F): The specific function within that category. Odd numbers are requests (Primary); even numbers are replies. For example, S1F1 is “Are you there?” and S1F2 is “Yes, I am.”

E5 also defines the message body data type system:

Common Stream/Function pairs include: S1F13/S1F14 (Establish Communications), S2F41/S2F42 (Host Command Send), S6F11/S6F12 (Event Report Send), and S7F19/S7F20 (Recipe Directory List). E5 defines hundreds of S/F combinations covering every equipment communication scenario.

2.3 SEMI E37 — HSMS (TCP/IP Transport Layer)

Full name: High Speed SECS Message Services

HSMS is the TCP/IP replacement for E4 (SECS-I) and is the transport protocol used by the vast majority of semiconductor equipment today. It eliminates the speed, distance, and wiring limitations of serial communication.

Key HSMS characteristics:

• TCP/IP based: Standard Ethernet with transfer rates of 100 Mbps+, vastly exceeding SECS-I’s 9.6 Kbps
• Active/Passive modes: Communication partners must agree on who initiates the connection (Active) and who listens (Passive). Typically the Host is Active and the equipment is Passive — but this is configurable
• Session management: HSMS defines Select, Deselect, and Linktest control messages for establishing, maintaining, and closing communication sessions
• Single Session (HSMS-SS): Most equipment uses HSMS-SS mode — one TCP connection carries one SECS communication session

Critical configuration parameters include T3 (Reply Timeout, typically 45 seconds), T5 (Connection Separation Timeout, 10 seconds), T6 (Control Transaction Timeout, 5 seconds), T7 (Not Selected Timeout, 10 seconds), and T8 (Network Intercharacter Timeout). If your SECS communication frequently times out or disconnects, mismatched timer parameters are the most likely culprit.

2.4 SEMI E30 — GEM (Equipment Behavior Model)

Full name: Generic Equipment Model

If E5 defines “message format” and E37 defines “transport method,” then E30 defines “how the equipment must behave.” It is the most important and most central standard in the entire SECS/GEM ecosystem.

GEM specifies the behavioral capabilities equipment must implement:

• Communication State Model: Equipment communication states include DISABLED, ENABLED (with NOT COMMUNICATING and COMMUNICATING substates), defining the complete flow for establishing and terminating communications
• Control State Model: OFF-LINE, ON-LINE (LOCAL/REMOTE) — determines whether the Host can control the equipment
• Event Reporting: Equipment proactively reports events to the Host (via S6F11); the Host can dynamically configure which events to receive
• Alarm Management: Equipment sends alarms on exceptions (S5F1) and clears them on recovery (S5F1 with different ALCD)
• Variable Queries (Status Variables & Equipment Constants): Host can query equipment runtime parameters (SVs) and configuration constants (ECs)
• Remote Control: Host sends remote commands via S2F41 (e.g., START, STOP, PAUSE)
• Recipe Management: Upload/download/query equipment recipes (S7F series messages)
• Spooling: When communication is interrupted, equipment buffers messages and automatically resends them when connection is restored

GEM is the baseline capability that fabs require from equipment suppliers. If your equipment does not support GEM, it cannot enter any major wafer fab.

2.5 SEMI E40 — PJM (Process Job Management)

Full name: Standard for Processing Management

E40 addresses the question: “Which recipe should this lot of wafers run, and what is the current progress?” It defines Process Job lifecycle management:

• Create: Host tells the equipment: run this lot with Recipe A, Slots 1 through 25
• Start/Pause/Stop/Abort: Host can remotely control Process Job execution
• State tracking: Process Jobs have a complete state machine (QUEUED → SETTING UP → PROCESSING → PROCESS COMPLETE → …)

E40 is the foundation for MES dispatching. Without PJM, the MES cannot precisely control what the equipment runs or how it runs.

Core Standards at a Glance

3. Extended Standards for the 300 mm Era: GEM300

When the industry transitioned to 300 mm (12-inch) wafers, all wafers began moving in FOUPs (Front Opening Unified Pods), manual handling dropped dramatically, and automation requirements escalated sharply. The original GEM standard was no longer sufficient, so SEMI extended it with a group of standards collectively known as GEM300.

GEM300 does not replace GEM — it layers additional capabilities on top. GEM remains the foundation; GEM300 standards depend on GEM to function.

E116 (EDA/Interface A) deserves special mention. Traditional SECS/GEM data collection is limited to second-level sampling rates, but advanced node FDC (Fault Detection & Classification) and VM (Virtual Metrology) require millisecond or even higher frequency sensor data. E116 provides a high-speed data channel independent of SECS/GEM, using SOAP/XML protocols to capture thousands to tens of thousands of data points per second.

For equipment engineers working in 300 mm fabs: GEM is mandatory; GEM300 is standard. If your equipment needs to enter TSMC, Samsung, or Intel production lines, passing GEM300 compliance testing is a non-negotiable requirement.

4. Practical Implementation: Getting SECS/GEM Communication Running

Now that you understand the standards framework, here are the implementation paths available:

4.1 Commercial Solutions

Leading commercial SECS/GEM SDKs include:

• Cimetrix CIMConnect/CIM300: The industry’s most mature solution, supporting the full GEM + GEM300 standard suite with .NET and C++ SDKs. Premium pricing — per-equipment licenses range from several thousand to tens of thousands of dollars.
• Brooks Automation (now Azenta): Similar commercial SDK with strong market presence in Japan.
• Peer Group: Provides SECS/GEM simulators and testing tools, highly regarded for standards compliance testing.

Commercial solutions offer proven stability, vendor support, and certified compliance. The downsides are high cost and limited customization flexibility. For large equipment OEMs, commercial SDKs are the go-to choice. For small teams or R&D prototyping, the cost barrier can be prohibitive.

4.2 Open Source: secsgem-driver

If you want to quickly validate SECS/GEM communication, build a data collection prototype, or work within a limited budget, open source is an excellent starting point.

We have open-sourced a Python-based SECS/GEM driver — secsgem-driver — supporting HSMS (E37) transport and SECS-II (E5) message parsing, covering the core GEM (E30) capabilities. A few lines of code connect your application to the equipment:

from secsgem_driver import HsmsConnection

# Connect to equipment (Active mode, targeting port 5000)
conn = HsmsConnection(address="192.168.1.100", port=5000, active=True)
conn.connect()

# Send S1F13 to establish communication
reply = conn.send_and_receive("S1F13", [])
print(f"Equipment reply: {reply}")

# Query status variables
sv_reply = conn.send_and_receive("S1F3", [1001, 1002, 1003])
print(f"Equipment status: {sv_reply}")

For detailed documentation and source code, see our guide: Open Source SECS/GEM Python Driver: secsgem-driver User Guide.

The open source driver is ideal for rapid prototyping, data collection POCs, and internal equipment debugging. For production-grade equipment shipments, we recommend using a solution that has passed full compliance testing.

5. Beyond the Protocol: From Data Collection to AI Intelligence

SECS/GEM solves the “how does the equipment talk” problem — enabling status reporting, event notification, and command reception. But what happens after you have the data?

The real value lies in using data to drive decisions. This is the central challenge of smart semiconductor manufacturing:

• VM (Virtual Metrology): Predicting process outcomes from equipment operating parameters, reducing physical metrology frequency and saving hundreds of thousands of dollars in metrology tool time
• R2R (Run-to-Run Control): Automatically fine-tuning recipe parameters based on previous batch results, continuously driving the process toward its optimal point
• FDC (Fault Detection & Classification): Real-time monitoring of equipment sensor data to trigger alerts at the first sign of anomaly, preventing batch scrap

The complete technology chain from communication protocol to AI application looks like this:

Every link in this chain is non-trivial. SECS/GEM must handle dozens of message types. Data collection must manage millisecond-frequency streaming data. Feature engineering requires deep process domain knowledge. AI inference must run at the edge in real time (latency budget typically under 100 ms). And control feedback must be safe and reliable.

This is exactly why we built NeuroBox E3200 — to encapsulate this entire chain in a single edge AI platform:

• Built-in SECS/GEM communication engine: Supports HSMS + GEM out of the box — plug and play, no custom communication layer development needed
• High-frequency data collection: Supports EDA/Interface A level sampling rates
• Edge AI inference: VM, R2R, and FDC models run locally in real time; data never leaves the factory
• Equipment-side deployment: Installed directly alongside the tool, minimizing communication latency for real-time control

For equipment manufacturers who have already implemented SECS/GEM communication, AI-driven intelligence is just the “last mile” away — and NeuroBox E3200 can help you get there.

SEMI E-Series Standards Quick Reference

Related Reading

• SECS/GEM Protocol Introduction: Your First Lesson in Semiconductor Equipment Communication
• Open Source SECS/GEM Python Driver: secsgem-driver User Guide
• GEM300 Standards Explained: The Complete 300mm Equipment Automation Specification