Semi E168.3
SEMI E168.3 applies E168's product-time measurement concept to AMHS transport — fixing which vehicle, stocker, and lifter events mark the start and end of transport time specifically, completing the set of context-specific bindings alongside E168.1's GEM300 equipment anchor and E168.2's material-control-system anchor. E168.1 and E168.2 between them account for a lot's time at the tool and a lot's time waiting on a scheduling decision, but neither one actually measures the transport segment itself in any detail — both treat "transport time" as a single undifferentiated block between a departure event and an arrival event, when the AMHS move itself is made up of several distinct sub-segments (vehicle dispatch delay, travel time, handoff time) that a fab diagnosing an AMHS bottleneck needs broken out separately.
A few things are worth knowing about why transport needed its own sub-segmented binding rather than being folded into E168.1 or E168.2:
A transport move isn't one event, it's a short chain of distinct events, each with a different possible cause for taking too long. A lot waiting for pickup might be stuck because every vehicle in the interbay loop is busy (a fleet-sizing problem), because the actual physical travel distance to the destination stocker is unusually long (a layout problem), or because the handoff at the destination port is slow for mechanical reasons (an E85/E156-interface problem). E168.1's GEM300 anchor and E168.2's MCS anchor both bound transport time as a single block precisely because neither one is built to look inside an AMHS move — that's specifically what E168.3 does, breaking the block into dispatch, travel, and handoff and anchoring each to the AMHS-specific events (E82's IBSEM, E153's AMHS SEM, E88's Stocker SEM) that actually generate them.
Transport also needed its own binding because it's the one time category that spans multiple pieces of equipment rather than living inside a single tool or a single software system. E168.1's process time belongs to one tool; E168.2's dispatch delay belongs to the MCS; but a transport move touches a vehicle, possibly a lifter or sorter, and a destination port, each generating its own events under its own standard — E82, E153, E85, E156. E168.3's job is specifically to stitch those separate equipment-category event streams into one coherent transport-time measurement, which is a different integration problem than anchoring a single system's events the way E168.1 and E168.2 each do.
Read E168.3 as the standard that finally lets a fab diagnose an AMHS bottleneck instead of just measuring its total cost: by breaking transport time into vehicle-dispatch delay, travel time, and handoff time, and anchoring each to the specific AMHS equipment standard that generates it, it completes E168's family of context-specific time bindings and gives a fab the one piece neither the equipment layer (E168.1) nor the scheduling layer (E168.2) alone could ever provide — visibility into what's actually slow during the minutes a lot spends moving between them.