SECS/GEM in 2026: Semiconductor Equipment Integration for Malaysia and Singapore

For semiconductor equipment, the host interface is part of the machine. It should not be treated as a small software add-on after the PLC, motion, HMI and process sequence are already finished.

That matters more now because Malaysia and Singapore are both adding semiconductor manufacturing and equipment capacity. Malaysia’s latest investment data shows a clear move towards front-end semiconductor design, equipment and higher-value manufacturing. In Penang, MKS opened its new Supercenter Factory in June 2026 to support wafer-fabrication equipment, while AIXTRON is building a new manufacturing and engineering facility for deposition equipment. Singapore is expanding on the other side of the same ecosystem: Applied Materials opened a S$600 million Tampines campus in June 2026, and Micron has started a roughly S$31 billion, 10-year wafer-fab expansion.

As more tools are built, localised, retrofitted and supported in this region, SECS/GEM integration becomes an engineering capability rather than an obscure protocol requirement. For machine builders selling into semiconductor plants, it can determine whether a tool is easy to qualify or painful to integrate.

SECS/GEM is not the machine control system

The terminology is confusing until the layers are separated.

Layer	What it does	Typical implementation
Machine control	Motion, I/O, interlocks, sequencing, process control	PLC, industrial PC, motion controller, embedded controller
SECS-II	Defines message content exchanged between equipment and host	SEMI E5
HSMS	Moves SECS messages over TCP/IP	SEMI E37 / HSMS-SS
GEM	Defines standard equipment behaviour seen by the factory host	SEMI E30
Factory host	Dispatching, tracking, recipes, production control, data collection	EAP, MES, factory automation system

The machine may use EtherCAT, PROFINET, EtherNet/IP, CAN, CAN FD, Modbus or proprietary embedded links internally. None of that has to disappear. SECS/GEM normally sits above the control layer and exposes a controlled, documented view of the equipment to the factory host.

In simple terms:

MES / EAP / Factory Host
          |
      HSMS over TCP/IP
          |
      SECS-II messages
          |
      GEM behaviour
          |
Equipment control PC / software
          |
 PLC / motion / I/O / embedded devices

I would keep hard real-time control, safety and machine sequencing in the machine. The host should request, supervise and collect; it should not become a remote PLC.

The standards are still being actively maintained

SECS/GEM is old enough to be mature, but it is not abandoned technology. SEMI currently lists SEMI E30-0526 as the current GEM revision. SECS-II is currently SEMI E5-0725, while the main HSMS generic-services standard remains SEMI E37-0222. Two important GEM300 standards, SEMI E87 for carrier management and SEMI E90 for substrate tracking, both have current July 2026 revisions.

That is worth noting because semiconductor factories do not want every equipment supplier inventing a different remote-control interface. The value of GEM is predictability: common communication states, control states, alarms, events, variables, recipes and remote commands that the host can handle consistently.

Do not bolt the GEM interface on at the end

The difficult part is rarely opening a TCP socket or encoding a SECS-II list. The difficult part is deciding what the machine means.

If I were designing a new tool, I would define the GEM interface while the machine state model is still being designed. At minimum, the equipment team should settle these items early:

equipment states: what states actually matter to the host, and how they relate to the PLC or software state machine;
collection events: which transitions or process milestones should generate event reports;
status variables: what the host may read at any time;
data variables: what belongs with a specific event report;
equipment constants: what configuration may be read or changed remotely;
alarms: which conditions are true equipment alarms rather than every PLC diagnostic bit;
remote commands: exactly what the host is allowed to request and under which machine conditions;
process programmes or recipes: ownership, versioning, checksum strategy and transfer rules;
trace data: what needs high-rate sampling, how long it is retained and how much traffic the host should receive.

If these are decided only during customer FAT, the software team ends up mapping an already-finished machine into a host model that does not quite fit. That usually produces brittle event logic, duplicated alarms and confusing state transitions.

Event design matters more than having thousands of tags

Industrial software teams are used to exposing tags. GEM is more disciplined than that.

A factory host does not need every internal variable every second. It needs the right data at the right process event. For example, when a wafer or carrier changes state, the host may need the current recipe, lot identification, chamber, result code, measured values and timestamp as one coherent report.

I would avoid three common patterns:

polling large groups of variables because the event model was never designed;
sending hundreds of low-value events that force the host to reconstruct the process sequence afterwards;
using internal PLC addresses as the permanent external data model.

The external interface should survive PLC software refactoring. A host should care that the equipment entered a process state or completed a substrate step, not that internal tag DB204.DBX16.3 changed from zero to one.

GEM300 adds the automation needed around 300 mm production

For 300 mm fabs, basic GEM is only the starting point. SEMI’s GEM300 family standardises additional behaviour that highly automated plants depend on.

SEMI E40 — Processing Management: process-job and recipe-related execution behaviour.
SEMI E87 — Carrier Management: carrier identification, placement and transfer behaviour.
SEMI E90 — Substrate Tracking: tracking wafers or other substrates as they move through equipment.
SEMI E94 — Control Job Management: coordinating carrier-based processing and production jobs.
SEMI E84: parallel I/O handshaking used for automated carrier handoff with material-handling systems.

Which standards are required depends on the equipment class and the fab specification. A wafer prober, deposition tool, handler, metrology station and back-end machine do not all expose the same behaviour. The customer equipment-interface specification remains the controlling document.

OPC UA can coexist with SECS/GEM

There is sometimes an assumption that OPC UA should replace older semiconductor protocols. I would not approach it that way.

OPC UA is useful for plant integration, edge systems, historians, analytics and brownfield data exchange. CANS already uses that pattern in industrial automation and SCADA integration, and we have discussed OPC DA to OPC UA modernisation for conventional plants.

But if a semiconductor fab’s equipment specification requires SECS/GEM, providing only OPC UA does not satisfy the requirement. The two interfaces can serve different jobs:

SECS/GEM for the formal equipment-to-factory host contract;
OPC UA or MQTT for selected engineering, maintenance, analytics or cross-system data;
industrial Ethernet or fieldbus for machine-level control;
an integration layer for ERP, MES, WMS, quality and maintenance systems.

For the operations layer, CANS’ MES integration work and CANiS Integration Server cover the broader problem of moving production data between machines and business systems without forcing every system to speak the same protocol.

Build the interface document together with the software

A working SECS/GEM implementation without a good interface document is still difficult to integrate.

The equipment supplier should maintain a clear data dictionary covering event IDs, report structure, variable IDs, alarm IDs, remote commands, equipment constants, state models and supported message behaviour. SEMI E172 defines a SECS Equipment Data Dictionary format specifically to make this information easier for both people and software to consume.

This is one place where discipline pays off. When firmware or PLC logic changes, the external IDs should not casually move. When a new alarm is added, the documentation should be updated at the same time. When a recipe parameter changes units or range, the host contract needs to remain explicit.

Test the host behaviour before the customer does

Protocol connectivity is only the first test. A proper FAT should exercise the machine through realistic host scenarios.

Drop and restore the HSMS connection.
Verify COMMUNICATING / NOT COMMUNICATING behaviour.
Exercise ONLINE, OFFLINE, LOCAL and REMOTE transitions.
Trigger every important alarm and confirm clear/set behaviour.
Run process start, abort, pause, recovery and completion paths.
Test invalid remote commands and commands issued in the wrong machine state.
Transfer recipes and verify version or checksum handling.
Run event-report and trace-data loading long enough to expose queueing or timing issues.
Restart the equipment software and confirm state recovery.
Confirm timestamps, units, data types and identifier stability against the interface document.

I would use a host simulator well before connecting to the customer’s MES or EAP. The first live host session should be validation, not software development.

Keep cybersecurity outside the process-control loop but inside the design

HSMS normally rides on TCP/IP, so it inherits the normal problems of an Ethernet-connected industrial system. That does not mean inserting cloud security software into the tool controller. It means engineering the boundary properly.

Use plant segmentation, explicit host addressing, firewall rules, controlled service access, account separation, patch planning, time synchronisation and logging. Remote service paths should be separated from the production host interface. If the equipment PC also exposes OPC UA, web diagnostics or vendor VPN access, those services need to be treated as separate attack surfaces rather than assumed safe because the GEM link works.

CANS’ automation and embedded-systems capability is relevant here because the interface crosses both worlds: machine software and controls on one side, factory IT/OT integration on the other.

Malaysia’s semiconductor shift makes this a local engineering skill

MIDA reported RM51.3 billion of approved manufacturing investment in the first half of 2026 and highlighted an 88.2% increase in manufacturing project numbers, together with a shift in semiconductor activity towards front-end design and equipment. Recent Malaysian projects include MKS wafer-fab equipment, AIXTRON deposition-equipment manufacturing, UWC front-end equipment modules and Pentamaster’s AI-enabled automation platform.

That changes the local engineering mix. It is no longer only about operating imported tools. More companies are building modules, automation, test systems, instruments and semiconductor equipment locally, then supporting regional and global customers.

For those machine builders, a clean SECS/GEM implementation is part of making the equipment exportable. A mechanically sound tool with excellent process performance can still create months of integration work if its host interface is undocumented or inconsistent.

Start with the equipment behaviour, not the protocol library

There are commercial libraries and open-source stacks that can save time on HSMS and SECS-II encoding. Use them where they make sense. I would spend more engineering effort on the equipment model: states, events, alarms, recipes, material tracking and recovery behaviour.

If those are well designed, the protocol layer becomes manageable. If those are vague, a perfect SECS-II library only moves vague data more reliably.

CANS can support semiconductor equipment builders and factories with machine-control integration, embedded interfaces, SECS/GEM host/equipment integration, MES connectivity and brownfield OT integration in Malaysia and Singapore. Send CANS an engineering enquiry or contact CANS on WhatsApp.

Featured image: Aileen Devlin / Jefferson Lab, via Wikimedia Commons. Public-domain image.