Semi E153

SEMI E153 defines the AMHS Specific Equipment Model (AMHS SEM) — the GEM-based state and event model for the transport and buffering equipment that sits outside the two categories a 300 mm fab's material-handling system had already standardized: E82's Interbay/Intrabay Specific Equipment Model (IBSEM) for the vehicles and track, and E88's Stocker Specific Equipment Model for the storage buffer itself. At a high level, a lot's physical path through the fab looks like this:

FOUP exits a stocker port
E88 Stocker SEM already covers slot state and retrieval
The gap E153 closesEquipment between the two already-standardized layers
Lifter
Moves carrier between fab levels
Sorter / buffer
Re-sequences carriers mid-route
Conveyor segment
Short fixed-path carrier transfer
Vehicle picks up on interbay/intrabay track
E82 IBSEM already covers vehicle motion state
Delivered to tool load port
End of the transport chain the host must track end to end

A few things are worth knowing about why this particular standard had to exist, and why it couldn't simply be absorbed into E82 or E88:

The gap wasn't theoretical — it was every lifter and sorter a host already had to talk to. By the time SEMI finished E82 and E88, a 300 mm AMHS had standardized host communication for its two largest equipment populations, vehicles and stockers, but a real fab's transport chain is longer than that. A FOUP routed from a stocker on one floor to a tool on another typically passes through at least one lifter, and a high-mix fab with crossing interbay loops often routes carriers through sorting or buffering equipment to resolve traffic before they reach a vehicle. None of that hardware was a vehicle in E82's sense or a stocker in E88's sense, so every supplier building it had been exposing its own status and event interface, and every host integration against that hardware was a one-off.

A lifter's defining state isn't a position on a track, and it isn't a slot map. E82's IBSEM models a vehicle's behavior around where it is and where it's going along a fixed guideway — motion state is the center of that model. E88's Stocker SEM models a storage buffer around which physical slot holds which carrier — occupancy state is the center of that model. A lifter's actual behavior center is neither: it's which transport tier it's currently connected to, whether a handoff into or out of it is in progress, and what carrier it's holding mid-transfer. Trying to describe that with IBSEM's vehicle-motion vocabulary or Stocker SEM's slot-occupancy vocabulary would have forced an awkward fit in both directions — which is the concrete reason AMHS SEM needed to be its own GEM-based model rather than an extension bolted onto either existing standard.

SEMI E153 — The Transport Chain's Missing Middle a FOUP's path crosses three different equipment models before it reaches a tool Stocker E88 Stocker SEM model center: slot occupancy Lifter E153 AMHS SEM carrier model center: tier + handoff-in-progress Sorter / buffer E153 AMHS SEM model center: route re-sequencing state Vehicle / track E82 IBSEM model center: position / motion three distinct behavior centers along one physical carrier path — slot occupancy, tier/handoff state, and motion state E153 gives the middle one a standard GEM-based model instead of leaving it to vendor-specific interfaces Before E153: host needed a bespoke integration for every lifter and sorter vendor After E153: one GEM-based vocabulary spans stocker → lifter/sorter → vehicle

AMHS SEM reuses the same host-facing conventions E82 and E88 already established, which is the whole point. The model exposes equipment states and collection events to the host in GEM's familiar vocabulary — the same state-transition and event-reporting pattern a host integration engineer already knows from Stocker SEM and IBSEM — so adding this third equipment category doesn't mean learning a fourth communication philosophy. A host system written to consume E82 and E88 data can extend to E153-compliant lifters and sorters without a structurally different code path, only a different equipment-specific state table.

The economic argument is the same one that justified E82 and E88 in the first place. Every AMHS equipment category left without a standard model is a category where the host side of every fab's automation software carries vendor-specific code that has to be rewritten whenever that fab swaps suppliers, and where a supplier's new lifter or sorter design has to be integrated from scratch rather than slotting into an existing host framework. E153 removes that cost for the equipment category that happened to be the last major piece of the AMHS transport chain still running on ad hoc interfaces.

Read E153 as the piece that makes a 300 mm fab's AMHS fully standardized end to end, not as a standalone equipment spec: by giving lifters, sorters, and conveyors the same GEM-based treatment E82 gave vehicles and E88 gave stockers, it means a host system can finally track a carrier's entire physical path — storage, transfer, and transport — through one consistent model instead of three incompatible ones stitched together at the integration layer.

Take SEMI E153 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app