Semi E168
SEMI E168 specifies Product-Time Measurement — a standardized definition for how to measure the time a product actually spends being processed, as distinct from the many other time categories a fab already tracks, like E10's equipment reliability/availability/maintainability intervals or E79's equipment-productivity metrics. A fab has no shortage of time-based metrics, but most of them describe the equipment's state, not the product's experience moving through the fab, and E168 exists because "how long did this lot actually take, start to finish" turns out to need its own careful definition once you account for queue time, transport time, and the equipment states E10 already measures.
A few things are worth knowing about why product time needed its own definition apart from the equipment-centric metrics a fab already had:
A tool can be 95% utilized by E79's definition while the product moving through it experiences a cycle time nowhere close to what that utilization number would suggest, because utilization measures the equipment's schedule, not the product's path. A lot can sit in a queue in front of a highly utilized tool for hours before it ever starts processing — the tool's utilization metric looks excellent the entire time, but the product's actual experience includes all of that queue time the equipment-centric number never captures. E168 exists because a fab optimizing purely against E10 and E79's equipment metrics can still have a cycle-time problem that neither metric would ever surface, since both were built to describe the equipment, not the thing moving through it.
E168's definition is what makes a decomposed cycle-time analysis possible at all, which is the actual payoff a fab gets from adopting it. Without a standard split between queue time, process time, and transport time, "cycle time is too long" is a single undifferentiated number that offers no clue where to intervene — add capacity, reduce dispatch delay, improve AMHS routing speed, or something else entirely. With E168's standardized boundaries, a fab can attribute a cycle-time problem to the specific segment causing it, the same way E157's module-level tracking turns a tool-level yield excursion into a localized, actionable root cause instead of a vague "something's wrong in that tool" observation.
E168 sits at the top of a family of more specific product-time standards that apply its core definition to particular equipment and system contexts. E168.1 applies it specifically to GEM300 production equipment, E168.2 to material-control systems, and E168.3 to transport — each one taking the base product-time concept E168 establishes here and specifying exactly how it applies in a context where the measurement boundaries need additional precision. That's the same base-standard-plus-context-specific-companions pattern this glossary has already seen with E54's SAN device model spawning per-device-type companions, or E142's substrate-mapping concept spawning XML, SECS-II, and web-services bindings.
Read E168 as the standard that finally gives a fab a product-centric cycle-time number to stand alongside its equipment-centric utilization numbers: E10 and E79 tell a fab how well its equipment is scheduled, but only E168's clear process/queue/transport boundaries tell it what a lot actually experienced getting through the fab — the difference between knowing your tools are busy and knowing why your product still took so long to get out the door.