Semi E168.1
SEMI E168.1 applies E168's product-time measurement concept specifically to GEM300 production equipment — fixing exactly which GEM states and collection events mark the start and end of process time, queue time, and transport time on a 300 mm tool, rather than leaving E168's general queue/process/transport boundaries open to each tool's own interpretation of when a lot "starts" or "finishes" a step. E168 defines the three time categories conceptually; E168.1 is what says, concretely, that process time begins at the PROCESSING state transition and ends at the PROCESSING-COMPLETE collection event on a GEM300-compliant tool, so two different tool vendors measuring the same lot's cycle time actually agree on where one segment ends and the next begins.
A few things are worth knowing about why GEM300 needed its own time-boundary mapping rather than relying on E168 alone:
A conceptual boundary and an actual state-transition timestamp are two different things, and only the second one is computable from real equipment data. E168 can say "process time is the interval the tool is actively performing the process step" in prose, but a host summing up a lot's cycle time doesn't have access to "actively performing" as a concept — it has access to whatever GEM states and collection events the tool actually reports. If one vendor's tool enters its PROCESSING state slightly before the wafer physically starts being processed, and another vendor's tool enters it slightly after, "process time" silently means two different things across the two tools even though both claim E168 compliance. E168.1 removes that ambiguity by naming the specific state transitions and CEIDs that mark each boundary on a GEM300-compliant tool.
Fixing these boundaries specifically for GEM300 rather than for GEM in general matters because GEM300 equipment carries its own defined state model and AMHS integration points that a generic GEM statement can't assume exist. GEM300's state machine, its standardized interaction with E82/E88-style AMHS equipment, and its collection-event numbering conventions give E168.1 a concrete vocabulary to anchor E168's time categories to — the kind of concrete anchor E168.2 and E168.3 go on to provide for material-control systems and transport respectively, each one binding the same general time-measurement concept to the specific state model its equipment category actually runs.
This is the same pattern seen throughout the SECS/GEM family wherever one base concept standard needs a context-specific binding to become computable rather than merely descriptive — E139's recipe lifecycle needed E139.1's content schema before it could be validated, E142's mapping requirement needed E142.1's XML schema before a result could be parsed consistently. E168.1 plays that same role for product-time measurement: it's the piece that turns E168's category definitions into boundaries a host can actually extract from a real GEM300 tool's event stream.
Read E168.1 as the standard that makes E168's time categories something a host can compute, not just discuss: by naming the specific GEM300 state transitions and collection events that start and end queue, transport, and process time, it closes the ambiguity that would otherwise let two compliant tools report the same category under subtly different definitions, and gives a fab's cycle-time analytics a number it can actually trust to mean the same thing across its entire 300 mm fleet.