Date Version Name Edits 11/15/ Lance Rist First working draft of SEMI Document # /25/ Lance Rist

Transcription

1 Background Statement for SEMI Draft Document 5751 REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR TRANSPORT SYSTEMS TO SEMI E , SPECIFICATION FOR PRODUCT TIME MEASUREMENT Notice: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this Document. Notice: Recipients of this Document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, patented technology is defined as technology for which a patent has been issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided. What is the problem being solved? The Specification for Product Time Measurement (SEMI E168) defines the concepts for creating an analysis-ready set of time elements. This Specification applies those concepts to semiconductor AMHS, addressing transport systems that conform to SEMI E82. What is the history of this issue and ballot? This is the first proposal of this new subordinate Specification. Who will this affect? How? Why? This new Specification will not conflict with existing Standards or with existing implementations. It utilizes data that should to be available for any transport system based upon SEMI E82. Is this a change to an existing solution, or, is it a new activity? This is a new activity. Revision Control This revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force. Date Version Name Edits 11/15/ Lance Rist First working draft of SEMI Document # /25/ Lance Rist Second version with changes based on TF input and known issues 12/8/ Lance Rist Updates based on TF inputs and known issues list 12/23/ Lance Rist Modified wording for use of ZFS, stocker; addressed case of transfer command queuing and case of multiple vehicle transport; adjusted the figures to help explain concepts; added RequirementIDs; added new example message sequences in RI 1; and made many editorial updates 12/30/ Lance Rist Small edits and updates; removed two restrictions on MCS 1/11/ Lance Rist Reverted definitions for SEMI CoT versions for carrier, carrier location, transfer port, TSC; removed some text about ZFS; rearranged 7 Overview; modified Table 1, last row. 1/28/ Lance Rist GEM 300 TF approved content for ballot with the following changes: term ZFS changed to storage buffer throughout; added new section 3.2 to Limitations to specifically not support transport vehicles that carry multiple carriers; added Discussion subparagraphs to several definitions.

2 A Note on Requirements ID s Requirements ID s are included in the proposed new Standard. See the Conventions section in SEMI E168 for a full description. All requirements are delimited. No other text should be considered a requirement. Sections near a requirement may provide examples or other supporting text that can help with interpreting the requirement. Note that the word should is used in some non-requirements text and it denotes a recommendation or a best practice, not a requirement. Each requirement has a requirement ID as contained in the [E168.ss-RQ-nnnnn-nn] delimiter. The E168.ss is the specification identifier and will be replaced by SEMI in the published version with the actual Standard number (for example E168.03), which cannot be known before approval is achieved. The nnnnn string is the requirement number within this Specification. The authors of this proposal have suggested requirement numbers, but the final assignment will be made by SEMI. Corrections to the requirement numbers are considered editorial. A Note on Definitions SEMI encourages the reuse of existing definitions of terms wherever possible. The SEMI Standards Procedure Guide, Section , requires that any definition taken unchanged from a published SEMI Standard or Safety Guideline includes a reference to its source Standards Document. This is a reference of the definition only. It is not considered a reference by this Specification to the source Standard. Therefore, these Standards Documents are not listed in the Referenced Standards & Documents section. The ballot results will be reviewed and adjudicated at the meetings indicated in the table below. Check under Calendar of Events for the latest update. Review and Adjudication Information Task Force Review Committee Adjudication Group: Wait Time Waste Task Force North America Metrics Committee Date: March 30, 2015 April 1, 2015 Time & Time Zone: 3:00 PM - 6:00 PM PST 2:00 PM 5:00 PM PST Location: SEMI Headquarters SEMI Headquarters City, State/Country: San Jose, CA / USA San Jose, CA / USA Leader(s): Lance Rist RistTex David Bouldin Fab Consulting Mark Frankfurth Cymer Standards Staff: Michael Tran mtran@semi.org Michael Tran mtran@semi.org This meeting s details are subject to change, and additional review sessions may be scheduled if necessary. Contact Standards staff for confirmation. Telephone and web information will be distributed to interested parties as the meeting date approaches. If you will not be able to attend these meetings in person but would like to participate by telephone/web, please contact Standards staff.

3 SEMI Draft Document 5751 REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR TRANSPORT SYSTEMS TO SEMI E , SPECIFICATION FOR PRODUCT TIME MEASUREMENT Contents 1 PURPOSE SCOPE LIMITATIONS REFERENCED STANDARDS AND DOCUMENTS TERMINOLOGY CONVENTIONS IMPLEMENTATION OVERVIEW PREREQUISITES REQUIREMENTS TEST METHODS RELATED DOCUMENTS APPENDIX Purpose 1.1 SEMI E168 defines the concepts for creating an analysis-ready set of time elements. The purpose of this Specification is to apply the concepts of SEMI E168 to define the standard product time measurement (PTM) method for product units in the domain of a transport system within a semiconductor automated material handling system (AMHS). 2 Scope 2.1 This Document specifies the details needed to apply the PTM method to a semiconductor transport system that implements SEMI E82 and that utilizes discrete vehicles for the transport of carriers. It utilizes messages and data exchanged between the transport system controller (TSC) and the host. NOTICE: SEMI Standards and Safety Guidelines do not purport to address all safety issues associated with their use. It is the responsibility of the users of the documents to establish appropriate safety and health practices, and determine the applicability of regulatory or other limitations prior to use. 3 Limitations 3.1 This Specification is limited to the time substrates spend within the factory domain of a transport system. 3.2 The time elements specified in this Specification address transport systems with transport vehicles that can carry only one carrier at a time. Transport vehicles that can carry multiple carriers are not supported. 3.3 A primary objective of this Specification is to support analysis of time periods that are routine. Most error situations and infrequently occurring scenarios in the transport system are not addressed. However, these are not Page 1 Doc SEMI

4 specifically excluded from the scope and could be added at a later time. Many such scenarios are specific to a particular implementation. 3.4 The lot identifier (LotID) and substrate identifier (SubstrateID) are not routinely available from semiconductor material handling systems. Analysis of PTM data may need to focus on the carrier identifier (CarrierID). Alternately, the LotID may be associated with the CarrierID using data from the factory information and control system (FICS) and/or production equipment. 4 Referenced Standards and Documents 4.1 SEMI Standards and Safety Guidelines SEMI E5 SEMI Equipment Communications Standard 2 Message Content (SECS-II) SEMI E82 Specification for Interbay/Intrabay AMHS SEM (IBSEM) SEMI E88 Specification for AMHS Storage SEM (Stocker SEM) SEMI E151 Guide for Understanding Data Quality SEMI E168 Specification for Product Time Measurement 4.2 Internet Society (ISOC) 1 NTP Network Time Protocol, NTP Version 3 (IETF proposed standard RFC 1305, NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. 5 Terminology 5.1 Note that terms from the Primary Standard also apply to this Specification. 5.2 Abbreviations and Acronyms AGT automated guided transport DWC direct WIP conveyor MCS material control system NTP Network Time Protocol OHT overhead hoist transport TSC transport system controller 5.3 Definitions carrier a container with one or more fixed positions at which material may be held [SEMI E30.1] carrier location a location in the AMHS which may correspond to a physical location or a virtual location [SEMI E153] Discussion In the context of this Specification, a carrier location holds a single carrier collection event an event that may be used to initiate the collection and reporting of data. A collection event may trigger an event report. A collection event may also start or stop one or more trace reports. [SEMI E53] material a term used to refer to discrete objects used in or required by the manufacturing process and which may be transferred to and from equipment. This may include carriers, substrates, reticles, nonproduct wafers, etc material control system (MCS) a supervisory control system that accepts commands from the FICS to transport material between locations within the factory and accomplishes the work by supervisory control and coordination of transport systems and stockers. 1 Internet Society (ISOC), 1775 Wiehle Avenue, Suite 201, Reston, VA 20190, USA, Page 2 Doc SEMI

5 5.3.6 overhead hoist transport (OHT) a rail-guided vehicle and hoist used to transport material above the factory floor over the heads of factory personnel. [SEMI E156] storage buffer a set of one or more locations for storing carriers in the transport system. [SEMI E82] Discussion A storage location is a type of carrier location storage location a specific type of carrier location that is used for carrier storage. [SEMI E153] Discussion Stockers and storage buffers contain storage locations transfer command a message from the host to the TSC requesting movement of material to a specified location within the scope of the transport system. An accepted transfer command results in the creation of an operation or job (also referred to as a transfer ) that can be monitored using a provided identifier transfer port point in the transport system at which a change of equipment ownership of the carrier occurs. See also internal transfer port. [SEMI E82] transport system the component of AMHS that moves material from one part of the factory to another. [SEMI E88] transport system controller (TSC) interbay or intrabay transport system controller that communicates with the factory host and represents the system as the equipment. [SEMI E82] Discussion The host of a TSC can be an MCS transport vehicle a component of a transport system that transports material between factory locations Discussion In the context of this specification, a factory location refers to a carrier location that is accessible to a transport system or stocker supervised by an MCS. 6 Conventions 6.1 Conventions from the Primary Standard also apply to this Specification. There are no additional conventions. 7 Implementation Overview This subordinate Specification builds upon its primary Specification. Please review 7 from SEMI E168 for an overview of its contents. To that basis is added the detail to support PTM from the viewpoint of the transport system Transport System Concepts Transport systems are responsible for transferring carriers among carrier locations in the factory, which include production equipment, stockers, and storage buffer locations Figure 1 illustrates coordination of carrier transfer by the transport system. Page 3 Doc SEMI

6 Figure 1 Illustration of Transport System Physical Connections Transport systems may be of different types and employ various means of transport. Some transport system types include overhead hoist transport (OHT), automated guided transport (AGT), and direct WIP conveyor (DWC) Communication from the host to the transport system for control purposes is specified by SEMI E82. The host side of the communications link can be an MCS. The role of an MCS is to coordinate activities of transport systems, stockers, and any other AMHS equipment that might exist Figure 2 illustrates the communication link between host and transport system. Figure 2 Transport System Communication In this Specification, it is assumed that the transport system uses a vehicle of some type upon which the carrier is transported. For transport systems that do not use vehicles, the user of the PTM method will need to adjust the time elements accordingly. This might be done by identifying events that approximate the vehicle-related events used in Table 7 or by merging existing time elements separated by vehicle-related events. This adjustment is beyond the scope of this Specification Communication with transport system controllers (TSCs) is specified in SEMI E A transport system may consist of various hardware resources. The only transport system resources visible from the PTM standpoint are the storage buffer locations, the vehicles, and the carrier locations on those vehicles. While the TCS will report on carrier handoff operations, some resources involved in those operations are not tracked. Events denoting the pathway for delivery are also not tracked except for cases where a carrier is transferred from one vehicle to another A transport system will also have access to external resources in the form of transfer ports. Production equipment and stockers have carrier locations that serve as transfer ports. While the transport system does not typically Page 4 Doc SEMI

7 control these transfer ports, it normally has a means of coordinating carrier handoff with the owner of the related carrier locations. The transfer system does not have visibility to other carrier locations within production equipment or stockers SEMI E82 specifies state models for the following objects. Each state model has a number of transitions between states. Each transition may result in an event report. Transport system controller the TSC executes host commands to move carriers from one carrier location to another among its accessible locations. Transfer command a transfer command message from the host that results in the creation of an operation or job referred to as a transfer command. Transport vehicle a component of a transport system that transports carriers between factory locations. A transport vehicle is also referred to in this Specification simply as a vehicle. Carrier a container that holds one or more product units Transfer port a point in a transport system at which a change of ownership of the carrier occurs Note that once a carrier is delivered to a production equipment or stocker, that carrier can no longer be tracked by the transport system. The carrier will once again be tracked when the transport system is commanded to pick it up Events Events based upon the SEMI E82 transfer command and transport vehicle state models are used in the definition of time elements in Table The events of interest available from the TSC are listed in Table A2-1 found in Appendix Carrier to Represent Product Units A significant challenge of using transport system data for PTM is that it typically does not contain product identification (e.g., lot and substrate identifiers). Host commands to the TSC are keyed on the CarrierID. The transport system is focused upon moving carriers. The content of the carrier has no bearing on the function of the transport system A full analysis of transport system data requires a mapping of product identification (lot and substrate identifiers) to the carrier. This data is typically available within the FICS as well as in production equipment communication logs Data fields are provided in the PTMData output file format for inclusion of product identifiers. The means of populating the product identifier fields is not addressed in this Specification. It may not be possible to populate those data fields If the product identifier is not available, meaningful analysis of the PTM data is still possible for generic cases. For example, comparison of transport times from stocker A to production equipment B is valid, independent of the specific product units in the carrier However, analysis of product time for specific product units is severely limited if product identifiers are not available Lot-Level vs. Substrate-Level Data The PTM method is designed to support analysis of carrier-based data. If LotID or SubstrateID values are available, it will also support analysis at either the lot-level or for individual substrates When the product units are under the control of the transport system, the substrates are grouped in carriers. Typically a carrier contains exactly one lot. However, this may not always be true. It is possible for a lot to span multiple carriers or for multiple lots to be represented in a single carrier. This poses a challenge for lot-level data collection and analysis Another challenge for lot-level data collection and analysis is that the product units in a carrier might not be consistent from one process step to the next. Lots can be split and merged for various reasons. Page 5 Doc SEMI

8 In general, lot-level data collection is only viable for a limited span of process steps where the entire lot is in a carrier. Such a view does not work well beyond the point where a lot may be split or merged When the SubstrateID values are available, the user of the PTM method should consider using substrate-level data collection and analysis. This avoids the issue of how lots are aligned with carriers and whether they split or merge. A single substrate can be chosen as representative of the lot, or each wafer in the lot can be analyzed separately. The data set can span the entire lifecycle of the substrate if desired In the absence of product identification such as LotID or SubstrateID, analysis may need to proceed with the assumption that a carrier represents a single unidentified lot Carrier Reroute A carrier is said to be rerouted when the original destination for a carrier is changed to an alternate destination. When a carrier is rerouted, the time for delivery of that carrier may vary widely from the typical duration. The PTM method allows for marking time elements associated with a transfer command that includes a reroute. This allows those message sequences to be separated and categorized differently from the others during analysis if so desired A carrier reroute may be initiated by an external system that needs the carrier to go elsewhere. It may also be initiated by the TSC because the original delivery cannot be made due to conditions in the factory (e.g., the destination port is occupied) Carrier reroute is detected by the PTM method by means of an indicator event that occurs during the message sequence of a transfer command that includes a carrier reroute (see 9.5.6). Each time element related to such a transfer command is marked in the Reroute field of the PTMData file (see Table 3) There are a number of other problems that may occur during carrier delivery to extend carrier delivery (e.g., mechanical problems, traffic jams). The PTM method can help identify times when transport duration is longer than usual, but in some cases, the PTMData is not sufficient to support identification of the cause Time Elements The time element definitions for transport systems are the same for lot-level as for substrate-level analysis. Since the substrate cannot leave the carrier except within production equipment (including sorters), all TSC events, and thus all of the related time elements, apply equally to all substrates in the carrier Transfer Command Queuing and Overlap Some TSC implementations may allow transfer commands for a carrier to be accepted and queued when another transfer command is already executing. There may be cases where a queued transfer command begins execution before the previous transfer command has completed For example, the second transfer command may start a vehicle to a stocker for carrier pickup before the previous transfer command has completed delivery of the carrier to that stocker The design of the time elements provides for this type of overlap, should it occur Transfer command queuing and overlap are not required by this Specification. 8 Prerequisites 8.1 The basic prerequisite for this subordinate Specification is conformance to the primary Specification. [E168.ss-RQ ] Application of the PTM method to Host-TSC communication logs shall conform to the requirements in SEMI E168. [/RQ] 8.2 Communication Interface Support [E168.ss-RQ ] The transport system shall support an interface with the host conforming to the requirements of SEMI E82. [/RQ] Details about the key SEMI E82 events are listed in Table A2-1 found in Appendix 2. Key SEMI E82 context data variables are listed in Page 6 Doc SEMI

9 [E168.ss-RQ ] Host-TSC communication logs for the selected system shall be made available for processing by the PTM method. [/RQ] Note that if the factory utilizes multiple transport systems, a carrier might be transferred by multiple such systems during its factory cycle time. When employing the PTM method, it may be necessary to include communication logs from multiple Host-TSC interfaces to ensure that all time elements during the selected time period for a given carrier are included in the output The mapping of LotID and SubstrateIDs to CarrierID will typically need to come from external sources within the FICS. The user of the PTM method is responsible for this mapping. Without the LotID information, application of this method might be valid only for time periods covering transport of the product unit among factory equipment where the product units cannot change carriers. 8.3 Data Quality Important aspects of data quality are discussed in SEMI E168 and in SEMI E A key part of data quality is synchronization of transport system clock(s) with the factory system time. The clock used by the TSC should be synchronized with a factory-selected time server using the Network Time Protocol (NTP) or an equivalently accurate method, if possible. 9 Requirements The following is the top level parent requirement of all others in this Specification. [E168.ss-RQ ] Conformance to this Specification requires conformance to all other identified requirements in this Document as stated conditions apply. [/RQ] 9.2 This Specification applies the SEMI E168 PTM method to the transport system. [E168.ss-RQ ] The requirements in this Specification apply only to communications exchanged between the host and a TSC. [/RQ] 9.3 SEMI E168 s requirements consist of two parts: dataset construction and time element definition. In this Specification, these topics are revisited with a focus on data and events present in communications between the host and a TSC. 9.4 Product Time Data Set Construction Product Time Inputs [E168.ss-RQ ] In order to support PTM for transport systems, the data specified in Table 1 shall be provided. [/RQ] Table 1 Data Required for PTM for Transport Systems RequirementID Required Data Description E168.ss-RQ E168.ss-RQ E168.ss-RQ Communication Log Collection Event Documentation Data Variable Documentation A record of the messages exchanged between host and TSC during the time period specified for analysis. This can be a message log recorded by the host or a log recorded by the TSC. Necessary context data shall be included in the event reports (see and 9.5.4). The format for this log is not specified. A list of the collection event identifiers (CEIDs) supported by the TSC. The documentation for each event shall include the event identifier, the supplier name for the event, and a description of when and why the event occurs. See Table A2-1 for a list of the TSC events used in this Specification. A list of the variable identifiers (VIDs) supported by the TSC. The documentation for each data variable shall include the variable identifier, the supplier-assigned name for the variable, the format, the size, and a description of the content of the variable. Page 7 Doc SEMI

10 RequirementID Required Data Description E168.ss-RQ Event Configuration A list of the event reports (RPTIDs) linked to each collection event (CEID), along with definitions for the event reports, including the identifiers of the variables (VIDs) to be included with each report #1. #1 Note that the event reports for a SECS-II interface may be reconfigured at any time. This listing needs to pertain to the particular communication log under investigation Host-TSC Communication Log SECS-II messages are structured as a set of nested lists. Each data item in the message is either a data value or a list designator with the length of the list included. Each item in a list may also be a data value or a list (nested list) The communication log format for the Host-TSC interface is not specified. However, the content is addressed in the following two requirements. [E168.ss-RQ ] Communication logs shall contain all messages exchanged over the time period to be examined. [/RQ] [E168.ss-RQ ] Communication logs shall include the following for each message: a) an identification of the type of message (e.g., SECS stream and function), b) a timestamp associated with the message, and c) all data items from the original message, including the format and value of each data item. [/RQ] Collection Event Documentation In transport systems that support SEMI E82, all event data is communicated using collection events that trigger event reports. These are typically reported by the TSC using the S6F11 message See A2-1.1 for a list of the events from SEMI E82 that is used in this Specification User Configuration SECS-II provides the capability to configure SECS-II event data collection. This is done in three stages. The first stage is the definition of event reports. Each event report is assigned an identifier (RPTID) and a list of variable identifiers (VIDs). The S2F33 message is used to request the definition of event reports The second stage of SECS-II event configuration is the linking of event reports to specific events. The S2F35 message is used to provide a list of collection event identifiers (CEIDs) and the reports (RPTIDs) to be attached to each The final stage of SECS-II event configuration is the enabling of each event to be reported. This is requested by the host using the S2F37 message. [E168.ss-RQ ] A list of all collection events enabled for the TSC (referenced by the CEIDs) shall be provided, including the reports attached to each (referenced by the RPTIDs). This list serves as input to the PTM process. [/RQ] Product Time Data Transformations This section builds upon the data transformation steps defined in SEMI E168. It adds SEMI E82 Standardspecific information and requirements Step 1 Communication Log Normalization no additional comment Page 8 Doc SEMI

11 Step 2 Message Filtering [E168.ss-RQ ] For communications between Host and TSC, the message filtering step shall retain the following messages when they appear in the communication log: o S6F11 Event Report Send o S2F33 Define Report o S2F35 Link Event Report o S2F41 Host Command Send o S2F42 Host Command Acknowledge o S2F49 Enhanced Remote Command o S2F50 Enhanced Remote Command Acknowledge [/RQ] Step 3 Data Code Translation The collection event documentation (see RQ-00010), data variable documentation (see RQ-00011), and user configuration (see RQ-00012) serve as the inputs to the data code translation Step 4 Context Data Population Key context data variables include the following: CarrierID The identifier of the carrier that holds the product unit(s). This is likely to appear in most TSC events and other messages. CommandID The identifier of the command (i.e., job) that is currently associated with the carrier. This value corresponds to the JobID field in the PTMData. CarrierLocationID The identifier of the current location of the carrier. This should consist of two parts: the identifier of the production equipment, stocker, or transport vehicle concatenated with the identifier of the specific location within that equipment, stocker, or vehicle. SourceLocationID - The location of the carrier at the start of the command DestinationLocationID - The intended new location for the carrier as specified in the command VehicleID The identifier of the transport vehicle associated with the command. In some cases, the VehicleID is the same as the CarrierLocationID associated with the vehicle. LotID and/or SubstrateID The identifier of the product unit or group of product units being transported. The identification of the product unit(s) is typically not available within the TSC or is not populated in the messages Naming of these context variables is not standardized because the variable names are not communicated. The variable names may vary from one implementation to another Selected messages provide links between certain key context data items. This includes the events listed in Table A2-1 as well as the various command messages and responses Timestamps need to be included with each message in the log (see RQ-00014) Step 5 Time Segment Construction [E168.ss-RQ ] Time segment construction shall be done using the Level 4 time elements specified in [/RQ] Dataset Output Format SEMI E168 specifies the PTMData output file format. This subordinate Specification adds detail to some PTMData fields defined in the primary Specification (see Table 2) and adds new fields specific to the Host-TSC interface (see Table 3) Unaffected fields are not included The field order, as specified in the primary Standard is not affected. Page 9 Doc SEMI

12 [E168.ss-RQ ] The requirements for each field specified in Table 2 shall be added to the requirements for those same PTMData fields as specified in SEMI E168. [/RQ] Table 2 Additional Definition for PTMData Fields from Primary Specification RequirementID Field Description Format E168.ss-RQ E168.ss-RQ E168.ss-RQ LotID SubstrateID SubstrateLocationID Lot identifier relevant to this time element (for appropriate time elements) Note that the LotID and SubstrateID may need to be filled in from an external source, since it is typically not available in Host- TSC communication logs. Identifier of the substrate relevant to this time element (for appropriate time elements) This field is left blank when lot-level data is created. Substrate location identifier relevant to this time element (for appropriate time elements) For Host-TSC communications, the SubstrateLocationID is the same as the CarrierLocationID. Text (no change) Text (no change) Text (no change) [E168.ss-RQ ] The fields specified in Table 3 shall be included in the PTMData in the order that they are listed, following the PTMData fields specified in SEMI E168 and preceding any user-added fields. [/RQ] Table 3 Added PTMData Fields to Support Host-TSC Communications RequirementID Field Description Format E168.ss-RQ JobID Identifier of the related transfer command for TSC Text E168.ss-RQ Reroute This field identifies those transfer commands where the destination is changed during the operation (e.g., carrier reroute). Each time element for such a transfer command shall be identified with Reroute value for this field. Text: Reroute or zero length string Where the description field in Table 2 includes the text for appropriate time elements, the requirement applies only for time elements where such a value exists. 9.5 Time Elements The primary Specification does not define the Level 3 or Level 4 time elements in detail because they are specific to the type of event-source. Those time elements are defined here for the transport system domain Level 3 Resources In Level 3, wait time and active time elements are further subdivided into elements related to specific factory resources. This Subordinate Specification of SEMI E168 is focused on the time the product unit spends within the domain of the transport system as specified in SEMI E82. [E168.ss-RQ ] The Level 3 time elements that are subcategories of Wait Time are: o Wait for Host o Wait for TSC [/RQ] Page 10 Doc SEMI

13 [E168.ss-RQ ] The Level 3 time elements that are subcategories of Active Time are: o Active Time for TSC o Active Time for Production Equipment [/RQ] Table 4 shows the Level 3 time elements with their associated parent categories. Table 4 Level 3 Time Elements Level 1 Level 2 Level 3 Product Time Level 4 Detailed Time Elements Wait Time Active Time Wait for Host Wait for TSC Active Time for TSC Active Time for Production Equipment Level 4 time elements provide the finest level of detail defined in this Specification. These are shown in Table 5 (wait time elements) and Table 6 (active time elements) The set of Level 4 time elements applies both to lot-level and substrate-level data. Table 5 Level 4 Wait Time Elements Level 3 RequirementID Level 4 Wait for Host E168.ss-RQ Wait Time within Storage Location Wait for TSC E168.ss-RQ E168.ss-RQ E168.ss-RQ E168.ss-RQ E168.ss-RQ E168.ss-RQ Wait for Carrier Deposit Wait for Carrier Pickup Wait for Job Cleanup Wait for Vehicle Arrival Wait for Vehicle Assignment Wait for Vehicle Departure Table 6 Level 4 Active Time Elements Level 3 RequirementID Level 4 E168.ss-RQ Active Time for Carrier Pickup Active Time for TSC E168.ss-RQ Active Time for Carrier Delivery E168.ss-RQ Active Time for Carrier Transport Active Time for Production Equipment E168.ss-RQ Active Time within Production Equipment Context Information Events are used to mark the beginning and end of each time segment. However, the collection event identifier (CEID) is not sufficient for the assignment of time elements. Context information must be included with events to identify the product unit and/or carrier, to clarify the event (e.g., carrier location), and to determine when the event occurred (see Table 1 and ) Carrier Location In the definition of time elements where location may be used to quality an event, the locations are grouped according to type. Page 11 Doc SEMI

14 For the transport system domain, three types of carrier locations have been identified. These are described in RQ Some events referenced in Table 7 are qualified with these location types. [E168.ss-RQ ] Carrier locations visible within the Host-TSC communication logs shall be categorized into carrier location types. All carrier locations corresponding to the carrier location types listed in this requirement shall be categorized according to those carrier location types. Storage a storage location is located within a stocker or storage buffer Production Equipment the carrier location that is associated with the transfer port for a production equipment in the factory. This is typically an equipment load port. Vehicle a carrier location on a vehicle within a transport system. This location is not fixed within the factory. [/RQ] The carrier location types listed in RQ are used in relation to the Level 4 time element definitions Additional carrier locations beyond the types listed in RQ may be visible in the communication logs. These may be assigned user-defined carrier location types and used in Level 5 user extensions. NOTE 1: See Related Information Level 4 Time Element Definitions Table 7 defines each of the Level 4 time elements listed in Table 5 and Table The time elements in Table 7 are not listed in chronological order. The order of the time elements is dependent, to some degree, on factors such as user implementation choices, equipment design, and factory situation. Please see RELATED INFORMATION 1 for example sequences of messages and time elements. [E168.ss-RQ ] When applied to a transport system, the PTM method shall use the time elements as defined in Table 7. [/RQ] Table 7 contains three columns. The first is the RequirementID The second column lists the name of each time element. Below the name, in parentheses, is the Label. The label is a shortened name intended for visualizations or tables where space may be limited The third column contains the definition of each time element. This includes: Text to describe the time element such as the reason for waiting (if Wait Time) or the particular activity (if Active Time) The identifier of each event that will start this time element The identifier of each event that will end this time element Each event identifier (EventID) mentioned in the bullets above is followed by text explaining the significance of the event In some cases, two consecutive time segments in the PTMData file may be assigned the same time element. This presents the user of the PTM method the opportunity, during analysis, to differentiate the two occurrences of that time element or combine them Level 2 and Level 3 time elements are provided as divider rows above their Level 4 time elements listed in Table 7. Page 12 Doc SEMI

15 Table 7 Level 4 Time Element Definitions RequirementID Level 4 Time Element Name (Label) E168.ss-RQ Wait Time Elements (Level 2) E168.ss-RQ Wait for Host (Level 3) E168.ss-RQ Wait Time within Storage Location (WaitInStorage) Time Element Definition The carrier is at a location not associated with a production equipment (e.g., a storage location) and is awaiting a transfer command from the TSC. Start: TransferCompleted-NotProdEqp The carrier has been placed in a location not associated with a production equipment (e.g., at a storage location). or TransferAbortCompleted The transfer command has been aborted. The carrier remains on the transport vehicle. or TransferCancelCompleted The transfer command has been cancelled before the carrier was moved. End: TransferInitiated The transfer command has begun execution. E168.ss-RQ Wait for TSC (Level 3) E168.ss-RQ E168.ss-RQ Wait for Carrier Deposit (WaitForCarrierDeposit) Wait for Carrier Pickup (WaitForCarrierPickup) The transport vehicle has arrived at the delivery location and is preparing to begin carrier deposit. Start: VehicleArrived-WithCarrier The transport vehicle has arrived at the delivery location ready to deposit the carrier. End: VehicleDepositStarted Carrier placement onto the delivery location has begun. or VehicleAssigned-WithCarrier The fact that the carrier is already on the vehicle indicates that a previous transfer did not complete. The transport vehicle has been reassigned to the task of delivering the carrier, but it may be to a new location. or TransferAbortCompleted The transfer command has been aborted. The carrier remains on the vehicle. Any TransferInitiated, VehicleAssigned-NoCarrier, or VehicleArrived-NoCarrier event that occurs during this time element shall not start a new time element (see 7.1.8). The transport vehicle has arrived and the carrier is awaiting pickup to begin. Start: VehicleArrived-NoCarrier The assigned transport vehicle has arrived at the pickup location. End: VehicleAcquireStarted The carrier is being acquired by the transport vehicle. or TransferCancelCompleted The transfer command has been cancelled before the carrier was moved. Any TransferCompleted-Storage event that occurs during this time element shall not start a new time element (see 7.1.8). Page 13 Doc SEMI

16 RequirementID E168.ss-RQ Level 4 Time Element Name (Label) Wait for Job Cleanup (WaitForJobCleanup) Time Element Definition The carrier has been placed in the delivery location and is awaiting release from the transfer command. Start: VehicleDepositCompleted Carrier placement onto the delivery location has completed. End: TransferCompleted-ProdEqp The carrier has been placed on the input port of a production equipment. or TransferCompleted-NotProdEqp The carrier has been placed in a location not associated with a production equipment (e.g., at a storage location). or TransferInitiated A transfer command for this carrier has begun execution. or VehicleAssigned-NoCarrier A transport vehicle has been assigned to this transfer command and is traveling to the pickup location. or VehicleArrived-NoCarrier The assigned transport vehicle has arrived at the pickup location. or VehicleAcquireStarted A transport vehicle has begun the process of picking up the carrier. The last four end events for Wait for Job Cleanup indicate the continued transfer of the carrier on another vehicle. It may mean the continuation of the current transfer command or the start of a queued transfer command that has begun before the previous one has completed. See also The transport vehicle has been assigned to the transfer and is traveling to the appropriate location. Start: VehicleAssigned-NoCarrier A transport vehicle has been assigned to this transfer command. End: VehicleArrived-NoCarrier The assigned transport vehicle has arrived at the pickup location. or TransferCancelCompleted The transfer command has been cancelled before the carrier was moved. Any TransferCompleted-Storage event that occurs during this time element shall not start a new time element (see 7.1.8). E168.ss-RQ Wait for Vehicle Arrival (WaitForVehicleArrival) The transfer command has begun execution, but the transport vehicle has not yet been assigned. Start: TransferInitiated The transfer command has begun execution. End: VehicleAssigned-NoCarrier A transport vehicle has been assigned to this transfer command and is traveling to the pickup location. or TransferCancelCompleted The transfer command has been cancelled. Any TransferCompleted-Storage event that occurs during this time element shall not start a new time element (see 7.1.8). E168.ss-RQ Wait for Vehicle Assignment (WaitForVehicleAssign) Page 14 Doc SEMI

17 RequirementID E168.ss-RQ Level 4 Time Element Name (Label) Wait for Vehicle Departure (WaitForVehicleDepart) Time Element Definition The carrier has been secured on the transport vehicle and readied for transport. It waits for the transport vehicle to begin its journey to the delivery location. Start: VehicleAcquireCompleted The transport vehicle has acquired the carrier. End: VehicleDeparted The carrier is parked on the transport vehicle and the transport vehicle has begun travel to the delivery location. E168.ss-RQ Active Time Elements (Level 2) E168.ss-RQ Active Time for TSC (Level 3) E168.ss-RQ Active Time for Carrier Pickup (ActiveCarrierPickup) or TransferAbortCompleted The transfer command has been aborted. The carrier remains on the transport vehicle. The carrier is being acquired by a transport vehicle. Start: VehicleAcquireStarted The carrier is being acquired by the transport vehicle. End: VehicleAcquireCompleted The transport vehicle has acquired the carrier. or TransferCancelCompleted The transfer command was cancelled before the carrier was moved. E168.ss-RQ Active Time for Carrier Delivery (ActiveCarrierDelivery) The carrier is being handed off from a transport vehicle to another entity within the factory. Start: VehicleDepositStarted Carrier placement onto the delivery location has begun. End: VehicleDepositCompleted Carrier placement onto the delivery location has completed. or TransferAbortCompleted The transfer command has been aborted. The carrier remains on the vehicle. or VehicleAssigned-WithCarrier The fact that the carrier is already on the vehicle indicates that a previous transfer did not complete. The transport vehicle has been reassigned to the task of delivering the carrier, but it may be to a new location. Any TransferInitiated, VehicleAssigned-NoCarrier or VehicleArrived-NoCarrier event that occurs during this time element shall not start a new time element (see 7.1.8). Page 15 Doc SEMI

18 RequirementID E168.ss-RQ Level 4 Time Element Name (Label) Active Time for Carrier Transport (ActiveCarrierTransport) Time Element Definition The carrier is being transported on the transport vehicle. Start: VehicleDeparted The carrier is parked on the transport vehicle and the transport vehicle has begun travel to the delivery location. or VehicleAssigned-WithCarrier The fact that the carrier is already on the vehicle indicates that a previous transfer did not complete. The transport vehicle has been reassigned to the task of delivering the carrier, but it may be to a new location. End: VehicleArrived-WithCarrier The transport vehicle has arrived at the delivery location ready to deposit the carrier. or TransferAbortCompleted The transfer command had been aborted. The carrier remains on the transport vehicle. Any TransferInitiated, VehicleAssigned-NoCarrier or VehicleArrived-NoCarrier event that occurs during this time element shall not start a new time element (see 7.1.8). E168.ss-RQ Active Time for Production Equipment (Level 3) E168.ss-RQ Active Time within Production Equipment (ActiveInProdEqp) The carrier has been delivered to a production equipment for processing. Because additional information is not available, the product unit is assumed to be active during its entire stay. Start: TransferCompleted-ProdEqp The carrier has been delivered to the load port of a production equipment. End: TransferInitiated A transfer command for this carrier has begun execution Carrier Reroute Indicators Carrier reroute is described in A carrier is said to be rerouted when the original destination for a transfer command is changed to an alternate destination. A carrier reroute may be initiated by an external system that needs the carrier to go elsewhere. It may also be initiated by the TSC because the original delivery cannot be made due to conditions in the factory (e.g., the destination port is occupied) A carrier reroute may occur at almost any point during a transfer command. It can be identified by one or more related events that occur during the span of a transfer command that is rerouted. These events are called indicator events. The carrier reroute indicator events do not affect the associated time elements except to cause them to be marked in the PTMData. Therefore, it is not feasible to make different time elements for a transfer command that includes a carrier reroute versus one that does not The PTM method uses the indicator events to identify rerouted carriers and designates these using the Reroute field in the PTMData file. The Reroute field defined in Table 3 is set to Reroute for all time elements related to a transfer command that has been identified as rerouted If the carrier reroute is initiated by the TSC, the reroute is typically caused by a barrier to delivery such as the destination port being occupied or a problem with handoff at the port The mechanism for carrier reroute is dependent on the design of the system. There are two common approaches. One approach is to change the destination in a currently active transfer command. A second approach is to terminate the current transfer command and have the host or the TSC initiate a subsequent transfer command to move the carrier to a new location. An implementation can include both approaches. NOTE 2: Scenarios provided in Related Information 1 provide an example of the latter (see R1-5). The carrier reroute indicator event for this approach is the assignment of a new destination for the transfer command. Page 16 Doc SEMI

19 The latter approach is demonstrated for transfer systems in the SEMI E82 scenario entitled Host-Initiated Override of a TRANSFER Command. The carrier reroute indicator event for this approach is the early termination of the transfer command User Extensions Level The user of the PTM method is allowed to add detail to time elements as long as the original time elements can be reconstituted. These extensions are referred to as Level 5 time element definitions. This concept is introduced in SEMI E168. NOTE 3: Also, this concept is discussed in Related Information 2 as it relates to the transport system domain. 10 Test Methods 10.1 No test methods are defined for this Specification 11 Related Documents 11.1 SEMATECH Wait Time Waste (WTW) Metrics and Methods Guidance for Automated Material Handling Systems (AMHS), v1.0; October 24, SEMATECH, 257 Fuller Road, Suite 2200, Albany, NY 12203, USA, Telephone: , Page 17 Doc SEMI

20 APPENDIX 1 STATEMENT OF COMPLIANCE NOTICE: The material in this appendix is an official part of SEMI [insert designation, without publication date (month-year) code] and was approved by full letter ballot procedures on [insert date of approval by responsible regional standards committee]. A1-1 Statement of Compliance [E168.ss-RQ ] Each implementer of this Specification shall complete a Capability Requirements compliance table per Table A1-1 when reporting on compliance to E168.ss. [/RQ] A1-2 Compliance Table: Capability Requirements [E168.ss-RQ ] Each implementer of this Specification shall document compliance to E168.ss capabilities requirements per Table A1-1 with the following compliance codes: C comply, NC not comply, WC will comply, NA not applicable. [/RQ] [E168.ss-RQ ] The NA compliance code shall be used only in the case where a requirement is conditional and the condition evaluates to render the requirement not applicable for the current implementation. [/RQ] A1-2.1 Child requirements inherit the conditional status of the parent requirement. Where a parent requirement is marked NA, the child requirements should also be marked NA. [E168.ss-RQ ] An explanation for NC shall be provided by the implementer. [/RQ] A1-2.2 If WC is assigned, the implementer should provide a date for implementation. A1-2.3 Items included in the Condition/Selection Criteria column of Table A1-1 are defined in Table A1-2. [E168.ss-RQ ] Each implementer of this Specification shall include in the completed Capability Requirements compliance table a value as specified in Table A1-2 for all defined conditions or selection criteria included in Table A1-1. [/RQ] Table A1-1 E168.ss Capability Requirements Section RequirementID Parent RequirementID Condition/Selection Criteria Compliance Codes (C/NC/WC/NA) Capability: Statement of Compliance A.1-1 E168.ss-RQ E168.ss-RQ <none> A.1-2 E168.ss-RQ E168.ss-RQ <none> A.1-2 E168.ss-RQ E168.ss-RQ <none> A.1-2 E168.ss-RQ E168.ss-RQ <none> A.1-2 E168.ss-RQ E168.ss-RQ <none> A1-3 E168.ss-RQ E168.ss-RQ <none> Page 18 Doc SEMI

21 Section RequirementID Parent RequirementID Condition/Selection Criteria Capability: 8 Prerequisites 8.1 E168.ss-RQ E168.ss-RQ <none> 8.2 E168.ss-RQ E168.ss-RQ <none> 8.2 E168.ss-RQ E168.ss-RQ <none> 8.2 E168.ss-RQ E168.ss-RQ <none> 8.2 E168.ss-RQ E168.ss-RQ <none> Capability: 9 Requirements E168.ss-RQ None <none> 9.2 E168.ss-RQ E168.ss-RQ <none> Capability: 9.4 Product Time Data Set Construction Compliance Codes (C/NC/WC/NA) Capability: Product Time Inputs E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: Product Time Data Transformations E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: Dataset Output Format E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Page 19 Doc SEMI

22 Section RequirementID Parent RequirementID Condition/Selection Criteria E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: 9.5 Time Elements Capability: Level 3 Resources E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: Level 4 Detailed Time Elements Compliance Codes (C/NC/WC/NA) E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: Context Information E168.ss-RQ E168.ss-RQ <none> Capability: Level 4 Time Element Definitions E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Page 20 Doc SEMI

23 Section RequirementID Parent RequirementID Condition/Selection Criteria E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Compliance Codes (C/NC/WC/NA) E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> A1-3 Compliance Table: Conditional Criteria [E168.ss-RQ ] Each implementer supplier shall document E168.ss specific conditional criteria per Table A1-2. [/RQ] A1-3.1 Conditional criteria are used to identify when Conditional requirements are to be implemented. Table A1-2 Conditional Criteria Name Values Description Section None There are no conditional criteria related to the requirements in this Specification. Page 21 Doc SEMI

24 APPENDIX 2 SEMI E82 TSC EVENTS USED FOR PTM NOTICE: The material in this Appendix is an official part of SEMI [designation number] and was approved by full letter ballot procedures on [A&R approval date]. A2-1 Introduction A2-1.1 Table A2-1 lists the events required in this Specification for use in PTM. These events were originally specified in SEMI E82. They are listed here for the convenience of the user of the PTM method. These events are referenced in the time element definitions in Table 7. A2-1.2 The EventIDs included in the tables are created in this Specification. SEMI E82 does not have specific EventIDs. A2-1.3 Where the event represents a state machine transition, the state machine and transition number are listed in the State Machine & Transition column. A2-1.4 All SEMI E82 information listed in this Specification is based upon SEMI E A2-1.5 Note that Table A2-1 does not include RequirementIDs. The requirements for these events are included elsewhere in this Specification. This table provides a convenient summary list for use by the users of the PTM method. Table A2-1 TSC Events Required For PTM State Machine & Transition EventID Description IBSEM Transfer Command Transition# 2 IBSEM Transfer Command Transition# 3 IBSEM Transfer Command Transition# 11 IBSEM Transfer Command Transition# 9 IBSEM Transfer Command Transition# 12 Transfer Command Events Transfer command has been accepted and begun TransferInitiated execution. Context Data: CommandID Transferring TransferCompleted TransferAbortInitiated TransferAbortFailed (not used) Transfer activity has begun. The transport vehicle has arrived and carrier acquisition is beginning. This event is coincident with the VehicleAcquireStarted event. Context Data: CommandID The transfer has completed. In practice, this is qualified with the context variable that contains carrier location: TransferCompleted-ProdEqp TransferCompleted-NotProdEqp These differentiate those transfers that terminate at production equipment from those that do not. Context Data: CommandID, CarrierID, CarrierLocationID, SourceLocationID, DestinationLocationID (not used) Indicates that an abort command has been accepted. Since an abort might not succeed, this event is not used. See the event TransferAbortCompleted. (not used) If an abort fails, the transfer continues; there is typically no significant effect on the transfer. Page 22 Doc SEMI

25 State Machine & Transition EventID Description IBSEM Transfer Command Transition# 10 IBSEM Transfer Command Transition# 4 IBSEM Transfer Command Transition# 5 IBSEM Transfer Command Transition# 6 IBSEM Vehicle Transition #10 IBSEM Vehicle Transition #9 IBSEM Vehicle Transition #3 IBSEM Vehicle Transition #4 TransferAbortCompleted TransferCancelInitiated TransferCancelFailed TransferCancelCompleted VehicleAssigned VehicleUnassigned VehicleAcquireStarted Transport Vehicle Events VehicleAcquireCompleted Ends a transfer. The carrier may be in a port, but is often still in route (e.g., on a transport vehicle). This event designates Carrier Reroute scenarios. Context Data: CommandID, CarrierID, CarrierLocationID, SourceLocationID, DestinationLocationID (not used) Indicates that a cancel command has been accepted. Since a cancel might not succeed, this event is not used. See TransferCancelCompleted event. (not used) If a cancel fails, transfer continues; there is typically no significant effect on the transfer. Ends a transfer before the carrier has left the source location. Context Data: CommandID, CarrierID, CarrierLocationID, SourceLocationID, DestinationLocationID Transport vehicle has been assigned to the transfer. In practice, this is qualified with the context variable that identifies the carrier(s) held on the vehicle: VehicleAssigned-NoCarrier the carrier specified for this transfer command is not present on the vehicle. VehicleAssigned-WithCarrier the carrier specified for this transfer command is present on the vehicle. This event is also useful for filling in context data. See the description of the VehicleUnassigned event for more detail. Context Data: CommandID, VehicleID (context event only) This event is coincident with the TransferCompleted event and is therefore not needed to delineate time elements. However, it can be useful for filling in context data. It denotes when a carrier is associated with a transfer command. Each event that references the carrier between VehicleAssigned and VehicleUnassigned events relate to the same transfer command. The transport vehicle begins the process of acquiring the carrier and lifting it from its current location. Context Data: CarrierID, VehicleID, CarrierLocationID The transport vehicle has completed the process of securing the carrier to the vehicle for transport. Context Data: CarrierID, VehicleID, CarrierLocationID Page 23 Doc SEMI

26 State Machine & Transition EventID Description IBSEM Vehicle Transition #5 IBSEM Vehicle Transition #6 IBSEM Vehicle Transition #1 IBSEM Vehicle Transition #2 IBSEM Vehicle Transition #7 IBSEM Vehicle Transition #8 IBSEM Carrier Transition #1 IBSEM Carrier Transition #2 VehicleDepositStarted VehicleDepositCompleted VehicleArrived VehicleDeparted VehicleAcquireDeposit VehicleDepositAcquire CarrierInstalled CarrierRemoved Carrier Events The transport vehicle begins the process of placing the carrier onto the delivery location. Context Data: CarrierID, VehicleID, CarrierLocationID The carrier has been placed in the delivery location. The vehicle is now parked at the intended handoff location. In practice, this is qualified with the context variable that identifies the carrier(s) held on the vehicle: VehicleArrived-NoCarrier the carrier specified for this transfer command is not present on the vehicle. VehicleArrived-WithCarrier the carrier specified for this transfer command is present on the vehicle. These differentiate the case of a vehicle arriving to pick up the specified carrier versus a vehicle arriving to deliver the carrier. The vehicle is moving to a new location. (not used) Vehicle has completed the acquisition of a carrier from the port and begins delivery of a different carrier to the port. (not used) Vehicle has completed the delivery of a carrier to the port and begins acquisition of a different carrier from the port. (not used) This event is coincident with the VehicleAcquireCompleted event and is therefore not necessary. The event indicates that the carrier is in the control of the transport system. This occurs upon the acquisition of the carrier by the transport vehicle. Context Data: CommandID, CarrierID, CarrierLocationID, VehicleID (not used) This event is coincident with the VehicleDepositCompleted event and is therefore not necessary. The event indicates that the carrier is no longer in the control of the transport system. This occurs upon the delivery of the carrier to another factory entity, such as storage or production equipment. A2-1.6 The PTM method for transport systems does not support transitions #7 and #8 of the IBSEM vehicle state model in Level 4 Time Elements. These transitions represent Carrier Replace where the vehicle moves directly between the Depositing state and the Acquiring state. For example, a vehicle might have two carrier locations and will arrive at a handoff point with a carrier onboard. It would pick up a carrier from the port and then place the onboard carrier in the same port. A Support for Carrier Replace requires a user extension to handle these events. It would also require treating a single event as applying to two different carriers an implementation detail that would not otherwise be necessary. Page 24 Doc SEMI

27 RELATED INFORMATION 1 EXAMPLE MESSAGE SEQUENCES IN HOST-TSC COMMUNICATIONS NOTICE: This Related Information is not an official part of SEMI [designation number] and was derived from the work of the global [committee name] Technical Committee. This Related Information was approved for publication by full letter ballot procedures on [A&R approval date]. R1-1 Purpose R1-1.1 This Related Information provides example message sequences that might be found in Host-TSC communication message logs. These examples represent a subset of the possible messaging scenarios. The intent is to show how the time elements defined in Table 7 can be applied to a sequence of events. R1-2 TSC Event Sequences R1-2.1 The tables that illustrate the examples show one time element per row. A row contains the event that started the time element, the time element started by that event, and comments to help explain what is happening. The event that ends one time element begins the next row. To save space in the table, the end event of each time element is considered to be the start event of the time element in the following row. R1-2.2 All examples assume an OHT transport system. R1-3 TSC Example 1 Stocker-to-Production Equipment R1-3.1 Table R1-1 shows the sequence of events and associated time elements for the transport of a carrier directly from a stocker to a production equipment using a single transfer command. Table R1-1 TSC Example 1 Stocker-to-Production Equipment # Event Time Element Entered (Label) Comments 1 TransferInitiated WaitForVehicleAssign Transfer command has begun execution, but no OHT vehicle has been assigned. 2 VehicleAssigned-NoCarrier WaitForVehicleArrival An OHT vehicle has been assigned, but has not yet arrived at the stocker. 3 VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 4 VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. 5 VehicleAcquireCompleted WaitForVehicleDepart Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location. 6 VehicleDeparted ActiveCarrierTransport Carrier is being transported to the delivery location on an OHT vehicle. 7 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the delivery location. 8 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. 9 VehicleDepositCompleted WaitForJobCleanup Carrier is awaiting release from the transfer command. 10 TransferCompleted-ProdEqp ActiveInProdEqp Carrier has been delivered to a production equipment for processing. R1-4 Simple Variations on TSC Example 1 R1-4.1 The basic message sequence for production equipment to stocker in this scenario would be exactly the same for the first nine events/time elements. The last row would show the event TransferCompleted-NotProdEqp and time element Wait Time within Storage Location. Similarly, stocker-to-stocker and production equipment-to-production equipment scenarios would vary only by the last row, depending on the destination type. R1-4.2 This message sequence would expand if the TSC involves multiple vehicles in the transfer. The nature of the handoff between vehicles (direct or using additional resources) will determine the final message sequence in this case. Page 25 Doc SEMI

28 R1-4.3 A TransferCancelCompleted event could end the scenario in Table R1-1 after any of the first four steps. R1-4.4 Similarly, a TransferAbortCompleted event could end the scenario in Table R1-1 after any of the steps 4-8. A transfer abort would result in the carrier being left on the transport vehicle. This would also lead to a carrier reroute (see the following example and and for discussion of carrier reroute). R1-5 TSC Example 2 Carrier Reroute R1-5.1 Table R1-2 shows one way that a carrier reroute may occur. This is the case where the original transfer command is aborted while the carrier is on the vehicle for delivery. The delivery failed and a new transfer command was issued with a new destination. Table R1-2 TSC Example 2 Carrier Reroute # Event Time Element Entered (Label) Comments 1 TransferInitiated WaitForVehicleAssign Transfer command has begun execution, but no OHT vehicle has been assigned. 2 VehicleAssigned-NoCarrier WaitForVehicleArrival An OHT vehicle has been assigned, but has not yet arrived at the stocker. 3 VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 4 VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. 5 VehicleAcquireCompleted WaitForVehicleDepart Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location 6 VehicleDeparted ActiveCarrierTransport Carrier is being transported to the delivery location on an OHT vehicle. 7 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the delivery location. 8 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. 9 TransferAbortCompleted WaitInStorage The carrier remains in temporary storage on the OHT vehicle for a new transfer command to be issued. 10 TransferInitiated WaitForVehicleAssign Transfer command has begun execution, but no OHT vehicle has been assigned. 11 VehicleAssigned-WithCarrier ActiveCarrierTransport The vehicle holding the carrier was reassigned to the new transfer command. 12 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the new delivery location. 13 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. 14 VehicleDepositCompleted WaitForJobCleanup Carrier is awaiting release from the transfer command. 15 TransferCompleted-ProdEqp ActiveInProdEqp Carrier has been delivered to a production equipment for processing. R1-6 TSC Example 3 Transfer Using Multiple Vehicles R1-6.1 Table R1-3 shows a possible sequence of events and associated time elements for the transport of a carrier from a stocker to a production equipment using multiple vehicles. In this example, the handoff from one vehicle to the next occurs in a stocker in an intermediate location. Page 26 Doc SEMI

29 Table R1-3 TSC Example 3 Transfer Using Multiple Vehicles # Event Time Element Entered (Label) 1 TransferInitiated WaitForVehicleAssign Comments Transfer command has begun execution, but no OHT vehicle has been assigned. 2 VehicleAssigned-NoCarrier WaitForVehicleArrival An OHT vehicle has been assigned, but has not yet arrived at the stocker. 3 VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 4 VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. 5 VehicleAcquireCompleted WaitForVehicleDepart Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location. 6 VehicleDeparted ActiveCarrierTransport Carrier is being transported to the delivery location on an OHT vehicle. 7 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the handoff location a stocker where the second vehicle will pick up the carrier. 8 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle to a stocker for temporary storage before continuing its journey to the assigned destination. 9 VehicleDepositCompleted WaitForJobCleanup Carrier is temporarily held in the stocker until it can continue on its journey. 10 VehicleAssigned-NoCarrier WaitForVehicleArrival An OHT vehicle has been assigned, but has not yet arrived at the stocker. 11 VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 12 VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. 13 VehicleAcquireCompleted WaitForVehicleDepart Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location. 14 VehicleDeparted ActiveCarrierTransport Carrier is being transported to the delivery location on an OHT vehicle. 15 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the delivery location. 16 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. 17 VehicleDepositCompleted WaitForJobCleanup Carrier is awaiting release from the transfer command. 18 TransferCompleted-ProdEqp ActiveInProdEqp Carrier has been delivered to a production equipment for processing. R1-7 TSC Example 4 Transfer Using Multiple Transfer Commands R1-7.1 Table R1-4 shows an alternate sequence of events and associated time elements for the transport of a carrier from a stocker to a production equipment. In this case, the host has chosen the intermediate handoff location by issuing two separate transfer commands for the carrier. R1-7.2 This example shows a high degree of overlap between the two consecutive transfer commands for this carrier. Such overlap might be designed to gain efficiency in the transfer. R The degree of overlap between the two transfer commands may vary, but would not be expected to include time elements where both transfer commands are directly affecting the carrier. This is only one such variation. R It is also possible for no overlap to occur. This sequence would appear as two instances of Example 1 in succession, where the first delivered to a stocker and the second to a production equipment. R1-7.3 Rows associated with the first transfer command are numbered 1, 2, 3, etc. Rows associated with the second transfer command are lettered A, B, C, etc. Page 27 Doc SEMI

30 R1-7.4 Note that because of the overlap in the two transfer commands, some of the time elements that might otherwise be identified are not. The time elements are designed to give precedence to those that directly affect the carrier and then to time elements of the second transfer command. Table R1-4 TSC Example 4 Transfer Using Multiple Transfer Commands # Event Time Element Entered (Label) 1 TransferInitiated WaitForVehicleAssign 2 VehicleAssigned-NoCarrier WaitForVehicleArrival Comments Transfer command has begun execution, but no OHT vehicle has been assigned. An OHT vehicle has been assigned, but has not yet arrived at the stocker. 3 VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 4 VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. 5 VehicleAcquireCompleted WaitForVehicleDepart 6 VehicleDeparted ActiveCarrierTransport A TransferInitiated WaitForVehicleAssign N/A Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location. Carrier is being transported to the delivery location on an OHT vehicle. This event does not trigger a new time element because it occurs while the Active Time for Carrier Transport time element is in effect. 7 VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the delivery location. 8 VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. B VehicleAssigned-NoCarrier WaitForVehicleArrival N/A 9 VehicleDepositCompleted WaitForJobCleanup This event does not trigger a new time element because it occurs while the Active Time for Carrier Delivery time element is in effect. Carrier is awaiting release from the transfer command. C VehicleArrived-NoCarrier WaitForCarrierPickup Vehicle is parked at the pickup location. 10 TransferCompleted-Storage WaitInStorage N/A This event does not trigger a new time element because it occurs while the Wait for Carrier Pickup time element is in effect. D VehicleAcquireStarted ActiveCarrierPickup Carrier is being picked up by an OHT vehicle. E VehicleAcquireCompleted WaitForVehicleDepart Carrier is on the OHT vehicle, but it has not yet begun moving to the delivery location. F VehicleDeparted ActiveCarrierTransport Carrier is being transported to the delivery location on an OHT vehicle. G VehicleArrived-WithCarrier WaitForCarrierDeposit Vehicle is parked at the delivery location. H VehicleDepositStarted ActiveCarrierDelivery Carrier is being delivered by an OHT vehicle. I VehicleDepositCompleted WaitForJobCleanup Carrier is awaiting release from the transfer command. J TransferCompleted-ProdEqp ActiveInProdEqp Carrier has been delivered to a production equipment for processing. R1-7.5 This example does not imply that a transfer system is expected to queue transfer commands or begin execution of one transfer command for a carrier before the previous one is complete. This is left to the requirements of SEMI E82 and the discretion of the TSC implementer. Page 28 Doc SEMI

31 RELATED INFORMATION 2 LEVEL 5 USER EXTENSIONS NOTICE: This Related Information is not an official part of SEMI [designation number] and was derived from the work of the global [committee name] Technical Committee. This Related Information was approved for publication by full letter ballot procedures on [A&R approval date]. R2-1 Purpose R2-1.1 This Related Information is provided to provide guidance in the creation of Level 5 User Extensions to the standard PTM time elements. R2-2 Approach for Level 5 User Extensions R2-2.1 There are two ways the user might extend the time element definitions. One is to keep the specified start and end events but differentiate the time element based on a context variable. For example, CarrierLocation-Storage might be qualified with the name of a specific stocker or group of storage buffer locations. The associated time elements could then be specialized to a different one for each stocker or group of storage buffer locations. It is also possible to make this type of separation during data analysis, since the necessary context data is included in the PTMData file (see 9.4.3). R2-2.2 The other way to extend the time element definitions is to subdivide them into smaller time segments. This process involves adding a new event report that occurs between the start and end events of a specified time element. R2-2.3 The process involves replacing the original time element with two time elements. The first begins with the original start event and ends with the user-selected event. The second time element begins with the same user-selected event and ends with the original end event. This can be compared to adding a new link to a chain, where the old link is removed and the two new ones, already joined together, reconnect the two pieces of the chain. This is illustrated in Figure R2-1. Figure R2-1 Chain Link Replacement Illustration R2-2.4 User extensions are not specifically limited by this Specification. Page 29 Doc SEMI