Semi E168.2
SEMI E168.2 applies E168's product-time measurement concept to material-control systems — the MES-layer software that dispatches lots, tracks their location, and decides what runs next — fixing which MCS-level events mark the start and end of each time category from the material-control side of the fab, as distinct from E168.1's equipment-side mapping to GEM300 state transitions. E168.1 says what counts as process time on the tool itself; E168.2 says what counts as queue time, dispatch delay, and hold time from the perspective of the system that actually decides when a lot moves, which turns out to be a genuinely different set of boundaries than anything visible at the equipment layer alone.
A few things are worth knowing about why material-control systems needed their own binding separate from E168.1's equipment-side one:
A lot can be sitting idle for two entirely different reasons that look identical from the equipment's own state data, and only the MCS layer can tell them apart. From a tool's perspective, a lot that's ready and waiting looks the same whether the wait is because the tool itself is busy, or because the MCS hasn't yet decided to dispatch that lot even though the tool is free — E168.1's equipment-state boundaries can tell you the tool wasn't processing, but they can't tell you whether that was an equipment constraint or a scheduling decision. E168.2 exists specifically to make that distinction, anchoring queue-time measurement to the MCS's own dispatch and hold-release events rather than only to what the equipment reports.
This distinction matters operationally because the two root causes point toward opposite investments. If equipment-side idle time dominates, the fix is more capacity, faster changeovers, or better preventive-maintenance scheduling. If MCS-side dispatch delay dominates, the fix is better scheduling logic, tighter dispatch-list priority rules, or reduced batching overhead — and spending on the wrong one wastes real capital. Without E168.2's MCS-anchored boundaries, a fab analyzing E168.1's equipment-state data alone would see the same 22 minutes of idle time either way and have no standardized way to attribute it correctly.
E168.2 completes the same job for material-control systems that E168.1 completed for GEM300 equipment — turning E168's general time categories into something computable from a specific system's actual event stream, rather than something only the equipment layer can anchor. Where E168.1 binds queue/process/transport time to GEM state transitions and CEIDs, E168.2 binds those same categories to MCS dispatch decisions, hold placements, and hold releases — the event vocabulary a scheduling system actually generates, which is a different data source than anything a tool itself reports.
Read E168.2 as the standard that lets a fab separate equipment-caused delay from scheduling-caused delay inside the same cycle-time number: by anchoring E168's time categories to the material-control system's own dispatch and hold events rather than only to equipment state, it answers the question E168.1 alone cannot — not just how long a lot waited, but whether the wait was the tool's fault or the scheduler's.