Background Statement for SEMI Draft Document 5730 Line ...downloads.semi.org/web/wstdsbal.nsf/de4d7939711... · Line-item Revision to SEMI E170-0714 Specification for Production Recipe

1

Background Statement for SEMI Draft Document 5730 Line-item Revision to SEMI E170-0714 Specification for Production Recipe Cache Note: 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. Note: 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. Background Through the feedbacks on SEMI E170-0714 after its first publication, the following line item revisions are proposed. Note that, for simplicity, the section numbers in the quotation of E170-0714 in this ballot are used for explanations unless otherwise noted. 1. Line-item #1: Improve Convention

Motivation

‘6.1.5.1 Object Attribute Table’ of the convention quoted from SEMI E87 does not have conditional and optional expressions.

Action

Add expressions for conditional and optional to the section, delete example in ‘Table 1 Object Attribute Table’, and apply it to this document.

Impact

No specification change. 2. Line-item #2: Delete section 9 (Section 8 in E170-0714), and add a section for ‘Conceptual

Description’

Motivation

There was a negative vote which says that the Section 9 (Section 8 in E170-0714) does not contain any requirement and should be moved to appendix. The negative was not technically persuasive, however, TF decided to make an amendment for better readability.

Action

As the chapter contains conceptual descriptions rather than application notes, TF decided to improve the chapter as ‘Conceptual Description’ and to place before requirements.

According to the change from ‘folder’ to ‘subspace’ for more logical expression in the ‘Conceptual Description’, change ‘folder’ to ‘subspace’ in entire document.

Impact

No specification change. Explanations on the concept are added.

2

3. Line-item #3: Add explicit expressions to the protection requirements of ‘Recipe Queue Space’ and ‘Recipe Execution Space’

Motivation

There are device manufacturers’ requests to make more explicit expression on the security requirements of ‘Recipe Queue Space’ and ‘Recipe Execution Space’

Action

Add explicit expression to section 10.1.4. (Section 9.1.4 in E170-0714)

Impact

Protection of ‘Recipe Queue Space’ and ‘Recipe Execution Space’ is clarified. 4. Line-item #4: Add Cache Management Rules

Motivation

To balance security and system performance by Cache Hit Rate, define a rule to preserve recipes in PRC.

Action

Add Cache Management Rules as requirements and options. Introduce a function to set Maximum Number of recipes in PRC. Introduce a function to set optional Maximum Time to preserve recipes in PRC. As the result of the introduction of Maximum Number, the combination of MaxNumber and the

sequence from the host automatically determines Operation Mode of PRC. So, obsolete PRCOperationMode attribute and simplify the PRC Operation.

Make related changes which support above changes. PRC Operations are introduced to flexibly support PRC Operation Modes. Functions (Write Recipe function etc.) are improved. Related definitions and explanations are added.

Impact

Cache Management Rules become requirements. PRC Operation Modes are simplified.

5. Line Item #5: Add automatic Clear PRC function by equipment upon host communication

establishment

Motivation

To ensure Clear PRC upon equipment restart, add automated Clear PRC by equipment upon host communication establishment.

Action

Add a function, which automatically clears PRC by equipment upon host communication loss, establishment, or reestablishment, with Enable/Disable capability, as a requirement.

Impact

Automated Clear PRC function with Enable/Disable capability becomes a requirement. 6. Line Item #6: Adjust access (R/W) definitions of attributes and variables

Motivation

Attributes and variables, which are not changed by SetAttr service of OSS but changed by dedicated services, are not needed to be RW.

3

Action

The following attributes in ‘Table 24 (21 in E170-0714) PRCOBJ Attribute Definition’ should be RO because they are not changed by SetAttr service of OSS but changed by the dedicated service ‘SetPRCAttributes’.

・RUGNumber RWRO ・ClassInfo RWRO ・RecipeID RWRO ・UniqueID RWRO ・RecipeHeader RWRO ・RecipeBody RWRO The following variables in ‘Table 38 (35 in E170-0714) PRCOBJ Variable Data Definitions’ should be RO

because they are not changed by SetAttr service of OSS but changed by the dedicated service ‘SetPRCAttributes’.

・PRCSwitch RWRO ・RUGNumber RWRO ・Pre-ExeCheck RWRO ・ClassInfo RWRO ・RecipeID RWRO ・UniqueID RWRO ・RecipeHeader RWRO ・RecipeBody RWRO

Impact

No big impact. 7. Line Item #7: Improvement of wordings and explanations

Motivation

There are some expressions needed to be improved or corrected from wording view point. There are some parts more explanations / clarifications are expected.

Action

Improve / correct wordings and add explanations / clarifications as needed. Note that this line item is not numbered by <#7> and </#7>, underlines are used for addition and double

strikeouts are used for deletion.

Impact

No technical changes. Note in the proposals, line items are distinguished by colors. The start point of a line item is marked with the line item number as <#n>, and the end point of a line item is marked with the line item number as </#n>. The added text is typically highlighted with underline. Removed text is typically denoted with double strikeout marks (on the bottom for figure). Deleted figure is denoted with <#n>Delete</#n>, added figure is denoted with <#n>Add</#n> (may be nested in the tags with the same number). These markings are for highlight in the ballot only. They are not proposed to be included in the updated standard. Where the proposals show text extracted from the existing standard, any references in the text are aligned with current section numbering. However, recognize that various proposals may add or remove sections, requiring adjustment of references. This ballot assumes that SEMI will adjust these references prior to publication.

4

Revision Control

This revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force.

Date Version Name Edits

Oct. 15, 2014 1.0 Terry Asakawa The first line item ballot

Review and Adjudication Information Task Force Review Committee Adjudication Group: Japan GEM 300 TF Japan TC Chapter of Global Information &

Control Technical Committee Date: Thursday, December 4, 2014 Friday, December 5, 2014 Time & Time Zone: 10:00-13:30 [JST] 11:00-17:00 [JST] Location: Tokyo Big Sight Conference Tower Tokyo Big Sight Conference Tower City, State/Country: Tokyo, Japan Tokyo, Japan Leader(s): Yoshihisa Takasaki (SCREEN

Semiconductor Solutions Co., Ltd) Takayuki Nishimura (SCREEN Semiconductor Solutions Co., Ltd) Mitsuhiro Matsuda (Hitachi Kokusai Electric Inc.)

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

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

Task Force Review meeting’s details are subject to change, and additional review sessions may be scheduled if necessary. Contact the task force leaders or 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. This line-item ballot includes the purpose, scope, limitations and terminology sections per SEMI Standards Procedure Guide. 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] Please be advised that voter requests for access to the full Standard must be made at least three business days before the voting deadline. Late requests may not be honored, and if the Standard is not available for this reason, the voter may not use this as justification for rejecting the ballot.

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

Date: 2014/10/20

SEMI Draft Document 5730 Line-item Revision to SEMI E170-0714: SPECIFICATION FOR PRODUCTION RECIPE CACHE (PRC) Make following line item revisions to the specified part of SEMI E170-0714. Note that, for simplicity, the section numbers in the quotation of SEMI E170-0714 in this ballot are used for explanations unless otherwise noted. Line Item #1: Improve Convention Line Item #2: Delete section 9 (Section 8 in E170-0714), and add a section for ‘Conceptual Description’ Line Item #3: Add explicit expressions to the protection requirements of ‘Recipe Queue Space’ and ‘Recipe Execution Space’ Line Item #4: Add Cache Management Rules Line Item #5: Add automatic Clear PRC function by equipment upon host communication establishment Line Item #6: Adjust access (R/W) definitions of attributes and variables Line Item #7: Improve wordings and add explanations as needed (not numbered)

#7-1 Replace ‘Upstream’ in the figures in appendix 1 to ‘Host’.

Note in the proposals, line items are distinguished by colors. The start point of a line item is marked with the line item number as <#n>, and the end point of a line item is marked with the line item number as </#n>. The added text or figure is typically highlighted with underline. Removed text or figure is typically denoted with double strikeout marks (on the bottom for figure). In addition, for better visibility, deleted figure is denoted with <#n>Delete</#n>, added figure is denoted with <#n>Add</#n> (may be nested in the tags with the same number). These markings are for highlight in the ballot only. They are not proposed to be included in the updated standard. Where the proposals show text extracted from the existing standard, any references in the text are aligned with current section numbering. However, recognize that various proposals may add or remove sections, requiring adjustment of references. This ballot assumes that SEMI will adjust these references prior to publication.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Quotation from SEMI E170-0714: SPECIFICATION FOR PRODUCTION RECIPE CACHE (PRC)

This Standard was technically approved by the Information & Control Global Technical Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on June 17, 2014. Available at www.semiviews.org and www.semi.org in July 2014.

1 Purpose

1.1 The purpose of this Standard is to provide a standardized recipe transfer and storage mechanism from Recipe Server to equipment, which is used for semiconductor manufacturing systems or similar ones, where the management of the master copies of the recipes for mass-production is centralized on the Recipe Server.

1.2 The purpose of this Standard is to provide a standardized mechanism to transfer production recipes from Recipe Server to equipment, and to store the recipes securely in the equipment, so that the recipes in the equipment are exact subset copies of the recipes in the Recipe Server and are protected from non-authorized access, in a factory in which the master copies of production recipes are managed on the Recipe Server.

1.3 The purpose of this Standard is to provide a recipe transfer and storage mechanism which provides the following benefits.

Protection of the recipes in equipment from non-privileged access by defining a protected recipe space and Recipe User Group management capability

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

Reduction of operator efforts to download recipes that are used for production from Recipe Server to equipment by providing an automatic transfer mechanism

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

Reduction of communication and computation overhead and cost due to recipe download related transactions by adopting Cache Mode operation

1.4 The purpose of this Standard is to provide a recipe transfer and storage mechanism which is compatible with current practices in the following aspects for easier deployment.

Recipe identification and uniqueness control

Recipe linkage

Variable Parameter management

Recipe operations except for production execution

Consistency check of a recipe with the recipe in Recipe Server just before execution (Pre-Execution Check)

Conventional recipe download modes such as Pre-Download Mode or Full Download Mode

2 Scope

2.1 This Standard covers a definition and usage of Production Execution Mode (PEM) state which represents the status of equipment, whether the equipment is in use for mass production or not.

2.2 This Standard covers a definition and usage of Recipe User Group for recipe security control.

2.3 This Standard covers a definition of new recipe space named Production Recipe Cache (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.4 This Standard covers definitions of mechanisms and operations which manage PRC so that recipes in PRC are protected from non-privileged access and are consistent with the recipes on the Recipe Server in the host.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

NOTICE: SEMI Standards and Safety Guidelines do not purport to address all safety issues associated with their use. It is the responsibility of the users of the documents to establish appropriate safety and health practices, and determine the applicability of regulatory or other limitations prior to use.

3 Limitations

3.1 No Message Definition — This Document does not define any messaging. Messaging may be defined in a separate standard.

3.2 Master Copies on Recipe Server — This Standard has a precondition that the master copies of the recipes that are used in PEM On state are stored and managed on Recipe Server. This Standard cannot be applied to the factory in which a Recipe Server does not exist.

3.3 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 by allowing the structure of PRC to be composed as equivalent with the structure of the Conventional Recipe Space.

3.4 Recipe Identification — This Standard does not define any recipe identification scheme requirements but is intended to be compatible with the existing recipe identification schemes.

3.5 Variable Parameters — This Standard does not define any specific requirements for Variable Parameters but is intended to be compatible with the current implementations.

3.6 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 (PM)

SEMI E87 — Specification for Carrier Management (CMS)

SEMI E94 — Specification for Control Job Management (CJM)

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 PJ — process job

5.1.5 PRC — production recipe cache

5.1.6 PEM — production execution mode

5.2 Definitions

<#4>

5.2.1 cache full — the required recipe cannot be written into the PRC because the PRC does not have enough space to write the specified recipe.

</#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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 carrier — a container, such as a FOUP or open cassette, with one or more positions for holding substrates. [SEMI E87]

5.2.5 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 E30]

5.2.6 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.7 host — the factory computer system or an intermediate system that represents the factory and the user to the equipment [SEMI E87], the intelligent system which communicates with the equipment. [SEMI E4, SEMI E5]

5.2.8 multi-part equipment — equipment that has a capability to accomplish multiple operations that require recipe execution by multiple users simultaneously.

5.2.9 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.10 operator — a human who operates the equipment to perform its intended function (e.g., processing). The operator typically interacts with the equipment via the equipment supplied operator console. [SEMI E30]

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

5.2.12 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.13 production execution mode (PEM) — a mode of equipment, in which the equipment is used for production. The state which determines whether the equipment operates in this mode or not shall be set by the host or privileged user. In PEM On state, Online/Remote/Auto may typically be used; however other combinations may also be used for some purposes such as operator assistance, so PEM is an independent mode from Online/Offline, Remote/Local or Auto/Manual.

5.2.14 production execution mode recipe (PEM Recipe) — a recipe which is used in PEM On state. PEM Recipe consists of not only recipes for mass production lots but also recipes for engineering lots, etc., as long as the recipes are used in PEM On state. Any recipe that is prepared to be used in the PEM On state shall be considered as a PEM Recipe.

5.2.15 production recipe cache (PRC) — a recipe space that resides in equipment and holds exact subset copies of PEM Recipes on the Recipe Server by using PRC Operation.

5.2.16 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.17 recipe executor — a component of a module that stores and executes recipes. [SEMI E40]

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

5.2.19 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.20 recipe queue space — a recipe space in the equipment which holds the recipe(s) already referred and queued for execution.

5.2.21 recipe server — a 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.22 substrate — material held within a carrier. This can be product, or durables such as reticles. [SEMI E87]

5.2.23 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 in addition to the Recipe ID.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

5.2.24 user — a human or humans who represent the factory and enforce the factory operation model. A user is considered to be responsible for many setup and configuration activities that cause the equipment to best conform to factory operations practices. [SEMI E30]

5.2.25 recipe user group — a group which consists of one or more users who have the same privilege to access specified recipes from a security control view point. The recipes may be specified as the ones in the same recipe space. Recipe User Group is not intended to be used for safety control purposes.

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.

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. Using SEMI E39 Object Services Standard, for example, it is possible to:

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

get the specified properties for one or more individual objects.

6.1.4 Rules for Object Properties

Attributes with RO (Read Only) access cannot be changed using SetAttr service as defined in OSS.

Attributes with RW (Read/Write) 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 <#1> (Y), conditional (C), or optional (O) </#1> 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

<#1> ObjType Object type RO Y Text = ‘Carrier’ </#1>

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.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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, 1987.1

6.2.3 State Model Definition Table — The State Model Definition Table used in this Standard has the following format. This table defines states and possible transition(s) from each state side by side. Each state has one or more transitions. In case the transition comes from outside this table, the State column for the transition may be blank (see #1). 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 the State column define States with No. (Number), Name and Abstract of Definition. ‘No.’ corresponds to the state number in the associated state diagram. ‘Name’ defines a name of each state. ‘Abstract of Definition’ provides an abstract of the State Definition in the State Definition Table.

6.2.3.2 Definition of Transition — Columns under the Transition column define Transitions with No. (Number), Abstract of Trigger, Abstract of Action, New State, and Comments. ‘No.’ corresponds to transition number in the associated state diagram. ‘Abstract of Trigger’ and ‘Abstract of Action’ provide abstracts of the Trigger and Action in the State Transition Table accordingly. ‘New State’ defines a state number to move after the transition is completed by pointing one of the states defined in the state definition in left side of the table. The Comment column may be used to put comments to each transition or their From state.

Table 2 State Model Definition Table

State Transition

No. Name Abstract of Definition No. Abstract of Trigger Abstract of 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 of 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 A state which has substates.

#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 Table — State definition tables are provided in conjunction with the state diagrams to explicitly describe the definition of each state. A state definition table contains columns for State Number, Mnemonic, State Definition, and Comments.

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: 2014/10/20

Table 3 State Definition Table

Num Mnemonic State Definition Comments

6.2.5 State Transition Table — State transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each state transition. A state 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 4 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 Standard. 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 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 Substates — Some equipment may need to include additional substates other than those in this Standard. Additional substates 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 Substates — In case a state model is defined with multiple AND substates, 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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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 assigned 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 5 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:

Table 6 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 7 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):




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

Table 9 Variable Data Definitions

Variable Name Description Type Access Comment

<#2>

7 PRC Conceptual Descriptions . 7.1 Conceptual Descriptions — This chapter defines and describes a concept of PRC. This chapter does not contain any requirements.

7.2 Equipment Centric vs. Recipe Server Centric — There may be several management policies of production recipes from equipment centric to Recipe Server centric. This Standard is designed to be applicable to the methods described in the following Figure.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#2>Add</#2>

Figure 1 Typical Recipe Server-Equipment Models and Coverage of PRC

7.3 Intended Application of This Standard — The intended application of this standard is to construct a Recipe Server centric recipe management system which provides ‘What you have done on the Recipe Server is what you will have on the equipment’ operability and ‘Secure and safe Production Execution path isolated from operators’. The key features are:

Clear separation between ‘Production’ and ‘Preparation’ activities

‘Centralized Management’ of the master copy of ‘Production Recipes’ on Recipe Server

Only privileged user can handle Production Recipes (e.g. Certification)

Leave ‘Conventional Recipe Space’ flexible as it is, for installation, maintenance, recipe development, etc.

Introduction of ‘Production Recipe Cache’ as secure and safe ‘Production Execution Path’ for Production Recipes

Introduction of ‘Production Execution Mode’ flag which selects ‘Production Recipe Cache’ instead of ‘Conventional Recipe Space’ for secure production execution, when the flag shows the equipment is in ‘Production Execution Mode’.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#2>Add</#2>

Figure 2 Example of Intended Application of PRC

7.4 Direct Service from Recipe Server in the Host — Introduction of Query Recipe from equipment may ease the use of direct service from Recipe Server in the host system instead of the use of service through MES.

7.5 Reduction of Computing and Communication Loads for Recipe Download and Check — Introduction of protected recipe space ‘PRC’ and Cache Mode operation reduces computing and communication loads for recipe download and avoids pre-execution check overhead. Recently used recipes are safely preserved in PRC and reused for consequent PJ creations with the same recipe.

7.6 Deployment Considerations — Introduction of Enable/Disable capability by the host makes deployment easier. The host can enable PRC when the host is ready to use PRC.

7.7 Cascading Considerations — Introduction of Cache Mode operation or Pre-Download Mode operation gives more freedom to recipe service timings for better cascading of process execution while reducing recipe related transactions.

7.8 Operational Compatibility — To be upward compatible with conventional operations, this Standard covers the following PRC Operation Modes. Pre-execution check is not logically required for PRC which is properly implemented and operated, however, may be required to help deployment path from conventional Pre-execution check based system or for double check purpose in some situations.

PRC Operation Modes

Full Download Mode: The host downloads required recipes every time just before demanding a PJ creation. Full Query Mode: Equipment queries required recipes every time upon PJ creation. Pre-Download Mode: The host downloads recipes prior to PJ creation demands for some duration. Cache Mode: Equipment holds recently used recipes in the PRC and queries required recipes in case they are

not in the PRC.

Pre-execution check operation

Pre-Exe Check: Equipment uploads check information of the required recipe to the host for consistency check upon PJ creation, and the host responds with affirmative message or download of the correct recipe.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

7.9 Linked Recipe Compatibility — To be compatible with current implementations, PRC introduces a concept which makes the recipe linkage scheme of PRC the same with Conventional Recipe Space.

7.9.1 Management of Host-Managed Sub-Recipes — Sub-recipes, which are under management of the host, may be managed similarly 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.

<#2>Add</#2>

Figure 3 Linkage to Host-Managed Sub-Recipes

7.9.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 the scope of PRC. Those recipes may reside somewhere in the equipment (may reside in a part of Conventional Recipe Space), and may 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.

<#2>Add</#2>

Figure 4 Linkage to Locally Managed Sub-Recipes

7.10 PRC Space Structure Concept — The PRC may be used in the following ways to maintain compatibility with existing implementations of recipe space.

7.10.1 Subspace Structure in PRC — PRC may be structurally divided into multiple tiers of multiple subspaces. Alignment of subspace structure with the one in the Conventional Recipe Space and/or the recipe space in Recipe Server may be useful for following purposes.

7.10.1.1 Linked Recipe Aspect — This subspace concept may be used to deal with Linked Recipe.

7.10.1.2 Recipe Security Aspect — This subspace concept may also be used for security purposes.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#2>Add</#2>

Figure 5 PRC Space Structure Concept

7.10.2 How to Specify Subspace — To be compatible with the current implementations, the same subspace specification (path specification) mechanism, which is used in the Conventional Recipe Space, may be used.

7.10.3 Subspace Structure Relationship between Conventional Recipe Space and PRC — The subspace structure of PRC may be aligned with the subspace structure of Conventional Recipe Space in the equipment for easier correlation.

7.10.4 Subspace Structure Relationship between PRC and Recipe Server — The subspace structure in the recipe serving function in the host may be aligned with the subspace structure of PRC in equipment for easier correlation.

</#2>

8 PRC Space Requirements

8.1 PRC Space Implementation Requirement — Equipment compliant with this Standard shall have a recipe space named PRC in addition to the Conventional Recipe Space.

8.1.1 PRC as Logical Space — The space requirement of PRC is to prepare a space which can logically separate PEM Recipes from others. This Standard does not define an implementation method. For example, equipment may adopt a method which stores all recipes in Conventional Recipe Space as they are, mark PEM Recipes, and deal with the marked recipes as PEM Recipes in PRC. In other words, equipment may adopt a method which stores all recipes in the same location, but enables a flag to mark PEM Recipes. The PEM Recipes are then considered to be in PRC.

8.2 Usage of PRC and Conventional Recipe Space — Usage of PRC and Conventional Recipe Space are shown in the following table in relation with PRCOBJ State and PEMJ State.

Table 10 Usage of PRC and Conventional Recipe Space

States Recipe Spaces Comment

PRCOBJ State PEMJ State Conventional Recipe Space PRC

PRC Disabled Not applicable Holds all recipes the equipment has Used for all purposes

Not used This is the state which is compatible with the conventional operation




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

States Recipe Spaces Comment

PRCOBJ State PEMJ State Conventional Recipe Space PRC

PRC Enabled PEM Off Holds recipes other than PEM Recipes that are managed on Recipe Server Used for process execution

Holds copies of PEM Recipes that are managed on Recipe Server Not used for process execution Used for preparations operation of PRC before PEM On such as Cache Clear operation or Download operation and pre-download

This is the state for non-mass production operations such as installation, maintenance and process development

PEM On Holds recipes other than PEM Recipes that are managed on Recipe Server Used for process execution of recipes that are not managed on Recipe Server

Holds copies of PEM Recipes that are managed on Recipe Server Used for process execution of recipes that are managed on Recipe Server

This is the state for mass production

Figure 6

Concept of PRC

8.3 Multi-Part Equipment Compatibility (Optional) — In case the equipment has a capability to divide itself into multiple parts that can operate in PEM On state or in PEM Off state independently (as a consequence, each part has its own Recipe Execution Space, and also may have its own Recipe Queue Space), the PEMJ state of the each part shall separately be managed and the use of PRC shall separately be controlled as shown in the following figure.

8.3.1 Multi-Part Equipment with One PRC — In case security control is not required between the recipes for multiple parts of the equipment, one PRC may be shared across all parts of the equipment.

8.3.2 Multi-Part Equipment with Dedicated PRCs — In case security control is required between the recipes for the multiple parts of the equipment, each part of the equipment shall have a dedicated PRC.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure 7

PRC Implementation for Multi-Part Equipment

<#2>

9 PRC Space Recommendations .

9.1 This chapter describes recommendations that are related to the PRC space implementations and does not contain any requirement.

9.2 PRC Space Structure Recommendations — The PRC may be used in the following ways to maintain compatibility with conventions and existing implementations of recipe space.

9.2.1 Folder Structure in PRC — PRC may be structurally divided into multiple tiers of multiple folders. This Standard does not define 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.

9.2.1.1 Linked Recipe Aspect — This folder capability may be used to deal with Linked Recipe.

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

<#2>Delete</#2>

Figure 8 Example PRC Folder Structure




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

<#2>Delete</#2>

Figure 9 Example PRC Folder Structure Relationship

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

<#2>Delete</#2>

Figure 10 Folder Structure Relationship of PRC to Conventional Recipe Space in Equipment

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

<#2>Delete</#2>

Figure 11 Folder Structure Relationship Between PRC and Recipe Server

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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

9.3.1 Management of Host-Managed Sub-Recipes — Sub-recipes which are under management of the host, may be managed similarly 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.

<#2>Delete</#2>

Figure 12 Host-Managed Sub-Recipes

9.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 the scope of PRC. Those recipes may reside somewhere in the equipment, and may 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.

<#2>Delete</#2>

Figure 13 Linkage to Locally Managed Sub-Recipes

</#2>

10 PRC Operational Requirements

10.1 Operational Preconditions — This section describes preconditions for operations of the PRC.

10.1.1 Single Point of Control (SPOC) — <#4> All PRC Operation is done between the host and Equipment. </#4> The host side (e.g., something like an Equipment Interface) should maintain which node in the host takes care of which functionality of PRC oOperation.

10.1.2 Single Point of Recipe Management (SPORM) — The master copy of PEM Recipes shall be managed by the host (normally by Recipe Server) and all PEM Recipe related interactions defined in this Standard shall be done between the host (including Recipe Server) and the equipment. Backup copies may be somewhere in the host, and temporary copies to support seamless execution are normally in the equipment.

10.1.3 PRC as Temporary Recipe Space — PRC shall be considered as a temporary recipe space which may be cleared whenever the host or privileged user decides for consistency or security reasons.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.1.4 Copy Out of the Recipes Already Referred (Recipe Queue Space and Recipe Execution Space) — Recipes already used to create PJs shall be copied from the PRC to other protected recipe spaces such as Recipe Queue Space or Recipe Execution Space which hold the recipes while the PJs are queued or executed accordingly, so that recipes in PRC can be overwritten or deleted at any time. <#3> Recipes in the protected recipe space (such as Recipe Queue Space or Recipe Execution Space) shall not be able to be read or written by Non-host-controlled or non-privileged-user-controlled actions. </#3>

Figure 14 Position of PRC

10.2 Fundamental Requirements — This section defines operation rules of PRC.

10.2.1 Use of Recipes in PRC — Recipes in PRC shall be used for process execution only in the PEM On state. Conventional Recipe Space shall be used in the PEM Off state.

10.2.2 Recipe Security Control of PRC — To ensure the security of the recipes in PRC, the entire recipes in PRC may be cleared by the host or privileged user upon the change of Recipe User Group which is indicated by RUGNumber attribute of PRC.

10.2.3 No Concurrent PRC Reference for Multiple Recipe Request — Equipment may have multiple recipe reference requirements simultaneously, however, concurrent requests for multiple recipes to PRC (such as a new recipe request during Query Recipe state) are not allowed. Recipes shall be requested one by one.

<#4>

10.2.4 Recipe Consistency Management by the Host — In the following cases the host (Recipe Server) shall delete a PEM Recipe potentially exists in PRC by using Delete Operation in order to maintain consistency between the PEM Recipes in Recipe Server and the PEM Recipes in PRC. In case recipe modification under the same Recipe ID or recipe deletion occurred on Recipe Server, overwrite or deletion of the recipe in PRC shall be done accordingly by the host (Recipe Server) in order to maintain consistency of recipes between Recipe Server and PRC. The host shall not execute Delete Operation on the PEM recipe which is being used for PJ creation (the PJ creation demand from the host is not responded with completion by the equipment) by the equipment. Equipment ignores the Delete Operation from the host in case the specified recipe is not in PRC. In case MaxNumber=0 (Full Download Mode or Full Query Mode), the deletion may not be required.

10.2.4.1 Recipe Modification under the Same Recipe ID on Recipe Server — In case PEM Recipe modification under the same Recipe ID without the use of Unique ID occurred on Recipe Server, the host (Recipe Server) shall delete a PEM Recipe, which has the same Recipe ID, potentially exists in PRC.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.2.4.2 Recipe Deletion on Recipe Server — In case PEM Recipe deletion occurred on Recipe Server, the host (Recipe Server) shall delete the PEM Recipe, which has the same Recipe ID (and Unique ID if in use), potentially exists in PRC.

</#4>

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

10.2.6 No Editing of 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.

10.2.7 Copy Out of a Recipe from PRC — Except for the copy out of a recipe for PJ creation in PEM On state, 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 or experiment. It may be faster to copy a recipe in PRC into Conventional Recipe Space than to download the recipe from the host.

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

<#4>

10.2.9 Content Management Logics Overflow Control of PRC — This section defines content management logics of PRC. To prevent PRC overflow, following actions may be taken.

The 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

10.2.9.1 Maximum Number of PEM Recipes Preserved in PRC Recipe Deletion Order for Overflow Control — Maximum number of PEM Recipes preserved in PRC after PJ creation is dynamically settable from the host by using MaxNumber attribute of PRC. MaxNumber has a list structure so that each subspace may have individual number in case PRC has subspace structure. PRC shall accept as many PEM recipes downloaded by the host before PJ creation demand (See Write Recipe function for Cache Full handling), and MaxNumber shall be referred to determine how many PEM Recipes are preserved in PRC upon the change of MaxNumber or each time after PJ creation. Least recently accessed (written into PRC or used for PJ creation) PEM Recipes are deleted in case the number of PEM Recipes exceeds the value in MaxNumber after PJ creation. Regardless of the value set to MaxNumber, absolute maximum number of PEM Recipes in PRC is limited by the capacity of the PRC. 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

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

10.2.9.2 Maximum Time of PEM Recipes Preserved in PRC (Optional) — An optional function which determines the maximum preservation duration, after its latest accesses (write into PRC or used for PJ creation), of PEM Recipes in PRC preserved under Maximum Number management. PRC object has an attribute MaxTime for this purpose. A PEM Recipe which expired with this time limit shall automatically be deleted by the equipment. MaxTime is dynamically settable from the host.

</#4>

<#4>

10.3 PRC Operation Modes — PRC Operation Mode is a way to use PRC Operations in order to transfer PEM Recipe from the host to the equipment, and to use the PEM Recipes in the equipment. PRC performs following four PRC Operation Modes. In case PRC has subspace structure, each subspace may independently operate in different PRC Operation Mode.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Table 11 PRC Operation Modes

MaxNumber

Download or Query

MaxNumber =‘0’ MaxNumber =‘1’ or More Download/Query and Lookup Relationship

Download Basis The host downloads required PEM Recipes prior to the associated PJ creation demand.

Full Download Mode Download: Every time just before associated PJ creation demand Look-up: Upon PJ creation Cache Hit: Occurs Cache Miss: Doesn’t occur Preservation: None. Delete all

Pre-Download Mode Download: Appropriately before associated PJ creation demand Look-up: Upon PJ creation Cache Hit: Occurs Cache Miss: Doesn’t occur Preservation: Allowed number

Upon PJ creation, equipment looks up the required PEM Recipes in PRC. The required PEM Recipes are in PRC and are used for the PJ creation.

Query Basis The host doesn’t download required PEM Recipes prior to the associated PJ creation demand.

Full Query Mode Download: None Look-up: Upon PJ creation Cache Hit: Doesn’t occur Cache Miss: Occurs every time. Query is used. Preservation: None. Delete all

Cache Mode Download: None Look-up: Upon PJ creation Cache Hit: May occur Cache Miss: May occur. Query is used. Preservation: Allowed number

Upon PJ creation, equipment looks up the required PEM Recipes in PRC. In case the required PEM Recipes are in PRC, the PEM Recipes are used for the PJ creation. In case the required PEM Recipes are not in PRC, the equipment queries the required PEM Recipes and uses the served PEM Recipes for the PJ creation.

MaxNumber and Write Recipe Relationship

PEM Recipes downloaded by the host or queried by the equipment are once written into PRC regardless of MaxNumber. In case Cache Full occurred, least recently accessed (written into PRC or used for PJ creation) PEM Recipe is deleted.

MaxNumber and Preservation Relationship

No PEM Recipes are preserved in PRC after PJ creation.

Allowed numbers of PEM Recipe are preserved in PRC after PJ creation. In case the number of PEM Recipes exceeds MaxNumber, least recently accessed (written into PRC or used for PJ creation) PEM Recipe is deleted.

10.4 PRC Operations — PRC has the following operations. PRC Operation Modes uses these PRC Operations.

Table 12 PRC Operations

PRC Operation Operation Used PRC Function Note

Cache Clear Clear entire contents of PRC Clear PRC The host or equipment triggers

Download The host downloads PEM Recipes into PRC Write Recipe

Delete The host deletes a specified PEM Recipe in PRC

Delete Recipe

Lookup Equipment looks up the required PEM Recipe in PRC

Cache Miss Equipment queries the required PEM Recipe to Recipe Server as the required PEM Recipe is not in PRC

Query Recipe Write Recipe

Equipment uses the served PEM Recipe from Recipe Server for the PJ creation




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

PRC Operation Operation Used PRC Function Note

Cache Hit Equipment finds the required PEM Recipe in PRC

- Equipment uses the PEM Recipe found in PRC for the PJ creation

Consistency Check (Optional)

Equipment optionally initiates Pre-Execution check upon Cache Hit

Pre-Execution CheckWrite Recipe

10.4.1 Cache Clear Operation — Cache Clear Operation clears all the recipes in PRC. Clear PRC function is used for Cache Clear Operation.

<#4>Add</#4>

Figure 15 Cache Clear Operation

10.4.2 Download Operation — Download Operation writes down PEM recipes into PRC by using Write Recipe function. The host can issue Download Operation whenever the equipment is not in PJ creation.

<#4>Add</#4>

Figure 16 Download Operation

10.4.3 Delete Operation — Delete Operation deletes the specified PEM Recipe in PRC. Delete Operation from the host uses Delete Recipe function. The host can issue Delete Operation whenever the equipment is not in PJ creation.

<#4>Add</#4>

Figure 17 Delete Operation




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.4.4 Lookup Operation — Lookup Operation is used to look up the required recipe in PRC. Equipment initiates Lookup Operation upon PJ creation.

10.4.4.1 Cache Miss Operation — In case the required recipe is not in the PRC (Cache Miss), equipment requests the recipe to the Recipe Server by using Query Recipe function, Recipe Server downloads the requested recipe into PRC by using Write Recipe function (See Write Recipe function for Cache Full handling). The recipe written into PRC is served to PJ Creator for PJ creation.

<#4>Add</#4>

Figure 18 Cache Miss Operation

10.4.4.2 Cache Hit Operation — In case the required recipe is in the PRC (Cache Hit), equipment uses the recipe for the PJ creation.

<#4>Add</#4>

Figure 19 Cache Hit Operation

10.4.4.2.1 Consistency Check Operation (Optional) — Upon Cache Hit, Consistency Check operation may be used in order to confirm the consistency of the content of the PEM Recipe in the PRC with the PEM Recipe with the same Recipe ID in Recipe Server. The equipment uses Pre-Execution Check function in order to request consistency check to the host (Recipe Server) and to have OK/NG information. In case of NG, the host downloads correct PEM Recipe by using Write Recipe function.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#4>Add</#4>

Figure 20 Consistency Check Operation (OK and NG)

</#4>

10.5 PRC Functions — This section defines each function of PRC.

<#4>

Table 13 PRC Functions

PRC Function Function Used Service Used Event Note

Clear PRC Clear entire contents of PRC ClearPRC -

Query Recipe Request a PEM Recipe to Recipe Server - Query

Write Recipe Write PEM Recipes into PRC WriteRecipe -

Delete Recipe Delete a specified PEM Recipe in PRC DeleteRecipe -

Read Recipe (Optional)

Read a specified PEM Recipe from PRC ReadRecipe - Not used for PRC Operations

Pre-Execution Check (Optional)

Pre-Execution check upon Cache Hit Pre-ExeCheckAck Pre-ExeCheck

</#4>

10.5.1 Clear PRC Function — A function which clears entire contents of PRC. This function is used in case the recipes in PRC are deemed inconsistent with the recipes in Recipe Server. The host uses ClearPRC service to execute Clear PRC. The equipment executes Clear PRC function, triggered by the cases listed below.

The host or the privileged user shall trigger Clear PRC in case there is a known mismatch between recipes in PRC and the recipes on the Recipe Server.

The host or the privileged user may trigger Clear PRC in case they deem that mismatch is highly probable between recipes in PRC and the recipes on the Recipe Server (such as after maintenance).

An operator may trigger Clear PRC in case there is a known mismatch between recipes in PRC and the recipes on the Recipe Server (such as after maintenance).

The host or the privileged user may trigger Clear PRC in case they deem there is a security concern on leaving the recipes in PRC (such as Recipe User Group change).

<#4>

The equipment shall trigger Clear PRC after copy out of the downloaded recipe in case the PRC is used as one time buffer space for each download of recipe.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

</#4>

The equipment may trigger Clear PRC for security in case Recipe User Group is changed (Recipe User Group change is known as the change of RUGNumber in the attributes of the PRCOBJ).

Privileged user may trigger Clear PRC in case there is a known impact to the contents of the PRC (such as disk drive exchange in maintenance).

<#5>

10.5.1.1 Auto Clear Function — A function which automatically clears PRC by equipment, in order to avoid unexpected recipe read out after the host communication for PRC management is lost, and in order to avoid unexpected recipe existence when the host communication for PRC management is established. Equipment shall trigger Clear PRC function automatically when the host communication for PRC management is established, lost, or re-established. Auto Clear function is enabled or disabled by AutoClear. AutoClear shall be nonvolatile.

</#5>

10.5.2 Query Recipe Function — A function which requests a recipe to Recipe Server. The equipment sends a Query Event which specifies and requests a recipe to Recipe Server.

10.5.2.1 Query of Linked Recipes (Optional) — In case the recipe has linkage(s) to sub-recipe(s), and those linked sub-recipe(s) are also managed in the Recipe Server and PRC, the linked sub-recipe(s) are also queried upon their Cache Miss. Multiple queries may occur from the equipment sequentially during a PJ creation, and the Recipe Server shall respond with a download for each query.

<#4>

10.5.3 Write Recipe Function — A function which writes a one or more recipes directly into PRC or overwrites a recipe already existing in PRC. In case the specified recipes areis already in PRC, the Write Recipe function simply overwrites those recipes in PRC. In case Cache Full occurred upon the execution of Write Recipe function, the specified recipe is not written in PRC and an error is reported. This function is triggered done by the WriteRecipe service from the host (Recipe Server) or operation by a privileged user.

10.5.3.1 Cache Full Handling — In case Cache Full occurred upon the execution of Write Recipe function, least recently accessed (written into PRC or used for PJ creation) recipes are deleted in order to create sufficient space to proceed with the Write Recipe function.

10.5.4 Delete Recipe Function (Optional) — An optional function which deletes the specified recipe in PRC. In case the specified recipe is not in PRC, the Delete Recipe function performs no action. This function may be used to delete a recipe which is not needed or not consistent with the recipe on the Recipe Server. Equipment shall execute Delete Recipe function upon DeleteRecipe service from the host or operation by a privileged user. GetRecipeIDList service may be used to see what recipes are in PRC.

10.5.5 Read Recipe Function (Optional) — An optional function which reads the specified recipe from PRC. This function may be used to copy out a recipe from PRC. This function is triggered by the ReadRecipe service from the host (Recipe Server) or operation by privileged user. GetRecipeIDList service may be used to see what recipes are in PRC.

10.5.6 Pre-Execution Check Function (Optional) — An optional function which requests consistency check to the host upon Cache Hit. The equipment uploads check information to the host by using Pre-ExeCheck Event. The host responds with Pre-ExeCheckAck service if it is OK or NG. 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, in case, all linked recipes or equipment parameters are managed as PEM Recipes in the Recipe Server.

10.5.6.1 Check Information — The check information (such as Checksum or entire Recipe) which is sent by Pre-ExeCheck Event is user defined. The host-managed sub-recipes may also be taken into account for the check information composition.

10.5.6.2 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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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 the recipe for PJ creation. The number 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.

10.5.6.3 Consistency Checks of Non-Host-Managed Sub-Recipes and/or Equipment Parameters — In case consistency checks of Nnon-host-managed sub-recipes and/or equipment parameters may also be are taken into account, equipment may upload check information (such as Checksum) to the host upon Cache Hit. , may wait for the host response (the host may compare the information with the correct information which was prospectively uploaded to the host), however, and may continue execution upon an affirmative response from the host. In upon a negative response from case, the host may respond with error information, and the equipment can only report an error and shall stop the execution. This Standard does not define check information (e.g., checksum) specification.

</#4>

<#4>

10.6 Operation Modes of PRC — PRC has the following operation modes, Cache Mode, Full Query Mode, Full Download Mode and Pre-Download Mode. Cache Mode is the basic mode. Though it may not be recommended from a performance view point, Full Query Mode, Full Download Mode or Pre-Download Mode may also be required in some cases. To be compliant with those different operational requirements with one standard, PRC provides those optional PRC operation modes. The modes which are used for a particular implementation shall be determined between the host and the equipment. Interactions between the host and the equipment, including internal interactions between PRC and other parts of the equipment, are described in the following subsections. In the figures of the subsections, PJ Creator represents the control software which receives a demand from the host.

Table 14 PRC Operation Modes vs. PRC Functions

PRC Operation Modes

PRC Functions

Cache Mode

Full Query Mode

Full Download Mode

Pre-Download Mode

Note

Clear PRC Required Required Required Required

Query Recipe Required

(Used upon Cache Miss)

Required

(Use every time to get a specified recipe from the host)

Not used

Required

(Used upon Cache Miss)

Write Recipe Required (May be used to overwrite the recipe which is modified in the host keeping the same Recipe ID)

Required

Required (Use every time to download a required recipe from the host)

Required (Use to download required recipes from the host)

Delete Recipe Optional (Used to delete the recipe which is deleted in the host)

Not used Not used

Required (Use to delete unneeded recipe to avoid Cache Full)

Read Recipe Optional Not used Not used Optional

Delete upon Cache Full

The equipment deletes recipe(s) with lower possibility to be used

Not applicable Not applicable The equipment reports an error, and the host shall delete some recipes by using DeleteRecipe service

Pre-Execution Check

Optional Not used Not used Optional




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.6.1 Cache Mode Operation — Cache Mode is the basic operation mode of PRC. PRC is controlled to hold recently used recipes for better Cache Hit rate in order to minimize transportation overhead of the recipes. Clear PRC function shall be executed appropriately as defined in PRC Functions. Then, upon PJ creation, the equipment looks up the PRC for the specified recipe by the PJ. In case the requested recipe is in PRC, the recipe is used for PJ creation. In case the requested recipe is not in PRC, the recipe is queried to Recipe Server, the Recipe Server downloads the requested recipe into PRC, and then the recipe is used for PJ creation.

10.6.1.1 Cache Miss — In case the recipe is not in the PRC (Cache Miss), equipment requests the recipe to the Recipe Server by using Query Recipe of the PRC function, Recipe Server downloads the requested recipe into PRC by using Write Recipe function. The recipe is served to PJ Creator to create PJ. The recipe written in PRC stays in PRC even after it is copied out for use.

10.6.1.2 Cache Full — In case the PRC is full upon execution of Write Recipe function, equipment automatically deletes one or more recipes with lower probability to use in order to create a space to write the recipe. No error is reported as this case is not an error case but a normal download method of the Cache Mode operation.

<#4>Delete</#4>

Figure 21 Cache Mode Operation (Clear PRC and Cache Miss)

10.6.1.3 Cache Hit — In case the recipe is in the PRC (Cache Hit), equipment uses the recipe for PJ creation.

<#4>Delete</#4>

Figure 22 Cache Mode Operation (Cache Hit)




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.6.1.4 Recipe Consistency Management — In case a recipe is modified (under the same Recipe ID) or deleted on Recipe Server, the Recipe Server shall overwrite or delete the recipe by using Write Recipe or Delete Recipe function accordingly, in order to maintain consistency between the recipes in Recipe Server and the recipes in PRC.

10.6.1.5 Optional Pre-Download — The host may download recipes into PRC proactively, prior to query from the equipment by using Write Recipe function.

10.6.2 Full Query Mode Operation (Optional) — PRC is not used to hold any recipe. The equipment queries the required recipe every time upon the process demand from the host. This means that different nodes in the host may take different roles to demand process and to serve recipe to the equipment. Process execution may be cascaded as long as the next process demand comes from the host with sufficient lead time to query the recipe while the previous process is in progress. In case the lead time is not sufficient, waste time due to the query occurs.

10.6.2.1 Query Every Time — The equipment queries the specified recipe to Recipe Server by using Query Recipe function every time just after the equipment received a process demand from the host, and the Recipe Server downloads the recipe to PRC by using Write Recipe function. The equipment then uses the recipe for PJ creation.

10.6.2.2 Clear PRC after Copy Out of the Recipe — PRC is used as a temporarily space to hold the recipe during communication, and is cleared after the recipe is copied out from PRC for PJ creation.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#4>Delete</#4>

Figure 23 Full Query Mode Operation

10.6.3 Full Download Mode Operation (Optional) — PRC is used to hold a downloaded recipe until the recipe is used by the process demand from the host, which follows to the download. PRC is cleared after the recipe is used for PJ creation. The host downloads the required recipe just before the process demand is sent to the equipment. Write Recipe function is used to download the recipe to PRC. The equipment looks up the PRC for the specified recipe by the PJ upon PJ creation, Cache Hit always occurs, and uses the recipe for the PJ creation. PRC is only used as a temporary space to hold the recipe, and is cleared after the recipe is copied out from PRC for PJ creation. Query Recipe function is not used.

<#4>Delete</#4>

Figure 24 Full Download Mode Operation

10.6.4 Pre-Download Mode Operation (Optional) — PRC is used to hold recipes downloaded from the host prior to the process requests from the host that uses the recipe. The host shall control what recipes remain in PRC. Clear PRC function shall be executed appropriately as defined in PRC functions. Then, the host downloads required recipes into PRC by using Write Recipe function at any time prior to the process request that uses the recipe. The equipment looks up the PRC for the specified recipe by the PJ upon PJ creation.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

10.6.4.1 Cache Full — Cache Full may occur at any time Write Recipe function is executed. In this mode, the equipment does not delete recipes in order to make appropriate space in PRC, the host shall confirm if there is enough space in PRC and delete appropriate recipes by using Delete Recipe function in case there is not enough space.

10.6.4.2 Cache Hit — In case the recipe is in PRC, the equipment uses the recipe for the PJ creation.

<#4>Delete</#4>

Figure 25 Pre-Download Mode Operation

10.6.4.3 Cache Miss — In case the specified recipe is not in PRC, the equipment sends Query Recipe to the host, and the host downloads the recipe into PRC by using Write Recipe function. Then, the equipment uses the recipe for PJ creation. The recipe written into PRC stays in PRC even after it is copied out for PJ creation.

<#4>Delete</#4>

Figure 26 Pre-Download Mode Operation (Cache Miss)

10.6.4.4 Recipe Consistency Management — In case a recipe is modified (under the same Recipe ID) or deleted on Recipe Server, the Recipe Server shall overwrite or delete the recipe by using Write Recipe or Delete Recipe function accordingly, in order to maintain consistency between the recipes in Recipe Server and the recipes in PRC.

</#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

11 Production Execution Mode (PEM) State Management Job Object Requirements

11.1 PEM State Management Job (PEMJ) Object Requirement — Equipment compliant with this Standard shall have PEM State Management Job (PEMJ) capability.

11.1.1 Definition of PEMJ Object — The PEMJ Object is a software representation of the PEMJ State that determines whether the equipment operates in PEM or not. Information about PEMJ State is encapsulated as an object. This allows the host to exchange information with the equipment about one or more specific PEMJ by using services defined in SEMI E39 Object Services Standard.

11.1.2 Usage of PEMJ State — PEMJ state is used to determine which recipe space is used for process execution, Conventional Recipe Space or PRC. In PEM Off state, Conventional Recipe Space shall be used, and, in PEM On state, PRC shall be used.

11.1.3 Multiple PEMJ for Multi-part Equipment — In case the equipment has a capability to divide itself into multiple parts that can operate in PEM or in non-PEM independently, the PEMJ State of the each part may separately be managed by separate PEMJs.

11.1.4 Who Sets PEMJ State — The host or privileged user of the equipment sets PEMJ State.

11.2 PEMJ Object Descriptions

11.2.1 PEMJ Object Instantiation — Under normal circumstances PEMJ object is instantiated by the equipment when the equipment is started up or is changed its configuration from PEM view point.

11.2.2 PEMJ Object Identifier (ObjID) — The PEMJID is the PEMJ Object Identifier. The equipment is responsible for ensuring uniqueness of the PEMJID prior to instantiation.

11.2.3 PEMJ Object Destruction — A PEMJ Object reaches the end of its lifecycle in case the equipment is shut down or the configuration change of PEM affects to the PEMJ Object.

11.2.4 PEMJ Object Persistence — A PEMJ Object does not need to persist over equipment shut down to restart.

11.3 PEMJ Object Attribute Definitions — The following table defines the attributes of PEMJ object.

11.3.1 Who to Maintain the Attributes — All attributes in the following table are always maintained and updated by the equipment.

11.3.2 Validity of Attributes of Parallel States — Attributes of parallel states are valid only when the parent state is active.

Table 15 PEMJ Attribute Definition

Attribute Name Definition Access#1 Reqd Form

ObjID PEMJ object Identifier. RO Y Text. PEMJID. Numerical text expression of positive integer. ObjID is equipment defined.

ObjType Object Type. RO Y Text = PEMJob

PEMJState State of the equipment FALSE: The equipment does not operate in PEM TRUE: The equipment operates in PEM

<#6> RW RO</#6>

Y Boolean: FALSE = “The equipment does not operate in PEM” TRUE = “The equipment operates in PEM”

#1 Even though a value may be marked as RO (read only), the initial value for the attribute may be provided by the host.

11.4 PEMJ State Model — Following diagram and tables define the state model of PEMJ.

11.4.1 PEMJ State Model Diagram




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure 27

PEMJ State Model

11.4.2 PEMJ State Model Definition

Table 16 PEMJ State Model Definition

State Transition

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

Comments

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

Sp00 PEM Off The equipment is not operating in PEM

Tp01 Request to go to PEM On state SetPEMJState service with PEMJState= TRUEPrivileged user may trigger this transition.

Set PEMJState to TRUE

Sp01

Sp01 PEM On The equipment is operating in PEM

Tp02 Request to go to PEM Off state SetPEMJState service with PEMJState= FALSEPrivileged user may trigger this transition.

Set PEMJState to FALSE

Sp00

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

11.4.3 PEMJ State Definition Table

Table 17 PEMJ State Definition Table


Sp00 PEM Off This state indicates that the equipment is not operating in PEM.

Recipes in Conventional Recipe Space shall be used for process execution. PRC may be used for reference or setting only.

Sp01 PEM On This state indicates that the equipment is operating in PEM. Recipes in PRC shall be used for process execution. Recipes in Conventional Recipe Space shall not be used for process execution.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

11.4.4 PEMJ State Transition Table

Table 18 PEMJ State Transition Table

Num#1 Previous State Trigger New State Actions Comments

Tp00 (No state) Start-up of the equipment PEM Off None.

Tp01 PEM Off Request to go to PEM On state

SetPEMJState service with PEMJState= TRUE Privileged user may trigger this transition.

PEM On Set PEMJState to TRUE

Tp02 PEM On Request to go to PEM Off state SetPEMJState service with PEMJState= FALSE Privileged user may trigger this transition.

PEM Off Set PEMJState to FALSE


11.5 PEMJ Services — This section defines the message services required to support PEMJ State Management functionalities.

11.5.1 PEMJ Service Message Description — The following table is a list of PEMJ services.

Table 19 PEMJ Service Message Description

Service Name Type#1 Description

SetPEMJState R This service sets PEMJState.

GetPEMJState R This service gets PEMJState.

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

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

Table 20 PEMJ Service Message Parameter Definition


PEMJState Boolean: FALSE for PEM Off state TRUE for PEM On state

State of PEMJ FALSE: Equipment is not in PEM Off state TRUE: Equipment is in PEM On state

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

11.5.3.1 SetPEMJState — This service is used to set PEMJState to specified state.

Table 21 SetPEMJState Service Parameter Definitions

Parameter Name Req/Ind Rsp/Conf Description

ObjID M - Object ID

PEMJState M - State of PEMJState to be set




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

11.5.3.2 GetPEMJState — This service is used to get current PEMJ State.

Table 22 GetPEMJState Service Parameter Definitions


ObjID M - Object ID

PEMJState - M Current value of PEMJState

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

Table 23 PEMJ Variable Data Definitions


PEMJState State of the equipment FALSE: The equipment is not in PEM On state TRUE: The equipment is in PEM On state

Boolean: FALSE for PEM Off state TRUE for PEM On state

<#6> RW RO

</#6>

12 PRC Object Requirements

12.1 PRC Object (PRCOBJ) Requirement — Equipment compliant with this Standard shall have PRC Object management capability.

12.1.1 Definition of PRCOBJ — The PRCOBJ is a software representation of the PRC. Information about PRC is encapsulated as an object. This allows the host to exchange information with the equipment about one or more specific PRCOBJ by using services defined in SEMI E39 Object Services Standard.

12.1.2 Multiple PRCOBJ for Multi-Part Equipment — In case the equipment has a capability to divide itself into multiple parts that can operate in PEM or in non-PEM independently, the equipment may have multiple PRCOBJs that represent multiple PRCs.

12.2 PRCOBJ Object Descriptions

12.2.1 PRCOBJ Object Instantiation — Under normal circumstances PRCOBJ object is instantiated by the equipment when the equipment is started up or is changed its configuration of PRC.

12.2.2 PRCOBJ Object Identifier (ObjID) — The PRCOBJID is the PRCOBJ Object Identifier. The equipment is responsible for ensuring uniqueness of the PRCOBJID prior to instantiation.

12.2.3 PRCOBJ Object Destruction — A PRCOBJ Object reaches the end of its lifecycle when the equipment is shut down or is changed its configuration that affects to the PRCOBJ Object.

12.2.4 PRCOBJ Object Persistence — A PRCOBJ Object does not need to persist over equipment shut down to restart.

12.3 PRCOBJ Object Attribute Definitions — The following table defines the attributes of PRCOBJ object.

12.3.1 Who to Maintain the Attributes — All attributes in the following table are always maintained and updated by the equipment.

12.3.2 Validity of Attributes of Parallel States — Attributes of parallel states are valid only when the parent state is active.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Table 24 PRCOBJ Attribute Definition


ObjID PRCOBJ object Identifier. RO Y Text. PRCOBJID. Numerical text expression of positive integer. ObjID is equipment defined.

ObjType Object Type. RO Y Text = “PRCObject”

PRCExecState Current state of PRC Enabled sub-state in PRC State Model

RO Y Enumerated: NonExecutionMode, ExecutionMode

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

RO Y Enumerated: NotInitialized, StandBy, Query, Pre-ExeCheck

<#5> AutoClear

A flag which enables or disables the Auto Clear function

RO Y Enumerated: Enable, Disable </#5>

<#4> MaxNumber

Maximum number of PEM Recipes allowed to be preserved in PRC after PJ creation.

RO Y List of: Unsigned integer: ‘n’ = n recipes are allowed

</#4>

<#4> MaxTime

Maximum time a PEM Recipe allowed to be in PRC after use

RO O Unsigned integer. Unit is user defined. ‘0’ = Maximum Time function is not used ‘1’ or more = Maximum Time </#4>

RUGNumber A number which describes what Recipe User Group is using the PRC.‘0’: No Recipe User Group is specified and user of PRC is not limited (default) ‘n’: Recipe User Group ‘n’ is specified and the user of PRC is limited to the user(s) belongs to the Recipe User Group or the host which represents the Recipe User Group

<#6> RW RO</#6>

Y Positive Unsigned integer: ‘0’ = No Recipe User Group is specified and user of PRC is not limited. (Default) ‘n’ = Recipe User Group ‘n’ is specified and user of PRC is limited.

ClassInfo Class Information Class Information is an optional information which may contain information such as type of the recipe or path to the targeted <#2>foldersubspace</#2>, mainly supports recipe linkage

<#6> RW RO</#6>

<#1>YO

</#1>

User defined

RecipeID Recipe ID <#6> RW RO</#6>

Y RecID which is defined in E40

UniqueID Unique ID

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

<#6> RW RO</#6>

<#1>YO

</#1>

User defined

RecipeHeader Optional Recipe Header which may contain recipe linkage information

<#6> RW RO</#6>

<#1>YO

</#1>

User defined




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20


RecipeBody Recipe Body <#6> RW RO</#6>

Y Equipment defined recipe

#1 Even though a value may be marked as RO (read only), the initial value for the attribute may be provided by the host.

12.4 State Management of PRCOBJ

12.4.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 the host or privileged user.

12.4.2 Process Execution with PRC — In addition to the activation of PRC, PEMJ State shall be set to PEM On in order to use recipes in PRC for process execution.

12.5 PRCOBJ State Model

12.5.1 Purpose of PRCOBJ State Model — The purpose of the PRCOBJ State Model is to define the state of PRCOBJ. Normally, PRC operates in Cache Mode operation, and may operate in other mode optionally. The state model for Cache Mode is shown here as it contains all the PRC functions as options.

12.5.2 PRCOBJ State Model Diagram

<#4>Delete</#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#4>Add</#4>

Figure 28 PRCOBJ State Model Diagram

12.5.2.1 Relation of Parallel States — The parallel states Sc01 and Sc10 in PRCOBJ 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 state. Tc03 shall not occur until Tc11 or Tc12 is completed.

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

<#4>Delete</#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

<#4>Add</#4>

Figure 29 Relation of Parallel States in PRCOBJ State Model

12.5.3 PRCOBJ State Model Definition

Table 25 PRCOBJ State Model Definition

State Transition

No. Name Abstract of Definition

No.#1 Abstract of Trigger Abstract of Action#2 New State

Comments

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

Sc00 PRC Disabled

PRC is disabled Tc01 PRC enable request Enable PRC Sc01

Sc01 PRC Enabled

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

PRC is not used for process

Tc03 PEMJ State is set to PEM On

PRCM Event Sc03

Sc03 In Execution PRC is used for process

Tc04 PEMJ State is set to PEM Off

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

Sc12 Stand by PRC is ready to be referred

Tc13 Cache Clear PRC Clear recipes in PRC

Sc12

Tc14 Cache Hit and Pre-Execution Check OFF

Use the recipe Sc12

Tc15 Cache Miss Query Event Sc13 Queries the recipe




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Tc17 Delete Recipe Delete specified recipe

Sc12

<#4>Tc18Tc19</#4>

Read Recipe Respond with the specified recipe

Sc12

<#4> Tc19Tc18 </#4>

Write Recipe <#4> , and not Cache Full </#4>

Write the recipes in PRC

Sc12 The recipes are is written

<#4> Tc20

Write Recipe, however Cache Full

Cache Full error Sc12 Couldn’t write the recipe </#4>

<#4> Tc21Tc20 </#4>

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 the host

<#4> Tc22Tc21 </#4>

Pre-Execution Check OK

Use the recipe for PJ creation

Sc12 Optional

<#4> Tc23Tc22 </#4>

Pre-Execution Check NG and the host responds with WriteRecipe service

Put the served recipe in PRC and use for PJ creation

Sc12


#2 Events in the ‘Abstract of Action’ column report following information.

PRCM Event reports PRCExecState.

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.

12.5.4 PRCOBJ State Definition Table

Table 26 PRCOBJ State Definition Table


Sc00 PRC Disabled PRC is disabled and not used.

Sc01 PRC Enabled PRC is enabled and in use.

Sc02 Non Execution Equipment does not work in PEM, and recipes in PRC are not used for process execution. Recipes in Conventional Recipe Space are used for process execution.

Sc03 In Execution Equipment works in PEM, and recipes in PRC are used for process execution.

Sc10 PRC Operation A parallel state of PRC Enabled, which determines elemental operations of PRC.

Sc11 Not Initialized PRC is not initialized yet. The contents of PRC shall not be used for process execution.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20


Sc12 Stand By PRC is ready for operation and waiting for a request for a recipe.

Sc13 Query Cache Miss occurred, and PRC has sent a Query Event and is waiting for the response from Recipe Server.

Cache Miss is not an error, so this is not an error state. A requester of the recipe shall wait for PRC to receive the specified recipe from Recipe Server.

Sc14 Pre-Exe Check PRC has sent information to the host in order to check the consistency of the recipe which is found in PRC (Cache Hit), and is waiting for the response from the host.

12.5.5 PRCOBJ State Transition Table

Table 27 PRCOBJ State Transition Table

Num#1 Previous State Trigger New State Actions#2 Comments

Tc00 (No state) System startup PRC Disabled None

Tc01 PRC Disabled PRC is enabled PRC Enabled Enable PRC

Tc02 PRC Enabled None Non Execution None

Tc03 Non Execution

PEMJ State is in PEM On (PEMState is TRUE)

In Execution PRCM Event

Tc04 In Execution PEMJ State is in PEM Off (PEMState is FALSE)

Non Execution PRCM Event

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

PRC Enabled Clear PRC PRCM Event

Returns to Not Initialized state

Tc06 PRC Enabled PRC is disabled PRC Disabled Disable PRC

Tc10 PRC Enabled 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 ClearPRC service from the host (or an equivalent operation by privileged user)

Stand By Clear the contents of PRC.

Tc14 Stand By Cache Hit PRC is requested a recipe from Recipe Executor, and the recipe is in PRC.

Stand By Serve the recipe to Recipe Executor

Tc15 Stand By Cache Miss PRC is requested a recipe from Recipe Executor, and the recipe is not in PRC.

Query Send Query Event to Recipe Server

Tc16 Query WriteRecipe service from the host.

(Queried recipe is served from Recipe Server)

Stand By Store the recipe in PRC and serve the recipe to Recipe Executor

Tc17 Stand By DeleteRecipe service from the host (or an equivalent operation by privileged user)

Stand By Delete specified recipe




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Num#1 Previous State Trigger New State Actions#2 Comments

<#4> Tc18

Tc19 </#4>

Stand By ReadRecipe service from the host (or an equivalent operation by privileged user)

Stand By Respond with the specified recipe

<#4> Tc19

Tc18 </#4>

Stand By WriteRecipe service from the host (or an equivalent operation by privileged user) <#4>, and not Cache Full</#4>

Stand By Write the recipes in PRC

<#4>Tc20

Stand By WriteRecipe service from the host (or an equivalent operation by privileged user), and Cache Full

Stand By Report Cache Full error </#4>

<#4> Tc21

Tc20 </#4>

Stand By Cache Hit and send information to the host in order to check the consistency of the recipe

Pre-Exe Check Send Pre-ExeCheck Event

Optional

<#4> Tc22 Tc21 </#4>

Pre-Exe Check

The host responded with OK by using Pre-ExeCheckAck service

Stand By Serve the recipe to Recipe Executor

Optional

<#4> Tc23

Tc22 </#4>

Pre-Exe Check

The host responded with NG by using Pew-ExeCheckAck service, and sent down correct recipe by using WriteRecipe service

Stand By Overwrite the recipe in PRC with the correct recipe and serve the correct recipe to Recipe Executor

Optional


#2 Events in the Action column report following information.

PRCM Event reports PRCExecState.

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.

12.6 PRCOBJ Services — This section defines the message services required to support PRCOBJ functionalities. Equipment compliant with this Standard shall have following services to manage PRCOBJ.

12.6.1 PRCOBJ Service Message Description — The following table is a list of PRCOBJ services.

Table 28 PRCOBJ Service Message Description

Service Name Type#1 Description

SetPRCAttributes R This service sets attributes of PRCOBJ

GetPRCAttributes R This service gets attributes of PRCOBJ

ClearPRC R This service clears all recipes in PRC

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-ExeCheck Event, whether the result of the Pre-Execution Check 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’.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

Table 29 PRCOBJ Service Message Parameter Definition


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

<#5> AutoClear

Enumerated: Enable, Disable

A flag which enables or disables the Auto Clear function </#5>

<#4> MaxNumber

List of: Unsigned integer: ‘n’ = n recipes are allowed

Maximum number of PEM Recipes allowed to be preserved in PRC after PJ creation. </#4>

<#4> MaxTime

Unsigned integer. Unit is user defined.

Maximum time a PEM Recipe allowed to be in PRC after use ‘0’ = Maximum Time function is not used ‘1’ or more = Maximum Time </#4>

RUGNumber Positive Unsigned integer: ‘0’ = No Recipe User Group is specified and user of PRC is not limited. (Default) ‘n’ = Recipe User Group ‘n’ is specified and user of PRC is limited.

A number which describes what Recipe User Group is using the PRC ‘0’: No Recipe User Group is specified and user of PRC is not limited (default) ‘n’: Recipe User Group ‘n’ is specified and the user of PRC is limited to the user(s) belongs to the Recipe User Group or the host which represents the Recipe User Group

<#4> PRCOperationMode

Enumerated: Cache, FullDownload, FullQuery, PreDownload

Operation Mode of PRC Default mode is Cache </#4>

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

ClassInfo User defined Class Information Class Information is an optional information which may contain information such as type of the recipe or path to the targeted <#2>foldersubspace</#2>, mainly to support recipe linkage

RecipeID RecID which is defined in SEMI 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

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.

<#4> Pre-ExeCheckResult

Enumerated: OK, NG OK/NG response from the host to Pre-Exe Check event from equipment </#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20


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 <#4> In case the result of Pre-Execution Check is Fail, ListOfPEMRecipe is sent from the Recipe Server. </#4>

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

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, <#4> Full </#4>, Error Information concerning the result of the service

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

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

Table 30 SetPRCAttributes Service Parameter Definitions


ObjID M - Object ID

PRCSwitch M - Enable/Disable of entire PRC functionalities

<#5> AutoClear M - Auto Clear upon host communication establishment </#5>

<#4> MaxNumber M - Maximum number of recipes preserved in PRC </#4>

<#4> MaxTime O - Maximum time to preserve recipes in PRC </#4>

RUGNumber O - Number of Recipe User Group

</#4> PRCOperationMode M - Operation mode of PRC </#4>

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

SetPRCAttributesResp - M Information concerning the result of the service

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

Table 31 GetPRCAttributes Service Parameter Definitions


ObjID M - Object ID

PRCSwitch - M Enable/Disable of entire PRC functionalities

<#5> AutoClear - M Auto Clear upon host communication establishment </#5>

<#4> MaxNumber - M Maximum number of recipes preserved in PRC </#4>

<#4> MaxTime - O Maximum time to preserve recipes in PRC </#4>

RUGNumber - O Number of Recipe User Group

<#4> PRCOperationMode - M Operation mode of PRC </#4>

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

GetPRCAttributesResp - M Information concerning the result of the service




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

12.6.3.3 ClearPRC — This service clears all recipes in PRC.

Table 32 ClearPRC Service Parameter Definitions


ObjID M - Object ID

ClearPRCResp - M Information concerning the result of the service

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

Table 33 GetRecipeIDList Service Parameter Definitions


ObjID M - Object ID

RecipeIDList - M List of Recipe ID in PRC.

GetRecipeIDListResp - M Information concerning the result of the service

12.6.3.5 DeleteRecipe — This service deletes specified recipe in PRC.

Table 34 DeleteRecipe Service Parameter Definitions


ObjID M - Object ID

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.

DeleteRecipeResp - M Information concerning the result of the service

12.6.3.6 WriteRecipe — This service writes a PEM Rrecipes into PRC. If a same named PEM Rrecipes exists in PRC, this service overwrites them recipe.

<#4> Table 35 WriteRecipe Service Parameter Definitions


ObjID M - Object ID

ListOfPEMRecipe M - List of PEM Recipes




RecipeHeader O - Optional Recipe Header

RecipeBody M - Recipe Body

WriteRecipeResp - M Information concerning the result of the service

</#4>

12.6.3.7 ReadRecipe — This service reads specified recipe from PRC.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Table 36 ReadRecipe Service Parameter Definitions


ObjID M - Object ID




RecipeHeader - O Optional Recipe Header

RecipeBody - M Recipe Body

ReadRecipeResp - M Information concerning the result of the service

<#4>

12.6.3.8 Pre-ExeCheckAck — This service acknowledges to the Pre-Execution Check if the result of the recipe check is OK or NG passes or fails. In case where the Pre-Execution Check option is selected, equipment shall send Pre-ExeCheck Event which includes check information 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 service shall follow.

Table 37 Pre-ExeCheckAck Service Parameter Definitions


ObjID M - Object ID

Pre-ExeCheckResult M - Check result. Pass OK or Fail NG

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

</#4>

12.7 PRCOBJ 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 38 PRCOBJ Variable Data Definitions


PRCSwitch Enable/Disable of entire PRC functionalities

Enumerated: Enabled, Disabled

<#6> RW RO

</#6>

<#5> AutoClear

A flag which enables or disables Auto Clear function

Enumerated: Enable, Disable

RO </#5>

<#4> MaxNumber

Maximum number of PEM Recipes allowed to be preserved in PRC after PJ creation.

List of: Unsigned integer: ‘n’ = n recipes are allowed

RO Absolute maximum number of PEM Recipes in PRC is limited by the capacity of the PRC. </#4>

<#4> MaxTime

Maximum time a PEM Recipe allowed to be in PRC after use

Unsigned integer: Unit is user defined ‘0’ = Maximum Time function is not used ‘1’ or mote = Maximum Time

RO </#4>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20


RUGNumber A number which describes what Recipe User Group is using the PRC. ‘0’: No Recipe User Group is specified and user of PRC is not limited (default) ‘n’: Recipe User Group ‘n’ is specified and the user of PRC is limited to the user(s) belongs to the Recipe User Group or the host which represents the Recipe User Group

Positive Unsigned integer:

‘0’ = No Recipe User Group is specified and user of PRC is not limited. (Default) ‘n’ = Recipe User Group ‘n’ is specified and user of PRC is limited.

<#6> RW RO

</#6>

<#4> PRCOperationMode

Operation Mode of PRCDefault mode is Cache

Enumerated: Cache, FullDownload, FullQuery, PreDownload

RW </#4>

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

Enumerated: Enabled, Disabled

<#6> RW RO

</#6>

PRCExecState Current state of PRC Enabled substate in PRC State Model

Enumerated: NonExecutionMode, ExecutionMode

RO

PRCOperationState Current state of PRC Operation substate in PRC State Model

Enumerated: NotInitialized, StandBy, Query, Pre-ExeCheck

RO

ClassInfo Class Information Class Information is an optional Information which may contain information such as type of the recipe or path to the targeted <#2>foldersubspace</#2>, mainly supports recipe linkage

User defined <#6> RW RO

</#6>

RecipeID Recipe ID RecID which is defined in SEMI E40

<#6> RW RO

</#6>

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.


</#6>

May be standardized if needed

RecipeHeader Optional Recipe Header which may contain recipe linkage information


</#6>

May be standardized if needed

RecipeBody Recipe Body Equipment defined recipe <#6> RW RO

</#6>




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

13 Requirements for Compliance

13.1 Following table provides a checklist for PRC compliance.

Table 39 PRC Compliance Statement

Fundamental PRC Requirements PRC Section Implemented PRC Compliant

PRC Space Requirements 7

PRC Space Implementation Requirement 7.1 Yes No Yes No

Usage of PRC and Conventional Recipe Space 7.2 Yes No Yes No

Multi-Part Equipment Compatibility (Optional) 7.3 Yes No Yes No

Multi-Part Equipment with One PRC 7.3.1 Yes No Yes No

Multi-Part Equipment with dedicated PRCs 7.3.2 Yes No Yes No

PRC Operational Requirements 9

Fundamental Requirements 9.2 Yes No Yes No

Use of Recipes in PRC 9.2.1 Yes No Yes No

No Concurrent PRC Reference for Multiple Recipe Request

9.2.3 Yes No Yes No

No Editing of Recipe in PRC 9.2.6 Yes No Yes No

Copy Out of a Recipe from PRC 9.2.7 Yes No Yes No

Local Access to PRC 9.2.8 Yes No Yes No

<#4>Content Management Logics of PRC

Maximum Number of PEM Recipes Preserved in PRC

Yes No Yes No

Maximum Time of PEM Recipes Preserved in PRC (Optional)

Yes No Yes No

Operation Modes of PRC Yes No Yes No

PRC Operations

Cache Clear Operation Yes No Yes No

Download Operation Yes No Yes No

Delete Operation Yes No Yes No

Lookup Operation Yes No Yes No

Cache Miss Operation Yes No Yes No

Cache Hit Operation Yes No Yes No

Consistency Check Operation (Optional) Yes No Yes No </#4>

PRC Functions 9.3 Yes No Yes No

Clear PRC Function 9.3.1 Yes No Yes No

<#5> Auto Clear Function

9.3.1.1 Yes No Yes No </#5>

Query Recipe Function 9.3.2 Yes No Yes No

Write Recipe Function 9.3.3 Yes No Yes No

Delete Recipe Function <#4> (Optional) </#4> 9.3.4 Yes No Yes No

Read Recipe Function (Optional) 9.3.5 Yes No Yes No

Pre-Execution Check Function (Optional) 9.3.6 Yes No Yes No

<#4> Operation Modes of PRC

9.4 Yes No Yes No




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Fundamental PRC Requirements PRC Section Implemented PRC Compliant

Cache Mode Operation 9.4.1 Yes No Yes No

Full Query Mode Operation (Optional) 9.4.2 Yes No Yes No

Full Download Mode Operation (Optional) 9.4.3 Yes No Yes No

Pre-Download Mode Operation (Optional) 9.4.4 Yes No Yes No </#4>

PEM State Management Job (PEMJ) Object Requirements 10

PEMJ Object Requirement 10.1 Yes No Yes No

PEMJ Object Descriptions 10.2 Yes No Yes No

PEMJ Object Attribute Definitions 10.3 Yes No Yes No

PEMJ State Model 10.4 Yes No Yes No

PEMJ Services 10.5 Yes No Yes No

PEMJ Variable Data Definitions 10.6 Yes No Yes No

PRC Object Requirements 12

PRC Object (PRCOBJ) Requirement 12.1 Yes No Yes No

PRCOBJ Object Descriptions 12.2 Yes No Yes No

PRCOBJ Object Attribute Definitions 12.3 Yes No Yes No

State Management of PRCOBJ 12.4 Yes No Yes No

PRCOBJ State Model 12.5 Yes No Yes No

PRCOBJ Services 12.6 Yes No Yes No

PRCOBJ Variable Data Definitions 12.7 Yes No Yes No

14 Related Documents

14.1 None.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

APPENDIX 1 EXAMPLE OF PRODUCTION RECIPE CACHE OPERATION IN CACHE MODE

NOTICE: The material in this Appendix is an official part of SEMI E170 and was approved by full letter ballot procedures on June 17, 2014.

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 Operation

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

a. MES demands PRC Controller to clear PRC at any time.

b. PRC Controller clears the PRC.

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

c. MES sends a PJ.

d. Recipe Executor queries the recipe specified by the PJ to PRC Controller.

e. PRC Controller searches the recipe from PRC.

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 Executor with the recipe in the PRC.

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 writes the recipe served from Recipe Server into PRC, and serves the recipe to Recipe Executor.

i. If the PRC 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 Executor holds the recipe in Recipe Execution Space and executes.

Figure A1-1 Cache Mode Operations

A1-3 Example Scenario

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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

Figure A1-7

PRC Controller Writes Recipe #A in PRC

A1-3.7 Recipe Executor sends Recipe #A to Recipe Execution Space — Recipe execution starts!




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure A1-8

Recipe Executor Sends Recipe #A to Recipe Execution Space

A1-3.8 PJ Ends — Recipe #A remains in the PRC.

Figure A1-9

PJ Ends

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




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure A1-10

MES Sends PJ with Recipe #A Again

A1-3.10 PRC Controller Passes Recipe #A to Recipe Executor — Recipe Executor sends Recipe #A to Recipe Execution Space.

Figure A1-11

PRC Controller Passes Recipe #A to Recipe Executor

A1-3.11 PJ Ends Again — Recipe #A still remains in the PRC.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure A1-12

PJ Ends Again

A1-3.12 MES Requests PJ with Recipe #B — Cache Miss occurs as Recipe #B is not in PRC.

Figure A1-13

MES Requests PJ with Recipe #B

A1-3.13 PRC Queries Recipe #B to Recipe Server — And Recipe #B is served, written into PRC, passed to Recipe Executor and sent to Recipe Execution Space. And process starts.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

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

A1-3.15 MES Requests PJ with Recipe #A Again —Text.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2014/10/20

Figure A1-16

MES Requests PJ with Recipe #A Again

A1-3.16 Recipe #A Starts Immediately After Completion of Recipe #B — Recipe Executor 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: 2014/10/20

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