Background Statement for SEMI Draft Document #5538 New ...downloads.semi.org/.../83647fc8c66b3ab788257bcc0009f7a5/$FILE/… · Page 1 Background Statement for SEMI Draft Document

Page 1

Background Statement for SEMI Draft Document #5538 New Standard: SPECIFICATION FOR PRODUCTION RECIPE CACHE (PRC)

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

General Background

Recipe Management is one of the most important parts of factory integration and operation; however, there is no practical recipe management standard that is well accepted by industry. As a result, there have been a number of device manufacturer specific implementations that have been independently revised, and it causes several issues such as;

Increased development and maintenance overheads for device manufacturers and equipment suppliers in the areas that have no positive value for competition.

Variations cause dilution of industry resources which lowers maturity of each implementation

Unexpected recipe inconsistencies due to unexpected operation of recipes which sometimes causes wafer scrap

Variations and complexity of equipment software cause cost, resource, maturity and time-to-market issues

In an industry trend towards “Centralized Recipe Management”, it is timely to focus on those issues in preparation for the transition to 450mm which is a good opportunity to improve in conjunction with stepwise changes to be compatible with the 450mm requirements.

Focus of This Document

Recipes contain key information for production, and involve many management aspects such as Development (at equipment, remote), Storage (management space, execution space), Synchronization (factory system, equipment), Delivery (factory system, equipment), Protection (in equipment), Lifecycle (development, verification, certification, deletion) and Security.

This document focuses on an interface tier between factory system and equipment, which supports;

Central management (storage) in factory system (Single Point of Management)

Page 2

Delivery from factory system to equipment

Synchronization (consistency keeping) between factory system and equipment

Protection of PEM Recipes in equipment from unexpected operations

This document focuses on the schemes required to:

Protect “PEM Recipes” in equipment from unexpected modification during maintenance etc.

Synchronize (Keep Consistency) with recipes on the “Recipe Server”.

Benefits of “Production Recipe Cache” Concept

In a “Centralized Recipe Management” scenario, “Caching” (which is commonly used in computer architecture) is a very efficient management methodology that provides the following benefits.

Easy to maintain consistency between “A Recipe on the Recipe Server” and “A Recipe in the Equipment”

Operators do not need to care about the contents of the cache space as “Cache” operation provides automated maintenance of consistency with the recipe on the “Recipe Server”.

Operators can simply clear the cache with minimal penalty of new recipe download time, in case operators are not confident with the recipe contents.

Operators can only view and use recipes in the cache - no recipe duplication and/or modification is allowed.

Easier control of Recipe uniqueness by Centralized control at “Recipe Server” as “Recipe Server” stores and controls all Recipes.

Naming, Revision & Authorization, and equipment-to-equipment difference control using Variable Parameters. “Recipe Life Cycle” control such as Creation, Verification, Certification and Deletion

Rapid in response time as recipes are cached in equipment.

Less communication overhead to download Recipes as Equipment queries a recipe to “Recipe Server” only in case of “Cache Miss”

Also, Cache Operation comprehends other operations such as “Full Query”, “Full Download” or “Pre-Download” with some additional rules as Cache embodies the required elemental functions for those operations.

Overview of PRC

The PRC concept duplicates the current “Recipe Storage” Equipment capability, uses one as a “Conventional Recipe Space” and the duplicate as a “Production Recipe Cache”.

“Production Recipe Cache” is dedicated to automated production under Host control

Isolated and protected recipe space. Cache Operation with Recipe Management at the host level, and holds temporal copy of recently used Recipes

downloaded from the “Recipe Server” (Cache Operation). No recipe write action is allowed by the equipment user - only recipe deletion is allowed. Recipe(s) in PRC

can be deleted at any time when they are found to be inconsistent with the recipes in the “Recipe Server”, such as after installation and/or maintenance.

Page 3

Referenced in Production Mode.

“Conventional Recipe Space” is used for other operations.

Used for operations other than host demanded production.

Compatibility Policy

This document is a New Standard and requires no modification to existing standards. Upon implementation, the following equipment implementation changes will be required:

Addition of a new recipe space “PRC”.

Add a switch to refer PRC for Recipe in “Production Execution Mode”.

Add Cache operational functionality.

Deployment Consideration

This standard is optional and has an ON/OFF capability. Factory system can control whether this capability is turned ON or OFF according to its PRC compatibility.

The ballot results will be reviewed and adjudicated at the meetings indicated in the table below. Check www.semi.org/standards under Calendar of Events for the latest update.

Review and Adjudication Information

Task Force Review Committee Adjudication

Group: Japan GEM300 TF Japan Information and Control Committee

Date: Wednesday, December 4, 2013 Friday, December 6, 2013

Time & Timezone: 13:00-17:00, Japan Time 13:00-17:00, Japan Time

Location: Makuhari Messe Makuhari Messe

City, State/Country: Chiba, Japan Chiba, Japan

Leader(s): Yoshihisa Takasaki (Dainippon Screen Mfg.) Tadashi Mochizuki (Tokyo Electron)

Takayuki Nishimura (Dainippon Screen Mfg.) Mitsuhiro Matsuda (Hitachi Kokusai Electric)

Standards Staff: Chie Yanagisawa (SEMI Japan) +81.3.3222.5863 / [email protected]

Chie Yanagisawa (SEMI Japan) +81.3.3222.5863 / [email protected]

This meeting’s details are subject to change, and additional review sessions may be scheduled if necessary. Contact Standards staff for confirmation.

Page 4

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.

If you need a copy of the documents in order to cast a vote, please contact the following person within SEMI.

Chie Yanagisawa SEMI Standards, SEMI Japan Tel: 81.3.3222.5863 Email: [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 5 Doc. 5538 SEMI

Semiconductor Equipment and Materials International 3081 Zanker Road San Jose, CA 95134-2127 Phone: 408.943.6900, Fax: 408.943.7943

LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT

DRAFTDocument Number: 5538

Date: 2013/08/26

SEMI Draft Document #5538 New Standard: SPECIFICATION FOR PRODUCTION RECIPE CACHE (PRC)

1 Purpose

1.1 The purpose of this standard is to provide a commonly usable recipe delivery and storage management mechanisms for “Recipe Servers” and equipment that enables the following capabilities as an extension of current capabilities.

Elimination of operator effort to download recipes to be used for production from “Recipe Server” to Equipment by providing an automatic delivery mechanism

Elimination of operator effort required to maintain consistency of recipes in equipment with “Recipe Server” by providing an automated consistency maintenance mechanism

Protection of the recipes in equipment from non-privileged access by defining a protected recipe space

Reduction of communication and computation overhead and cost due to recipe related transactions by adopting cache operation

Authentication of consistency of recipes in equipment with “Recipe Server” by providing an optional “Pre-Execution Check” mechanism

1.2 The purpose of this standard is to provide the above recipe management mechanism, keeping compatibility with current practices in following aspects.

Recipe identification and uniqueness control

Recipe linkage

“Variable Parameter” management

Recipe operations other than production execution

“Pre-Execution Check” of recipe consistency

2 Scope

2.1 This standard covers a definition of “Production Execution Mode (hereinafter PEM)”.

2.2 This standard covers a definition of new recipe space named “Production Recipe Cache” (hereinafter PRC) in equipment, which is dedicated for host controlled process execution in which recipes shall be synchronized with the host and shall be protected from modification by unauthorized operations.

2.3 This standard covers definitions of operations and messaging schemes to manage PRC so that recipes in PRC are “Protected” and “Synchronized” with recipes on the “Recipe Server” function in the host.

PRC set up operations

“Cache Operations”

“Direct Access” from Host

2.4 This standard covers following options for effective implementation under a single SEMI standard.

Optional “Pre-Execution Check” mechanism

Optional operation mode such as “Pre-Download” or “Full Download”

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.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

3 Limitations

3.1 This document does not define any messaging. Messaging may be defined in separate standard.

3.2 Linked Recipe Compatibility — This standard does not define any requirements for linked recipes but is intended to be compatible with currently implemented recipe linkage schemes. This standard only requires an extra recipe space PRC on equipment which may have the same structure as the currently implemented recipe space on equipment, and only defines the Cache operation between host and equipment.

3.3 Recipe Identification — This standard does not define any recipe identification scheme requirements but may use recipe identification schemes to check the consistency of recipes.

3.4 Variable Parameters — This standard does not define any specific requirements for “Variable Parameters” but conforms with current implementations. This standard may recommend operations to transfer and store Variable Parameters as an application of PRC.

3.5 User Authentication and Access Privilege — This standard does not define any requirement for user authentication and access privileges but only recommends the use of access control on PRC resources and functions. User authentication and access privilege should be defined separately from this standard.

4 Referenced Standards and Documents

4.1 SEMI Standards and Safety Guidelines

SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM)

SEMI E39 — Object Services Standard: Concepts, Behavior, and Services

SEMI E40 — Standard for Processing Management (PJ)

SEMI E87 — Specification for Carrier Management (CMS)

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

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 FOUP — front opening unified pod

5.1.2 GEM — generic equipment model

5.1.3 MES — manufacturing execution system

5.1.4 PRC — production recipe cache

5.1.5 PEM — production execution mode

5.2 Definitions

5.2.1 automation — the degree to which activities of machines or production systems are self-acting. In this standard automation provides methods that will reduce the amount of operator intervention required. [SEMI E87]

5.2.2 cache hit — the required recipe is found in the PRC

5.2.3 cache miss — the required recipe is not found in the PRC.

5.2.4 cache operation — an operation to keep contents of PRC to be a partial copy of contents on the “Recipe Server”, which is based on a query action from the PRC upon “Cache Miss”.

5.2.5 carrier — a container, such as a FOUP or open cassette, with one or more positions for holding substrates. [SEMI E87]

5.2.6 CarrierID — a readable and unique identifier for the carrier. [SEMI E87]

5.2.7 collection event — a collection event is an event (or grouping of related events) on the equipment that is considered to be significant to the host. [SEMI E87]




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

5.2.8 conventional recipe space — an existing recipe space on the equipment, which is normally used by every user including the host for various purposes such as equipment installation, process development and production operation.

5.2.9 host — the factory computer system or an intermediate system that represents the factory and the user to the equipment. [SEMI E87]

5.2.10 object instantiation — the act of storing of information related to a physical or logical entity so that it can be recalled on demand based on its public identifier. [SEMI E87]

5.2.11 on-line equipment — equipment that is connected to, and able to communicate fully with, the host. [SEMI E87]

5.2.12 privileged user — a user who is allowed to use system functions that are not available to other users

5.2.13 process equipment — equipment used to produce product, such as semiconductor devices. This excludes metrology and material handling equipment. [SEMI E87]

5.2.14 production equipment — equipment used to produce product, such as semiconductor devices, including substrate sorting, process, and metrology equipment and excluding material handling equipment. [SEMI E87]

5.2.15 production execution mode (PEM) — a mode of fab and equipment, which indicates that they are in mass Production Execution Mode. This mode should be set by the host or “Privileged user”. In “Production Execution Mode”, Online/Remote/Auto may typically be used; however other modes may also be used for backup/preparation purposes, so “Production Execution Mode” is an independent mode from Online/Offline, Remote/Local or Auto/Manual.

5.2.16 production execution mode recipe (PEM Recipe) — a recipe which is used in “Production Execution Mode” such as recipes for mass production lots. Whatever recipes used in PEM shall be dealt as PEM Recipe.

5.2.17 production recipe cache (PRC) — a recipe space that resides in equipment and holds exact copies of “PEM Recipes” on the factory’s centralized “Recipe Server” by using “Cache Operation” under control of the host.

5.2.18 properties — a set of name value pairs assigned to an object or used in a service message to include additional information about the object (i.e., carrier, port, etc.). [SEMI E87]

5.2.19 recipe executer — a component in the equipment which executes a recipe.

5.2.20 recipe execution space — a recipe space in the equipment which holds the recipe(s) under execution.

5.2.21 recipe header — a set of descriptors of the recipe which contains information related to the recipe such as linkage information. “Recipe Header” is optional information defined by user or standardized if needed.

5.2.22 recipe queue space — a recipe space in the equipment which holds the recipe(s) already queued for execution.

5.2.23 recipe server — the computer system in the host, which maintains the master copy of the recipes that are used by the equipment for host-controlled process executions.

5.2.24 substrate — material held within a carrier. This can be product, or durables such as reticles. [SEMI E87]

5.2.25 Unique ID — an additional ID for a recipe, which provides a unique name to the recipe. In case “Recipe ID” cannot ensure naming uniqueness of recipes, “Unique ID” may be used.

6 Conventions

6.1 Objects

6.1.1 Whenever the equipment is required to know about specific kinds of entities, and required to manage information concerning these entities, it is useful to treat these entities as objects that comply with the basic requirements of SEMI E39 Object Services Standard (OSS). This is especially true whenever there are a large number of objects of a given type or when the entities are transient rather than permanent. In both cases, it is difficult to describe a general way for the host and equipment to specify which particular entity is referenced and to get information related only to a specific one out of many.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

6.1.2 By defining these entities as objects that comply with OSS, it is only necessary for the host to specify the type of object and its specific identifier in order to inquire about one or more properties of the specific entity of interest.

6.1.3 Object Properties

6.1.3.1 A property (attribute) is information about an individual object that is presented as a name/value pair. The name is a formally reserved text string that represents the property, and the value is the current setting for that property.

6.1.3.2 Properties shall be accessible to the host via the service GetAttr for the Carrier object. Using SEMI E39 Object Services Standard, for example, it is possible to:

get the list of IDs for the current carriers at the equipment, and

get the specified properties for one or more individual carriers.

6.1.4 Rules for Object Properties

Attributes with RO access cannot be changed using SetAttr service as defined in OSS.

Attributes with RW access can be changed using SetAttr service as defined in OSS.

Additional attributes may be specified by the user or the equipment supplier by using an attribute name starting with “UD” (User Defined). Care should be taken to ensure the name of the attribute is unique.

6.1.5 Object Attribute Table

6.1.5.1 The object attribute table is used to list all the attributes related to the defined object as shown below the access is defined as Read only (RO) or Read/Write (RW). The Reqd column is used to specify whether the attribute is required for implementation. Finally, the Form column is used to specify the format of that particular attribute.

Table 1 Object Attribute Table

Attribute Name Definition Access Reqd Form

ObjType Object type RO Y Text = ‘Carrier’

6.2 State Model Methodology

6.2.1 A state model consists of four elements: a “State Model Diagram”, a “State Model Definition Table”, a “State Definition” and a “State Transition Table”.

6.2.2 State Model Diagram — The diagram of the state model uses the Harel State Chart notation. An overview of this notation is presented in an Appendix of SEMI E30. The definition of this notation is presented in Science of Computer Programming 8, “Statecharts: A Visual Formalism for Complex Systems,” by D. Harel, 19871.

6.2.3 State Model Definition Table — “State Model Definition Table” used in this standard has the following format. This table defines states and, also defines possible transition(s) from each state side by side. Each state has one or more transition(s). In case the transition comes from outside this table, the state definition column initiates the transition may be blank. Also, in case the transition comes from unspecified multiple states with the same condition, the state definition column may say “#Any state”, and there may not be an explicit transition number.

6.2.3.1 Definition of “State” — Columns under “State” column define “States” with its “No. (Number)”, “Name” and “Definition”. “No.” corresponds to the state number in the associated state diagram. “Name” defines a name of each state. “Definition” defines what the meaning of the state is and what to be done in the state.

6.2.3.2 Definition of “Transition” — Columns under “Transition” column define “Transitions” with its “No. (Number)”, “Trigger”, “Action”, “New State” and “Comments”. “No.” corresponds to transition number in the associated state diagram. “Trigger” defines a condition to start the transition from current state to the next. “Action” defines thing(s) to be done during the transition. “New State” defines a state number to move after the transition is

1 Elsevier Science, P. O. Box 945, New York, NY 10159-0945; http://www.journals.elsevier.com/science-of-computer-programming/




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

completed by pointing one of the states defined in the state definition in left side of the table. “Comment” may be used to put comments to each transition or their “From” state.

Table 2 State Model Definition Table

State Transition

No. Name Definition No. Trigger Action New State

Comments

-#1 -#1 -#1 T00 S00

Snn#2 # Any state#2 -#2 - S03

S00 T01 S01

S04#3 T02 S00

S01 T03 S02

T04 S03

S02 T05#4 S00

S10#5 - - - -

S11 T10 S12

S12 T11 S11

S03 T06 S00

#1 In case the transition comes from outside this table, the state definition column may be blank.

#2 In case the transition comes from unspecified multiple states with the same condition, the state definition column may say “#Any state”.

#3 State which has sub-states.

#4 One transition path has multiple cases (trigger and action pairs).

#5 A state separated by a dotted line is a parallel state of the state above.

6.2.4 State Definition — Each state is defined as one paragraph.

6.2.5 State Transition Table — Transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each state transition. A transition table contains columns for Transition number, Previous State, Trigger, New State, Actions, and Comments. The ‘trigger’ (column 3) for the transition occurs while in the ‘previous’ state. The ‘actions’ (column 5) includes a combination of:

Actions taken upon exit of the previous state,

Actions taken upon entry of the new state, and

Actions taken which are most closely associated with the transition.

Table 3 State Transition Table

Num Previous State Trigger New State Actions Comments

6.2.6 State Model Requirements

6.2.6.1 Requirement — The state models included in this Standard are a requirement for compliance. Equipment must maintain state models for each of the required state models as defined in this Document. Equipment shall maintain individual and unique state models for each logical entity instantiated or physical entity in the equipment that has state models associated with it.

6.2.6.2 Representation as the Host View — A state model represents the host’s view of the equipment, and does not necessarily describe the internal equipment operation. All state model transitions shall be mapped sequentially into




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

the appropriate internal equipment collection events that satisfy the requirements of those transitions. In certain implementations, the equipment may enter a state and have already satisfied all of the conditions required by the state models in this standard for transition to another state. In this case, the equipment makes the required transition without any additional actions in this situation.

6.2.6.3 Additional Sub-states — Some equipment may need to include additional sub-states other than those in this Standard. Additional sub-states may be added, but shall not change the defined state transitions in this standard. All expected transitions between states in this standard shall occur.

6.2.6.4 Uniqueness of Event Identifier — The event identifier reported during a particular state transition change for each of these state models shall be shared for all associated state models but unique for each transition. For example, if the equipment has two load ports and the load port state model defines 10 transitions, there must be exactly 10 event identifiers for each load port transfer state model but not 10 for each physical load port. The information identifying the physical entity or logical entity undergoing the transition will be contained within the associated event report.

6.2.6.5 Events — All state transitions in this Standard, unless otherwise specified, shall correspond to collection events. More explicitly, there must be a unique collection event for each state transition.

6.2.6.6 Events for Multiple AND Sub-states — In case a state model is defined with multiple AND sub-states, the equipment may report all state entry events with only one collection event.

6.2.6.7 Events for Conditional Path — In case conditional paths are defined in the state model, it is not necessary to report any state transition(s) until a terminal state is reached at which time each transition used to reach that state is reported.

6.3 Object

6.3.1 Recognition of Object — From the host point of view, an object is instantiated if the host is able to query the equipment about that object, its current state, and other attributes. Once instantiated, the object is considered destroyed (no longer instantiated) if the response to such queries is ‘unknown object’.

6.3.2 Object Identifier (ObjID) — The purpose of an Object Identifier is to allow references to an object within the system. The object identifier is created when an object is instantiated and should be unchanged or persistent until the end of the object lifecycle. The Object Identifier shall be unique at the equipment during lifecycle of the object.

6.4 Services

6.4.1 Definition of Service — Services are functions or methods that may be provided by either the equipment or the host. A service message may be either a request message, which always requires a response, or a notification message that does not require a response.

6.4.1.1 Notification Message Service — Notification type messages are initiated by the service provider (e.g., the equipment) and the provider does not expect to get a response from the service user.

6.4.1.2 Request Message Service — Request messages are initiated by a service user (e.g., the host). Request messages ask for data or an activity from the provider. Request messages expect a specific response message (no presumption on the message content).

6.4.2 Service Message Description — A service message description table defines the parameters used in a service, as shown in the following table:

Table 4 Service Message Description Table

Service Name Type Description

#1 Type can be either ‘N’ = Notification or ‘R’ = Request & Response.

6.4.3 Service Message Parameter Definition — A service parameter dictionary table defines the description, range, and type for parameters used by services, as shown in the following table:




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Table 5 Service Message Parameter Definition Table

Parameter Name Form Description

#1 A row is provided in the table for each parameter used on a service.

6.4.4 Service Message Definition — A service message description table defines the parameters used in a service message, and also, describes each message and its cause/effect to the equipment, as shown in the following table:

Table 6 Service Message Definition Table

Service Parameter Req/Ind Rsp/Conf Description

6.4.4.1 Definition of Req/Ind and Rsp/Conf Columns — The columns labeled Req/Ind and Rsp/Conf link the parameters to the direction of the message. The message sent by the initiator is called the ‘Request’. The receiver terms this message the ‘Indication’. The receiver may then send a ‘Response’, which the original sender terms the ‘Confirmation’.

6.4.4.2 Definition of Codes for Req/Ind and Rsp/Conf Columns — The following codes appear in the Req/Ind and Rsp/Conf columns and are used in the definition of the parameters (e.g., how each parameter is used in each direction):

Table 7 Codes For Req/Ind and Rsp/Conf Columns

M Mandatory Parameter – must be given a valid value.

C Conditional Parameter – may be defined in some circumstances and undefined in others. Whether a value is given may be completely optional or may depend on the values of other parameters.

U User-Defined Parameter.

- The parameter is not used.

= (for response only) Indicates that the value of this parameter in the response must match that in the primary (if defined).

6.5 Variable Data Definitions

6.5.1 This defines variable data requirements. Values of these variables are available to the host via collection event reports and host status queries.

6.5.2 Event Report Requirement — The identifier of that object and all of the attributes of that object shall be available for inclusion in event reports associated with that object.

6.5.3 Object Attribute Variable in Non-extinction Event — The object attribute variables in event reports linked to non-extinction event(s) shall contain the values of the attributes after the transition. This requirement allows the receiver of the report to know the current condition of the object.

6.5.4 Object Attribute Variable in Extinction Event — The object attribute variables in event reports linked to extinction event(s) shall contain the values of the attributes before the transition unless it is specifically stated that the destruction transition modifies the attribute value. This requirement allows the receiver of the report to know the final condition of the object at the time it was deleted.

6.5.5 Subscripted variables are used either as items within a list or to differentiate data representing different entities. Subscripted variables are always valid.

6.5.6 Table Format — The following table defines variable data that shall be provided by the production equipment.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Table 8 Variable Data Definitions

Variable Name Description Type Access Comment

7 PRC Space Requirements

7.1 PRC Space Requirement — Equipment compliant with this standard shall have a recipe space named “Production Recipe Cache (PRC)” in addition to the “Conventional Recipe Space”.

7.1.1 Definition of PRC — PRC is a dedicated recipe space for “Production Execution Mode” operation controlled by the host. Only Recipes in PRC are used in “Production Execution Mode”. PRC stores a partial copy of contents on the “Recipe Server” by using the “Cache Operation” under the control of the host. In case the host is not in service, a privileged user of the equipment may execute the functions normally performed by the host.

7.1.2 Usage of “Conventional Recipe Space” — “Conventional Recipe Space” is used in other modes than “Production Execution Mode.” during the PRC is enabled.

Figure 1

Concept of PRC

7.2 PRC Space Recommendations — The PRC may be used in following ways to maintain compatibility with existing implementations and recipe storage conventions.

7.2.1 Folder Structure in PRC — PRC may be structurally divided into multiple tiers of multiple folders. This standard does not define anything about the folder structure inside PRC in equipment or inside recipe space in the “Recipe Server”. The folder in the “Recipe Server” may or may not be shared by multiple same type equipment.

7.2.1.1 Linked Recipe Aspect — This folder capability may be used to deal with “Linked Recipe”.

7.2.1.2 Recipe Security Aspect — This folder capability may also be used for security purposes.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 2

Example PRC Folder Structure

7.2.2 How to Specify Folder — This standard does not define how to specify folders in the PRC. To be compatible with the current implementations, it is recommended to use the same folder specification (path) mechanism as used in the “Conventional Recipe Space”.

Figure 3

Example PRC Folder Structure Relationship

7.2.3 Folder Structure Relationship between “Conventional Recipe Space” and PRC — The folder structure of PRC may be aligned with the folder structure of “Conventional Recipe Space” in the equipment for easier correlation.

Figure 4

Folder Structure Relationship of PRC to “Conventional Recipe Space” in Equipment

7.2.4 Folder Structure Relationship between PRC and “Recipe Server” — The folder structure in the recipe serving function in the host may be aligned with the folder structure of PRC in equipment for easier correlation.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 5

Folder Structure Relationship between PRC and “Recipe Server”

7.3 Linked Recipe Compatibility — To be compatible with current implementations, linked recipes are recommended to be dealt as below.

7.3.1 Management of Host-Managed Sub-Recipes — Sub-Recipes which are under management of the host, may similarly be managed in PRC. Those recipes should reside in the PRC, and should be linked together in the same way as the recipes in the “Conventional Recipe Space”. This standard does not define the linkage specification.

Figure 6

Host-Managed Sub-Recipes

7.3.2 Management of Locally Managed Sub-Recipes — Sub-Recipes which are not under management of the host but are linked under the recipes managed by host are out of scope of PRC. Those recipes shall reside somewhere in the equipment, and shall be linked from the recipes in PRC in the same way as the link from the recipes in the “Conventional Recipe Space”. This standard does not define the way of linkage.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 7

Linkage to Locally Managed Sub-Recipes

8 PRC Operational Requirements

8.1 Preconditions — This section describes preconditions for PRC.

8.1.1 Single Point of Control (SPOC) — All PRC Operation is done between the host and “Equipment”. Which node in the host to take care of which functionality of PRC operation should be maintained by the host side (by something like an Equipment Interface).

8.1.2 Centralized and Privileged Recipe Management — The recipes which are used in “Production Execution Mode” shall be managed by centralized recipe management function.

8.1.3 User of PRC — According to the equipment user change, user of the PRC will also change. For recipe security, contents of the PRC shall be cleared upon the user change indicated by PEM management functionality.

8.1.4 Use of Recipes in PRC — Recipe(s) in PRC shall be used when PEM is on. “Conventional Recipe Space” shall be used when PEM is off.

8.1.5 Local Access to PRC — Non-host–controlled or non-privileged-user-controlled recipe write (such as create, edit) actions are not allowed to PRC in order to isolate and protect PEM Recipes from inadequate operations in equipment. Only delete is allowed.

8.1.6 Overflow Control of PRC — To prevent PRC overflow, following actions may be taken.

Host or privileged user may delete recipes in PRC at any time

Equipment or non-privileged user may delete recipes in PRC at any time

8.1.7 Setting Aside the Recipes Already Referred (Recipe Queue Space and Recipe Execution Space) — Recipe(s) for already queued PJs and recipe(s) under execution shall be copied from PRC to other protected recipe spaces such as “Recipe Queue Space” and “Recipe Execution Space” accordingly, so that recipes in PRC can be deleted at any time.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 8

Position of PRC

8.2 Fundamental Requirements — This section defines operation rules of PRC. “Recipe Server” shall be prepared in the host for one or more equipment. Equipment shall be compliant with PRC.

8.2.1 Host Side — PRC mechanism shall be implemented in the host. “Recipe Server” may be in any computing node in upstream system, higher tier than equipment.

8.2.1.1 “Single Point of Recipe Management (SPORM)” — “Recipe Server” shall manage the master copy of the PEM Recipes.

8.2.1.2 Response to “Query Event” — “Recipe Server” shall respond to “Query Events” from equipment, and download the queried recipe by using “Serve Recipe” service.

8.2.1.3 Cache Write Through — In case a recipe with same “Recipe ID” but different contents is made and “Recipe Server” wants to maintain recipe uniqueness by “Recipe ID”, “Recipe Server” shall delete the same named recipe in PRC by using “Delete Recipe” service.

8.2.1.4 Recipe Management per Equipment — “Recipe Server” may separately manage the master copies of the PEM Recipes which are optimized for particular equipment, and may manage variable parameters as well.

8.2.2 Equipment Side — PRC mechanism shall be implemented in each equipment.

8.2.2.1 “Clear PRC” — An Operator may delete particular recipe(s) or clear the entire PRC whenever there is a known mismatch between recipes in PRC and the recipes on the “Recipe Server” (such as after maintenance).

Equipment shall clear the entire PRC upon a request from the host or privileged user whenever there is a known mismatch between recipes in PRC and the recipes on the “Recipe Server” (such as after maintenance)

Equipment may clear the entire PRC upon a request from non-privileged user whenever there is a known impact to the contents of the PRC (such as disk drive exchange in maintenance)

8.2.2.2 “Write Recipe” into PRC — Equipment shall only write recipes into the PRC which are provided from “Recipe Server” through “Cache Operation”.

8.2.2.3 “Delete Recipe” in PRC — Equipment shall delete recipes in PRC in following cases.

Equipment shall delete specified recipe in the PRC upon request from the host or privileged user whenever there is a known mismatch between recipes in PRC and the recipes on the “Recipe Server” (such as after




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

maintenance). This may be used to delete a recipe which is not needed or not consistent with the recipe on the “Recipe Server” any more.

Equipment shall automatically delete recipe(s) with lower probability of use upon “Cache Full”, in order to make appropriate room to write the recipe which is downloaded from “Recipe Server” into PRC

8.2.2.4 No “Edit Recipe” in PRC — Equipment shall not edit recipes in PRC upon any request from any user. Users shall not be allowed to edit any recipe in the PRC.

8.2.2.5 “Copy Recipe” from PRC — Equipment shall only be allowed to copy the recipes out from the PRC upon a request from the host or a privileged user in order to use the recipes as a base copy for other experiment uses. This function may be used by privileged users to copy out the recipes managed in PRC into the “Conventional Recipe Space” and modify the recipe to run for process development/experiment. It may be a lot faster to copy a recipe in PRC into “Conventional Recipe Space” than to download the recipe from the host.

8.2.2.6 Use of Recipe in PRC — Equipment shall use the recipes in the PRC for process execution in “Production Execution Mode”.

8.3 Cache Mode Operation — Cache Mode is the native mode of PRC.

8.3.1 Cache Setup — Equipment clears the PRC upon the following conditions.

At any time the recipes in the Cache seem to be inconsistent with the ones in “Recipe Server” such as after installation and/or maintenance

Upon “Clear PRC” message from Host

8.3.2 Cache Operation — Equipment searches in the Cache for specified recipe upon PJ from Host

Upon a process job creation demand, equipment to look up the PRC for the specified recipe

In case the recipe is in the PRC (“Cache Hit”), equipment uses the recipe

In case the recipe is not in the PRC (“Cache Miss”), equipment queries the recipe to the “Recipe Server”. Equipment writes the recipe which is downloaded from the “Recipe Server” into the PRC and uses it. In case the PRC is full, equipment automatically deletes some recipes with lower possibility to use.

8.3.3 Query of Linked Recipes — In case the recipes have linkage information to sub-recipes, and those linked sub-recipes are also managed in the “Recipe Server” and PRC, the linked sub-recipes are also queried upon their “Cache Miss”. Multiple queries may occur from the equipment, and the “Recipe Server” shall respond with a download for each query.

8.3.4 Recipe Deletion Order for Overflow Control — This standard does not define any specification about deletion order; however a combination of the following rules may be a candidate.

Not recently used recipe first (older one first)

Among the recipes which have similar used timing, less frequently used recipe first

8.3.5 “Pre-Execution Checks” (Optional) — This standard provides an optional “Pre-Execution Check” mechanism which may be used for following purposes. Since the PRC is protected and a previously downloaded recipe cannot be modified, this option is not needed to be used in case “Recipe ID” is unique or “Unique ID” is used, and all linked recipes or equipment parameters are managed as PEM Recipes in the “Recipe Server”.

8.3.5.1 Consistency Checks of Host-managed Recipes in Case the Unique Identification is Not Complete — In this case, equipment may upload check information defined by the user (such as “Checksum” or the “Recipe”) to the host upon “Cache Hit”, may wait for the host response, and may execute the recipe upon an affirmative response from the host. In a negative response case, the host may download a correct recipe to the equipment, and the equipment shall write the recipe into PRC and use it. Numbers of recipes is not limited to one in case linked recipes are also managed in PRC. This standard does not define check information (e.g. “Checksum”) specification.

8.3.5.2 Consistency Checks of Non-Host-managed Sub-recipes and/or Equipment Parameters — In case consistency checks of non-host-managed sub-recipes and/or equipment parameters are taken into account, equipment may upload check information (such as “Checksum”) to the host upon “Cache Hit”, may wait for the host




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

response (the host may compare the information with the correct information which was prospectively uploaded to the host), and may continue execution upon an affirmative response from the host. In a negative response case, the host may respond with error information, and the equipment shall stop the execution. This standard does not define check information (e.g. “Checksum”) specification.

8.4 Other Operation Modes of PRC (optional) — Though it is not recommended from a performance view point, some operation modes other than “Cache” mode may be required in some cases. To be compliant with those different operational requirements, PRC provides optional PRC operation modes as defined below.

8.4.1 “Full Query” Mode — Query action from equipment is used every time a process request is made and no Write action from Host is used. Process execution may be cascaded as long as the process demands come with sufficient lead time during the previous process. If the lead time is not given, penalty due to query action occurs each time.

8.4.2 “Full Download” Mode — Write action from Host is used every time and no Query action from equipment is used.

8.4.3 “Pre-Download” Mode — Host to “Write” down required recipes prior to start using PRC. Host needs to have full control (“Write” down or “Delete”) of recipes in PRC. Equipment simply refers and uses the recipes in PRC, and reports an error upon “Cache Miss” or “Cache Full”.

Table 9 PRC Operation Modes

Functions “Cache” “Full Query” “Full Download” “Pre-Download” Note

Cache Clear Host or Equipment at any time

Host or Equipment at any time. Cache is used only to store one recipe most recently queried and served

Host shall control.Cache is used only to store one recipe most recently written by host

Host shall control.

Delete (from Host)

Used to delete the recipe deleted in host side (c.f. host wants to change recipe contents with same name)

Host. Equipment, after use of the recipe

Host. Equipment, after use of the recipe

Host. Used to delete unneeded recipe to avoid “Cache Full”

Query and Serve Used upon “Cache Miss”

Always used Not used Not used

Write (from host)

May be used (c.f. in case host wants to change recipe contents with same name)

Not used Always used to write down a recipe

Used for “Pre-Download” action

Upon Cache Full Equipment to delete least significant recipe according to defined rule

No cache full anticipated

No cache full anticipated

Equipment reports error, and the host to clear all or delete some

9 Production Execution Mode (PEM) Management Requirements

9.1 PEM Management — Equipment compliant with this standard shall have a “Production Execution Mode” management capability.

9.1.1 Use of PEM — In order to provide PRC functionality, equipment needs to have a definition if the equipment is in production execution or not. This determines which recipe space shall be used, PRC or “Conventional Recipe Space”.

9.1.2 Who Sets PEM — Host or privileged user of the equipment sets PEM.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

9.1.3 User Management Capability in PEM — “Production Execution Mode” flag has a capability to indicate which user has a privilege and in use. This enables PRC to clear its contents upon the change of its user.

9.2 PEM State Model — Following diagram and tables define the state model of PEM.

9.2.1 PEM State Model Diagram

Figure 9

PEM State Model

9.2.2 PEM State Model Definition

Table 10 PEM State Model Definition

State Transition

No. Name Definition No. #1 Trigger Action New State

Comments

- - (No state) Tp00 Start-up of equipment. None. Sp00

Sp00 Non Production Execution Mode

The equipment is not in Production Execution Mode

Tp01 Set Production Execution Mode to On SetPEM with PEMNumber which is not equals “0” or equivalent operation by privileged user on equipment

Set PEMNumber to “n (not 0)”

Sp01

Sp01 Production Execution Mode “n”

The equipment is in Production Execution Mode “n”

Tp02 Set Production Execution Mode to Off SetPEM with PEMNumbe=0 or equivalent operation by privileged user on equipment

Set PEMNumber to “0”

Sp00

#1 Numeric portion of the transition numbers in this column shall be used as event numbers.

9.2.3 PEM State Definition

9.2.3.1 Non Production Execution Mode — Recipes in “Conventional Recipe Space” are used. PRC may be used for reference or setting only.

9.2.3.2 Production Execution Mode — Recipes in PRC shall be used for process.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

9.2.4 PEM State Transition Table

Table 11 PEM State Transition Table

Num#1 Previous State Trigger New State Actions Comments

Tp00 (No state) Start-up of equipment Non Production Execution Mode

None.

Tp01 Non Production Execution Mode

Production Execution Mode On Production Execution Mode

Set PEMNumber to “n (not 0)”

Tp02 Production Execution Mode

Production Execution Mode Off Non Production Execution Mode

Set PEMNumber to “0”


9.3 PEM Services — This section defines the message services required to support Process Mode functionalities.

9.3.1 PEM Service Message Description — The following table is a list of PEM services.

Table 12 PEM Service Message Description

Service Name Type#1 Description

SetPEM R This service sets Production Execution Mode.

GetPEM R This service gets Production Execution Mode status.

#1 The ‘TYPE’ column is used to indicate whether the service consists of a request/response message pair, ‘R’, or a single notification message, ‘N’.

9.3.2 PEM Service Message Parameter Definition — The following is a list of required parameters used in conjunction with PEM service messages.

Table 13 PEM Service Message Parameter Definition


PEMNumber Positive integer: “0” for “Non-Production Mode” “n (not 0)” for “Production Mode n”

Number of PEM

“0”: Equipment is in “Non-Production Mode” and user is not limited (conventional mode) “n (not 0)”: Equipment is in “Production Mode n” and user category n and the host which represents the user category have privilege

9.3.3 PEM Service Message Definitions — The following tables specify the allowable/required parameters for each service.

9.3.3.1 SetPEM — This service is used to set PEM.

Table 14 SetPEM Service Parameter Definitions

Parameter Name Req/Ind Rsp/Conf Description

PEMNumber M - Number of PEM to be set

PEMStatus - M Information concerning the result of the service




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

9.3.3.2 GetPEM — This service is used to get PEM status.

Table 15 GetPEM Service Parameter Definitions


PEMStatus - M Information concerning the result of the service

9.4 PEM Variable Data Definitions — This section defines variable data requirements for PEM. Values of these variables are available to the host via collection event reports and host status queries.

Table 16 PEM Variable Data Definitions


PEMNumber Number of PEM

“0”: Equipment is in “Non-Production Mode” (conventional mode) “n (not 0)”: Equipment is in “Production Mode n” and user category “n” and the host which represents the user category have privilege

Positive integer:

“0” for “Non-Production Mode” “n (not 0) ” for “Production Mode n”

RW

PEMStatus Current number of PEM “0”: Equipment is in “Non-Production Mode” (conventional mode) “n (not 0)”: Equipment is in “Production Mode n” and user category “n” and the host which represents the user category have privilege

Positive integer: “0” for “Non-Production Mode” “n (not 0)” for “Production Mode n”

RO

10 PRC State Management Requirements

10.1 State Management of PRC

10.1.1 Activation of PRC — For upward compatibility, PRC shall be disabled when equipment is started up, and all recipe operation shall be done with “Conventional Recipe Space”. In order to use PRC in addition to “Conventional Recipe Space”, PRC shall be enabled by Host or privileged user.

10.1.2 Process Execution with PRC — In addition, in order to use recipes in PRC for process execution, PEM needs to be set to “Production Execution Mode”.

10.1.3 Cache Operation — This chapter defines the operation of PRC.

10.2 PRC State Model

10.2.1 Purpose of PRC State Model — The purpose of the PRC State Model is to define the state of PRC. Normally, PRC operates in cache operation, and may operate in other mode optionally.

10.2.2 PRC State Model Diagram




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 10

PRC State Model Diagram

10.2.2.1 Relation of Parallel States — The parallel states Sc01 and Sc10 in PRC State Model have the following restrictions. Refer to the following figure for an image.

Sc11 “Not Initialized” state shall be completed during Sc02 “Non Execution Mode” state. Tc03 shall not occur until Tc11 or Tc12 is completed.

Transitions Tc14 to Tc23 and States Sc13 and Sc14 only occur in Sc03 “Execution Mode” state. In normal cases, Tc04 shall not occur until the transitions and states are over. In case of fatal error such as a cross restricting situation (dead lock), Tc05 shall be taken to exit.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Figure 11

Relation of Parallel States in PRC State Model

10.2.3 PRC State Model Definition

Table 17 PRC State Model Definition

State Transition

No. Name Definition No. #1 Trigger Action#2 New State

Comments

- - (No state) Tc00 Startup of system None Sc00

Sc00 Non-PRC Mode

PRC is disabled Tc01 PRC enable request Enable PRC Sc01

Sc01 PRC Mode PRC is enabled Tc05 Error “Clear PRC” “PRCM Event”

Sc01

Tc06 PRC disable request Disable PRC Sc00

- - (No state) Tc02 None None Sc02

Sc02 Non Execution Mode

PRC is not used for process

Tc03 PEM is set to Production Execution Mode

“PRCM Event” Sc03

Sc03 Execution Mode

PRC is used for process

Tc04 PEM is set to Non- Production Execution Mode

“PRCM Event” Sc02

Sc10 PRC Operation

Cache is in Operation

- - - -

- - (No state) Tc10 None None Sc11

Sc11 Not Initialized

Contents of PRC are not qualified yet

Tc11 Contents of PRC are not valid

“Clear PRC” “PRCOP Event”

Sc12

Tc12 Contents of PRC are valid

“PRCOP Event” Sc12




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Sc12 Stand by PRC is ready to be referred

Tc13 “Cache Clear” “Clear PRC” Sc12

Tc14 “Cache Hit” and “Pre-Execution Check” OFF

Use the recipe Sc12

Tc15 “Cache Miss” “Query Event” Sc13 Queries the recipe

Tc17 “Delete Recipe” Delete specified recipe

Sc12

Tc18 “Read Recipe” Respond with the specified recipe

Sc12

Tc19 “Write Recipe”, and not Cache Full

Write the recipe in PRC

Sc12 The recipe is written

Tc20 “Write Recipe”, however “Cache Full”

“Cache Full” error Sc12 Couldn’t write the recipe

Tc21 “Cache Hit” and “Pre-Execution Check” ON

“Pre-ExeCheck Event”

Sc14 Optional “Pre-Execution Check”

Sc13 Query PRC is requesting a recipe to “Recipe Server”

Tc16 Queried recipe is served Put the served recipe in PRC

Sc12

Sc14 Pre-Exe Check

PRC is requesting “Pre-Execution Check” to host

Tc22 “Pre-Execution Check” OK

Use the recipe Sc12 Optional

Tc23 “Pre-Execution Check” NG and “Serve Recipe”

Put the served recipe in PRC and use

Sc12


#2 Events in the Action column report following information.

“PRCM Event” reports PRCModeState.

“PRCOP Event” reports PRCOperationState.

“Query Event” reports PRCOperationState, ClassInfo (optional), RecipeID, and UniqueID (optional).

“Pre-ExeCheck Event” reports PRCOperationState, ClassInfo (optional), RecipeID, UniqueID (optional), and check information.

10.2.4 PRC State Definitions

10.2.4.1 Non-PRC Mode — PRC is disabled and not used.

10.2.4.2 PRC Mode — PRC is enabled and used.

10.2.4.3 Non-Execution Mode — Equipment is in Non-Production Execution Mode, and recipes in PRC are not used for process.

10.2.4.4 Execution Mode — Equipment is in Production Execution Mode, and recipes in PRC are used for process.

10.2.4.5 PRC Operation — A parallel state of PRC Mode which determines elemental operations of PRC.

10.2.4.6 Not Initialized — Contents of PRC are not qualified yet.

10.2.4.7 Stand By — PRC is ready for operation.

10.2.4.8 Query — PRC has sent a Query and is waiting for the response from “Recipe Server”.

10.2.4.9 Pre-Exe Check — PRC sent information to host to check the recipe which is found (“Cache Hit”) in PRC.

10.2.5 PRC State Transition Table




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Table 18 PRC State Transition Table

Num#1 Previous State

Trigger New State Actions#2 Comments

Tc00 (No state) System startup Non-PRC Mode None

Tc01 Non-PRC Mode

PRC is enabled PRC Mode Enable PRC

Tc02 PRC Mode None Non-Execution Mode

None

Tc03 Non- Execution Mode

PEM is in “Production Execution Mode” (PEMNumber is “n (not 0)”)

Execution Mode

“PRCM Event”

Tc04 Execution Mode

PEM is in “Non Production Execution Mode” (PEMNumber is “0”)

Non-Execution Mode

“PRCM Event”

Tc05 PRC Mode Any fatal error including state problems and consistency concerns

PRC Mode “Clear PRC” “PRCM Event”

Returns to “Not Initialized” state

Tc06 PRC Mode PRC is disabled Non-PRC Mode Disable PRC

Tc10 PRC Mode None Not Initialized None

Tc11 Not Initialized

Authorization of PRC content, and decision to clear PRC

Stand By “Clear PRC” “PRCOP Event”

Tc12 Not Initialized

Authorization of PRC content, and decision not to clear PRC

Stand By “PRCOP Event”

Tc13 Stand By “Clear PRC” command Stand By “Clear PRC”

Tc14 Stand By “Cache Hit” Stand By Send the recipe to “Recipe Executer”

Tc15 Stand By “Cache Miss” Query “Query Event”

Tc16 Query Queried recipe is served Stand By Put the recipe in PRC and send the recipe to “Recipe Executer”

Tc17 Stand By “Delete Recipe” Stand By Delete specified recipe

Tc18 Stand By “Read Recipe” Stand By Respond with the specified recipe

Tc19 Stand By “Write Recipe”, and not Cache Full Stand By Write the recipe in PRC

Tc20 Stand By “Write Recipe”, and Cache Full Stand By “Cache Full” error

Tc21 Stand By “Cache Hit” and send information to host to check the recipe

Pre-Exe Check “Pre-ExeCheck Event” Optional

Tc22 Pre-Exe Check

Host responded with OK Stand By Send the recipe to “Recipe Executer”

Optional

Tc23 Pre-Exe Check

Host responded with NG, and sent down correct recipe

Stand By Put the recipe in PRC and send the recipe to “Recipe Executer”

Optional


#2 Events in the Action column report following information.

“PRCM Event” reports PRCModeState.

“PRCOP Event” reports PRCOperationState.

“Query Event” reports PRCOperationState, ClassInfo (optional), RecipeID, and UniqueID (optional).

“Pre-ExeCheck Event” reports PRCOperationState, ClassInfo (optional), RecipeID, UniqueID (optional), and check information.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

10.3 PRC Services — This section defines the message services required to support PRC functionalities. Equipment compliant with this standard shall have following services to manage PRC.

10.3.1 PRC Service Message Description — The following table is a list of PRC services.

Table 19 PRC Service Message Description

Service Name Type#1 Description

SetPRCAttributes R This service sets attributes of PRC

GetPRCAttributes R This service gets attributes of PRC

ClearPRC R This service clears all recipes in PRC

ServeRecipe R This service serves a recipe requested by “Query event”

GetRecipeIDList R This service gets list of “Recipe ID” in PRC

DeleteRecipe R This service deletes specified recipe in PRC

WriteRecipe R This service writes recipe into PRC

ReadRecipe R This service reads specified recipe from PRC

Pre-ExeCheckAck R This optional service acknowledges to the “Pre-Execution Check” if it is OK or not

#1 The ‘TYPE’ column is used to indicate whether the service consists of a request/response message pair, ‘R’, or a single notification message, ‘N’.

10.3.2 PRC Service Message Parameter Definition — The following is a list of required parameters used in conjunction with PRC service messages.

Table 20 PRC Service Message Parameter Definition


PRCSwitch Enumerated: Enabled, Disabled Enable/Disable of entire PRC function

PRCUser Positive Integer: “0”: PRC is not assigned to user

“n (not 0)”: PRC is under use of user category n and the host

Current user of PRC The same user numbers which are defined for PEMNumber shall be used Upon a change of PRCUser, the contents of PRC shall be cleared

PRCOperationMode Enumerated: Cache, FullDownload, FullQuery, PreDownload

Operation Mode of PRC Default mode is Cache

PRCPre-ExeCheck Enumerated: Enabled, Disabled Enable/Disable of “Pre-Execution Check” option This defines use of optional “Pre-Execution Check”

ClassInfo User defined Optional “Class Information” which may contain information such as type of the recipe or path to the targeted folder, mainly to support recipe linkage

RecipeID RecID which is defined in E40 “Recipe ID” RecID may not always be a unique identifier

UniqueID User defined May be standardized if needed

“Unique ID” In case “Recipe ID” cannot ensure uniqueness of recipes, “Unique ID” option or “Pre-Execution Check” option is required.

RecipeHeader User defined May be standardized if needed

Optional “Recipe Header” which may contain recipe linkage information

RecipeBody Equipment defined recipe “Recipe Body”




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26


RecipeIDList List of “ClassInfo” (optional), “RecipeID”, and “UniqueID” (optional). The optional parameters shall be NULL in case corresponding options are not selected.

List of “Recipe ID” in PRC. This includes “Class Information” and “Unique ID”.

ListOfPEMRecipe List of “ClassInfo” (optional), “RecipeID”, “UniqueID” (optional), “RecipeHeader” (optional), and “RecipeBody”. The optional parameters shall be NULL in case corresponding options are not selected.

List of “PEM Recipes”; In case of “Fail”, ListOfPEMRecipe is sent from the “Recipe Server”

SetPRCAttributesResp Enumerated: Done, Error Information concerning the result of the service

GetPRCAttributesResp Enumerated: Done, Error Information concerning the result of the service

ClearPRCResp Enumerated: Done, Error Information concerning the result of the service

ServeRecipeResp Enumerated: Done, Full, Error Information concerning the result of the service

GetRecipeIDListResp Enumerated: Done, Error Information concerning the result of the service

DeleteRecipeResp Enumerated: Done, Error Information concerning the result of the service

WriteRecipeResp Enumerated: Done, Full, Error Information concerning the result of the service

ReadRecipeResp Enumerated: Done, Error Information concerning the result of the service

Pre-ExeCheckAckResp Enumerated: Done, Full, Error Information concerning the result of the service

10.3.3 PRC Service Message Definitions — The following tables specify the allowable/required parameters for each service.

10.3.3.1 SetPRCAttributes — This service is used to initialize and start functionalities of PRC.

Table 21 SetPRCAttributes Service Parameter Definitions


PRCSwitch M - Enable/Disable of entire PRC function

PRCUser M - Current user of PRC

PRCOperationMode M - Operation mode of PRC

PRCPre-ExeCheck M - Enable/Disable of “Pre-Execution Check” option

SetPRCAttributesResp - M Information concerning the result of the service

10.3.3.2 GetPRCAttributes — This service is used to get attributes of the specified PRC.

Table 22 GetPRCAttributes Service Parameter Definitions


PRCSwitch - M Enable/Disable of entire PRC function

PRCUser - M Current user of PRC

PRCOperationMode - M Operation mode of PRC

PRCPre-ExeCheck - M Enable/Disable of “Pre-Execution Check” option

GetPRCAttributesResp - M Information concerning the result of the service

10.3.3.3 ClearPRC — This service clears all recipes in PRC.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

Table 23 ClearPRC Service Parameter Definitions


ClearPRCResp - M Information concerning the result of the service

10.3.3.4 ServeRecipe — This service serves requested recipe to PRC. “Recipe Service” from “Recipe Server” in response to “Recipe Query”. Serves corresponding “Recipe Body” and “Variable Parameters”.

Table 24 ServeRecipe Service Parameter Definitions


ClassInfo O - Optional “Class Information”

RecipeID M - “Recipe ID”

UniqueID O - Optional “Unique ID”. In case “Recipe ID” cannot ensure uniqueness of recipes, “Unique ID” option or “Pre-Execution Check” option is required.

RecipeHeader O - Optional “Recipe Header”

RecipeBody M - “Recipe Body”

ServeRecipeResp - M Information concerning the result of the service

10.3.3.5 GetRecipeIDList — This service gets a recipe identifier list of the recipes in PRC.

Table 25 GetRecipeIDList Service Parameter Definitions


RecipeIDList - M List of “Recipe ID” in PRC.

GetRecipeIDListResp - M Information concerning the result of the service

10.3.3.6 DeleteRecipe — This service deletes specified recipe in PRC.

Table 26 DeleteRecipe Service Parameter Definitions





DeleteRecipeResp - M Information concerning the result of the service

10.3.3.7 WriteRecipe — This service writes a recipe into PRC. If a same named recipe exists in PRC, this service overwrites the recipe.

Table 27 WriteRecipe Service Parameter Definitions








LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26


RecipeHeader O - Optional “Recipe Header”

RecipeBody M - “Recipe Body”

WriteRecipeResp - M Information concerning the result of the service

10.3.3.8 ReadRecipe — This service reads specified recipe from PRC.

Table 28 ReadRecipe Service Parameter Definitions





RecipeHeader - O Optional “Recipe Header”

RecipeBody - M “Recipe Body”

ReadRecipeResp - M Information concerning the result of the service

10.3.3.9 Pre-ExeCheckAck — This service acknowledges to the “Pre-Execution Check” if the recipe check passes or fails. In case where the “Pre-Execution Check” option is selected, equipment shall send “Pre-Execution Check Value” to the host upon “Cache Hit”, and the host shall respond to equipment with this service to inform “Pass” or “Fail”. In the case of a “Fail”, a “WriteRecipe” shall follow.

Table 29 Pre-ExeCheckAck Service Parameter Definitions


Pre-ExeCheckResult M - Check result. “Pass” or “Fail”

ListOfPEMRecipe C - List of “PEM Recipes”; In case of “Fail”, ListOfPEMRecipe shall be sent from the “Recipe Server”

Pre-ExeCheckAckResp - M Information concerning the result of the service

10.4 PRC Variable Data Definitions — This section defines variable data requirements for PRC compliant equipment. Values of these variables are available to the host via collection event reports and host status queries.

Table 30 PRC Variable Data Definitions


PRCSwitch Enable/Disable of entire PRC function

Enumerated: Enabled, Disabled

RW

PRCUser Current user of PRC The same user numbers which are defined for PEMNumber shall be used Upon a change of PRCUser, the contents of PRC shall be cleared

Positive Integer: “0”: PRC is not assigned to user “n (not 0)”: PRC is under use of user category n and the host

RW

PRCOperationMode Operation Mode of PRCDefault mode is Cache

Enumerated: Cache, FullDownload, FullQuery, PreDownload

RW




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26


PRCPre-ExeCheck Enable/Disable of “Pre-Execution Check” option This defines use of optional “Pre-Execution Check”

Enumerated: Enabled, Disabled

RW

PRCModeState Current state of “PRC Mode” sub-state in PRC State Model

Enumerated: NonExecutionMode, ExecutionMode

RO

PRCOperationState Current state of “PRC Operation” sub-state in PRC State Model

Enumerated: NotInitialized, StandBy, Query, Pre-ExeCheck

RO

ClassInfo Optional “Class Information” which may contain information such as type of the recipe or path to the targeted folder, mainly supports recipe linkage

User defined RW

RecipeID “Recipe ID” RecID which is defined in E40 RW RecID may not always be a unique identifier

UniqueID “Unique ID” In case “Recipe ID” cannot ensure uniqueness of recipes, “Unique ID” option or “Pre-Execution Check” option is required.

User defined RW May be standardized if needed

RecipeHeader Optional “Recipe Header” which may contain recipe linkage information

User defined RW May be standardized if needed

RecipeBody “Recipe Body” Equipment defined recipe RW

11 Related Documents

11.1 SEMI Standards and Safety Guidelines

None.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

12 Requirements for Compliance

12.1 Following table provides a checklist for PRC compliance.

Table 31 PRC Compliance Statement

Fundamental PRC Requirements PRC Section Implemented PRC Compliant

PRC Space Requirements 7

PRC Space Requirement 7.1 Yes No Yes No

PRC Operational Requirements 8

User of PRC 8.1.3 Yes No Yes No

User of Recipes in PRC 8.1.4 Yes No Yes No

Setting Aside Recipes Already Referred 8.1.7 Yes No Yes No

Fundamental Requirements 8.2 Yes No Yes No

Equipment Side 8.2.2 Yes No Yes No

“Clear PRC” 8.2.2.1 Yes No Yes No

“Write Recipe” into PRC 8.2.2.2 Yes No Yes No

“Delete Recipe” in PRC 8.2.2.3 Yes No Yes No

No “Edit Recipe” in PRC 8.2.2.4 Yes No Yes No

“Copy Recipe” from PRC 8.2.2.5 Yes No Yes No

Use of Recipe in PRC 8.2.2.6 Yes No Yes No

Cache Mode Operation 8.3 Yes No Yes No

“Pre-Execution Checks” (Optional) 8.3.5 Yes No Yes No

Other Operation Modes of PRC (Optional) 8.4

“Full Query” Mode 8.4.1 Yes No Yes No

“Full Download” Mode 8.4.2 Yes No Yes No

“Pre-Download” Mode 8.4.3 Yes No Yes No

Production Execution Mode (PEM) Management 9 Yes No Yes No

PEM Management 9.1 Yes No Yes No

Use of PEM 9.1.1 Yes No Yes No

User Management Capability in PEM 9.1.3 Yes No Yes No

PEM State Model 9.2 Yes No Yes No

PEM Services 9.3 Yes No Yes No

PRC State Management 10

State Management of PRC 10.1 Yes No Yes No

PRC State Model 10.2 Yes No Yes No

PRC Services 10.3 Yes No Yes No




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

APPENDIX 1 Example of “Production Recipe Cache” Operation in Cache Mode

NOTICE: The material in this Appendix is an official part of SEMI [designation number] and was approved by full letter ballot procedures on [A&R approval date].

A1-1 Example of PRC Operation

A1-1.1 Typical Cache Mode Operation — This appendix shows an operation example of PRC in cache mode.

A1-2 PRC Operations

A1-2.1 Cache Clear — PRC need to be cleared before start using as it may contain invalid recipes.

a. MES demands “PRC Controller” to clear “PRC Space” at any time.

b. “PRC Controller” clears the “PRC Space”.

A1-2.2 Cache Operation — Upon a demand from MES, PRC Controller looks up PRC for required recipe.

c. MES sends a PJ.

d. “Recipe Executer” queries to “PRC Controller” the recipe specified by the PJ.

e. “PRC Controller” searches the recipe from “PRC Space”.

A1-2.2.1 “Cache Hit” Operation — In case of “Cache Hit”, following operation should take place.

f. Upon “Cache Hit”, “PRC Controller” responds to “Recipe Executer” with the recipe in the “PRC Space”.

A1-2.2.2 “Cache Miss” Operation — In case of “Cache Miss”, following operation should take place.

g. Upon “Cache Miss”, “PRC Controller” queries the recipe to “Recipe Server”.

h. Then, “PRC Controller” responds to “Recipe Executer” with the recipe from “Recipe Server” and writes it in “PRC Space”.

i. If the “PRC Space” is full, “PRC Controller” deletes the recipes which have lower possibility to be used.

A1-2.3 Recipe Execution Operation — Specified recipe is copied and used.

j. “Recipe Executer” holds the recipe in “Recipe Execution Space”.

Figure A1-1 Cache Operations




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3 Example Scenario

A1-3.1 Equipment Start Up — In case such as recovery from maintenance. Unknown recipes may remain in PRC.

Figure A1-2

Equipment Start Up

A1-3.2 MES Sends “Cache Clear” Request — PRC Controller deletes recipes in PRC.

Figure A1-3

MES Sends “Cache Clear” Request




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.3 PRC is Cleared — No recipe remains in PRC.

Figure A1-4

PRC is Cleared

A1-3.4 MES Sends PJ with Recipe #A — “Cache Miss” occurs as PRC is empty.

Figure A1-5

MES Sends PJ with Recipe #A




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.5 PRC Controller Queries Recipe #A to “Recipe Server” — “Recipe Server” responds with Recipe #A.

Figure A1-6

PRC Controller Queries Recipe #A to “Recipe Server”

A1-3.6 PRC Controller Writes Recipe #A in PRC — And sends Recipe #A to “Recipe Executer”.

Figure A1-7

PRC Controller Writes Recipe #A in PRC




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.7 “Recipe Executer” sends Recipe #A to “Recipe Execution Space” — Recipe execution starts!

Figure A1-8

“Recipe Executer” sends Recipe #A to “Recipe Execution Space”

A1-3.8 PJ Ends — Recipe #A remains in the “Production Recipe Cache Space”.

Figure A1-9

PJ Ends




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.9 MES sends PJ with Recipe #A again — Cache hits as Recipe #A is in PRC.

Figure A1-10

MES sends PJ with Recipe #A again

A1-3.10 PRC Controller passes Recipe #A to “Recipe Executer” — “Recipe Executer” sends Recipe #A to “Recipe Execution Space”.

Figure A1-11

PRC Controller passes Recipe #A to “Recipe Executer”




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.11 PJ Ends Again — Recipe #A still remains in the “Production Recipe Cache Space”.

Figure A1-12

PJ Ends Again

A1-3.12 MES requests PJ with Recipe #B — “Cache Miss” occurs as Recipe #B is not in “Production Recipe Cache Space”.

Figure A1-13

MES requests PJ with Recipe #B




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.13 PRC queries Recipe #B to “Recipe Server” — And Recipe #B is served, written into “Production Recipe Cache Space”, passed to “Recipe Executer” and sent to “Recipe Execution Space”. And process starts.

Figure A1-14

PRC queries Recipe #B to “Recipe Server”

A1-3.14 PJ with Recipe #B is in Progress — Recipe #A and Recipe #B remain in PRC.

Figure A1-15

PJ with Recipe #B is in Progress




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

A1-3.15 MES requests PJ with Recipe #A again —Text.

Figure A1-16

MES requests PJ with Recipe #A again

A1-3.16 Recipe #A Starts Immediately After Completion of Recipe #B — “Recipe Executer” sends Recipe #A to “Recipe Execution Space”.

Figure A1-17

Recipe #A Starts Immediately After Completion of Recipe #B




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2013/08/26

NOTICE: Semiconductor Equipment and Materials International (SEMI) makes no warranties or representations as to the suitability of the Standards and Safety Guidelines set forth herein for any particular application. The determination of the suitability of the Standard or Safety Guideline is solely the responsibility of the user. Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant literature, respecting any materials or equipment mentioned herein. Standards and Safety Guidelines are subject to change without notice. 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 items 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.