If your semiconductor equipment runs on a PLC or exposes data through OPC UA, you already have most of what a fab needs — the equipment just doesn’t “speak” the language a fab’s host system understands yet. That language is SECS/GEM, and getting there doesn’t have to mean rebuilding your control system from scratch.

This guide covers what SEMI compliance actually requires, why PLC-based equipment is often left out of that conversation, and how converting PLC and OPC UA to SECS/GEM through a protocol gateway lets OEMs meet fab requirements while keeping the control architecture they’ve already invested in.

What Does SEMI Compliance Mean for Semiconductor Equipment?

SEMI compliance refers to an equipment’s ability to meet the interface and communication standards defined by SEMI (Semiconductor Equipment and Materials International) — most notably SECS-I/HSMS and GEM (SEMI E4, E5, E30, E37, E40, E87, and related standards). These standards define how equipment reports status, alarms, recipes, and production data to a fab’s host system.

For a fab, SEMI compliance isn’t optional — it’s the baseline requirement for connecting new tools to MES, dispatching systems, and automated material handling. For an equipment OEM, it’s the difference between a tool that can be sold into a modern fab and one that can’t.

Compliance covers a defined set of behaviors:

  • Standard state models for equipment status (idle, running, down, etc.)
  • Event reporting for process starts, stops, and alarms
  • Remote command and recipe management from the host
  • Data collection aligned to SEMI E5 (GEM) and E30 (GEM300) where applicable

None of this is built into a typical PLC or OPC UA server out of the box — which is exactly where most equipment builders get stuck. A PLC can absolutely track machine states internally, and an OPC UA server can expose those states as readable nodes, but neither one natively formats that information into SECS-II messages or manages the handshaking a GEM host expects during startup, online/offline transitions, or remote command execution.

This is also where many OEMs underestimate the scope of the work. SEMI compliance isn’t a single feature to bolt on — it’s an ongoing communication contract between the equipment and the host, and it has to hold up reliably across every shift, every recipe change, and every alarm condition the tool encounters in production. For a deeper look at how these standards fit together, see our introduction to the SECS/GEM protocol.

Why PLC-Based Equipment Needs SECS/GEM

Most semiconductor process and metrology tools are still controlled by industrial PLCs — Siemens, Rockwell, Mitsubishi, Omron, and similar platforms. These controllers are excellent at real-time machine control, but they were never designed to natively communicate in SECS-II message formats or manage a GEM state model.

That gap creates a real business problem. A fab evaluating new equipment will typically ask, early in the process, whether the tool is SECS/GEM compliant. If the answer is no, the equipment either gets excluded from consideration or the OEM is forced into a costly, time-consuming control system redesign just to add compliance.

This is the core reason PLC to SECS/GEM integration has become a priority for OEMs: it lets the existing PLC continue doing what it does best — machine control — while a separate layer handles translation into fab-standard communication. Purpose-built solutions such as EIGEM-HMI for PLC and HMI-based equipment were designed specifically to solve this without touching the underlying control logic.

For OEMs with a large installed base, this matters even more. Many companies have dozens of equipment models running on different PLC generations and firmware versions, deployed across multiple fabs and customers worldwide. A full control system redesign for each of those variants isn’t just expensive — it’s operationally unrealistic. A gateway-based approach lets a single mapping methodology be applied consistently across an entire product line, rather than treating each tool as a one-off engineering project.

How OPC UA Connects Equipment Data

OPC UA (Open Platform Communications Unified Architecture) has become the standard for exposing equipment data in a structured, secure, and platform-independent way. Many newer tools already publish tags, alarms, and process variables through an OPC UA server as part of their standard architecture.

The advantage of OPC UA is that it gives external systems a clean, well-documented way to read and write equipment data without touching the PLC’s native protocol directly. That structure makes it a strong foundation for OPC UA to SECS/GEM conversion, because equipment data is already organized into addressable nodes rather than scattered across proprietary registers.

However, OPC UA on its own still isn’t SECS/GEM. A fab host doesn’t consume raw OPC UA nodes — it expects SECS-II messages structured according to GEM’s state model and event definitions. That translation is the next step.

How to Convert PLC/OPC UA Data to SECS/GEM

Converting PLC or OPC UA data into SECS/GEM communication generally follows the same core steps, regardless of the underlying control platform:

  1. Data mapping — Identify which PLC tags or OPC UA nodes correspond to GEM-required data: equipment state, alarms, process events, recipe parameters, and collection events.
  2. State model definition — Map the equipment’s operational states to the GEM state model so the host always has an accurate, standardized view of what the tool is doing.
  3. Event and alarm configuration — Define which PLC/OPC UA triggers become SECS/GEM collection events (CEIDs) and alarms, and how they’re reported to the host.
  4. Protocol translation — Convert the mapped data into properly formatted SECS-II messages over HSMS, without modifying the underlying PLC logic.
  5. Host communication and testing — Validate the interface against the fab’s host system or a GEM host simulator to confirm compliant, reliable communication.

Done manually, this process can take months of engineering effort and specialized SECS/GEM expertise most controls teams don’t have in-house. A purpose-built gateway compresses that timeline significantly by handling protocol translation as a configurable layer rather than custom-coded logic.

PLC/OPC UA to SECS/GEM Architecture

A typical architecture for this kind of integration looks like this:

PLC / OPC UA Server → Protocol Gateway (e.g., EIGEMLink) → SECS/GEM Interface → MES / Host System

  • The PLC or OPC UA server continues to handle real-time equipment control exactly as it does today.
  • The gateway sits between the equipment and the fab network, reading tags or OPC UA nodes and mapping them to GEM-compliant behavior.
  • The SECS/GEM interface manages the SECS-II/HSMS communication layer, state model, and event reporting.
  • The MES or host system receives standardized data and can issue commands, recipes, and requests back to the equipment through the same interface.

Because the gateway handles the translation layer, the equipment’s core control logic — the part that’s been tested, validated, and proven in production — stays untouched. This separation also makes long-term maintenance easier: if a fab’s host requirements change, or the equipment needs to support a new collection event, updates happen at the gateway configuration level instead of requiring a change to validated PLC code or re-certification of the control system.

Benefits of Using a Protocol Gateway

Bringing in a dedicated gateway rather than building SECS/GEM support from scratch has several practical advantages:

  • No control system redesign. The existing PLC program and OPC UA configuration remain in place, reducing risk and re-validation effort.
  • Faster time to compliance. Configuration-based mapping is typically much quicker than custom software development.
  • Lower engineering overhead. Teams don’t need to build and maintain SECS/GEM protocol expertise internally.
  • Easier standardization across a product line. A gateway approach can often be replicated across multiple tool models with adjusted mappings rather than separate custom builds.
  • Better alignment with fab expectations. Fabs increasingly look for GEM300-ready equipment (SEMI E30, E40, E87 where relevant), and a gateway makes that bar more practical to hit consistently.

EIGEMLink is built specifically to address this integration gap for PLC and OPC UA to SECS/GEM conversion. Rather than requiring OEMs to rework their control architecture, EIGEMLink acts as a configurable bridge that connects directly to existing PLC platforms and OPC UA servers, maps the required data points, and manages GEM state models, alarms, and collection events on the equipment’s behalf.

For controls and automation teams, this turns SEMI compliance into a configuration and integration project rather than a ground-up development effort — with SECS/GEM expertise built into the tool rather than something the internal team has to develop from scratch.

Explore how EIGEMLink fits your equipment architecture on the EIGEMLink product page.

Conclusion: Making Equipment Fab-Ready

SEMI compliance is quickly becoming table stakes for equipment sold into semiconductor fabs, but it doesn’t have to come at the cost of redesigning a control system that already works. Whether your equipment is built on a PLC, an OPC UA server, or both, a protocol gateway approach lets you bridge the gap to SECS/GEM without disrupting proven machine control logic.

For OEMs and automation teams evaluating their path to compliance, the fastest and lowest-risk route is usually not a rebuild — it’s a translation layer purpose-built for the job. eInnoSys has spent years solving exactly this problem for semiconductor equipment builders, and EIGEMLink reflects that experience in a single, configurable gateway.