Semi E167.1

SEMI E167.1 specifies the SECS-II protocol binding for Equipment Energy Saving Mode communications — the actual message set that carries E167's energy-state model between equipment and host, following the same split this glossary has already seen between a GEM-based concept standard and its SECS-II transport companion, like E39/E39.1 for object services or E90/E90.1 for substrate tracking. E167 defines what energy-saving states exist and what a host can command and observe about them; E167.1 defines the specific SECS-II stream/function messages that actually carry those commands and observations over the wire.

E167 defines host-commandable energy-saving states and recovery-time reporting
The conceptual model: what states exist, what a host can know and command
What E167 alone doesn't specifyA state model isn't a wire protocol
No defined SECS-II stream/function messages
Without this, every vendor implements its own message encoding for the same states
SEMI E167.1 — SECS-II protocol for EESMThe specific messages a host actually sends and receives
Remote command messages to enter/exit energy-saving states
Collection-event and status-variable messages reporting state and recovery time
Any SECS-II-capable host can command and monitor EESM states on any compliant tool
No vendor-specific message translation layer required

A few things are worth knowing about why energy-saving communications needed this protocol-level companion standard in addition to E167 itself:

Every GEM-based concept standard in this glossary's SECS/GEM family eventually needs a wire-format companion, because SECS-II is the actual transport layer underneath all of them, and "SECS-II support" is never automatic just because a concept standard exists. E39 defined object services conceptually; E39.1 defined the SECS-II messages that carry object-service data. E90 defined substrate tracking conceptually; E90.1 defined its SECS-II messages. E167 follows the identical pattern: a host and a piece of equipment both understanding "the tool is in reduced-power state 2 with a four-minute recovery time" conceptually still can't exchange that fact without an agreed message format, and E167.1 is that message format for exactly this state model.

An Actual E167.1 Message Exchange, Message by Message the specific stream/function pairs that carry E167's states over the wire Host Equipment S2F41 RCMD=ENTER_EESM(tier=2) S2F42 HCACK=0, recovery=240s S6F11 CEID=EESM_ENTERED, SVID 9001=2 S1F3 request SVID 9001 S1F4 SVID 9001=2, remaining=112s S6F11 CEID=EESM_EXITED, SVID 9001=0 E167 says these states and recovery times exist E167.1 says exactly which SECS-II messages carry them, in what order

The reason this split pattern keeps appearing across the SECS/GEM family rather than every standard just folding its protocol binding into the concept document is that the two halves evolve on different timescales. A concept standard like E167 is relatively stable — the idea of host-commandable energy states with known recovery times isn't likely to need frequent revision. A protocol binding, especially one layered on something as mature as SECS-II, occasionally needs adjustment as message conventions get refined or as a newer transport (XML, SOAP, Protocol Buffers) gets added alongside the original SECS-II binding for the same concept — which is exactly the pattern seen elsewhere in this glossary with standards like E125/E125.1/E125.2 or E132/E132.1/E132.2, where one concept standard accumulates multiple protocol-binding companions over time as transport options expand.

E167.1's practical value is identical to every other SECS-II binding in this family: it's what lets a host integration engineer implement EESM support by reading one specification instead of reverse-engineering a vendor's interpretation of E167's concepts. Without E167.1, two equipment vendors could both claim EESM compliance while encoding the same energy state in incompatible SECS-II messages, forcing a host to maintain per-vendor translation logic — the exact integration cost every protocol-binding companion standard in the SECS/GEM family exists to eliminate.

Read E167.1 as the standard that makes E167 actually interoperable rather than merely well-specified: a concept as clean as host-commandable energy-saving states still produces vendor-fragmented implementations without an agreed SECS-II message format, and E167.1 is that agreement — the detail that turns "every vendor implements energy saving somehow" into "every vendor's energy-saving messages mean the same thing to any host that speaks SECS-II."

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