SEMI E84 in practice : What the standard defines, and what integration teams must solve
PART OF A SERIES ● ● ● ● ● ● 1 / 6
SEMI E84 in Practice: The Complete Engineer's Guide to AMHS Carrier Handoff
From protocol basics to integration decisions — what every OEM and fab engineer needs to know before they start.
By Grégory SAINT LOUIS AUGUSTIN - Marketing & Business Development Manager | Focussia
This series draws from direct experience across OEM and FAB deployments — from conversations with automation engineers, equipment architects, and fab integration teams. Developed in close collaboration with Focussia's engineering and management team.
Francis ROMANO, CTO & Grégory s.L.A , Marketing & Business D. Manager | Focussia
In a modern semiconductor fab, thousands of carrier transfers happen every day without a single human touch. An AMHS vehicle arrives at a load port, a FOUP is placed or retrieved, and production continues. Behind every one of those transfers, governing the precise moment of handoff, is SEMI E84. Sixteen signals — eight in, eight out. A handful of timing sequences. A physical interface that has remained fundamentally stable for decades. The protocol is not complex. What surrounds it is.
"The protocol is not complex. What surrounds it is."
The E84 protocol surfaces differently depending on who you are and where you sit in the supply chain, but the underlying dynamic tends to be the same. A fab extends its AMHS, and tools that have been running reliably for years suddenly need to comply with an interface they were never designed for. An OEM receives a customer qualification requirement mid-development, with the architecture already frozen. A team handling E84 for the first time quickly learns that writing a compliant implementation is one thing — making it hold under real AMHS conditions, across different vehicle types and fab configurations, and maintaining it as requirements evolve, is a different scope entirely.
In each case, the challenge is less about technical capability than about how the work gets scoped, resourced, and timed. E84 is niche enough that it rarely has a natural owner. Because it requires real depth, the gap between expectation and reality tends to be significant. That gap is where delays begin.
The protocol does not create the problem. The circumstances do — timing, internal capacity, and the cost of solving under constraint what could have been solved by design.
What follows is a practical guide to SEMI E84: how it works, where it fits in the broader automation stack, and what integration decisions actually look like across OEM and FAB contexts. Whether you are starting from scratch, working within constraints, or re-evaluating something already in production, the goal is the same — give you enough clarity to make the right call at the right moment.
What is SEMI E84, and why does it exist?
An OHT vehicle traveling on overhead rails in a semiconductor fab — every carrier transfer is governed by SEMI E84.
Think of E84 as the protocol that secures automated material transfers in semiconductor fabs. The moment an AMHS vehicle arrives at your tool, E84 is what governs that moment — identifying which port the vehicle is addressing, confirming whether it is ready to receive or remove a carrier, verifying the previous one is properly clamped and cleared, and managing what happens if any of that is not right. Its core purpose is simple: ensure every handoff between a vehicle and a load port happens safely, reliably, and in the right sequence.
SEMI E84 has a precise scope, and that precision is also what keeps it below the radar until it becomes a project constraint.
The standard defines the handshake between active equipment (an AMHS vehicle: OHT, AGV, or AMR) and passive equipment (a tool's load port). In most AMHS configurations, the vehicle initiates and drives the physical transfer. Some equipment — notably certain stocker systems — operates with its own transfer mechanism, inverting the active and passive roles. Its job is narrow by design: coordinate the physical transfer of a carrier through a defined sequence of electrical signals via an I/O interface, ensure both sides agree on timing and readiness, and provide a structured response when something goes wrong. That is all it does. It does not manage carrier identification, process recipes, factory scheduling, or host communication. Those responsibilities belong to other layers of the SEMI stack — E87 for carrier management, SECS/GEM for host-equipment communication.
That separation matters in practice. The factory host is not part of the E84 handshake. The sequence runs directly between the vehicle and the load port, executed autonomously at the hardware level. A tool with a fully compliant SECS/GEM implementation can still have no E84 capability. The two layers coexist but do not overlap. Which means E84 requires its own explicit integration decision — independent of everything else in the stack.
E84 requires its own explicit integration decision — independent of everything else in the stack.
E84 was first published in 1999, developed in the context of the semiconductor industry's transition to 300mm production. While it is often discussed alongside the GEM300 standards — and required in the same automation contexts — it is technically a standalone standard. It governs a separate I/O interface, completely independent of GEM and SECS/GEM. Its predecessor, E23, managed carrier transfers for 200mm environments but without safety management, without timeouts, without HO_AVBL, and without simultaneous or continuous handoff modes. E84 extended that foundation with all of these — making it significantly more robust for high-throughput automated environments. The physical interface — a DB25 connector paired with transceivers, either infrared (IR) or radio frequency (RF) depending on the installation — has remained stable across revisions. What has evolved is the precision of the sequencing requirements and the error handling logic.
Knowing the protocol is not the hardest part. Understanding how to place it in your architecture is what can make the difference between a smooth integration and a constrained one.
Where E84 sits in the SEMI stack
Understanding where E84 sits relative to the other standards is what prevents the most common integration mistakes.
The diagram below shows the key layers that govern automation in a semiconductor fab — on the equipment side and on the AMHS side. Each layer has a defined scope. They do not replace each other.
How the SEMI automation stack is organized — and where E84 fits.
At the top, the fab host: MES, EAP, or automation system — orchestrates production across both sides: scheduling, recipes, carrier routing, equipment states. It communicates with tools through SECS/GEM (E30), the software layer that defines how equipment reports alarms, events, and process data to the factory.
On the AMHS side, the vehicle fleet is managed by a Fleet Management system — the operational equivalent of SECS/GEM for the transport layer. It handles vehicle dispatch, routing, and coordination with the fab host. It is the system that decides which vehicle goes to which load port to do what. That decision happens above E84 — not within it.
E87 manages carrier identity and state at the load port level, tracking which FOUP is where, whether it has been verified, and coordinating carrier transfers with the host through the SECS/GEM channel. When both E84 and E87 are implemented, they draw from the same source — the load port itself, which provides carrier state information to both layers independently. The Auto/Manual mode can in some configurations be coordinated through E87, when both standards are implemented and the architecture supports it.
E84 operates at the hardware level, independently of the host. When an AMHS vehicle arrives at the load port, the handshake runs directly between the vehicle and the tool via transceivers — infrared or radio frequency. The MES does not intervene. SECS/GEM does not intervene. The sequence is autonomous, deterministic, and hardware-level.
A tool can be fully compliant with SECS/GEM and E87, and still have no E84 implementation. E84 must be explicitly implemented, independently of everything else in the stack.
Frequently Asked Questions
What is SEMI E84?
SEMI E84 is a standalone standard that defines the I/O handshake between AMHS vehicles and semiconductor equipment load ports. Its core purpose is to secure automated carrier transfers — ensuring every handoff happens safely, reliably, and in the correct sequence.
What is the difference between SEMI E84 and SECS/GEM?
SEMI E84 and SECS/GEM operate at different layers and serve different functions. SECS/GEM manages host-equipment software communication — alarms, events, recipes, process data. E84 governs the physical carrier handoff between an AMHS vehicle and a load port, autonomously and independently of the host. A tool can be fully SECS/GEM compliant with no E84 implementation.
Does SEMI E84 belong to the GEM300 standards suite?
E84 is often discussed alongside GEM300 and required in the same automation contexts, but it is technically a standalone standard. It governs a separate I/O interface, completely independent of GEM and SECS/GEM. E84 was published in 1999 as its own specification — distinct from the GEM-based standards like E87, E90, or E94.
What is the difference between SEMI E84 and SEMI E23?
E23 was the predecessor standard for 200mm cassette-based carrier transfers. E84 extended it with safety management, defined timeouts, HO_AVBL signaling, and support for simultaneous and continuous handoff modes — making it suitable for high-throughput automated environments.
Why does SEMI E84 need to be implemented independently?
Because E84 operates at the hardware level, independently of the host communication stack. Neither SECS/GEM nor E87 triggers E84 automatically. It requires an explicit integration decision — separate from everything else in the automation stack.
Recent Comments