downloads.semi.orgdownloads.semi.org/.../$FILE/5750.docx · Web viewSemiconductor Equipment and Materials International. 3081 Zanker Road. San Jose, CA 95134-2127. Phone: 408.943.6900,

Background Statement for SEMI Draft Document 5750REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR MATERIAL CONTROL SYSTEMS TO SEMI E168-1114, 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 ControlThis 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 Edits11/3/14 0.1 Lance Rist First working draft of SEMI Document #5750

11/15/14 0.2 Lance Rist Completed some unfinished sections; editorial changes; alignment with the 5751 draft

11/25/14 0.3 Lance Rist Updates based on TF inputs12/8/14 0.4 Lance Rist Updates based on TF inputs including some extended scenarios

12/19/14 0.5 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/14 0.6 Lance RistIntegration of TF feedback; adjustment of use of term AMHS; removal of some restrictions on MCS; spell check, pagination; added RequirementIDs

DRAFTDocument Number:

Date: 5/6/23

Date Version Name Edits

1/11/15 0.7 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-00019.

1/28/15 1.0 Lance Rist

GEM 300 TF approved content for ballot with the following changes: term ZFS changed to ‘storage buffer’ throughout; added 7.1.4.4 to note that an event might need to be applied separately to different carriers; RQ-00003 was reworded; RequirementIDs were renumbered; Discussion subparagraphs added to some definitions

A Note on Requirements ID’sRequirements 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 DefinitionsSEMI encourages the reuse of existing definitions of terms wherever possible. The SEMI Standards Procedure Guide, Section 3.11.3, 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 http://www.semi.org/standards under Calendar of Events for the latest update.

Review and Adjudication InformationTask Force Review Committee Adjudication

Group: Wait Time Waste Task Force North America Metrics TC ChapterDate: March 30, 2015 April 1, 2015Time & Time Zone: 3:00 PM – 6:00 PM PST 2:00 PM – 5:00 PM PSTLocation: SEMI Headquarters SEMI HeadquartersCity, State/Country: San Jose, CA / USA San Jose, CA / USALeader(s): Lance Rist – RistTex David Bouldin – Fab Consulting

Mark Frankfurth – CymerStandards Staff: Michael Tran

[email protected]

Michael [email protected]

This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.

Page 1 Doc. jn l SEMI

Semiconductor Equipment and Materials International3081 Zanker RoadSan Jose, CA 95134-2127Phone: 408.943.6900, Fax: 408.943.7943


Date: 5/6/23

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.





Date: 5/6/23

SEMI Draft Document 5750REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR PRODUCT TIME MEASUREMENT FOR MATERIAL CONTROL SYSTEMS TO SEMI E168-1114, SPECIFICATION FOR PRODUCT TIME MEASUREMENT

Contents

1 PURPOSE........................................................................................................12 SCOPE............................................................................................................13 LIMITATIONS...................................................................................................14 REFERENCED STANDARDS AND DOCUMENTS....................................................25 TERMINOLOGY................................................................................................26 CONVENTIONS................................................................................................37 IMPLEMENTATION OVERVIEW...........................................................................38 PREREQUISITES...............................................................................................69 REQUIREMENTS...............................................................................................710 TEST METHODS...........................................................................................1611 RELATED DOCUMENTS.................................................................................16APPENDIX 1.....................................................................................................17

1 Purpose1.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 Scope2.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 Limitations3.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.





Date: 5/6/23

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.

3.4.1 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 Documents4.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 Standards1

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, http://www.ntp.org)

NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.

5 Terminology5.1 Note that terms from the Primary Standard also apply to this Specification.

5.2 Abbreviations and Acronyms

5.2.1 MCS — material control system

5.2.2 NTP — Network Time Protocol

5.2.3 OHT — overhead hoist transport

5.2.4 TSC — transport system controller

5.3 Definitions

5.3.1 carrier — a container with one or more fixed positions at which material may be held. [SEMI E30.1]

5.3.2 carrier job — a task commanded by the FICS to the MCS to move a carrier from one location to another

5.3.3 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: 41.22.749.01.11, Fax: 41.22.733.34.30, http://www.iso.org2 Internet Society (ISOC), 1775 Wiehle Avenue, Suite 201, Reston, VA 20190, USA, http://www.internetsociety.org




http://www.ntp.org/

http://www.internetsociety.org/

http://www.iso.org/


Date: 5/6/23

5.3.3.1 Discussion — In the context of this Specification, a carrier location holds a single carrier.

5.3.4 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.

5.3.5 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.

5.3.5.1 Discussion — This Specification assumes that the MCS is tasked only with moving carriers within the factory. See Limitations (¶ 3.3 ).

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]

5.3.7 storage buffer — a set of one or more locations for storing carriers in the transport system. [SEMI E82]

5.3.7.1 Discussion — A storage location is a type of carrier location.

5.3.8 storage location — a specific type of carrier location that is used for carrier storage. [SEMI E153]

5.3.8.1 Discussion — Stockers and storage buffers contain storage locations.

5.3.9 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]

5.3.10 transport system — the component of AMHS that moves material from one part of the factory to another. [SEMI E88]

5.3.11 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]

5.3.11.1 Discussion — For the purpose of this Specification, the host of the TSC is the MCS.

5.3.12 transport vehicle — a component of a transport system that transports material between factory locations.

5.3.12.1 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 Conventions6.1 Conventions from the Primary Standard also apply to this Specification. There are no additional conventions.

7 Implementation Overview7.1.1 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.

7.1.2 AMHS Communication Architecture

7.1.2.1 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).





Date: 5/6/23

Figure 1Typical AMHS Communication Architecture

7.1.3 MCS Concepts

7.1.3.1 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.

7.1.3.2 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.

7.1.3.3 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.

7.1.3.4 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

7.1.3.5 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.

7.1.3.6 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.

7.1.3.7 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.

7.1.4 Events

7.1.4.1 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.





Date: 5/6/23

7.1.4.2 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 § 9.5.7 .

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 § 9.5.6 .

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.

7.1.4.2.1 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.

7.1.4.3 The MCS events described above are described in more detail in Table 1 in § 8.2 .

7.1.4.4 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.

7.1.5 Carrier to Represent Product Units

7.1.5.1 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.

7.1.5.2 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.

7.1.5.3 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.

7.1.5.4 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.

7.1.5.5 However, analysis of product time for specific product units is severely limited if product identifiers are not available.

7.1.6 Lot-Level vs. Substrate-Level Data

7.1.6.1 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.

7.1.6.2 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.

7.1.6.3 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.





Date: 5/6/23

7.1.6.4 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.

7.1.6.5 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.

7.1.6.6 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.

7.1.7 Carrier Reroute

7.1.7.1 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.

7.1.7.2 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).

7.1.7.3 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).

7.1.7.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.

7.1.8 Time Elements

7.1.8.1 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.

7.1.9 Carrier Job Queuing and Overlap

7.1.9.1 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.

7.1.9.2 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.

7.1.9.3 The design of the time elements provides for this type of overlap, should it occur.

7.1.9.4 Carrier job queuing and overlap are not required by this Specification.

8 Prerequisites8.1 The basic prerequisite for this subordinate Specification is conformance to the primary Specification.

[E168.ss-RQ-00002-00] 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-00003-00] A precondition for the FICS-MCS interface is support for the MCS events in Table 1. [/RQ]

8.2.1 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





Date: 5/6/23

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.

Table 1 MCS Events Needed in FICS-MCS Interface

RequirementID MCS Event Description

E168.ss-RQ-00004-00 CarrierJob-Accepted Affirmative response from the MCS to accept a job request/command. This event is used only to provide context (e.g. JobID),

E168.ss-RQ-00005-00 CarrierJob-Executing

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.

E168.ss-RQ-00006-00 CarrierJob-AbortedCarrier 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.

E168.ss-RQ-00007-00 CarrierJob-ReroutedThe destination for the carrier has been changed. This event is used as an 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-00008-00 CarrierLocation-Storage Carrier location changed to storageE168.ss-RQ-00009-00 CarrierLocation-ProdEqp Carrier location changed to production equipmentE168.ss-RQ-00010-00 CarrierLocation-Vehicle Carrier location changed to vehicleE168.ss-RQ-00011-00 CarrierLocation-ManualIn Carrier location changed to manual input portE168.ss-RQ-00012-00 CarrierLocation-ManualOut Carrier location changed to manual output port

8.2.2 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.

8.2.3 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-00013-00] FICS-MCS communication logs for the selected system shall be made available for processing by the PTM method. [/RQ]

8.2.4 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.

8.2.5 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

8.3.1 Important aspects of data quality are discussed in the SEMI E168 and in SEMI E151.

8.3.2 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.





Date: 5/6/23

9 Requirements9.1.1 The following is the top level parent requirement of all others in this Specification.

[E168.ss-RQ-00001-00] 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-00014-00] 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

9.4.1 Product Time Inputs

[E168.ss-RQ-00015-00] 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-00016-00 Communication Log

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 §§ 9.4.2.5 and 9.5.4 ). The format for this log is not specified.

E168.ss-RQ-00017-00 MCS Event Documentation

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.

E168.ss-RQ-00018-00 Data Variable Documentation

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.

E168.ss-RQ-00019-00 Event ConfigurationIf 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.

9.4.1.1 FICS-MCS Communication Log

9.4.1.1.1 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-00020-00] Communication logs shall contain all messages exchanged over the time period to be examined. [/RQ]

[E168.ss-RQ-00021-00] 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]

9.4.1.2 User Configuration

9.4.1.2.1 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.





Date: 5/6/23

9.4.1.2.2 Requirement RQ-00019 in Table 2 addresses documentation of this type of user configuration.

9.4.2 Product Time Data Transformations

9.4.2.1 This section builds upon the data transformation steps defined in SEMI E168.

9.4.2.2 Step 1 – Communication Log Normalization – no additional comment

9.4.2.3 Step 2 – Message Filtering

[E168.ss-RQ-00022-00] The message filtering step shall retain all messages related to commands and status changes for the carriers, carrier jobs, and carrier locations. [/RQ]

9.4.2.4 Step 3 — Data Code Translation

9.4.2.4.1 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.

9.4.2.5 Step 4 — Context Data Population

9.4.2.5.1 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.

9.4.2.5.2 The actual names of these variables may vary among MCS implementations, but the concepts tend to be very similar.

9.4.2.5.3 Timestamps need to be included with each message in the log (see RQ-00021).

9.4.2.6 Step 5 — Time Segment Construction

[E168.ss-RQ-00023-00] Time segment construction shall be done using the Level 4 time elements specified in § 9.5.3 . [/RQ]

9.4.3 Dataset Output Format

9.4.3.1 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).

9.4.3.1.1 Unaffected fields are not included.

9.4.3.1.2 The field order, as specified in the primary Standard, is not affected.

[E168.ss-RQ-00024-00] 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]





Date: 5/6/23

Table 3 Additional Definition for PTMData Fields from Primary Specification

RequirementID Field Description Format

E168.ss-RQ-00025-00 LotID

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.

Text (no change)

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

E168.ss-RQ-00026-00 SubstrateID

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.

Text (no change)

E168.ss-RQ-00027-00 SubstrateLocationID

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)

[E168.ss-RQ-00028-00] 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-00029-00 JobID Identifier of the carrier job for MCS Text

E168.ss-RQ-00030-00 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.

9.4.3.2 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

9.5.1 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.





Date: 5/6/23

9.5.2 Level 3 — Resources

9.5.2.1 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-00031-00] 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-00032-00] The Level 3 time elements that are subcategories of Active Time are: o Active Time for MCS o Active Time for Production Equipment [/RQ]

9.5.2.2 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 TimeWait for System

Wait for Factory Personnel

Active TimeActive Time for MCS

Active Time for Production Equipment

9.5.3 Level 4 — Detailed Time Elements

9.5.3.1 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).

9.5.3.2 The set of Level 4 time elements applies both to lot-level and substrate-level data.

Table 6 Level 4 Wait Time Elements

Level 3 RequirementID Level 4

Wait for SystemE168.ss-RQ-00033-00 Wait Time at Storage Location

E168.ss-RQ-00034-00 Wait For Carrier Job Revision

Wait for Factory Personnel E168.ss-RQ-00035-00 Wait for Carrier Return to AMHS

Table 7 Level 4 Active Time Elements

Level 3 RequirementID Level 4

Active Time for MCS

E168.ss-RQ-00036-00 Active Time for Carrier Acquisition

E168.ss-RQ-00037-00 Active Time for Carrier Relocation

E168.ss-RQ-00038-00 Active Time for Carrier Import

Active Time for Production Equipment E168.ss-RQ-00039-00 Active Time at Production Equipment

9.5.4 Context Information

9.5.4.1 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-00016 and § 9.4.2.5 ).





Date: 5/6/23

9.5.4.2 Carrier Location

9.5.4.2.1 In the definition of time elements where location may be used to qualify an MCS event, the locations are grouped according to type.

9.5.4.2.2 For the MCS domain, five types of carrier locations have been identified. These are described in RQ-00040. Some MCS events referenced in Table 8 are qualified with these location types.

[E168.ss-RQ-00040-00] 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]

9.5.4.2.3 The carrier location types listed in RQ-00040 are used in relation to the Level 4 time element definitions.

9.5.4.2.4 Additional carrier locations beyond the types listed in RQ-00040 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 ).

2: See RELATED INFORMATION 2 also.

9.5.5 Level 4 — Time Element Definitions

9.5.5.1 Table 8 defines each of the Level 4 time elements listed in Table 6 and Table 7.

9.5.5.2 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.

3: Please see RELATED INFORMATION 1 for example sequences of messages and time elements.

[E168.ss-RQ-00041-00] When applied to an MCS, the PTM method shall use the time elements as defined in Table 8. [/RQ]

9.5.5.3 Table 8 contains three columns. The first is the RequirementID.

9.5.5.4 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.

9.5.5.5 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

9.5.5.5.1 Each EventID mentioned in the bullets above is followed by text explaining the significance of the MCS event.

9.5.5.6 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.





Date: 5/6/23

9.5.5.7 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) Time Element Definition

E168.ss-RQ-00042-00 Wait Time Elements (Level 2)

E168.ss-RQ-00043-00 Wait for System (Level 3)

E168.ss-RQ-00044-00Wait Time at Storage Location(WaitAtStorage)

The carrier is awaiting a carrier job to move it to a new location.Start: CarrierLocation-StorageCarrier was delivered to a storage location.End: CarrierJob-ExecutingThe FICS request to transport a carrier has begun execution. or CarrierLocation-VehicleThe 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.

E168.ss-RQ-00045-00Wait for Carrier Job Revision(WaitForJobRevision)

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-AbortedThe carrier job has been terminated prior to completion.End: CarrierJob-ExecutingThe FICS request to transport a carrier has begun execution. or CarrierLocation-VehicleThe carrier is on a transport vehicle and will be delivered to the new destination.

E168.ss-RQ-00046-00 Wait for Factory Personnel (Level 3)

E168.ss-RQ-00047-00Wait 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-ManualOutThe carrier has been placed in the manual output port of the stocker for pickup by factory personnel.End: CarrierLocation-ManualInThe carrier has been placed on a manual input port of a stocker by factory personnel.





Date: 5/6/23


E168.ss-RQ-00048-00 Active Time Elements (Level 2)

E168.ss-RQ-00049-00 Active Time for MCS (Level 3)

E168.ss-RQ-00050-00Active Time for Carrier Acquisition(ActiveCarrierAcquisition)

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-VehicleThe carrier is on a transport vehicle. or CarrierLocation-ManualOutThe carrier has been placed in the manual output port of the stocker for pickup by factory personnel. or CarrierJob-AbortedThe 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.

4: See RELATED INFORMATION 1, Table R1-1 for an example that illustrates the reason for the special case for the CarrierJob-Storage event above.

E168.ss-RQ-00051-00Active Time for Carrier Relocation(ActiveCarrierRelocation)

The carrier is being transported by the transport vehicle and delivered to the destination location.Start: CarrierLocation-VehicleThe carrier is now on the transport vehicle.End: CarrierLocation-StorageCarrier has been delivered to a storage location (e.g., stocker or zero-footprint storage) or CarrierLocation-ProdEqpCarrier has been delivered to a production equipment load port. or CarrierLocation-VehicleCarrier is handed off directly to another transport vehicle. or CarrierJob-AbortedThe carrier job has been terminated prior to completion.





Date: 5/6/23


E168.ss-RQ-00052-00Active Time for Carrier Import(ActiveCarrierImport)

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-ManualInThe carrier is now on the manual input port of a stocker.End: CarrierLocation-StorageCarrier has been accepted into the MCS and delivered to a storage location within the stocker. or CarrierJob-ExecutingCarrier 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-VehicleCarrier 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-00053-00 Active Time for Production Equipment (Level 3)

E168.ss-RQ-00054-00Active 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-ProdEqpThe carrier has been delivered to the load port of a production equipment by the transport system.End: CarrierJob-ExecutingThe FICS request to transport a carrier has begun execution. or CarrierLocation-ManualInThe 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.

9.5.6 Carrier Reroute Indicators

9.5.6.1 Carrier reroute is described in § 7.1.7 . 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.

9.5.6.2 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.

9.5.6.3 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.

9.5.6.4 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.

5: There is an example scenario provided in RELATED INFORMATION 1 to illustrate carrier reroute.

9.5.6.4.1 The following are examples of events that might be used as reroute indicator events:





Date: 5/6/23

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 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.

9.5.7 User Extensions — Level 5

9.5.7.1 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.

6: Also, this concept is discussed in RELATED INFORMATION 2 as it relates to the MCS domain.

10 Test Methods10.1 No test methods are defined for this Specification.

11 Related Documents11.1 SEMATECH3

11.1.1 Wait Time Waste (WTW) Metrics and Methods Guidance for Automated Material Handling Systems (AMHS), v1.0; October 24, 2014

3 SEMATECH, 257 Fuller Road, Suite 2200, Albany, NY 12203, USA, Telephone: 518-649-1000, http://www.sematech.org




http://www.sematech.org/


Date: 5/6/23

APPENDIX 1STATEMENT OF COMPLIANCENOTICE: 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-90001-00] 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-90002-00] 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-90003-00] 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-90004-00] 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 A1-2.3.1.1 Table A1-1 are defined in A1-3.1.1.1 Table A1-1 .

[E168.ss-RQ-90006-00] Each implementer of this Specification shall include in the completed Capability Requirements compliance table a value as specified in A1-3.1.1.1 Table A1-1 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 CriteriaCompliance

Codes(C/NC/WC/NA)

Capability: Statement of Compliance

A.1-1 E168.ss-RQ-90001-00 E168.ss-RQ-00001-00 <none>





A1-3 E168.ss-RQ-90005-00 E168.ss-RQ-90002-00 <none>





Date: 5/6/23


Codes(C/NC/WC/NA)

Capability: 8 Prerequisites

8.1 E168.ss-RQ-00002-00 E168.ss-RQ-00001-00 <none>

8.2 E168.ss-RQ-00003-00 E168.ss-RQ-00001-00 <none>

8.2 E168.ss-RQ-00004-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00005-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00006-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00007-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00008-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00009-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00010-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00011-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00012-00 E168.ss-RQ-00003-00 <none>

8.2 E168.ss-RQ-00013-00 E168.ss-RQ-00003-00 <none>

Capability: 9 Requirements

9 E168.ss-RQ-00001-00 None <none>

9 E168.ss-RQ-00014-00 E168.ss-RQ-00001-00 <none>

Capability: 9.4 Product Time Data Set Construction

Capability: 9.4.1 Product Time Inputs

9.4.1 E168.ss-RQ-00015-00 E168.ss-RQ-00014-00 <none>

9.4.1 E168.ss-RQ-00016-00 E168.ss-RQ-00015-00 <none>

9.4.1 E168.ss-RQ-00017-00 E168.ss-RQ-00015-00 <none>

9.4.1 E168.ss-RQ-00018-00 E168.ss-RQ-00015-00 <none>

9.4.1 E168.ss-RQ-00019-00 E168.ss-RQ-00015-00 EventReportingConfigurable=





Date: 5/6/23


Codes(C/NC/WC/NA)

9.4.1 E168.ss-RQ-00020-00 E168.ss-RQ-00016-00 <none>

9.4.1 E168.ss-RQ-00021-00 E168.ss-RQ-00016-00 <none>

Capability: 9.4.2 Product Time Data Transformations

9.4.2 E168.ss-RQ-00022-00 E168.ss-RQ-00001-00 <none>

9.4.2 E168.ss-RQ-00023-00 E168.ss-RQ-00001-00 <none>

Capability: 9.4.3 Dataset Output Format

9.4.3 E168.ss-RQ-00024-00 E168.ss-RQ-00001-00 <none>

9.4.3 E168.ss-RQ-00025-00 E168.ss-RQ-00024-00 <none>

9.4.3 E168.ss-RQ-00026-00 E168.ss-RQ-00024-00 <none>

9.4.3 E168.ss-RQ-00027-00 E168.ss-RQ-00024-00 <none>

9.4.3 E168.ss-RQ-00028-00 E168.ss-RQ-00027-00 <none>

9.4.3 E168.ss-RQ-00029-00 E168.ss-RQ-00027-00 <none>

9.4.3 E168.ss-RQ-00030-00 E168.ss-RQ-00027-00 <none>

Capability: 9.5 Time Elements

Capability: 9.5.2 Level 3 — Resources

9.5.2 E168.ss-RQ-00031-00 E168.ss-RQ-00001-00 <none>

9.5.2 E168.ss-RQ-00032-00 E168.ss-RQ-00001-00 <none>

Capability: 9.5.3 Level 4 — Detailed Time Elements

9.5.3 E168.ss-RQ-00033-00 E168.ss-RQ-00031-00 <none>

9.5.3 E168.ss-RQ-00034-00 E168.ss-RQ-00031-00 <none>

9.5.3 E168.ss-RQ-00035-00 E168.ss-RQ-00031-00 <none>

9.5.3 E168.ss-RQ-00036-00 E168.ss-RQ-00032-00 <none>

9.5.3 E168.ss-RQ-00037-00 E168.ss-RQ-00032-00 <none>





Date: 5/6/23


Codes(C/NC/WC/NA)

9.5.3 E168.ss-RQ-00038-00 E168.ss-RQ-00032-00 <none>

9.5.3 E168.ss-RQ-00039-00 E168.ss-RQ-00032-00 <none>

Capability: 9.5.4 Context Information

9.5.4 E168.ss-RQ-00040-00 E168.ss-RQ-00001-00 <none>

Capability: 9.5.5 Level 4 — Time Element Definitions

9.5.5 E168.ss-RQ-00041-00 E168.ss-RQ-00001-00 <none>

9.5.5 E168.ss-RQ-00042-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00043-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00044-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00045-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00046-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00047-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00048-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00049-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00050-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00051-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00052-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00053-00 E168.ss-RQ-00041-00 <none>

9.5.5 E168.ss-RQ-00054-00 E168.ss-RQ-00041-00 <none>





Date: 5/6/23

A1-3 Compliance Table: Conditional Criteria

[E168.ss-RQ-90005-00] 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-1 Conditional Criteria

Name Values Description Section

EventReportingConfigurable

True

False

True — Event reporting for the MCS can be configured by either enabling/disabling events or associating data with event reports.

False — Event reporting for MCS cannot be configured.9.4.1

RELATED INFORMATION 1





Date: 5/6/23

RELATED INFORMATION 1 EXAMPLE MESSAGE SEQUENCES IN FICS-MCS COMMUNICATIONSNOTICE: 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 PurposeR1-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 SequencesR1-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 EquipmentR1-3.1 R1-3.1.1.1.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) 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 and delivers it to the production equipment.

3 CarrierLocation-ProdEqp ActiveAtProdEqp 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-StockerR1-4.1 R1-4.1.1.1.1 Table R1-1 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-1 MCS Example 2 – Production Equipment-to-Stocker



2 CarrierLocation-Vehicle ActiveCarrierRelocation Vehicle transports the carrier and delivers it to the stocker.

3 CarrierLocation-Storage WaitAtStorage The carrier is awaiting a carrier job to move it to a new location.





Date: 5/6/23

R1-3 MCS Example 3 – Carrier Manual Output and ReturnR1-3.1 R1-4.1.1.1.1 Table R1-2 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-2 MCS Example 3 – Carrier Manual Output and Return


1 CarrierJob-Executing ActiveCarrierAcquisition Carrier job is active; the carrier is moved to the manual output port of the stocker.

2 CarrierLocation-ManualOut WaitForCarrierReturn Carrier is on the manual output port and will be removed by factory personnel.

2 CarrierLocation-ManualIn ActiveCarrierImport Carrier is being imported into the MCS and stored in the stocker.


R1-4.1 Table R1-3 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-3 MCS Example 4 – Carrier Manual Input To Location Outside The Stocker


1 CarrierLocation-ManualIn ActiveCarrierImportCarrier was placed on the manual input port at a stocker and is being imported into the MCS.

2 CarrierJob-Executing ActiveCarrierAcquisition The MCS has begun executing a carrier job to move the carrier to another stocker.

3 CarrierLocation-Vehicle ActiveCarrierRelocationThe carrier was placed on a vehicle and is being transported and delivered to the destination 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-3 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 RerouteR1-5.1 R1-5.2.1.1.1 Table R1-1 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.





Date: 5/6/23

Table R1-1 MCS Example 5 – Carrier Reroute



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.


R1-6 MCS Example 6 – Transfer Using Multiple VehiclesR1-6.1 Table R1-1 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-1 MCS Example 6 – Transfer Using Multiple Vehicles



2 CarrierLocation-Vehicle ActiveCarrierRelocationVehicle transports the carrier and delivers it to stocker where the carrier handoff to the new vehicle will occur.

3 CarrierLocation-Storage WaitAtStorageThe carrier is held at the storage location or in the stocker and then picked up by the new vehicle.

4 CarrierLocation-Vehicle ActiveCarrierRelocation Vehicle transports the carrier and delivers it to the destination 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-1 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.

R1-6.2.1 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 JobsR1-7.1 Table R1-1 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.





Date: 5/6/23

Table R1-1 MCS Example 7 – Transfer Using Multiple Carrier Jobs

# MCS Event Time Element Entered (Label) Comments

1 CarrierJob-Executing ActiveCarrierAcquisition The first carrier job is active; the vehicle moves to the stocker and picks up the carrier.


3 CarrierLocation-Storage WaitAtStorageThe carrier is held at the storage location or in the stocker and then picked up by the new vehicle.

4 CarrierJob-Executing ActiveCarrierAcquisition The second carrier job is active; the vehicle moves to the stocker and picks up the carrier.



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-1 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-1 MCS Example 7A – Alternative Transfer Using Multiple Carrier Jobs

# MCS Event Time Element Entered (Label) Comments

1 CarrierJob-Executing ActiveCarrierAcquisition The first carrier job is active; the vehicle moves to the stocker and picks up the carrier.


3 CarrierJob-Executing ActiveCarrierAcquisition The second carrier job is active; the vehicle moves to the stocker and picks up the carrier.

– CarrierLocation-StorageWait Time at Storage LocationN/A

This event does not trigger a new time element because it occurs while the ‘Active Time for Carrier Acquisition’ time element is in effect.



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.





Date: 5/6/23

RELATED INFORMATION 2 LEVEL 5 USER EXTENSIONSNOTICE: 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 PurposeR2-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 ExtensionsR2-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 R2-2.3.1.1 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 EventsR2-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 ¶ 7.1.4.2 ). 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.





Date: 5/6/23

R2-4 Carrier Location Changed EventsR2-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.





Date: 5/6/23

RELATED INFORMATION 3 MERGING PTM DATA SETSNOTICE: 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 PurposeR3-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 SetsR3-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.

Figure R3-1 Concept Illustration for PTM Data Merging

R3-3 Considerations for Merging PTM DataR3-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.

R3-3.1.1 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.

R3-3.1.2 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.

R3-3.1.3 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.

R3-3.1.4 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





Date: 5/6/23

MCS data. This does cause a small change to the MCS time elements, but this should not detract from the value of the result.

R3-4 Product Identity Is NeededR3-4.1 For the MCS data to be combined with the equipment, stocker, and transport system data to provide this extensive view of the product lifecycle, it is necessary for all the data sets to contain product identification (either LotID or SubstrateIDs). Such data is not typically included in MCS or transport system communications. It may be available from other sources within the FICS.

NOTICE: The user’s attention is called to the possibility that compliance with this Standard or Safety Guideline may require use of copyrighted material or of an invention covered by patent rights. SEMATECH has filed a statement with Semiconductor Equipment and Materials International (SEMI) asserting that the patented or copyrighted item can be used by the public for the purpose of implementing the Standard or Safety Guideline without specific license and without payment of royalty or other charge. Attention is also drawn to the possibility that some elements of this Standard or Safety Guideline may be subject to patented technology or copyrighted items other than those identified above. SEMI shall not be held responsible for identifying any or all such patented technology or copyrighted items.

By publication of this Standard or Safety Guideline, SEMI takes no position respecting the validity of any patent rights or copyrights asserted in connection with any item mentioned in this Standard or Safety Guideline. Users of this Standard or Safety Guideline are expressly advised that determination of any such patent rights or copyrights, and the risk of infringement of such rights are entirely their own responsibility.


