Semi E167

SEMI E167 specifies Equipment Energy Saving Mode communications (EESM) — a GEM-based state and event model that lets a host command a piece of equipment into a reduced-power state during idle periods and bring it back to production readiness on demand, rather than leaving every tool's power-saving behavior as an undocumented, vendor-specific firmware feature invisible to the fab's own scheduling and energy-management systems. A fab's equipment inventory spends a meaningful fraction of its time idle between lots, and EESM exists because idle time with no standardized power-down path is wasted energy that a host has no way to recover.

Equipment sits idle between lots with no standardized low-power path
Vendor-specific power-saving firmware, invisible to host scheduling
SEMI E167 — Equipment Energy Saving ModeGEM-based states a host can command and query, the same way it already commands process states
Host-commandable energy-saving states
Idle, standby, and reduced-power tiers, each with a defined recovery path
Standardized recovery-time reporting per state
Host knows exactly how long a return to production readiness takes
A scheduling system commands energy savings during predictable idle windows without risking a late tool on the next lot
Power management becomes a scheduling input instead of a hidden firmware behavior

A few things are worth knowing about why energy-saving behavior needed its own host-facing communication standard rather than being left to equipment firmware:

A power-saving mode that the host can't see or control is worth less to a fab than one it can schedule around, because the real cost of any low-power state is the recovery time it takes to leave it. A tool sitting in an undocumented vendor power-saving mode might save energy, but if a scheduling system doesn't know the tool is in that state or how long recovery takes, it risks dispatching a lot to a tool that isn't actually ready, turning an energy saving into a throughput loss. EESM's actual contribution isn't the idea of saving power during idle time — most equipment could already do that at the firmware level — it's making the state and its recovery time visible and commandable through the same GEM vocabulary a host already uses for every other equipment state, so energy management becomes something a scheduling algorithm can optimize against instead of something that happens invisibly and might collide with the next dispatched lot.

A Tool's Power Curve, With and Without EESM the cost of any power-saving state is the recovery time nobody told the scheduler about power time — lot A finishes, idle gap, lot B arrives no EESM: full power idle Lot A processing EESM reduced-power state — recovery time known: 4 min Lot B processing recovery Without EESM: full power the entire idle gap, nothing to schedule against With EESM: power drops during idle, climbs back in time for Lot B — on a known clock

EESM's design choice to reuse GEM's existing state/event model rather than invent a separate power-management protocol is the same interoperability discipline this glossary keeps finding across SEMI's host-communication standards. A host integration already built to read E90's substrate-tracking events or E53's collection events doesn't need a structurally new subsystem to also read EESM's energy-state events — it's the same event-reporting channel, just carrying a different category of state. That reuse is what makes it practical for a fab to add energy-aware dispatch logic to an existing MES without a parallel integration project.

E167 is also a direct answer to the same cost pressure E124's Overall Factory Efficiency metric already made visible at the factory level. OFE treats energy consumption as one of the factors limiting a factory's effective output per unit cost, but a metric alone doesn't reduce energy use — it just measures the problem. EESM is the operational mechanism that actually lets a fab act on that measurement, turning "our OFE number reflects high idle-energy cost" into something a scheduling system can directly address by commanding verified-safe power-down windows.

Read E167 as the standard that converts energy-saving mode from a hidden equipment feature into a managed fab resource: by giving idle-time power-down states the same host-visible, host-commandable treatment every other equipment state already gets under GEM, it lets a fab actually schedule around energy savings instead of either ignoring the feature entirely or trusting an opaque firmware behavior not to collide with the next lot's dispatch.

Take SEMI E167 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