What is the history of this issue and ballot? This is the first proposal of this new subordinate Specification.

Transcription

1 Background Statement for SEMI Draft Document 5750 REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR MATERIAL CONTROL 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 168) defines the concepts for creating an analysis-ready set of time elements. This Specification applies those concepts to semiconductor AMHS, addressing the material control system (MCS). 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 is believed to be available from existing MCS implementations. 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/3/ Lance Rist First working draft of SEMI Document # /15/ Lance Rist Completed some unfinished sections; editorial changes; alignment with the 5751 draft 11/25/ Lance Rist Updates based on TF inputs 12/8/ Lance Rist Updates based on TF inputs including some extended scenarios 12/19/ Lance Rist Updates based on TF discussion see attached resolved issues list for full detail; includes replacing carrier job accepted with carrier job executing event in most uses; handling of carrier job queuing; update/modification of several definitions; and rewording for clarity in numerous places 12/30/ Lance Rist Integration of TF feedback; adjustment of use of term AMHS; removal of some restrictions on MCS; spell check, pagination; added RequirementIDs 1/11/ Lance Rist Added limitation must use transport vehicle; reverted definitions to SEMI CoT versions for carrier, carrier location, transfer port, TSC; removed some text about ZFS; rearranged and updated 7 Overview; removed first row of Table 1 (unneeded) and updated related text just before the table; modified Table 2, last row; denoted conditional requirement RQ

2 1/28/ Lance Rist GEM 300 TF approved content for ballot with the following changes: term ZFS changed to storage buffer throughout; added to note that an event might need to be applied separately to different carriers; RQ was reworded; RequirementIDs were renumbered; Discussion subparagraphs added to some definitions 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 nonrequirements 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.02), 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 TC Chapter 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 5750 REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR MATERIAL CONTROL 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 material control system (MCS) as it relates to a semiconductor automated material handling system (AMHS). 2 Scope 2.1 This Document specifies the details needed to apply the PTM method to the MCS. It utilizes messages and data exchanged between the MCS and the factory information and control system (FICS). 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 domain of a factory s MCS. 3.2 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 MCS are not addressed. However, these are not specifically excluded from the scope and could be added at a later time. Many such scenarios are specific to a particular implementation. Page 1 Doc SEMI

4 3.3 This Specification addresses PTM using data typically available from messaging between the FICS and MCS. At the time this Specification was developed, the FICS-MCS interface was not specified in detail by any SEMI Standard. This Specification is not intended to define that interface or place restrictions upon it. Instead, certain event messages that are available in known MCS implementations and are thought to be generally necessary in any MCS are assumed to be available as prerequisites. This should not be construed as requirements placed upon the design of any MCS implementation. 3.4 This Specification is designed for factories where product is transported within carriers using transport vehicles. Application of the PTM method to other types of material or product moved without carriers is not addressed Carriers whose contents are not revealed in the PTM method s output data (called PTMData) can be assumed to contain product for the purpose of analysis. 3.5 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 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 ISO Standards 1 ISO 8601:2004 Data Elements and Interchange Formats Information Interchange Representation of Dates and Times 4.3 Internet Society (ISOC) 2 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 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 job a task commanded by the FICS to the MCS to move a carrier from one location to another carrier location a location in the AMHS which may correspond to a physical location or a virtual location. [SEMI E153] 1 International Organization for Standardization, ISO Central Secretariat, 1, Ch. De la Voie-Creuse, CP 56, CH-1211 Geneva 20, Switzerland; Telephone: , Fax: , 2 Internet Society (ISOC), 1775 Wiehle Avenue, Suite 201, Reston, VA 20190, USA, Page 2 Doc SEMI

5 Discussion In the context of this Specification, a carrier location holds a single carrier 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 Discussion This Specification assumes that the MCS is tasked only with moving carriers within the factory. See Limitations ( 3.3) 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 port point on 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 For the purpose of this Specification, the host of the TSC is the 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 MCS AMHS Communication Architecture A typical AMHS communication architecture in semiconductor factories is shown in Figure 1. In this hierarchy, the factory information and control system (FICS) sits at the top, issuing commands to one or more MCSs. The MCS coordinates the activities of transport systems (e.g., overhead hoist transport [OHT]) and storage systems (e.g., stockers). Page 3 Doc SEMI

6 7.1.3 MCS Concepts Figure 1 Typical AMHS Communication Architecture While SEMI Communication Standards exist that define a common set of messages exchanged with production equipment, transport systems, and stockers, there is no SEMI Standard that addresses the interface between the FICS and an MCS This Specification does not attempt to standardize such an interface. However, some basic features of the FICS-MCS interface were assumed based on details of the underlying standard interfaces for the transport system and stocker and upon inspection of message logs of communications between commonly used FICS and MCS software For some MCS implementations, the messaging has evolved directly from SECS-II communication interfaces. It is common for the interfaces to include commands from the FICS as well as MCS-initiated event reports and alarm messages. For the purpose of the PTM method, the important messages are the commands and event reports. The actual messaging technology used is not critical to the PTM method The basic concepts of the MCS domain include: carriers containers that hold product units carrier locations locations within the factory where carriers may reside and that are accessible to transport systems and stockers supervised by the MCS carrier jobs a task commanded by the FICS to move a carrier from one location to another These carriers, carrier locations, and carrier jobs are typically treated as objects with associated states. These states are typically reported by the MCS for tracking by the FICS. Selected state transitions for these items form the basis for most events used by the PTM method for MCS Because the FICS-MCS interface is not standard, the states of the carriers, carrier locations, and jobs, as well as the commands that affect those objects are also not standard 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 The term MCS event is used in this Specification to refer to most messages issued from the MCS to the FICS. These include messages initiated from MCS (e.g., event reports) and responses to FICS-initiated commands. Each MCS event signifies some occurrence within the MCS. Page 4 Doc SEMI

7 The MCS events chosen for use in the time elements in this Specification are only those most fundamental to FICS control and monitoring of the MCS. These include: Basic carrier job status: carrier job executing, carrier job aborted, and carrier rerouted o Note that other carrier job state transitions might be available for user extensions to the time elements, such as queued or on hold. User extensions are discussed in NOTE 1: User extensions are discussed in Related Information 2 also. o Carrier job request and accepted notifications are used to collect context data related to carrier jobs. o Carrier reroute is discussed in detail in Carrier location change to key locations, including stockers, production equipment, storage buffers, vehicles, manual input ports, and manual output ports. o Note that other carrier location transitions might be available for user extensions to the time elements, such as stocker input or output ports and stocker robot locations Carrier status events are not used because of the variation of potential states that could be defined. However, user extensions for specific systems may be created using carrier status events The MCS events described above are described in more detail in Table 1 in Implementers of the PTM method should note that certain events may apply to multiple product units or carriers. In that case, the events will need to be applied to each product unit or carrier separately as needed. For example, a transport vehicle might hold multiple carriers and its arrival at a new location might need to apply to both Carrier to Represent Product Units A significant challenge of using MCS data for PTM is that it typically does not contain product identification (e.g., LotID). FICS commands to the MCS are keyed on the CarrierID. The MCS is focused upon moving carriers. The content of the carrier has no bearing on the function of the MCS A full analysis of MCS data requires a mapping of product identification (e.g., 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 for the MCS 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 AMHS, 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 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. Page 5 Doc SEMI

8 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 carrier job 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 MCS 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 carrier job that includes a carrier reroute (see 9.5.6). Each time element related to such a carrier job is marked in the Reroute field of the PTMData file (see Table 4) 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 MCS 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 MCS events and, thus, all time elements apply equally to all substrates in the carrier Carrier Job Queuing and Overlap Some MCS implementations may allow carrier jobs for a carrier to be accepted and queued when another carrier job is already executing. There may be cases where a queued carrier job begins execution before the previous carrier job has completed For example, the second carrier job may start a vehicle to a stocker for carrier pickup before the previous carrier job has completed delivery of the carrier to that stocker The design of the time elements provides for this type of overlap, should it occur Carrier job 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 FICS-MCS communication logs shall conform to the requirements in SEMI E168. [/RQ] 8.2 Communication Interface Support [E168.ss-RQ ] A precondition for the FICS-MCS interface is support for the MCS events in Table 1. [/RQ] In order to standardize time elements for the MCS, a consistent set of MCS events reported to the FICS needs to be available in the FICS-MCS communication log for processing using the PTM method. A limited set of MCS events has been presented in Table 1. These events are believed to be necessary in any MCS and thus can be expected to be present in an MCS communication log. Page 6 Doc SEMI

9 Table 1 MCS Events Needed in FICS-MCS Interface RequirementID MCS Event Description E168.ss-RQ CarrierJob-Accepted E168.ss-RQ CarrierJob-Executing E168.ss-RQ CarrierJob-Aborted Affirmative response from the MCS to accept a job request/command. This event is used only to provide context (e.g. JobID), Notification that the carrier job has begun execution. The timing of this event may vary slightly from one MCS implementation to another, but it shall be reported no later than the first physical motion related to the carrier job, including motion of a vehicle toward the pickup location. Carrier job has been terminated prior to completion. Abort and cancel are not differentiated for MCS in this Specification. Both are represented by this event. Note that the carrier might be left on a vehicle with a subsequent carrier job required to move the carrier to a storage or production equipment location. The destination for the carrier has been changed. This event is used as an E168.ss-RQ CarrierJob-Rerouted indicator event only (see 9.5.6). It is not used to delineate time elements. For example, the original destination load port might be occupied when the vehicle arrives at the equipment. E168.ss-RQ CarrierLocation-Storage Carrier location changed to storage E168.ss-RQ CarrierLocation-ProdEqp Carrier location changed to production equipment E168.ss-RQ CarrierLocation-Vehicle Carrier location changed to vehicle E168.ss-RQ CarrierLocation-ManualIn Carrier location changed to manual input port E168.ss-RQ CarrierLocation-ManualOut Carrier location changed to manual output port The events listed in Table 1 might be implemented as specific events (e.g., CarrierJob-Aborted) or reported as more general events with context data included (e.g., CarrierJobStateChanged with JobState = Aborted ). Either approach is acceptable Event names in Table 1 might not match those used in the MCS implementation. The description of the event should be used to match the set of needed events with equivalent events present in the MCS communication log. [E168.ss-RQ ] FICS-MCS communication logs for the selected system shall be made available for processing by the PTM method. [/RQ] Note that if the factory utilizes multiple material control 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 FICS-MCS 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 the SEMI E168 and in SEMI E A key part of data quality is synchronization of MCS clock(s) with the factory system time. The clock used by the MCS 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. Page 7 Doc SEMI

10 [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 MCS. [E168.ss-RQ ] The requirements in this Specification apply only to communications exchanged between the FICS and an MCS. [/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 FICS and an MCS. 9.4 Product Time Data Set Construction Product Time Inputs [E168.ss-RQ ] In order to support PTM for MCS, the data specified in Table 2 shall be provided. [/RQ] Table 2 Data Required for PTM for Material Control Systems RequirementID Required Data Description E168.ss-RQ E168.ss-RQ E168.ss-RQ E168.ss-RQ Communication Log MCS Event Documentation Data Variable Documentation Event Configuration A record of the messages exchanged between FICS and MCS during the time period specified for analysis. This can be a message log recorded by the FICS or by the MCS. 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 MCS events supported by the MCS. The documentation for each event shall include the event identifier (EventID), the supplier name for the event, and a description of when and why the event occurs. See Table 1 for a list of the MCS events used in this Specification. A list of the data variables available for reporting with each MCS event. 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. If MCS event configuration is possible, a list of the events enabled for reporting and the data variables associated with each event report at the time the communication log was recorded shall be provided FICS-MCS Communication Log The communication log format for the FICS-MCS 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., if it is a SECS-II interface, then stream and function), b) a timestamp associated with the message, and c) all data items from the original message. [/RQ] User Configuration The details of user configuration are implementation specific. However, some systems follow SECS-II practices for configuration, which include user selection of data variables to include in event reports and then linking the event reports to selected events for reporting Requirement RQ in Table 2 addresses documentation of this type of user configuration. Page 8 Doc SEMI

11 9.4.2 Product Time Data Transformations This section builds upon the data transformation steps defined in SEMI E Step 1 Communication Log Normalization no additional comment Step 2 Message Filtering [E168.ss-RQ ] The message filtering step shall retain all messages related to commands and status changes for the carriers, carrier jobs, and carrier locations. [/RQ] Step 3 Data Code Translation The MCS event documentation (see RQ-00017), data variable documentation (see RQ-00018), and user configuration (see RQ-00019) serve as the inputs to the data code translation Step 4 Context Data Population Because the FICS-MCS interface is not standard, the context data population will depend on the specific MCS implementation. There are five context variables that are considered here: CarrierID The identifier of the carrier that holds the product unit(s). This is likely to appear in most MCS messages. JobID The identifier of the carrier job that is currently associated with the carrier 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 vehicle currently being used in the carrier job. 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 MCS or is not populated in the messages The actual names of these variables may vary among MCS implementations, but the concepts tend to be very similar Timestamps need to be included with each message in the log (see RQ-00021) 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 3) and adds new fields specific to the FICS-MCS interface (see Table 4) Unaffected fields are not included The field order, as specified in the primary Standard, is not affected. [E168.ss-RQ ] The requirements for each field specified in Table 3 shall be added to the requirements for those same PTMData fields as specified in SEMI E168. [/RQ] Page 9 Doc SEMI

12 Table 3 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) This field may be left blank if the LotID is unavailable to the MCS. Note that the LotID and SubstrateID may need to be filled in from an external source, since it is typically not available in FICS-MCS communication logs Identifier of the substrate relevant to this time element (for appropriate time elements) This field may be left blank when lot-level data is created or when the SubstrateID is unavailable to the MCS. Substrate location identifier relevant to this time element (for appropriate time elements) For FICS-MCS 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 4 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 4 Added PTMData Fields to Support FICS-MCS Communications RequirementID Field Description Format E168.ss-RQ JobID Identifier of the carrier job for MCS Text E168.ss-RQ Reroute This field identifies those carrier jobs or commands where the destination is changed during the operation (e.g., carrier reroute). Each time element for such a carrier job or command shall be identified with Reroute value for this field. Text: Reroute or zero length string Where the description field in Table 3 includes the text for appropriate time elements, the requirement applies only for time elements based upon events that include that data. 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 MCS domain. Page 10 Doc SEMI

13 9.5.2 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 MCS domain. [E168.ss-RQ ] The Level 3 time elements that are subcategories of Wait Time are: o Wait for System o Wait for Factory Personnel [/RQ] [E168.ss-RQ ] The Level 3 time elements that are subcategories of Active Time are: o Active Time for MCS o Active Time for Production Equipment [/RQ] Table 5 shows the Level 3 time elements with their associated parent categories. Table 5 Level 3 Time Elements Level 1 Level 2 Level 3 Product Time Wait Time Active Time Wait for System Wait for Factory Personnel Active Time for MCS Active Time for Production Equipment Level 4 Detailed Time Elements Level 4 time elements provide the finest level of detail defined in this Specification. These are shown in Table 6 (wait time elements) and Table 7 (active time elements) The set of Level 4 time elements applies both to lot-level and substrate-level data. Table 6 Level 4 Wait Time Elements Wait for System Level 3 RequirementID Level 4 E168.ss-RQ E168.ss-RQ Wait Time at Storage Location Wait For Carrier Job Revision Wait for Factory Personnel E168.ss-RQ Wait for Carrier Return to AMHS Table 7 Level 4 Active Time Elements Level 3 RequirementID Level 4 Active Time for MCS Active Time for Production Equipment Context Information E168.ss-RQ E168.ss-RQ E168.ss-RQ E168.ss-RQ Active Time for Carrier Acquisition Active Time for Carrier Relocation Active Time for Carrier Import Active Time at Production Equipment MCS events are used to mark the beginning and end of each time segment. However, the identity of the event is not sufficient for the assignment of time elements. Context information needs to 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 RQ and ). Page 11 Doc SEMI

14 Carrier Location In the definition of time elements where location may be used to qualify an MCS event, the locations are grouped according to type For the MCS domain, five types of carrier locations have been identified. These are described in RQ Some MCS events referenced in Table 8 are qualified with these location types. [E168.ss-RQ ] Carrier locations visible within the FICS-MCS 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. Manual Input Port a port on a stocker where factory personnel can place a carrier for input into the AMHS. Manual Output Port a port on a stocker where factory personnel can pick up a carrier that is output from the AMHS. [/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 (see 9.5.7). NOTE 2: See Related Information 2 also Level 4 Time Element Definitions Table 8 defines each of the Level 4 time elements listed in Table 6 and Table The time elements in Table 8 are not listed in chronological order. The order of the time elements is dependent, to some degree, on factors such as implementation choices, MCS design, and factory situation. NOTE 3: Please see Related Information 1 for example sequences of messages and time elements. [E168.ss-RQ ] When applied to an MCS, the PTM method shall use the time elements as defined in Table 8. [/RQ] Table 8 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 MCS event that will start this time element The identifier of each MCS event that will end this time element Each EventID mentioned in the bullets above is followed by text explaining the significance of the MCS 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. Page 12 Doc SEMI

15 Level 2 and Level 3 time elements are provided as divider rows above their Level 4 time elements listed in Table 8. Table 8 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 System (Level 3) E168.ss-RQ E168.ss-RQ Wait Time at Storage Location (WaitAtStorage) Wait for Carrier Job Revision (WaitForJobRevision) Time Element Definition The carrier is awaiting a carrier job to move it to a new location. Start: CarrierLocation-Storage Carrier was delivered to a storage location. End: CarrierJob-Executing The FICS request to transport a carrier has begun execution. or CarrierLocation-Vehicle The carrier is on a transport vehicle. When the end event is CarrierLocation-Vehicle, this indicates the occurrence of a handoff of the carrier from one vehicle to another via a stocker during a carrier job. In this case, note that the product time for the acquisition of the carrier from the storage location during this handoff is included in the Wait Time at Storage Location time element. A carrier job has been aborted and a new destination must be determined. An aborted carrier job may leave a carrier in its original location or somewhere in transit to the previous destination. Start: CarrierJob-Aborted The carrier job has been terminated prior to completion. End: CarrierJob-Executing The FICS request to transport a carrier has begun execution. or CarrierLocation-Vehicle The carrier is on a transport vehicle and will be delivered to the new destination. E168.ss-RQ Wait for Factory Personnel (Level 3) E168.ss-RQ Wait for Carrier Return to MCS (WaitForCarrierReturn) A carrier that was removed by factory personnel from a stocker manual output port is later returned to a stocker manual input port. During this time, the carrier is outside the control of the MCS. Start: CarrierLocation-ManualOut The carrier has been placed in the manual output port of the stocker for pickup by factory personnel. End: CarrierLocation-ManualIn The carrier has been placed on a manual input port of a stocker by factory personnel. Page 13 Doc SEMI

16 RequirementID Level 4 Time Element Name (Label) E168.ss-RQ Active Time Elements (Level 2) E168.ss-RQ Active Time for MCS (Level 3) E168.ss-RQ Active Time for Carrier Acquisition (ActiveCarrierAcquisition) Time Element Definition The carrier is being picked up by a transport vehicle from a storage or production location. This is termed an active time element, but contains aspects of both active time (carrier pickup) and wait time (waiting for vehicle arrival). Start: CarrierJob-Executing The FICS request to transport a carrier has begun execution. End: CarrierLocation-Vehicle The carrier is on a transport vehicle. or CarrierLocation-ManualOut The carrier has been placed in the manual output port of the stocker for pickup by factory personnel. or CarrierJob-Aborted The carrier job has been terminated prior to completion. A CarrierJob-Storage event that occurs during this time element shall not start a new time element. NOTE 4: See Related Information 1, Table R1-8 for an example that illustrates the reason for the special case for the CarrierJob- Storage event above. E168.ss-RQ Active Time for Carrier Relocation (ActiveCarrierRelocation) The carrier is being transported by the transport vehicle and delivered to the destination location. Start: CarrierLocation-Vehicle The carrier is now on the transport vehicle. End: CarrierLocation-Storage Carrier has been delivered to a storage location (e.g., stocker or zero-footprint storage) or CarrierLocation-ProdEqp Carrier has been delivered to a production equipment load port. or CarrierLocation-Vehicle Carrier is handed off directly to another transport vehicle. or CarrierJob-Aborted The carrier job has been terminated prior to completion. Page 14 Doc SEMI

17 RequirementID E168.ss-RQ Level 4 Time Element Name (Label) Active Time for Carrier Import (ActiveCarrierImport) Time Element Definition The carrier was placed on the manual input port of a stocker and is being imported into the MCS and stored in the stocker. Start: CarrierLocation-ManualIn The carrier is now on the manual input port of a stocker. End: CarrierLocation-Storage Carrier has been accepted into the MCS and delivered to a storage location within the stocker. or CarrierJob-Executing Carrier has been accepted into the MCS and the FICS has begun execution of a carrier job to move it to a location outside of the stocker. or CarrierLocation-Vehicle Carrier has been accepted into the MCS and the MCS has created a carrier job to move it to a location outside of the stocker. E168.ss-RQ Active Time for Production Equipment (Level 3) E168.ss-RQ Active Time at Production Equipment (ActiveAtProdEqp) The carrier has been delivered to a production equipment for processing. During this time, the carrier is outside the control of the MCS. The product unit is assumed to be active during its entire stay. Start: CarrierLocation-ProdEqp The carrier has been delivered to the load port of a production equipment by the transport system. End: CarrierJob-Executing The FICS request to transport a carrier has begun execution. or CarrierLocation-ManualIn The carrier appears at a manual input port at a stocker. The carrier was picked up manually from the production equipment and later returned to the stocker Carrier Reroute Indicators Carrier reroute is described in A carrier reroute may occur at almost any point during a job. It can be identified by one or more related events that occur during the span of a job 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 carrier job 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 4 is set to Reroute for all time elements related to a carrier job that has been identified as rerouted If the carrier reroute is initiated by the MCS, 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 MCS. There are two common approaches. One approach is to change the destination in a currently active carrier job. A second approach is to terminate the current carrier job and have the FICS or the MCS initiate a subsequent carrier job to move the carrier to a new location. An implementation could include both approaches. NOTE 5: There is an example scenario provided in Related Information 1 to illustrate carrier reroute The following are examples of events that might be used as reroute indicator events: Page 15 Doc SEMI

18 CarrierJob-Aborted In this case, there is a new carrier job created to deliver the carrier to the new location. The time elements for the carrier job that was aborted and the subsequent carrier job should both be flagged with Reroute. CarrierJob-Rerouted This indication of a reroute typically occurs in the case where the carrier job continues, but the destination has been changed. CarrierJob-Accepted The host may request a change to an existing carrier job. If this request is accepted, it indicates that the destination is likely to have changed. Also, the host, in the case where an existing job is aborted while the carrier is on a vehicle traveling to the destination, a new carrier job for that carrier may be requested. The time elements for the carrier job that was changed or aborted and the subsequent carrier job (if applicable) should be flagged with Reroute. An event that ends the Active Time for Carrier Relocation time element, but which references a location that is different than the one in the CarrierJob-Request o User Extensions Level 5 Detection of the change of destination in this way can be more difficult in practice than simply noting receipt of an event. This approach should be used only if no other event is available for this purpose 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 6: Also, this concept is discussed in Related Information 2 as it relates to the MCS 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 16 Doc SEMI

19 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 17 Doc SEMI

20 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> 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> Compliance Codes (C/NC/WC/NA) 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 9 E168.ss-RQ None <none> 9 E168.ss-RQ E168.ss-RQ <none> Capability: 9.4 Product Time Data Set Construction 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 EventReportingConfigurable= E168.ss-RQ E168.ss-RQ <none> E168.ss-RQ E168.ss-RQ <none> Capability: Product Time Data Transformations Page 18 Doc SEMI

21 Section RequirementID Parent RequirementID Condition/Selection Criteria 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> 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) 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 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 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> 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> 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 EventReportingConfigurable True True Event reporting for the MCS can be configured by either enabling/disabling events or associating data with event reports False False Event reporting for MCS cannot be configured. Page 20 Doc SEMI

23 RELATED INFORMATION 1 EXAMPLE MESSAGE SEQUENCES IN FICS-MCS 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 MCS 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 8 can be applied to a sequence of events. R1-2 MCS Event Sequences R1-2.1 The tables that illustrate the examples show one time element per row. A row contains the MCS event that started the time element, the time element started by that event, and comments to help explain what is happening. The MCS 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-3 MCS Example 1 Stocker-to-Production Equipment R1-3.1 Table R1-1 shows the sequence of MCS events with associated time elements for the transport of a carrier from a stocker to a production equipment. Table R1-1 MCS Example 1 Stocker-to-Production Equipment # MCS Event Time Element Entered (Label) 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-Vehicle ActiveCarrierRelocation 3 CarrierLocation-ProdEqp ActiveAtProdEqp Comments Carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to the production equipment. Carrier is at the production equipment for processing. R1-3.2 More complex scenarios will occur if the carrier changes vehicles along the delivery route. This would result in additional CarrierLocation-Vehicle events. There might also be CarrierLocation-Storage events if the change to a new vehicle uses the storage location as a temporary buffer for the handoff. R1-4 MCS Example 2 Production Equipment-to-Stocker R1-4.1 Table R1-2 shows the sequence of MCS events with associated time elements for the transport of a carrier from a production equipment to a stocker. It differs from the previous example only in the final time element. Table R1-2 MCS Example 2 Production Equipment-to-Stocker # MCS Event Time Element Entered (Label) 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-Vehicle ActiveCarrierRelocation 3 CarrierLocation-Storage WaitAtStorage Comments Carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to the stocker. The carrier is awaiting a carrier job to move it to a new location. Page 21 Doc SEMI

24 R1-3 MCS Example 3 Carrier Manual Output and Return R1-3.1 Table R1-3 shows the sequence of MCS events with associated time elements that typically occurs when a carrier is removed from the manual output of a stocker and later returned to the manual input of a stocker. In this case, the handoff is between factory personnel and the stocker. Table R1-3 MCS Example 3 Carrier Manual Output and Return # MCS Event Time Element Entered (Label) 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-ManualOut WaitForCarrierReturn 2 CarrierLocation-ManualIn ActiveCarrierImport 3 CarrierLocation-Storage WaitAtStorage Comments Carrier job is active; the carrier is moved to the manual output port of the stocker. Carrier is on the manual output port and will be removed by factory personnel. Carrier is being imported into the MCS and stored in the stocker. The carrier is awaiting a carrier job to move it to a new location. R1-4 MCS Example 4 Carrier Manual Input To Location Outside The Stocker R1-4.1 Table R1-4 shows the sequence of MCS events with associated time elements that is likely to occur when a carrier is placed on a manual input port and, as a result, is directed by the FICS to a location outside that stocker (in this case, another stocker). Table R1-4 MCS Example 4 Carrier Manual Input To Location Outside The Stocker # MCS Event Time Element Entered (Label) 1 CarrierLocation-ManualIn ActiveCarrierImport 2 CarrierJob-Executing ActiveCarrierAcquisition 3 CarrierLocation-Vehicle ActiveCarrierRelocation 4 CarrierLocation-Storage WaitAtStorage Comments Carrier was placed on the manual input port at a stocker and is being imported into the MCS. The MCS has begun executing a carrier job to move the carrier to another stocker. The carrier was placed on a vehicle and is being transported and delivered to the destination location. The carrier is awaiting a carrier job to move it to a new location. R1-4.2 A variation on this scenario is one in which the MCS decides to store the carrier in another stocker (e.g., because the local stocker is full). The scenario should differ from that in Table R1-4 only by the absence of step #2 - the CarrierJob-Executing event would not occur and the Active Time for Carrier Acquisition time element would not be recorded. In some cases, this scenario would be the same as Example 4 if the MCS creates a carrier job for this purpose without a request from the FICS. R1-5 MCS Example 5 Carrier Reroute R1-5.1 Table R1-5 shows the sequence of MCS events with associated time elements that might occur when a carrier is rerouted. Since the rerouting can occur at different points in a normal transfer, this is one of several variations on this scenario. R1-5.2 Carrier reroutes often occur during transport to production equipment when there is some problem with destination availability or with delivery of the carrier. The carrier is typically returned to a storage location to await further instructions. Page 22 Doc SEMI

25 Table R1-5 MCS Example 5 Carrier Reroute # MCS Event Time Element Entered (Label) Comments 1 CarrierJob-Executing ActiveCarrierAcquisition Carrier job is active; the vehicle moves to the stocker and picks up the carrier. 2 CarrierLocation-Vehicle ActiveCarrierRelocation Vehicle transports the carrier, intending to deliver it to the production equipment. 3 CarrierLocation-Rerouted <carrier reroute indicator event> Carrier has a new destination. 4 CarrierLocation-Storage WaitAtStorage The carrier is awaiting a carrier job to move it to a new location. R1-6 MCS Example 6 Transfer Using Multiple Vehicles R1-6.1 Table R1-6 shows a sequence of events with associated time elements that may occur when the carrier job includes that handoff of the carrier from one vehicle to another during the job. In some systems, a handoff directly from one vehicle to another is possible. However, it is common for the handoff to involve stockers and/or storage locations. The latter case is illustrated in this example. Table R1-6 MCS Example 6 Transfer Using Multiple Vehicles # MCS Event Time Element Entered (Label) 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-Vehicle ActiveCarrierRelocation 3 CarrierLocation-Storage WaitAtStorage 4 CarrierLocation-Vehicle ActiveCarrierRelocation 5 CarrierLocation-Storage WaitAtStorage Comments Carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to stocker where the carrier handoff to the new vehicle will occur. The carrier is held at the storage location or in the stocker and then picked up by the new vehicle. Vehicle transports the carrier and delivers it to the destination location. The carrier is awaiting a carrier job to move it to a new location. R1-6.2 Using only the limited set of events allowed for in this Specification, the acquisition of the carrier by the second vehicle in Step #3 of Table R1-6 is concealed in the CarrierLocation-Storage time element. It is recommended that analysis of the time elements for this scenario separate the Wait Time at Storage Location time elements that occur between carrier jobs from those that occur during the carrier jobs. The latter will contain product time for carrier acquisition while the former does not. R More detailed data may be available from the transport system that will allow the acquisition time to be separated from the time spent in the storage location. See Related Information 3 for a discussion of merging detailed data from transport systems with the MCS time elements. R1-7 MCS Example 7 Transfer Using Multiple Carrier Jobs R1-7.1 Table R1-7 shows a sequence of events with associated time elements that may occur when transfer from stocker to production equipment occurs in two steps specified by two different carrier jobs. This transfer is similar to MCS Example 6 above, except that the FICS mandates the intermediate handoff by issuing multiple carrier jobs. R1-7.2 This sequence assumes that the FICS issues two separate carrier jobs. The first is a transfer from one stocker to another. The second is a transfer from the second stocker to a production equipment. The second carrier job is requested immediately following the first and queued for execution as soon as the first carrier job completes. Page 23 Doc SEMI

26 Table R1-7 MCS Example 7 Transfer Using Multiple Carrier Jobs # MCS Event Time Element Entered (Label) Comments 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-Vehicle ActiveCarrierRelocation 3 CarrierLocation-Storage WaitAtStorage 4 CarrierJob-Executing ActiveCarrierAcquisition 5 CarrierLocation-Vehicle ActiveCarrierRelocation 6 CarrierLocation-ProdEqp ActiveAtProdEqp The first carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to stocker where the carrier handoff to the new vehicle will occur. The carrier is held at the storage location or in the stocker and then picked up by the new vehicle. The second carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to the destination location. Carrier is at the production equipment for processing. R1-7.3 A more complex scenario will occur if the MCS is optimized to start the second carrier job before the first is complete. Table R1-8 shows an example of this case. It assumes that the first event of the second carrier job (CarrierJob-Executing) occurs before the last event of the first carrier job (CarrierLocation-Storage). That creates overlap between the first and last time elements of the two carrier jobs. In normal circumstances, this is the largest overlap that should occur. R1-7.4 The time element definitions have been designed to handle this overlap by giving precedence to the Active Time for Carrier Acquisition time element that begins the second carrier job. Table R1-8 MCS Example 7A Alternative Transfer Using Multiple Carrier Jobs # MCS Event Time Element Entered (Label) Comments 1 CarrierJob-Executing ActiveCarrierAcquisition 2 CarrierLocation-Vehicle ActiveCarrierRelocation 3 CarrierJob-Executing ActiveCarrierAcquisition CarrierLocation-Storage Wait Time at Storage Location N/A 4 CarrierLocation-Vehicle ActiveCarrierRelocation 5 CarrierLocation-ProdEqp ActiveAtProdEqp The first carrier job is active; the vehicle moves to the stocker and picks up the carrier. Vehicle transports the carrier and delivers it to stocker where the carrier handoff to the new vehicle will occur. The second carrier job is active; the vehicle moves to the stocker and picks up the carrier. This event does not trigger a new time element because it occurs while the Active Time for Carrier Acquisition time element is in effect. Vehicle transports the carrier and delivers it to the destination location. Carrier is at the production equipment for processing. R1-7.5 This example does not imply that an MCS is expected to queue carrier jobs or begin execution of one carrier job for a carrier before the previous one is complete. This is completely at the discretion of the MCS implementer. Page 24 Doc SEMI

27 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. Some possible user extensions are discussed below. R2-3 Carrier Job Status Events R2-3.1 The two carrier job events used in the Level 4 time elements are CarrierJob-Executing and CarrierJob-Aborted. Four others are use as carrier reroute indicator events or for context data: CarrierJob-Rerouted, CarrierJob-Aborted, CarrierJob-Request, and CarrierJob-Accepted are used for context data. Other carrier job states may be reported (see ). Such events may vary from one MCS implementation to another. R2-3.2 The user of the PTM method could create Level 5 time elements by subdividing existing time elements using these additional carrier job status events. Page 25 Doc SEMI

28 R2-4 Carrier Location Changed Events R2-4.1 The Level 4 time element definitions use carrier location changed events for only a few of the carrier locations that could exist within the domain of the MCS. Changes to intermediate locations on the path are ignored. R2-4.2 The user of the PTM method could create Level 5 time elements by subdividing existing time elements using these additional carrier location changed events. R2-4.3 The user of the PTM method could also create Level 5 time elements by using the method described in R2-2.1 to differentiate specified locations rather than use only the location type. Page 26 Doc SEMI

29 RELATED INFORMATION 3 MERGING PTM DATA SETS 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]. R3-1 Purpose R3-1.1 This Related Information is provided to introduce the topic of combining PTM data sets from different sources. R3-1.2 This topic is included with the PTM method for MCS because the MCS data provides a kind of high-level view of product as it moves through the factory. R3-1.3 The details of the process of merging PTM data sets is beyond the scope of this Related Information. It is limited to introducing the topic and identifying points that should be considered in the merging process. R3-2 PTM Data Sets R3-2.1 PTM data sets may be available from different areas of the factory. In addition to the higher-level MCS data, there may be data available related to production equipment, transport systems, and stockers. Each of these three provides a higher level of detail than is provided in the MCS data. R3-2.2 For example, the MCS knows that a carrier is delivered to a production equipment and then picked up from that equipment at some later time. There is no indication in the MCS data of what happens to the material in the carrier while at the production equipment. R3-2.3 Thus, the MCS data allows a user to link together sets of detailed information and follow product through the factory. Figure R3-1 illustrates the concept of merging PTM data sets. R3-3 Considerations for Merging PTM Data Figure R3-1 Concept Illustration for PTM Data Merging R3-3.1 In an ideal world, an MCS time element could be replaced directly by a set of production equipment or transport system or stocker time elements. A barrier to this direct substitution is that the start and end events for the MCS time element would need to exactly coincide with events that occur in the domain of the production equipment, etc. In some cases, this correspondence may exist. However, in other cases, there are time offsets. R For example, a production equipment may declare that a carrier is present once it appears in the equipment s load port and the transport vehicle has released it. The MCS might not consider it delivered to the load port until the gripper mechanism has been retracted into the transport vehicle. R These offsets need to be accounted for. PTM assumes that it covers 100% of the time from the start to end of the duration under consideration. R The offset may represent a gap that can be filled in by constructing a new time element to assign to the gap. This can be thought of as a glue time element. R The offset may also represent an overlap. In this case, the time elements must be adjusted. The best approach for this is to allow the event from the more detailed data set to replace the corresponding one from the MCS data. This does cause a small change to the MCS time elements, but this should not detract from the value of the result. Page 27 Doc SEMI