Semi E84
SEMI E84 is the standard that defines the physical, electrical handshake between an AMHS vehicle (an OHT shuttle or an automated guided vehicle) and a load port — a fixed set of parallel I/O signals, not a SECS message exchange, that lets the two sides agree in real time on exactly when it's safe to set a FOUP down or pick one up. It's the lowest, most literal layer of load-port automation: before any carrier ID is read or any slot map is checked, E84 is what keeps a vehicle from releasing a pod onto a port that isn't ready, or a port from thinking a pod has arrived before it's actually seated.
It's a hardware-level signal protocol specifically so it can be fast and deterministic — there's no room for a software message queue in a handoff happening hundreds of times an hour. Each signal line (VALID, CS_0/CS_1, TR_REQ, BUSY, COMPT, and others) is a discrete electrical state the vehicle and port toggle back and forth, with the full sequence completing in a small, fixed number of milliseconds. A SECS/GEM message exchange, by comparison, carries far more overhead than this handoff can tolerate at AMHS traffic volumes — which is exactly why E84 exists as its own parallel-I/O standard instead of just being folded into GEM.
E84 and E87 divide the work by speed, not by importance — fast physical confirmation first, slower identity and content verification second. E84 only ever answers "is it safe to move the pod right now," never "whose pod is this" or "what's actually inside it." Carrier ID reading, state tracking, and slot-map verification are explicitly E87's job, running over the regular SECS-II channel once E84 has confirmed physical placement. A load port with a solid E84 implementation but a broken E87 integration will physically accept and release every FOUP perfectly while the host remains completely blind to which lot is actually sitting on which port — which is why both standards get checked independently during tool bring-up, not treated as a single pass/fail test.
Signal timeout handling is where E84 implementations most commonly diverge between vendors, even though the standard itself is tightly specified. If BUSY stays asserted longer than expected, or COMPT never arrives, the vehicle and port both need a defined timeout-and-recovery behavior rather than hanging indefinitely — AMHS integrators spend real engineering time tuning these timeout values per tool type, because a value that's too short causes false aborts on a slightly slow port, and a value that's too long leaves a stuck vehicle blocking an entire transport lane.
SEMI E84 is easy to overlook because it never shows up in a SECS log or an MES trace — it operates entirely below that layer, on dedicated wires, which is exactly what makes it fast enough to support real AMHS traffic, and exactly why a transport-layer problem on the fab floor often turns out to be an E84 timing issue rather than anything in the software stack above it.