Standards Border Template - SEMIdownloads.semi.org/.../$FILE/5888.docx · Web view— equipment used to produce product, such as semiconductor devices, including substrate sorting,

Background Statement for SEMI Draft Document 5888Revision to:

SEMI E170-0815: SPECIFICATION FOR PRODUCTION RECIPE CACHE (PRC) with title change to SPECIFICATION FOR SECURED FOUNDATION OF RECIPE MANAGEMENT SYSTEM (SFORMS)

SEMI E170.1-0815: SPECIFICATION FOR SECS-II PROTOCOL FOR PRODUCTION RECIPE CACHE with title change to SPECIFICATION FOR SECS-II PROTOCOL FOR SECURED FOUNDATION OF RECIPE MANAGEMENT SYSTEM (SFORMS)

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 application studies, addition of capability to support ‘Remote Access operation’ is requested and the TF agreed to add the capability as an option. According to this addition, following revisions are needed.

Generalize and improve the purpose section and the scope section in order to include ‘Remote Access operation’

Change document title to align with the expanded Scope. Add specifications of Remote Access (including some amendments in other sections to align with this addition) Add TypeID and EquipmentID to RecipeXID in order to specify what equipment the recipe is composed for In order to align with above additions, make necessary changes to SEMI E170 and SEMI E170.1

Also, Version ID has been planned to be defined in #5618A PRI, however, development of the document is frozen. So, the TF decided to add the definition in SEMI E170. Add definition of VersionID

In addition, Incremental Implementation Step is added.

Editorial errors and insufficient explanations that are found through the revision work are amended.

Note 1: Because this ballot involves changes to the Title and the Scope section, it cannot be conducted as Line Item ballot. Any part of the entire Document is open for Negatives and Comments regardless of the markups (e.g., underlines and strikethrough). In order to avoid unnecessary delays in developing the revisions, however, it would be appreciated if any items that you may object to, but that are not listed as changes, be objected to as comments rather than rejections, so that they may be taken up as new business at the next meetings.

1

Note 2: In this document, remarkable amendments from published Standard are distinguished by color. In addition, the added parts are typically highlighted with underline; the removed parts are typically denoted with double strikeout marks (on the bottom for figure). Deleted figures may also be denoted with Delete, added figures may also be denoted with Add for better readability. These markings are for highlight in the ballot only. They are not proposed to be included in the updated standard.

2

Revision ControlThis revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force.Date Version Name Edits

Review InformationTask Force Review Committee Review

Group: Japan GEM300 TF Japan TC Chapter of Information & Control Global Technical Committee

Date: Thursday, December 10, 2015 Friday, December 18, 2015Time & Time Zone: 1:00 p.m.- 5:00 p.m. [JST] 10:00 a.m.- 5:00 p.m. [JST]Location: SEMI Japan, Ichigaya office Tokyo Big Sight Conference TowerCity, State/Country: Tokyo, Japan Tokyo, JapanLeader(s): Yoshihisa Takasaki (SCREEN

Semiconductor Solution)Yuko Toyoshima (Hitachi High-Technologies)

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

Standards Staff: Chie Yanagisawa (SEMI Japan)81.3.3222.5863 / cyanagisawa @semi.org

Chie Yanagisawa (SEMI Japan)81.3.3222.5863 / cyanagisawa @semi.org

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.

3

DRAFTDocument Number: 5888

Date: 5/6/23

SEMI E170-mmyy: SPECIFICATION FOR SECURED FOUNDATION OF RECIPE MANAGEMENT SYSTEM (SFORMS) 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 Mmmm Dd, 2015. Available at www.semiviews.org and www.semi.org in Mmmmmm 2015.

1 Purpose1.1 The purpose of this Standard is to provide a standardized ‘secure, safe and efficient recipe operation transfer and storage mechanism between from Recipe Management System (RMS) and Server to equipment’, which is used as a foundation of RMS 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 ‘secure, safe and efficient recipe operation mechanism between Recipe Management System (RMS) and equipment’ which especially supports RMS with the following concepts.

Management of recipes is centralized to RMS (Single Point Of Recipe Management (SPORM) concept) Storage of the master copies of the recipes are centralized to Recipe Server in RMS (Recipe Server Centric

concept)

1.3 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.4 The purpose of this Standard is to support RMS in provide a recipe transfer and storage mechanism which provides the following aspects benefits.

Extension of recipe identification capability

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

Reduction of operator efforts required to maintain consistency of recipes in equipment with recipes in Recipe Server by providing an automated consistency maintenance mechanism based on cache

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 based on cache

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

Addition of remote access capability to access recipes on the host RMS by using recipe applications (such as recipe editor) on equipment or other workstation

1.5 The purpose of this Standard is to provide a recipe operation transfer and storage mechanism which supports similar with or a superset of 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

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 4 Doc. 5888 SEMI

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


Date: 5/6/23

2 Scope2.1 This Standard covers a definition and usage of secure, safe and efficient recipe operation mechanism intended to be used as a foundation of RMS.

2.2 This Standard covers a definition and usage of extended recipe identification scheme which identifies recipes from multiple aspects including uniqueness and security.

2.3 This Standard covers a definition and usage of secured recipe space management mechanism which manages multiple recipe spaces in order to provide logically separated recipe spaces for different security level of recipe operations.

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

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

2.6 This Standard covers a definition and usage of recipe feeding mechanism from the host to equipment which enables secure, safe and efficient recipe operation for production execution by the host.

2.6.1 This Standard covers a definition of new recipe space named Production Recipe Cache (PRC) as one of secured recipe space 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.6.2 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.

2.7 This Standard covers a definition and usage of remote access operation mechanism which enables remote access of the recipes on Recipe Server in RMS by using recipe applications on equipment or other workstation.

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

3 Limitations3.1 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 for host triggered PJ creation 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 introduces extended recipe identification scheme for new requirements but is intended to be compatible with the existing recipe identification schemes for existing functionalities.

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





Date: 5/6/23

SEMI E87 — Specification for Carrier Management (CMS)

SEMI E94 — Specification for Control Job Management

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

5 Terminology5.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 PEM — Production Execution Mode

5.1.5 PJ — process job

5.1.6 PRC — Production Recipe Cache

5.1.7 RAC — Remote Access Cache

5.1.8 RMS — Recipe Management System

5.2 Definitions

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

5.2.2 Cache Hit — the required recipe is found in the cache PRC.

5.2.3 Cache Miss — the required recipe is not found in the cache 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 extended recipe identifier (Recipe XID) — an identifier of a recipe which is extended with Version ID, and Security ID, Type ID, and Equipment ID in addition to conventional Recipe ID.

5.2.8 formalized recipe — a recipe which is recognized by and under control of the RMS in the host.

5.2.9 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.10 multi-part equipment — equipment that has a capability to accomplish multiple operations that require recipe execution by multiple users simultaneously.

5.2.11 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.12 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.13 privileged user — a user who is allowed to use system functions that are not available to other users.

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

5.2.15 Production Execution Mode (PEM) — a mode of 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





Date: 5/6/23

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.16 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.17 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.18 properties — a set of name value pairs assigned to an object or used in a service message to include additional information about the object (i.e., carrier, port, etc.). [SEMI E87]

5.2.19 Recipe Executor — a component of a module that stores and executes recipes. [SEMI E40]

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

5.2.21 Recipe Management System (RMS) — an information system that manages recipes. Especially, the factory information system that manages recipes registered to the factory and is a part of the host. Typically, RMS has a Recipe Server which holds the master copy of the recipes.

5.2.22 Recipe Queue Space — a recipe space in the equipment which holds the recipe(s) already referred and queued for execution.

5.2.23 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.24 Security Class — a category of recipe which has the same security requirements.

5.2.25 Security ID — an identifier of a recipe which identifies the Security Class of the recipe.

5.2.26 Secured Recipe Space (SRS) — a recipe space which logically discriminates recipes per Security Class identified by Security ID of each recipe.

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

5.2.28 Version ID — an additional ID for a recipe, which provides a unique version name to the recipe. In case Recipe ID cannot ensure naming uniqueness of recipes, Version ID may be used in addition to the Recipe ID.

5.2.29 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.30 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 Conventions6.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





Date: 5/6/23

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 (Y), conditional (C), or optional (O) 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

6.2 State Model Methodology

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

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

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




http://www.journals.elsevier.com/science-of-computer-programming/


Date: 5/6/23

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 S00Snn#2 # Any state#2 -#2 - S03S00 T01 S01S04#3 T02 S00

S01 T03 S02T04 S03

S02 T05#4 S00

S10#5 - - - -S11 T10 S12S12 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.

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





Date: 5/6/23

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

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:





Date: 5/6/23

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

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

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.





Date: 5/6/23

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

7 Conceptual Descriptions7.1 Position of Conceptual Descriptions — This section defines and describes a concept of this Standard. This section 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.

Delete





Date: 5/6/23

AddFigure 1

Typical Recipe Server-Equipment Models and Coverage of This Standard PRC

7.3 Introduction of Single Point of Recipe Management (SPORM) 　 Concept — In order to manage numbers of recipes in secure, safe, and efficient way, this Standard introduces SPORM concept. In SPORM concept, recipes are managed in the following manner. A recipe is formalized when it is registered to RMS (which is normally in the host). Basically, recipes which are not formalized are not used for production related operations.

The master copy of formalized recipes are stored in a Recipe Server (normally, under RMS in the host). Temporary copies of formalized recipes which are made to support quick and efficient operations (such as

recipe editing or recipe execution ) may be in equipment (normally in cache, queue, or execution spaces) . All recipe management operations are done under recognition and approval of RMS (normally in the host). Backup scheme which prepares for system failure of the host is not in scope of SPORM.

7.4 Intended Application of This Standard — The intended application of this Standard is to construct a SPORM based 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, and efficient recipe operation mechanism Production Execution path isolated from operators’. The key features are: Clear separation between ‘Production’ and ‘Preparation’ activities ‘Centralized Management’ of the master copy of ‘Formalized Production Recipes’ on Recipe Server Only privileged user can handle Production Recipes (e.g. Certification) Introduction of RecipeXID for more secure identification Introduction of ‘Secured Recipe Space’ to provide dedicated recipe spaces per purposes 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’





Date: 5/6/23

Introduction of ‘Remote Access Cache’ in order to access recipes on Recipe Server by using equipment applications

Delete

AddFigure 2

Example of Intended Application of This Standard PRC

7.5 Introduction of RecipeXID — In order to identify recipes from multiple aspects, this Standard introduces Extended Recipe ID called RecipeXID. RecipeXID consists of the following identifiers.

Recipe ID: Main recipe identifier (PPID)

Version ID: An optional recipe identifier which helps unique identification in case Recipe ID is not always unique

Only the host assigns the value Zero length is assigned when the recipe is locally edited on equipment





Date: 5/6/23

Security ID: An additional recipe identifier which indicates the Security Class of the recipe. Security Class is used to identify:

I n which logical recipe space the recipe shall be stored By which operator the recipe may be used For which operation the recipe may be used

Type ID: An optional recipe identifier which indicates type of the recipe.

Equipment ID: An optional recipe identifier that indicates equipment which the recipe is tuned for

May define ‘Ideal’ equipment for reference recipe

AddFigure 3

Introduction of Recipe XID

7.6 Introduction of Secured Recipe Space — In order to deal recipes with different security requirements, this Standard introduces Secured Recipe Space which logically discriminates recipes per their Security Class specified by SecurityID.

Delete





Date: 5/6/23

AddFigure 4

Introduction of Secured Recipe Space

7.6.1 Linked Recipe Compatibility — To be compatible with current implementations, SRS PRC introduces a concept which makes the recipe linkage scheme of SRS PRC the same with Conventional Recipe Space.7.6.1.1 Management of Host-Managed Sub-Recipes — Sub-recipes, which are under management of the host, may be managed similarly in SRS PRC. Those recipes should reside in the SRS 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.

Delete





Date: 5/6/23

AddFigure 5

Linkage to Host-Managed Sub-Recipes

7.6.1.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 this Standard 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 other SRS 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.

Delete

AddFigure 6

Linkage to Locally Managed Sub-Recipes

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

7.6.2.1 Subspace Structure in SRS PRC — SRS 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.6.2.1.1 Linked Recipe Aspect — This subspace concept may be used to deal with Linked Recipe.7.6.2.1.2 Recipe Security Aspect — This subspace concept may also be used for security purposes.





Date: 5/6/23

Delete

AddFigure 7

SRS PRC Space Structure Concept

7.6.2.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.6.2.3 Subspace Structure Relationship between Conventional Recipe Space and Other SRS PRC — The subspace structure of other SRS PRC may be aligned with the subspace structure of Conventional Recipe Space in the equipment for easier correlation.7.6.2.4 Subspace Structure Relationship between SRS PRC and Recipe Server — The subspace structure in the recipe serving function in the host may be aligned with the subspace structure of SRS PRC in equipment for easier correlation.

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





Date: 5/6/23

7.7 Introduction of Production Recipe Cache Operation — For efficient production recipe transaction, this Standard introduces PRC Operations.

7.7.1 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.7.2 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.7.3 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.7.4 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.

7.7.5 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.8 Introduction of Remote Access Cache Operation — For SPORM based factory RMS, flexible use of equipment supplier supplied recipe applications (such as recipe editor) on equipment or other work stations to manage the recipes on Recipe Server is important. For this purpose, this Standard provides functionalities to support Remote Access.

7.8.1 Purpose of Remote Access Operations — The purpose of Remote Access operation is to perform recipe operations (such as edit, compare etc.) directly to the recipes on the host (RMS) by using equipment applications on equipment or a workstation. Remote Access operation is independent from PRC operation (RAC Space and PRC Space are also independent in equipment), and how to reflect the result of Remote Access operation to Production Recipes which go through PRC operation depends on the business rule in RMS.

7.8.2 Relationship Between RAC and PRC Operations — Remote Access operation is independent from PRC operation (RAC Space and PRC Space are also independent in equipment), and how to reflect the result of Remote Access operation to Production Recipes which go through PRC operation depends on the business rule in RMS.

7.8.3 Preconditions for Standardization — In order to simplify Remote Access operation for standardization, following pre and post processes which use the host system (e.g. RMS operation) are considered as preconditions.

Pre-process: Prior to a Remote Access operation, the following preparations are expected to respond to the Remote Access operation request from equipment (or workstation) .

Assign SecurityID which will be used by the equipment to request Remote Access operation Prepare directory of required recipes for the planned work

Post-process: After completion of the Remote Access operation, the following post processing are expected.





Date: 5/6/23

Acceptance process of the newly registered recipes Utilization process of the results from other recipe work (such as comparison result)

7.8.4 Intended Remote Access Operations — Intended operations are as below.

An operator requests Remote Access session at equipment (or workstation).

The equipment requests OperatorID and OperatorPassword, that are required for operator authentication by the host, to the operator, assigns SecurityID, and then asks the host for establishment of a RAC session.

The host authenticates the operator and responds to the equipment.

Normally, the operator requests directory of recipes to the host, and the host responds with an appropriate RecipeXIDList considering the SecurityID and EquipmentID provided from the equipment.

The operator may query required recipes to the host.

The operator uses those recipes for required works such as edit, compare, etc.

The operator may post the result of the work to the host. The work may result with the information other than recipe; however, the information should be dealt as quasi-recipe from the identification aspect in order to post it to the host through recipe transaction mechanism. TypeID may be used to identify a type of the result.

The operator closes the session upon completion of the work. The equipment reports to the host and clear recipes and other working results in the RAC.

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

8 Extended Recipe Identification Requirements8.1 RecipeXID — In order to identify recipes from multiple aspects, this Standard introduces Extended Recipe ID called RecipeXID. RecipeXID consists of the following identifiers.

8.1.1 Recipe ID — The RecipeID is the main identifier of recipe.

8.1.2 Version ID — The VersionID is an optional recipe identifier that can be combined with the RecipeID to uniquely identify the recipe. If the host uses this field, it has the advantage of being factory-set so that uniqueness of the RecipeID and VersionID combination can be assured by the host. The VersionID is a field that can be set only with the cooperation of the host. The VersionID value is intended to be assigned by the factory. In a typical case, the recipe is created at the equipment with the VersionID set to a zero-length string. Upon upload, the recipe might be checked-in to a recipe management system. A part of this check-in could be the modification of the recipe header with a factory generated VersionID.

8.1.3 Security ID — The SecurityID is an additional recipe identifier that is used to indicate the Security Class which the recipe belongs to. The SecurityID is not used for unique identification of recipes. The SecurityID is intended to be used for the following purposes.

In which logical recipe space the recipe shall be stored.

By which operator the recipe may be used.

For which operation the recipe may be used.

8.1.4 Type ID — The TypeID is an optional recipe identifier which indicates the type of the recipe (such as Main recipe, process chamber recipe, pump recipe, etc.)

8.1.5 Equipment ID — The EquipmentID is an additional recipe identifier that indicates equipment which the recipe is tuned for.





Date: 5/6/23

Table 10 RecipeXID Definition

ID Name Mnemonic Form Definition Note

Recipe ID RecipeID RecID which is defined in SEMI E40

Recipe ID RecID may not always be a unique identifier

Version ID VersionID Maximum 256 characters.

A string that identifies this particular adaptation of a base recipe that shares the same RecipeID. It is intended to be populated based upon factory business rules.Upon creation or modification of a recipe, the VersionID shall be set to a zero-length string unless the recipe editor is able to work in conjunction with the host for proper VersionID assignment.Any two recipes in the factory with the same RecipeID and non-zero-length VersionID shall have the same content for the recipe body.

A recipe editor that is not integrated with factory business rules would not be able to determine an appropriate VersionID.The host may populate the VersionID at a later time, for example at the time the recipe is checked-in to the factory recipe management system. If the host does not choose to use the VersionID for a particular recipe, the VersionID will remain a zero-length string.When a VersionID is assigned, the combination of RecipeID and VersionID would provide unique identification of the recipe within the factory.

Security ID SecurityID Maximum 16 characters

An identifier which indicates Security Class of the recipe

Indicates in which Security Class the recipe shall be dealt with. The host shall define SecurityID per actions to be taken with/between the equipment.SecurityID is not an ID for unique identification of recipe.

Type ID TypeID Maximum 16 characters

An optional identifier which indicates the type of the recipe.TypeID shall be set to a zero-length string when it is not used.

Equipment ID EquipmentID Maximum 256 characters

An optional identifier that identifies for which equipment this particular recipe is prepared.The EquipmentID shall be set to a zero-length string when it is not used.

9 Secured Recipe Space Requirements9.1 Secured Recipe Space — Equipment compliant with this Standard shall be compliant with the SRS requirements defined in this section.

9.2 SRS and Security Class — SRS is a recipe space which logically discriminates recipes per Security Class identified by SecurityID of each recipe. Each Security Class is deemed to have its own logical recipe space in SRS.

9.3 Message Requirements — SRS uses following messages.

9.3.1 Conventional Messages — The messages based on the recipe identification scheme system which uses RecipeID (PPID) as an only identifier of recipe. For upward compatibility, access with conventional messages shall be directed to Conventional Recipe Space by applying VersionID= ‘’ (zero length), and SecurityID= ‘Conventional’, TypeID= ‘’ (zero length), and EquipmentID= ‘’ (zero length) except for the following cases.

9.3.1.1 PJ Creation from the Host — PJ creation demand from the host shall refer the recipes which belong to the Security Class specified by PEMFlag regarding the recipes which master copies are managed on Recipe Server. The references of recipes which master copies are managed in equipment are not affected by PEMFlag.





Date: 5/6/23

9.3.1.2 SecurityID in Recipe Body — In case SecurityID (and VersionID as required) is embedded in Recipe Body, the conventional message may be used instead of the equivalent extended message.

9.3.2 Extended Messages — The messages which are defined to support SRS in this Standard. The messages are based on the use extended recipe identification scheme system which uses SecurityID and VersionID in addition to RecipeID (PPID) as extended recipe identifiers (RecipeXID).

Table 11 Secured Recipe Space Definitions

Logical Recipe Space

Security Class

(SecurityID)

Messages Definition Note

Conventional Extended

Conventional Recipe Space

‘Conventional’ Usable Usable Default recipe space.For upward compatibility with current implementation, currently used recipe space is mapped to this Security Class.

PRC Space ‘Production Cache’ or ‘Production Cache n’In case multiple PRCcaches are used, numerical character n should be added as ‘Production Cache n’

Not usableExcept for:PJ creation during PEM On

To be usedExcept for:PJ creation

Recipe space for PRC.Holds subset of exact copies of PEM Recipes that are managed on Recipe Server

‘Which PRC should be used for which PJ creation’ is equipment dependent.

RAC Space ‘Remote’ or ‘Remote n’In case multiple RACs are used, numerical character n should be added as ‘Remote n’

Not usable To be used Recipe space for Remote AccessThis space may hold temporary copy of required recipes that are managed on Recipe Server.After a remote access operation, modified or created recipes may be uploaded to Recipe Server and all related recipes used for the remote access shall be deleted from RAC.One RAC Space is used for one Remote Access connection for secure operation.

Optional Recipe Spaces

‘<user defined>’ Not usable To be used Recipe space for user defined Recipe Security Class

May be used to provide isolated recipe spaces to different roles

9.4 PEM State and PEMFlag — PEMFlag determines the PEM State whether the equipment operates in PEM On or PEM Off. PEMFlag holds the Security Class, which is used for the host triggered PJ creation, to indicate PEM State. PEMFlag may be used for protection purpose even in the case SecurityID is directly specified upon PJ creation demand.

9.4.1 Multiple PEMFlags for Multi-Part Equipment — In the case the equipment has a capability to divide itself into multiple parts that can operate in PEM On or PEM Off independently, the PEMFlag of the each part may separately be managed.





Date: 5/6/23

Table 12 PEM State and PEMFlag Definitions

PEM State PEMFlag

(Security Class to be used for PJ

Creation)

Definition Usage of Secured Recipe Space

Conventional Recipe Space PRC Space

PEM Off(Default)

‘Conventional’ A state for non-mass production operations such as installation, maintenance, process development, etc.

Shall be used for PJ creation for the equipment or the part of equipment controlled by this PEMFlag.May be used for PJ creation for other part of the equipment controlled by associated PEMFlags.

Shall not be used for any PJ creationMay be used for preparations of PRC before PEM On such as Cache Clear operation or Download operation

PEM On ‘Production Cache’ or ‘Production Cache n’

A state for mass production operations.

Shall not be used for PJ creation for the equipment or the part of equipment controlled by this PEMFlag.May be used for PJ creation for other part of the equipment controlled by associated PEMFlags.

Shall be used for PJ creation for the equipment or the part of the equipment managed by this PEMFlag.

9.5 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 PEM state of the each part shall separately be managed and the use of PRC shall separately be controlled as shown in the following figure.

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

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

Figure 8PRC Implementation for Multi-Part Equipment





Date: 5/6/23

9.6 SRS Object (SRSOBJ) Requirement — Equipment compliant with SRS function of this Standard shall have SRS Object management capability.

9.6.1 Definition of SRSOBJ — The SRSOBJ is a software representation of SRS. Information about SRS is encapsulated as an object. This allows the host to exchange information with the equipment about SRSOBJ by using services defined in SEMI E39 Object Services Standard.

9.7 SRSOBJ Object Descriptions

9.7.1 SRSOBJ Object Instantiation — Under normal circumstances one SRSOBJ object is instantiated by the equipment when the equipment is started up.

9.7.2 SRSOBJ Object Identifier (ObjID) — The SRSOBJID is the SRSOBJ Object Identifier. The equipment is responsible for ensuring uniqueness of the SRSOBJID prior to instantiation.

9.7.3 SRSOBJ Object Destruction — A SRSOBJ Object reaches the end of its lifecycle when the equipment is shut down.

9.8 SRSOBJ Object Attribute Definitions — The following table defines the attributes of SRSOBJ object.

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

Table 13 SRSOBJ Attribute Definition

Attribute Name Definition Access#1 Reqd Form

ObjID SRSOBJ object Identifier. RO Y Text.SRSOBJIDNumerical text expression of positive integer.ObjID is equipment defined.

ObjType Object Type. RO Y Text = ‘SRSObject’SRSSwitch Enable / Disable entire SRS functionalities.

Default is Disabled.RO Y Enumerated: Disabled, Enabled

SecurityClassList List of implemented Security Classes RO Y List ofSecurityClass (Maximum 16 characters)

PEMFlagList List of implemented PEMFlagsThis attribute is required when PRC is implemented.

RO Y List ofPEMFlag (Maximum 16 characters)

PEMFlag = ‘Conventional’ :PEM Off PEMFlag = ‘Production Cache’ or

‘Production Cache n’ :PEM OnQueryStat Status of QueryRecipe.

RecipeXIDList under query is heldRO Y RecipeXIDList

Zero length when no QueryRecipe takes place

Pre-ExeCheckStat Status of Pre-ExeCheckRecipeXID and CheckInformation under check are listed.

RO Y List of RecipeXID CheckInformation Zero length when no Pre-ExeCheck takes place

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





Date: 5/6/23

9.9 SRSOBJ Services — This section defines the message services required to support SRSOBJ functionalities. Equipment compliant with SRS function of this Standard shall have following services.

9.9.1 SRSOBJ Service Message Description — The following table is a list of SRSOBJ services.

Table 14 SRSOBJ Service Message Description

Service Name Triggered by Type#1 Req#2 DescriptionGetSRSAttributes Host R R This service gets attributes of SRSOBJSetSRSSwitch Host R R This service sets SRSSwitchSetPEMFlag Host R R This service sets PEMFlagClearClass Host R R This service clears all recipes in the Security Class specified by

SecurityIDDeleteRecipe Host R R This service deletes specified recipes in SRSWriteRecipe Host R R This service writes recipes down into SRSGetRecipeXIDList Host R O This service gets a list of RecipeXID which has specified SecurityIDReadRecipe Host R O This service reads specified recipes from SRSPreSpecifyRecipe Host R O This service specifies recipes by using RecipeXID for subsequent PJ

creation message that does not support RecipeXID. If the specified recipes are not in SRS, the equipment shall query those recipes to the host and check them. When the same RecipeID with the one specified by this service is given by the subsequent PJ creation, the VersionID and SecurityID specified by this service are used.

PresetRecipeXID Host R O This service presets RecipeXID for subsequent conventional access with the same RecipeID.

QueryRecipe Equipment R R This service writes specified recipes down into SRS triggered by the associated event from equipment which requests recipes to the host.

Pre-ExeCheck Equipment R O This service sends Pre-Execution Check result to equipment (and write correct recipes down into SRS when the check result is NG) triggered by the associated event from equipment which reports check information to the host.

QueryRecipeXIDList Equipment R O This service requests RecipeXID list which can be seen by specified Security Class to the host, and host responds with RecipeXIDList.

PostRecipe Equipment N O This service post s recipes to the host. #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’.#2 The ‘Req’ column is used to indicate whether the service is required, ‘R’, or optional, ‘O’.

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

Table 15 SRSOBJ Service Message Parameter Definition


ObjID Text.SRSOBJID. Numerical text expression of positive integer.ObjID is equipment defined.

SRSOBJ object Identifier.

SRSSwitch Enumerated: Disabled, Enabled Enable / Disable entire SRS functionalities. Default is Disabled.

PEMFlagList List of PEMFlag





Date: 5/6/23


PEMFlag Maximum 16 characters PEMFlag = ‘Conventional’ :PEM Off PEMFlag = ‘Production Cache’ or

‘Production Cache n’ :PEM On

PEMFlag holds SecurityID to be used for PJ creation

RecipeID RecID which is defined in SEMI E40 Recipe IDRecID may not always be a unique identifier

VersionID Maximum 256 characters Optional unique identifier of recipesVersionID shall be unique within the recipes with the same Recipe ID

SecurityID Maximum 16 characters Identifier of Security Class of the recipeTypeID Maximum 16 characters Identifier of the Type of the recipeEquipmentID Maximum 256 characters Identifier that indicates equipment which the recipe is

tuned forRecipeXID List of

RecipeIDVersionIDSecurityIDTypeIDEquipmentID

Extended recipe identifier

RecipeBody Equipment defined recipe Recipe BodyRecipeXIDList List of (RecipeID, VersionID, SecurityID,

TypeID, EquipmentID )List of RecipeXID

RecipeList List of (RecipeID, VersionID, SecurityID, TypeID, EquipmentID , RecipeBody)

List of Recipe

CheckInformation User defined Check information of specified recipesPre-ExeCheckResult Enumerated: OK, NG OK/NG response from the host to Pre-Exe Check

event from equipmentSetSRSSwitchResp Enumerated: Done, Error Information concerning the result of the serviceSetPEMFlagResp Enumerated: Done, Error Information concerning the result of the serviceClearClassResp Enumerated: Done, Error Information concerning the result of the serviceDeleteRecipeResp Enumerated: Done, Error Information concerning the result of the serviceWriteRecipeResp List of

RecipeTransferResultList of EachRecipeTransfer

Information concerning the result of the service

RecipeCheckNotifResp List of EachRecipeCheck Notification of recipe check result to the serviceGetRecipeXIDListResp Enumerated: Done, Error Information concerning the result of the serviceReadRecipeResp Enumerated: Done, Error Information concerning the result of the servicePreSpecifyRecipeResp Enumerated: Done, Error Information concerning the result of the servicePresetRecipeXIDResp Enumerated: Done, Error Information concerning the result of the servicePre-ExeCheckResp List of

Pre-ExeCheckResultAckConditional WriteRecipeResp

Information concerning the result of the service

QueryRecipeXIDListResp Enumerated: Done, Error Information concerning the result of the serviceRecipeTransferResult Enumerated: Done, Full, Error Response component for a list of recipe transferEachRecipeTransfer Enumerated: OK, NG Response component for single recipe transferEachRecipeCheck Enumerated: OK, NG Response component for single recipe checkPre-ExeCheckResultAck Enumerated: Done, Error Response component for Pre-ExeCheckResult





Date: 5/6/23

9.9.3 SRSOBJ Host Triggered Service Message Definitions — The following tables specify the allowable/required parameters for each service.

9.9.3.1 GetSRSAttributes — This service gets attributes of SRSOBJ. Use GetAtt of E39 OSS.

9.9.3.2 SetSRSSwitch — This service sets SRSSwitch.

Table 16 SetSRSSwitch Service Parameter Definitions

Parameter Name Req/Ind Rsp/Conf Description

ObjID M - Object IDSRSSwitch M - SRSSwitch value to be set.SetSRSSwitchResp - M Information concerning the result of the service

9.9.3.3 SetPEMFlag — This service sets PEMFlag.

Table 17 SetPEMFlag Service Parameter Definitions


ObjID M - Object IDPEMFlagList M - List of PEMFlagSetPEMFlagResp - M Information concerning the result of the service

9.9.3.4 ClearClass — This service clears all recipes in the Security Class specified by SecurityID.

Table 18 ClearClass Service Parameter Definitions


ObjID M - Object IDSecurityID M - Security IDClearClassResp - M Information concerning the result of the service

9.9.3.5 DeleteRecipe — This service deletes specified recipes in SRS. In case the specified recipe does not exist, the DeleteRecipe performs no action.

Table 19 DeleteRecipe Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDDeleteRecipeResp - M Information concerning the result of the service

9.9.3.6 WriteRecipe — This service writes recipes down into SRS. If same named recipes exist, this service overwrites them.





Date: 5/6/23

Table 20 WriteRecipe Service Parameter Definitions


ObjID M - Object IDRecipeList M - List of RecipesWriteRecipeResp - M Information concerning the result of the serviceRecipeCheckNotifResp - M Notification of recipe check result to the service

9.9.3.7 GetRecipeXIDList — This service gets a list of RecipeXID which has specified SecurityID.

Table 21 GetRecipeXIDList Service Parameter Definitions


ObjID M - Object IDSecurityID M - Security IDRecipeXIDList - M List of RecipeXIDGetRecipeXIDListResp - M Information concerning the result of the service

9.9.3.8 ReadRecipe — This service reads specified recipes from SRS.

Table 22 ReadRecipe Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDRecipeList - M List of RecipesReadRecipeResp - M Information concerning the result of the service

9.9.3.9 PreSpecifyRecipe — This service specifies recipes by using RecipeXID for subsequent PJ creation message that does not support RecipeXID.

Table 23 PreSpecifyRecipe Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDPreSpecifyRecipeResp - M Information concerning the result of the serviceRecipeCheckNotifResp - M Notification of recipe check result to the service

9.9.3.10 PresetRecipeXID — This service presets RecipeXID for subsequent conventional access with the same RecipeID.

Table 24 PresetRecipeXID Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDPresetRecipeXIDResp - M Information concerning the result of the service





Date: 5/6/23

9.9.4 SRSOBJ Equipment Triggered Service Message Definitions — The following tables specify the allowable/required parameters for each service. Equipment triggered service starts with an event from the equipment, and normally, the host responds with a required service.

9.9.4.1 QueryRecipe — This service writes specified recipes down into SRS triggered by the associated event from equipment which requests recipes to the host. Equipment requests recipes by QueryRecipe Event to the host, and the host responds with the specified recipes by using WriteRecipe service. Interleave of QueryRecipes are not allowed.9.9.4.1.1 QueryRecipe Event — This event requests recipes to the host.

Table 25 QueryRecipe Event Parameter Definitions


RecipeXIDList M - List of RecipeXID

9.9.4.1.2 QueryRecipe Service — WriteRecipe service is used as this service.

9.9.4.2 Pre-ExeCheck — This service sends Pre-Execution Check result to equipment (and write correct recipes down into SRS when the check result is NG) triggered by the associated event from equipment which reports check information to the host. Equipment requests Pre-Execution Check to the host by using Pre-ExeCheck Event, and the host sends the Pre-Execution Check result by using Pre-ExeCheck Service.9.9.4.2.1 Pre-ExeCheck Event — This event requests Pre-Execution Check to the host by sending RecipeXIDList and CheckInformation.

Table 26 Pre-ExeCheck Event Parameter Definitions


RecipeXIDList M - List of RecipeXIDCheckInformation M - Check information for Pre-Execution Check.

9.9.4.3 Pre-ExeCheck Service — This service is used to send Pre-ExeCheckResult to the equipment. Correct recipes are also sent down when Pre-ExeCheckResult is NG.

Table 27 Pre-ExeCheck Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDPre-ExeCheckResult M - Check result from the host. OK or NGRecipeList - C List of Recipes is sent when Pre-ExeCheckResult is NGPre-ExeCheckResp - M Information concerning the result of the serviceRecipeCheckNotifResp - C Notification of recipe check result to the service

9.9.4.4 QueryRecipeXIDList — This service requests RecipeXIDList to the host by QueryRecipeList Event from the equipment, and host responds with the list of RecipeXID in specified Security Class by using QueryRecipeList Service.9.9.4.4.1 QueryRecipeXIDList Event — This event requests RecipeXIDList to the host.





Date: 5/6/23

Table 28 QueryRecipeXIDList Event Parameter Definitions


SecurityID M -EquipmentID C -

9.9.4.4.2 QueryRecipeXIDList Service — This service downloads RecipeXID list to the equipment.

Table 29 QueryRecipeXIDList Service Parameter Definitions


ObjID M - Object IDRecipeXIDList M - List of RecipeXIDQueryRecipeXIDListResp - M Information concerning the result of the service

9.9.4.5 PostRecipe — This service posts a list of recipe to the host. SecurityID and EquipmentID of RecipeXIDs of the recipes in the RecipeList may be checked by the host for security.

Table 30 PostRecipe Event Parameter Definitions


RecipeList M -

10 PRC Requirements10.1 Operational Preconditions — This section describes preconditions for operations of the PRC.

10.1.1 Single Point of Control (SPOC) — The host side (e.g., something like an Equipment Interface) should maintain which node in the host takes care of which functionality of PRC Operation.

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.

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





Date: 5/6/23

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

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.

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. 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 Version ID occurred on Recipe Server, the host (Recipe Server) shall delete a PEM Recipe, which has the same Recipe ID, potentially exists in PRC.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 Version ID if in use), potentially exists in PRC.

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





Date: 5/6/23

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.

10.2.9 Content Management Logics of PRC — This section defines content management logics of PRC.

10.2.9.1 Maximum Number of PEM Recipes Downloaded in PRC — Maximum number of PEM Recipes downloaded in PRC before PJ creation is limited by the capacity of the PRC. MaxNumber is not applied upon download. In case Cache Full occurred, least recently accessed (written into PRC or used for PJ creation) recipes are deleted in order to create sufficient space.

10.2.9.2 Maximum Number of PEM Recipes Preserved in PRC — 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, 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.

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

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.

Table 31 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 demandLook-up: Upon PJ creationCache Hit: OccursCache Miss: Doesn’t occurPreservation: None. Delete all

Pre-Download Mode

Download: Appropriately before associated PJ creation demandLook-up: Upon PJ creationCache Hit: OccursCache Miss: Doesn’t occurPreservation: 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.





Date: 5/6/23

MaxNumber

Download or Query

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

Query Basis

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

Full Query Mode

Download: NoneLook-up: Upon PJ creationCache Hit: Doesn’t occurCache Miss: Occurs every time. Query is used.Preservation: None. Delete all

Cache Mode

Download: NoneLook-up: Upon PJ creationCache Hit: May occurCache 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. Unless otherwise noted, ‘Production Cache’ or ‘Production Cache n’ shall be used for SecurityID in the services to PRC when SecurityID is required.

Table 32 PRC Operations

PRC Operation Operation Service to be used Note

Cache Clear Clear entire contents of PRC ClearClass The host or equipment triggersDownload The host downloads PEM Recipes into PRC WriteRecipeDelete The host deletes specified PEM Recipes in

PRCDeleteRecipe

Lookup Equipment looks up the required PEM Recipes in PRC

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

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

Cache Hit Equipment finds the required PEM Recipes in PRC

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

Consistency Check(Optional)

Pre-Execution Check Pre-ExeCheck

10.4.1 Cache Clear Operation — Cache Clear Operation clears all the recipes in PRC. This operation is used in case the recipes in PRC are deemed inconsistent with the recipes in Recipe Server. The host uses ClearClass service





Date: 5/6/23

to execute Cache Clear Operation. The equipment executes Cache Clear Operation, triggered by the cases listed below.

The host or the privileged user shall trigger Cache Clear Operation 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 Cache Clear Operation in case they deem that mismatch is probable between recipes in PRC and the recipes on the Recipe Server (such as after maintenance).

An operator may trigger Cache Clear Operation 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 Cache Clear Operation in case they deem there is a security concern on leaving the recipes in PRC (such as Recipe User Group change).

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

10.4.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 Cache Clear Operation 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.

Figure 10Cache Clear Operation

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

Figure 11Download Operation

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





Date: 5/6/23

Figure 12Delete Operation

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 QueryRecipe service. The recipe written into PRC is served to PJ Creator for PJ creation.

10.4.4.1.1 Query of Linked Recipes — In case the recipe has linkages to sub-recipes, and those linked sub-recipes are also managed in the Recipe Server and PRC, the linked sub-recipes are also queried upon their Cache Miss.

Figure 13Cache 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.





Date: 5/6/23

Figure 14Cache 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-ExeCheck Service in order to request consistency check to the host (Recipe Server) and to have OK/NG information, in case of NG, correct PEM Recipe.10.4.4.2.1.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. This Standard does not define check information (e.g., Checksum) specification. Non-host-managed sub-recipes and/or equipment parameters may also be taken into account (the host may compare the information with the correct information which was prospectively uploaded to the host), however, upon a negative response from the host, the equipment can only report an error and stop the execution.

Figure 15Consistency Check Operation (OK and NG)

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

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

10.6 PRCOBJ Object Descriptions

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

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

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

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

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





Date: 5/6/23


Table 33 PRCOBJ Attribute Definition

Attribute Name Definition Access#1 Reqd Form

ObjID PRCOBJ object Identifier. RO Y Text.PRCOBJID.‘<Security Class>’Security Class implemented by SRS ObjectObjID is equipment defined.

ObjType Object Type. RO Y Text = ‘PRCObject’PRCSwitch Enable/Disable of entire PRC

functionalities. Default is Disabled.RO Y Enumerated: Enabled, Disabled

AutoClear A flag which enables or disables the Auto Clear function

RO Y Enumerated:Enable, Disable

MaxNumber Maximum number of PEM Recipes allowed to be preserved in PRC after PJ creation. MaxNumber has a list structure so that it can be applied to each subspace. The usage of the list structure is equipment defined.

RO Y List of:Unsigned integer:

‘n’ = n recipes are allowedDefault = 1

MaxTime Maximum time during which 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 (Default)‘1’ or more = Maximum Time

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

RO O Enumerated: Enabled, DisabledDefault is Disabled

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

10.8 State Management of PRCOBJ

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

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

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

Table 34 PRCOBJ Service Message Description

Service Name Type#1 DescriptionSetPRCAttributes R This service sets attributes of PRCOBJGetPRCAttributes R This service gets attributes of PRCOBJ

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

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





Date: 5/6/23

Table 35 PRCOBJ Service Message Parameter Definition


ObjID Text.PRCOBJID.‘<Security Class>’Security Class implemented by SRS ObjectObjID is equipment defined.

PRCOBJ object Identifier.

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

Enable, DisableA flag which enables or disables the Auto Clear function

MaxNumber List of:Unsigned integer:‘n’ = n recipes are allowedDefault = 1

Maximum number of PEM Recipes allowed to be preserved in PRC after PJ creation. MaxNumber has a list structure so that it can be applied to each subspace. The usage of the list structure is equipment defined.

MaxTime Unsigned integer.Unit is user defined.‘0’ = Maximum Time function is not used (Default)‘1’ or more = Maximum Time

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

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

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

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

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

Table 36 SetPRCAttributes Service Parameter Definitions


ObjID M - Object IDPRCSwitch M - Enable/Disable of entire PRC functionalitiesAutoClear M - Auto Clear upon host communication establishmentMaxNumber M - Maximum number of recipes preserved in PRCMaxTime CO - Maximum time to preserve recipes in PRCPRCPre-ExeCheck CO - Enable/Disable of Pre-Execution Check optionSetPRCAttributesResp - M Information concerning the result of the service

10.9.3.2 GetPRCAttributes — Use GetAtt of E39 OSS.





Date: 5/6/23

11 Remote Access Cache Requirements11.1 Remote Access Cache — This section defines specifications of Remote Access Cache function.

11.2 Use of RAC Space — RAC Space is used as a work space for Remote Access operation. RAC caches required recipes which master copies are on Recipe Server, and holds newly revised or created recipes. Upon closing of a Remote Access session, RAC Space shall be cleared after uploading required results to the host.

11.3 One RAC Space for One Session — One RAC Space is used for one Remote Access session.

11.4 Initialization and Termination of RAC Space — RAC Space shall be ready when a Remote Access session is opened and shall be cleared when a Remote Access session is closed.

11.5 Authentication of Operator — Equipment shall maintain access control of RAC throughout a session. One RAC is used for one session for one operator.

11.5.1 Opening of a Session — Equipment shall request OperatorID and OperatorPassword to the operator who requests remote access and shall send them to the host through Open Remote Access operation for authentication by the host.

11.5.2 During the Session — Equipment is strongly recommended to confirm OperatorID and OperatorPassword at appropriate timings during the session.

11.5.3 Closing of a Session — Equipment shall request OperatorID and OperatorPassword to the operator and shall send CloseStatus to the host by Close Remote Access operation.

11.6 Remote Access Operations — RAC has the following operations. Unless otherwise noted, ‘Remote’ or ‘Remote n’ shall be used for SecurityID in RACOBJ services.

Table 37 Remote Access Operations

Remote Access Operation

Operation Originated by

Service to be used Note

Session Management

Establish session in secure manner

Open Remote Access

Equipment requests to open a Remote Access session to the host.

Equipment OpenRemoteAccess

Close Remote Access

Equipment requests to close the Remote Access session to the host.

Equipment CloseRemoteAccess

Directory Access Equipment gets directory from the host.Request Directory Equipment requests directory to the host Equipment QueryRecipeXIDList

Download/Upload of Recipes

Query Recipe Equipment queries specified recipes when the recipes are not in RAC Space.

Equipment QueryRecipe

Upload Recipe Equipment uploads specified recipes in RAC Space to the host.

Equipment PostRecipe

11.6.1 Open Remote Access Operation — This operation establishes a Remote Access session between the host and equipment. This operation is used at the beginning of Remote Access in order to have an operator authentication by the host. Upon the grant from the host, a Remote Access session is established. OperatorID and OperatorPassword are required for operator authentication.





Date: 5/6/23

AddFigure 16

Open Remote Access Operation

11.6.2 Close Remote Access Operation — This operation closes the Remote Access session between the host and equipment. This operation is used at the end of Remote Access. Upon the grant from the host, the RAC Space is cleared and the Remote Access session is closed.

AddFigure 17

Close Remote Access Operation

11.6.3 Request Directory Operation — This operation requests directory information to see required set of recipes in Recipe Server.

AddFigure 18

Request Directory Operation





Date: 5/6/23

11.6.4 Query Recipe Operation — This operation queries recipes to Recipe Server. When the specified recipes are found in RAC Space, the recipes are used and query to Recipe Server does not occur.

AddFigure 19

Query Recipe Operation (Cache Miss)

AddFigure 20

Query Recipe Operation (Cache Hit)

11.6.5 Upload Recipe Operation — This operation requests upload of recipes in RAC Space to Recipe Server. VersionID of the recipes locally edited on equipment shall be zero length. VersionID may be assigned by the host upon acceptance.

AddFigure 21

Upload Recipe Operation

11.7 RAC Object (RACOBJ) Requirement — Equipment compliant with RAC function of this Standard shall have RAC Object management capability.





Date: 5/6/23

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

11.8 RACOBJ Object Descriptions

11.8.1 RACOBJ Object Instantiation — Under normal circumstances RACOBJ object is instantiated by the equipment when the equipment recognizes request of Remote Access operation.

11.8.2 RACOBJ Object Identifier (ObjID) — The RACOBJID is the RACOBJ Object Identifier. The equipment is responsible for ensuring uniqueness of the RACOBJID prior to instantiation.

11.8.3 RACOBJ Object Destruction — A RACOBJ Object reaches the end of its lifecycle when the equipment closes the Remote Access session. Remote Access session is closed by operator, also, is closed by optional AutoClose timer for security.

11.8.4 RACOBJ Object Persistence — A RACOBJ Object does not need to persist over equipment shut down to restart.

11.9 RACOBJ Object Attribute Definitions — The following table defines the attributes of RACOBJ object.


Table 38 RACOBJ Attribute Definition

Attribute Name Definition Access #1 Reqd Form

ObjID RACOBJ object Identifier. RO Y Text.RACOBJID.‘<Security Class>’Security Class implemented by SRS ObjectObjID is equipment defined.

ObjType Object Type. RO Y Text = ‘RACObject’RACSwitch Enable/Disable of entire RAC

functionalities. Default is Disabled.RO Y Enumerated: Enabled, Disabled

AutoClose A function that equipment closes the session automatically when operator access doesn’t occur exceeding the predefined maximum time.

RO Y Unsigned integer.Unit is user defined.‘0’ = AutoClose function is not used (Default)‘1’ or more = Maximum time

OperatorID Host-registered identifier of the operator who uses the Remote Access session

RO Y Maximum 32 characters

OperatorPassword Host-registered password of the operator who uses the Remote Access session

RO Y Maximum 16 characters

CloseStatus Status of the RACObj RO Y Enumerated: Normal, AutoClosed, Error#5 Even though a value may be marked as RO (read only), the initial value for the attribute may be provided by the host.

11.10 State Management of RACOBJ

11.10.1 Activation of RAC — For upward compatibility, RAC shall be disabled when equipment is started up. In order to use RAC, RAC shall be enabled by the host or privileged user by enabling RACSwitch.

11.11 RACOBJ Services — This section defines the message services required to support RACOBJ functionalities. Equipment compliant with RAC function of this Standard shall have following services to manage RACOBJ.

11.11.1 RACOBJ Service Message Description — The following table is a list of RACOBJ services.





Date: 5/6/23

Table 39 RACOBJ Service Message Description

Service Name Triggered by Type #1 Req # 2 DescriptionSetRACAttributes Host R Y This service sets attributes of RACOBJGetRACAttributes Host R Y This service gets attributes of RACOBJOpenRemoteAccess Equipment R Y This service requests to open a Remote Access session to the host.CloseRemoteAccess Equipment R Y This service requests to close a Remote Access session to the host.

#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’.#2 The ‘Req’ column is used to indicate whether the service is required, ‘R’, or optional, ‘O’.

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

Table 40 RACOBJ Service Message Parameter Definition


ObjID Text.RACOBJID.‘<Security Class>’Security Class implemented by SRS ObjectObjID is equipment defined.

RACOBJ object Identifier.

RACSwitch Enumerated: Enabled, Disabled Enable/Disable of entire RAC functionalitiesAutoClose Unsigned integer.

Unit is user defined.‘0’ = AutoClose function is not used (Default)‘1’ or more = Maximum time

A function that equipment closes the session automatically when operator access doesn’t occur exceeding the predefined maximum time.

OperatorID Maximum 32 characters Identifier of the operator who uses the Remote Access session

OperatorPassword Maximum 16 characters Password of the operator who uses the Remote Access session

CloseStatus Enumerated: Normal, AutoClosed, Error Status which indicates how the RACObj is closedSetRACAttributesResp Enumerated: Done, Error Information concerning the result of the serviceOpenRemoteAccessResp Enumerated: OK, NG Information concerning the result of the serviceCloseRemoteAccessResp Enumerated: OK, NG Information concerning the result of the service

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

11.11.3.1 SetRACAttributes — This service is used to initialize and start functionalities of RAC.

Table 41 SetRACAttributes Service Parameter Definitions


ObjID M - Object IDRACSwitch M - Enable/Disable of entire RAC functionalitiesAutoClose M - Maximum time for AutoClose functionSetRACAttributesResp - M Information concerning the result of the service





Date: 5/6/23

11.11.3.2 GetRACAttributes — Use GetAtt of E39 OSS.

11.11.4 OpenRemoteAccess — This service requests to open Remote Access to the host. The host responds with OK or NG.

11.11.4.1 OpenRemoteAccess Event — This event requests to open Remote Access to the host. OperatorID and OperatorPassword are sent to the host for operator authentication.

Table 42 OpenRemoteAccess Event Parameter Definitions


OperatorID M - ID of the operatorOperatorPassword M - Password of the operatorSecurityID M - This specifies the Security Class of targeted recipesEquipmentID C -

11.11.4.2 OpenRemoteAccess Service — The host responds to the equipment if the Remote Access request is granted.

Table 43 OpenRemoteAccess Service Parameter Definitions


ObjID M - Object IDOpenRemoteAccessResp - M Information concerning the result of the service

11.11.5 CloseRemoteAccess — This service requests to close Remote Access to the host. The host responds with OK or NG.

11.11.5.1 CloseRemoteAccess Event — This event requests to close the Remote Access to the host.

Table 44 CloseRemoteAccess Event Parameter Definitions


SecurityID M -CloseStatus M - Informs if the session is closed properly

11.11.5.2 CloseRemoteAccess Service — The host responds to the equipment if the Remote Access is properly closed.

Table 45 CloseRemoteAccess Service Parameter Definitions


ObjID M - Object IDCloseRemoteAccessResp - M Information concerning the result of the service

12 Requirements for Compliance12.1 Following table provides a checklist for PRC compliance.





Date: 5/6/23

Table 46 PRC Compliance Statement

Fundamental PRC Requirements PRC Section Implemented PRC Compliant

Extended Recipe Identification Requirements 8 RecipeXID 8.1 Yes No Yes No

Secured Recipe Space Requirements 98 Secured Recipe Space 98.1 Yes No Yes NoSRS and Security Class 98.2 Yes No Yes NoMessage Requirements 98.3 Yes No Yes No

Conventional Messages 98.3.1 Yes No Yes NoPJ Creation from the Host 98.3.1.1 Yes No Yes NoSecurityID in Recipe Body 98.3.1.2 Yes No Yes No

Extended Messages 98.3.2 Yes No Yes NoPEM State and PEMFlag 9 8 .4 Yes No Yes No

Multiple PEMFlags for Multo-Part Equipment 98.4.1 Yes No Yes NoMulti-Part Equipment Compatibility (Optional) 9.58.7 Yes No Yes No

Multi-Part Equipment with One PRC 9.5.18.7.1 Yes No Yes NoMulti-Part Equipment with dedicated PRCs 9.5.28.7.2 Yes No Yes No

SRS Object (SRSOBJ) Requirement 9.68.8 Yes No Yes NoSRSOBJ Object Descriptions 9.78.9 Yes No Yes NoSRSOBJ Object Attribute Definitions 9.88.10 Yes No Yes NoSRSOBJ Services 9.9 8.11 Yes No Yes No

PRC Requirements 109 Fundamental Requirements 109.2 Yes No Yes No

Use of Recipes in PRC 109.2.1 Yes No Yes NoNo Concurrent PRC Reference for Multiple Recipe Request

109.2.3 Yes No Yes No

No Editing of Recipe in PRC 109.2.6 Yes No Yes NoCopy Out of a Recipe from PRC 109.2.7 Yes No Yes NoLocal Access to PRC 109.2.8 Yes No Yes NoContent Management Logics of PRC 109.2.9

Maximum Number of PEM Recipes Downloaded in PRC

109.2.9.1 Yes No Yes No

Maximum Number of PEM Recipes Preserved in PRC


Maximum Time of PEM Recipes Preserved in PRC (Optional)


PRC Operation Modes 109.3 Yes No Yes No PRC Operations 109.4

Cache Clear Operation 109.4.1 Yes No Yes NoDownload Operation 109.4.2 Yes No Yes NoDelete Operation 109.4.3 Yes No Yes NoLookup Operation 109.4.4 Yes No Yes No

Cache Miss Operation 109.4.4.1 Yes No Yes NoQuery of Linked Recipes 109.4.4.1.1 Yes No Yes No

Cache Hit Operation 109.4.4.2 Yes No Yes No





Date: 5/6/23

Fundamental PRC Requirements PRC Section Implemented PRC Compliant

Consistency Check Operation (Optional) 109.4.4.2.1 Yes No Yes NoPRC Object (PRCOBJ) Requirement 109.5 Yes No Yes NoPRCOBJ Object Descriptions 109.6 Yes No Yes NoPRCOBJ Object Attribute Definitions 109.7 Yes No Yes NoState Management of PRCOBJ 109.8 Yes No Yes NoPRCOBJ Services 109.9 Yes No Yes No

Remote Access Cache Requirements 11 Use of RAC Space 11.2 Yes No Yes NoOne RAC Space for One Session 11.3 Yes No Yes NoInitialization and Termination of RAC Space 11.4 Yes No Yes NoAuthentication of Operator 11.5 Yes No Yes No

Opening of a Session 11.5.1 Yes No Yes NoDuring the Session 11.5.2 Yes No Yes NoClosing of a Session 11.5.3 Yes No Yes No

Remote Access Operations 11.6 Yes No Yes NoOpen Remote Access Operation 11.6.1 Yes No Yes NoClose Remote Access Operation 11.6.2 Yes No Yes NoRequest Directory Operation 11.6.3 Yes No Yes NoQuery Recipe Operation 11.6.4 Yes No Yes NoUpload Recipe Operation 11.6.5 Yes No Yes No

RAC Object (RACOBJ) Requirement 11.7 Yes No Yes NoRACOBJ Object Descriptions 11.8 Yes No Yes NoRACOBJ Object Attribute Definitions 11.9 Yes No Yes NoState Management of RACOBJ 11.10 Yes No Yes NoRACOBJ Services 11.11 Yes No Yes No

13 Related Documents13.1 Subordinate Standards

SEMI E170.1 — Specification for SECS-II Protocol for Secured Foundation Of Recipe Management System Production Recipe Cache





Date: 5/6/23

RELATED INFORMATION 1 INCREMENTAL IMPLEMENTATION STEPSNOTICE: This Related Information is not an official part of SEMI E170 and was derived from the work of the global Information and Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on [ A&R approval date ].

R1-1 Purpose of Incremental Implementation Steps R1-1.1 Introduction of Incremental Implementation Steps — To make implementation barrier lower, following deployment steps are considered and recommended. Step 3A and Step 3B are independent and can be implemented in either order. Step 4 is the completion of E170 implementation with both 3A and 3B implemented.

Table R1-1 Incremental Implementation Steps

Steps Step 1 Step 2 Step 3A1 Step 3A2 Step 3B Step 4

Introduced E170 Capability

Message Set with RecipeXID

SRS Management PRC Space PRC Operation RAC Operation All

Purpose Introduce E170 recipe transaction capability (Preparation of Extended Recipe ID capability)

Introduce E170 Secured Recipe Space management capability

Introduce recipe space switching function for production execution

Introduce cache operation for production recipe transaction efficiency

Introduce Remote Access function for SPORM

Completion of E170 implementation

Precondition None(Decision to go with E170)

Step 1 Step 2 Step 3A1 Step 2(PEMFlag is not needed)

Step 3A or 3B

Implementation E170 Messages for Recipe Upload and Download

SRS Object except PEMFlag

PRC SpacePEMFlag

PRC Object RAC SpaceRAC Object

All components

Expected Effects Multiple recipe upload or download by single message is supported(Conventional messaging are not affected and are also usable)

Secured Recipe Spaces are usableOptional Recipe Spaces can be assigned to differently privileged operator groups

PRC Space is usable for secure production recipe handling(Pre-Download Mode, Full Download Mode)

Efficient transaction of recipe by cache operation(Cache Mode, Full Query Mode)

Remote Access of recipes on Recipe Server by using supplier provided recipe applications on equipment or workstation

Full effect of E170

Available Operations and Functions

Extended recipe identification by RecipeXIDMultiple recipes by single message

SRS Management (Security Class management by SecurityID)

PEMFlag which selects recipe space for E40 PJ

PRC operations RAC operations All E170 functionalities for SPORM





Date: 5/6/23

R1-2 Step 1: Message Set with RecipeXIDR1-2.1 Purpose — The purpose of this step is to provide a communication channel with expected identification capabilities of recipes by using basic set of E170 messages which uses RecipeXID.

R1-2.2 Expected Effects — By the implementation of basic set of E170 messages, the following functionalities are provided.R1-2.2.1 Messaging Capabilities — The messages provides following capabilities.

Multiple-recipe-upload/download by single message. This simplifies recipe transactions by enabling the use of single upload/download message for one set of recipes required for one process execution.

Replace conventional recipe Upload/Download messages preparing for the introduction of Step 2.

R1-2.2.2 Confirmation and Logging Capabilities — In case recipe editor is modified to manage RecipeXID, the following confirmation and logging are possible.

VersionID may be recorded in process log in order to make the version of the recipe used to each process clear.

SecurityID may be used to confirm if the recipe is the one certified by the host.

EquipmentID may be used to confirm if the recipe is prepared for the equipment.

Add

Figure R1-1Image of Step 1: Message Set with RecipeXID





Date: 5/6/23

R1-3 Step 2: SRS ManagementR1-3.1 Purpose — The purpose of this step is to provide SRS capability. SecurityID in the RecipeXID is used to distinguish recipe spaces with different Security Classes for different purposes.

R1-3.2 Expected Effects — By using SecurityID, recipe spaces are securely managed.

R1-3.2.1 SRS Space Definition — Any of SRS Spaces may be implemented. SRS Spaces including Conventional Recipe Space are clearly separated each other.R1-3.2.2 Optional Recipe Spaces (User Defined) — Optional Recipe Spaces with optional Recipe Security Class can be determined and used.

e.g. The recipes which SecurityID is ‘ABC’ can only reside in the recipe space with Security Class ‘ABC’.

R1-3.3 Available Functions — In addition to the Step1, this step has following functions.

Add

Figure R1-2Image of Step 2: SRS Management

R1-4 Step 3A1: PRC SpaceR1-4.1 Purpose — The purpose of this step is to provide SRS capability. SecurityID in the RecipeXID is used to distinguish recipe spaces with different Security Classes for different purposes.

R1-4.2 Expected Effects — By using SecurityID, recipe spaces are securely managed.

R1-4.2.1 PRC Space Definition — PRC Space is clearly separated from Conventional Recipe Space. PRC Space provides secure recipe space for Production Recipe. The recipes in PRC Space cannot be seen by equipment operator.





Date: 5/6/23

R1-4.2.2 Selection of Recipe Spaces upon PJ Creation — Host controlled PEMFlag shows if the equipment (or the part of equipment) is in PEM (Production Execution Mode), and determines which recipe space is used for PJ creation. Conventional E40 PJM message can be used for PJ creation by referencing PEM Flag.

PEM On State (when the host sets PEMFlag as ‘Production’), the Production Recipes (SecurityID= ‘Production’) in PRC Space are used.

PEM Off State (when the host sets PEMFlag as ‘Conventional’), the recipes (SecurityID= ‘Conventional’) in Conventional Recipe Space are used.

R1-4.2.3 Optional Recipe Spaces (User Defined) — Optional Recipe Spaces with optional Recipe Security Class can be determined and used.

e.g. The recipes which SecurityID is ‘ABC’ can only reside in the recipe space with Security Class ‘ABC’.

R1-4.3 Available Functions — In addition to the Step1, this step has following functions.

Add

Figure R1-3Image of Step 3A1: PRC Space

R1-5 Step 3A2: PRC OperationR1-5.1 Purpose — The purpose of this step is to add Cache Mode operation in order to improve recipe transaction efficiency.

R1-5.2 Expected Effects — The following functions are implemented.

R1-5.2.1 Cache Mode Operation — MaxNumber management provides optimum cache hit rate management.





Date: 5/6/23

R1-5.2.2 MaxNumber Management of PRC Space — MaxNumber management provides optimum cache hit rate management.

Normally, absolute maximum number of PRC Space is fixed and managed by equipment regardless of the implementation of dynamic MaxNumber control capability. So, implementation of MaxNumber management capability may not be needed at the begining to start using Cache Mode Operation.

R1-5.2.3 AutoClear — AutoClear is not a must for recipe operation but for security, and may be postponed.R1-5.2.4 MaxTime (Option) — MaxTime option may be implemented for more security in this Step or after.

Add

Figure R1-4Image of Step 3A2: PRC Operation

R1-6 Step 3B: RAC OperationR1-6.1 Purpose — The purpose of this step is to provide capability to access the recipes on RMS remotely from equipment or other work station in order to support SPORM. All master copies of the recipes are managed at single point on Recipe Server in RMS.

R1-6.2 Expected Effects — Remote Access capability becomes available and recipe access from equipment or other work stations are enabled.

R1-6.2.1 Enables Use of Equipment Supplier Provided Applications — Recipe applications, that are on equipment or equipment supplier provided work station and are optimized for the equipment, are also usable to the recipes on Recipe Server in RMS.





Date: 5/6/23

Recipe editor

Other recipe management applications such as history management, comparison, etc.

R1-6.2.2 Secured RAC Mechanism Supports Remote Access — The following secured RAC mechanisms are provided to enable Remote Access.

Dedicated Recipe Security Class ‘Remote’ or ‘Remote n’ is introduced.

Dedicated RAC Space ‘Remote’ or ‘Remote n’ is prepared.

Session management which support secure session initiation and close is implemented.

Add

Figure R1-5Image of Step 3B: RAC Operation

R1-7 Step 4: AllR1-7.1 Purpose — The purpose of this step is to improve recipe transaction efficiency improvement.

R1-7.2 Expected Effects — All functionalities of this Standard.

R1-7.2.1 Extended Recipe Identification — Recipes are identified by RecipeXID.R1-7.2.2 Recipe Space Security Management — SRS Object manages security among recipe spaces.R1-7.2.3 Recipe Transaction Efficiency Optimization — Cache Mode Operation and its options optimize recipe transaction efficiency in balance of security.R1-7.2.4 Remote Access Operation — Secured Remote Access supports SPORM based RMS.





Date: 5/6/23

Add

Figure R1-6Image of Step 4: All





Date: 5/6/23

RELATED INFORMATION 2 EXAMPLE OF PRODUCTION RECIPE CACHE OPERATION IN CACHE MODE NOTICE: This Related Information is not an official part of SEMI E170 and was derived from the work of the global Information and Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on [A&R approval date].

R2-1 Example of PRC OperationR2-1.1 Typical Cache Mode Operation — This Appendix shows an operation example of PRC in Cache Mode.

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

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

b. PRC Controller clears the PRC.

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

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

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

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

j. Recipe Executor holds the recipe in Recipe Execution Space and executes.

Figure R1-7Cache Mode Operations





Date: 5/6/23

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

Figure R1-8Equipment Start Up

R2-3.2 MES Sends Cache Clear Request — PRC Controller deletes recipes in PRC.

Figure R1-9MES Sends Cache Clear Request





Date: 5/6/23

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

Figure R1-10PRC is Cleared

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

Figure R1-11MES Sends PJ with Recipe #A





Date: 5/6/23

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

Figure R1-12PRC Controller Queries Recipe #A to Recipe Server

R2-3.6 PRC Controller Writes Recipe #A in PRC — And sends Recipe #A to Recipe Executor.

Figure R1-13PRC Controller Writes Recipe #A in PRC





Date: 5/6/23

R2-3.7 Recipe Executor Sends Recipe #A to Recipe Execution Space — Recipe execution starts!

Figure R1-14Recipe Executor Sends Recipe #A to Recipe Execution Space

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

Figure R1-15PJ Ends





Date: 5/6/23

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

Figure R1-16MES Sends PJ with Recipe #A Again

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

Figure R1-17PRC Controller Passes Recipe #A to Recipe Executor





Date: 5/6/23

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

Figure R1-18PJ Ends Again

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

Figure R1-19MES Requests PJ with Recipe #B





Date: 5/6/23

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

Figure R1-20PRC Queries Recipe #B to Recipe Server

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

Figure R1-21PJ with Recipe #B is in Progress





Date: 5/6/23

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

Figure R1-22MES Requests PJ with Recipe #A Again

R2-3.16 Recipe #A Starts Immediately After Completion of Recipe #B — Recipe Executor sends Recipe #A to Recipe Execution Space.

Figure R1-23Recipe #A Starts Immediately After Completion of Recipe #B





Date: 5/6/23

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.





Date: 5/6/23

SEMI E170.1-mmyy: SPECIFICATION FOR SECS-II PROTOCOL FOR SECURED FOUNDATION OF RECIPE MANAGEMENT SYSTEM PRODUCTION RECIPE CACHE

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 Mmmmm Dd, 2015. Available at www.semiviews.org and www.semi.org in Mmmm 2015

14 Purpose14.1 The purpose of this Standard is to provide a mapping of the services and data of SEMI E170-mmyy Specification for Secured Foundation Of Recipe Management System Production Recipe Cache to SECS-II message protocol.

15 Scope15.1 The scope of this Standard is to map the services and data of SEMI E170 to SECS-II streams, functions, and items.

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.

16 Referenced Standards and Documents16.1 SEMI Standards and Safety Guidelines

SEMI E5 — SEMI Equipment Communications Standard 2 Message Content (SECS-II)

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

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

SEMI E39.1 — SECS-II Protocol for Object Services Standard (OSS)

SEMI E40 — Standard for Processing Management

SEMI E170 — Secured Foundation Of Recipe Management System (SFORMS) Specification for Production Recipe Cache (PRC)

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

17 Terminology17.1 None.

18 Mapping of SRSOBJ Services

Table 1 SRSOBJ Service Messages Mapping

SRSOBJ Service Message Name E39 Object Service Message Name

Stream, Function SECS-II Name

GetSRSAttributes GetAttr S14F1,F2 GetAttr Request/GetAttr DataSetSRSSwitch ObjectAction S14F19,F20 Generic Service Request/AcknowledgeSetPEMFlag ObjectAction S14F19,F20 Generic Service Request/AcknowledgeClearClass ObjectAction S14F19,F20 Generic Service Request/AcknowledgeDeleteRecipe ObjectAction S14F19,F20 Generic Service Request/AcknowledgeWriteRecipe ObjectAction S14F19,F20 Generic Service Request/Acknowledge





Date: 5/6/23

SRSOBJ Service Message Name E39 Object Service Message Name


GetRecipeXIIDList ObjectAction S14F19,F20 Generic Service Request/AcknowledgeReadRecipe ObjectAction S14F19,F20 Generic Service Request/AcknowledgePreSpecifyRecipe ObjectAction S14F19,F20 Generic Service Request/AcknowledgePresetRecipeXID ObjectAction S14F19,F20 Generic Service Request/AcknowledgePre-ExeCheck ObjectAction S14F19,F20 Generic Service Request/AcknowledgeQueryRecipeXIDList ObjectAction S14F19,F20 Generic Service Request/AcknowledgeQueryRecipe Event - S6F11, F12 Event Report Send/AcknowledgePre-ExeCheck Event - S6F11, F12 Event Report Send/AcknowledgeQueryRecipeXIDList Event - S6F11, F12 Event Report Send/AcknowledgePostRecipe Event - S6F11, F12 Event Report Send/Acknowledge

19 Mapping of SRSOBJ Parameter

Table 2 Parameter to SECS-II Data Items Mapping

SRSOBJ Service Parameter

E39 Object Service Message Parameter

Range SECS-II Data Item

--- OperationID OPID [5( )]--- ObjSpec OBJSPEC [20]--- ObjectAction ‘SetSRSSwitch’

‘SetPRMFlag’‘ClearClass’‘DeleteRecipe’‘WriteRecipe’‘GetRecipeXIDList’‘ReadRecipe’‘PreSpecifyRecipe’‘PresetRecipeXID’‘QueryRecipe’‘Pre-ExeCheck’‘QueryRecipeXIDList’

SVCNAME [20]

ObjID for GetSRSAttributes

ObjID 1-80 characters OBJID

ObjID forother services

ObjectActionParameterRequest

L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘ObjID’SPVAL 1-80 characters





Date: 5/6/23




SRSSwitch ObjectActionParameterRequest


SPNAME= ‘SRSSwitch’SPVAL [51] 0=Disabled 1=Enabled

PEMFlagList ObjectActionParameterRequest


SPNAME= ‘PEMFlagList’SPVAL L, n 1. PEMFlag1

: n. PEMFlagn

PEMFlagn 0-16 characters ‘Conventional’, ‘Production Cache’ or ‘Production Cache n’

SecurityID ObjectActionParameterRequest


SPNAME= ‘SecurityID’SPVAL 0-16 characters





Date: 5/6/23




RecipeXIDList ObjectActionParameterRequest


SPNAME= ‘RecipeXIDList’SPVAL L, n 1.L,5 1. RecipeID1

2. VersionID1

3. SecurityID1

4. TypeID1

5. EquipmentID1

: n.L,5 1. RecipeIDn

2. VersionIDn

3. SecutiryIDn

4. TypeIDn

5. EquipmentIDn

RecipeID=RCPSPEC or PPID.VersionID 0-256 charactersSecurityIDn

L,2 1. ‘SecurityID’ 2. SecurityID 0-16 charactersTypeID 0-16 charactersEquipmentIDn

L,2 1. ‘EquipmentID’ 2. EquipmentID 0-256 characters





Date: 5/6/23




RecipeList ObjectActionParameterRequestObjectActionParameterResult


SPNAME= ‘RecipeList’SPVAL L, n 1.L,6 1. RecipeID1

2. VersionID1

3. SecurityID1

4. TypeID1

5. EquipmentID1

6. RecipeBody1> : n. L,6 n.L,n 1. RecipeIDn

2. VersionIDn

3. SecurityIDn

4. TypeIDn

5. EquipmentIDn

6. RecipeBodyn



L,2 1. ‘EquipmentID’ 2. EquipmentID 0-256 charactersRecipeBody User defined

CheckInformation ObjectActionParameterRequest


SPNAME= ‘CheckInformation’SPVAL User defined

Pre-ExeCheckResult ObjectActionParameterRequest


SPNAME= ‘Pre-ExeCheckResult’SPVAL [51] 0=OK 1=NG





Date: 5/6/23




SetSRSSwitchResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘SetSRSSwitchResp’SPVAL [51] 0=OK 1=NG

SetPEMFlagResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘SetPEMFlagResp’SPVAL [51] 0=OK 1=NG

ClearClassResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘ClearClassResp’SPVAL [51] 0=OK 1=NG

DeleteRecipeResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘DeleeteRecipeResp’SPVAL [51] 0=OK 1=NG





Date: 5/6/23




WriteRecipeResp List ofObjectActionParameterResult

List of RecipeTransferResult List of EachRecipeTransfer

L,2 1.L,2 1.<SPNAME> 2. <SPVAL> 2.L,n 1.L,2 1.<SPNAME1> 2.<SPVAL1> : n.L,2 1.<SPNAMEn> 2.<SPVALn>

SPNAME=‘RecipeTransferResult’SPNAMEn=‘EachRecipeTransfer’SPVAL [51] 0=Done 1=Error 2=FullSPVALn [51] 0=OK 1=NG

RecipeCheckNotifResp List of ObjectActionParameterResult

L,n 1.L,2 1.<SPNAME1> 2. <SPVAL1> : n.L,2 1.<SPNAMEn> 2. <SPVALn>

SPNAMEn= ‘EachRecipeCheck’SPVALn [51] 0=OK 1=NG

GetRecipeXIDListResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘GetREcipeXIDListResp’SPVAL [51] 0=OK 1=NG





Date: 5/6/23




ReadRecipeResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘ReadRecipeResp’SPVAL [51] 0=OK 1=NG

PreSpecifyRecipeResp

ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘PreSpecifyRecipeResp’SPVAL [51] 0=OK 1=NG

PresetRecipeXIDResp


SPNAME= ‘PresetREcipeXIDResp’SPVAL [51] 0=OK 1=NG





Date: 5/6/23




Pre-ExeCheckResp List of ObjectActionParameterResult

List of Pre-ExeCheckResultAck WriteRecipeResp

i.e.List of 1.Pre-ExeCheckResultAck 2.List of 1.RecipeTransferResult 2.List of EachRecipeTransfer

L,2 1.L,2 1.<SPNAMEa> 2. <SPVALa> 2.L,2 1.L,2 1.<SPNAMEb> 2. <SPVALb> 2.L,n 1.L,2 1.<SPNAME1> 2.<SPVAL1> : n.L,2 1.<SPNAMEn> 2.<SPVALn>

SPNAMEa=‘Pre-ExeCheckResultAck’SPNAMEb=‘RecipeTransferResult’SPNAMEn=‘EachRecipeTransfer’SPVALa,SPVALn [51] 0=OK 1=NGSPVALb [51] 0=Done 2=Full 5=Error

QueryRecipeXIDListResp


SPNAME= ‘QueryRecipeXIDListResp’SPVAL [51] 0=OK 1=NG

RecipeTransferResult ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘RecipeTransferResult’SPVAL [51] 0=OK 1=NG





Date: 5/6/23




EachRecipeTransfer ObjectActionParameterResult 1.L,2 1.<SPNAME> 2.<SPVAL>

SPNAME=‘EachRecipeTransfer’SPVAL [51] 0=Done 2=Full 5=Error

EachRecipeCheck ObjectActionParameterResult 1.L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘EachRecipeCheck’SPVAL [51] 0=OK 1=NG

Pre-ExeCheckResultAck ObjectActionParameterResult 1.L,2 1.<SPNAMEa> 2. <SPVAL>

SPNAMEa=‘Pre-ExeCheckResultAck’SPVAL [51] 0=Done 1=NG

--- ObjectActionStatus SVCACK 0=Acknowledge, service has been performed 1=Service does not exist 2=Cannot perform now 3=At least parameter is invalid 4=Acknowledge, service will be performed with completion notified later with parameters for response 5=Service is not completed or prohibited 6=No such object exists

L,2 1.<SVCACK> 2.Status

SVCACK [51]





Date: 5/6/23




--- Status L,n 1.L,2 1.<ERRCODE1> 2.<ERRTEXT1> : n.L,2 1.<ERRCODEn> 2.<ERRTEXTn>

ERRCODE [5( )]ERRTEXT [20]

--- ObjectLinkID LINKID [54]

20 Mapping of PRCOBJ Services

Table 3 PRCOBJ Service Messages Mapping

PRCOBJ Service Message Name E39 Object Service Message Name


SetPRCAttributes ObjectAction S14F19,F20 Generic Service Request/AcknowledgeGetPRCAttributes GetAttr S14F1,F2 GetAttr Request/GetAttr Data

21 Mapping of PRCOBJ Parameter


PRCOBJ Service Parameter



--- OperationID OPID [5( )]--- ObjSpec OBJSPEC [20]--- ObjectAction ‘SetPRCAttributes’ SVCNAME [20]ObjID for GetPRCAttributes


ObjID forSetPRCAttributes




PRCSwitch ObjectActionParameterRequest


SPNAME= ‘PRCSwitch’SPVAL [51] 0=Disabled 1=Enabled





Date: 5/6/23




AutoClear ObjectActionParameterRequest


SPNAME= ‘AutoClear’SPVAL [51] 0=Disabled 1=Enabled

MaxNumber ObjectActionParameterRequest


SPNAME= ‘MaxNumber’SPVAL L, n 1. <MaxNumber1> : n. <MaxNumbern>MaxNumbern [51] ‘n’ = n recipes are allowed

MaxTime ObjectActionParameterRequest


SPNAME= ‘MaxTime’SPVAL [51] 0=Maximum Time function is not used 1 or more = Maximum Time

PRCPre-ExeCheck ObjectActionParameterRequest


SPNAME= ‘PRCPre-ExeCheck AutoClear’SPVAL [51] 0=Disabled 1=Enabled

SetPRCAttributesResp

ObjectActionParameterResult 1.L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘SetPRCAttributesResp’SPVAL [51] 0=Done 1=Error





Date: 5/6/23






SVCACK [51]




22 Mapping of RACOBJ Services

Table 5 RACOBJ Service Messages Mapping

RACOBJ Service Message Name E39 Object Service Message Name


SetRACAttributes ObjectAction S14F19,F20 Generic Service Request/AcknowledgeGetRACAttributes GetAttr S14F1,F2 GetAttr Request/GetAttr DataOpenRemoteAccess ObjectAction S14F19,F20 Generic Service Request/AcknowledgeCloseRemoteAccess ObjectAction S14F19,F20 Generic Service Request/Acknowledge





Date: 5/6/23

23 Mapping of RACOBJ Parameter


RACOBJ Service Parameter



--- OperationID OPID [5( )]--- ObjSpec OBJSPEC [20]--- ObjectAction ‘SetRACAttributes’

‘OpenRemoteAccess’‘CloseRemoteAccess’

SVCNAME [20]

ObjID for GetRACAttributes


ObjID forother services




RACSwitch ObjectActionParameterRequest


SPNAME= ‘RACSwitch’SPVAL [51] 0=Disabled 1=Enabled

AutoClose ObjectActionParameterRequest


SPNAME= ‘AutoClese’SPVAL [5()] 0=AutoClose function is not used (default) >0 Maximum time

OperatorID ObjectActionParameterRequest


SPNAME= ‘OperatorID’SPVAL 0-32 characters

OperatorPassword ObjectActionParameterRequest


SPNAME= ‘OperatorPassword’SPVAL 0-16 characters





Date: 5/6/23




SecurityID ObjectActionParameterRequest


SPNAME= ‘SecurityID’SPVAL 0-16 characters

EquipmentID ObjectActionParameterRequest


SPNAME= ‘EquipmentID’SPVAL 0-256 characters

SetRACAttributesResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘SetRACAttributeResp’SPVAL [51] 0=Done 1=Error

OpenRemoteAccessResp ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘OpenRemoteAccessResp’SPVAL [51] 0=OK 1=NG

CloseStatus ObjectActionParameterResult L,2 1.<SPNAME> 2. <SPVAL>

SPNAME= ‘CloseStatus’SPVAL [51] 0=Normal 1=AutoClose 2=Error

CloseRemoteAccessResp


SPNAME= ‘CloseRemoteAccessResp’SPVAL [51] 0=OK 1=NG





Date: 5/6/23






SVCACK [51]




24 Mapping of Variable Data Item24.1 Table 5 shows the specific SECS-II data classes, and formats needed for SECS-II implementations of SEMI E170 variable data items.





Date: 5/6/23

Table 7 Variable Data Item Mapping

Variable Name Class Format

RecipeXIDList DVVAL L,2 1. ‘RecipeXIDList’ 2., n 1.L,5 1. [20]RecipeID1

2. [20]VersionID1

3. SecurityID1

4. [20]TypeID1

5. EquipmentID1

: n.L,5 1. [20]RecipeIDn

2. [20]VersionIDn

3. SecurityIDn

4. [20]TypeIDn

5. EquipmentIDn



L,2 1. ‘EquipmentID’ 2 EquipmentID 0-256 characters





Date: 5/6/23

Variable Name Class Format

RecipeList L,2 1. ‘RecipeList’ 2.L, n 1.L,6 1. RecipeID1

2. VersionID1

3. SecurityID1

4. TypeID1

5. EquipmentID1

6. RecipeBody1> : n. L,6 1. RecipeIDn

2. VersionIDn

3. SecurityIDn

4. TypeIDn

5. EquipmentIDn

6. RecipeBodyn

RecipeID=RCPSPEC or PPID.VersionID 0-256 charactersSecurityIDn L,2 1. ‘SecurityID’ 2. SecurityID 0-16 charactersTypeID 0-16 charactersEquipmentID L,2 1. ‘EquipmentID’ 2 EquipmentID 0-256 charactersRecipeBody User defined

RecipeID DVVAL [20]VersionID DVVAL [20]SecurityID DVVAL L,2

1.[20]=’SecurityID’ 2.[20]





Date: 5/6/23

25 SECS-II Attribute Definitions25.1 SRS Object SECS-II Attributes Definitions — The following table defines the SECS-II structure for SRSOBJ object of SEMI E170.

Table 8 SRSOBJ SECS-II Attribute Definitions

Attribute Name Attribute Data Form: SECS-II Structure

ObjID [20] <OBID> (Conforms to the restrictions of ObjID as specified in SEMI E39.1, § 6.)ObjType [20] ‘SRSObject’SRSSwitch [51]

SRSSwitch is enumerated as follows:0=Disabled1=Enabled

SecurityClassList L,n 1. [20] SecurityClass1

: n. [20] SecurityClassn

PEMFlagList L,n 1. [20] PEMFlag1

: n. [20] PEMFlagn

QueryStat L,2 1. ‘RecipeXIDList’ 2., n 1.L,5 1. [20]RecipeID1

2. [20]VersionID1

3. SecurityID1

4. [20]TypeID1

5. EquipmentID1

: n.L,5 1. [20]RecipeIDn

2. [20]VersionIDn

3. SecurityIDn

4. [20]TypeIDn

5. EquipmentIDn

n=0 indicates no QueryRecipe takes place

SecurityIDn

L,2 1. ‘SecurityID’ 2. SecurityIDEquipmentIDn

L,2 1. ‘EquipmentID’ 2 EquipmentID





Date: 5/6/23


Pre-ExeCheckStat L, n 1.L,6 1. [20] RecipeID1

2. [20] VersionID1

3. SecurityID1

4. [20] TypeID1

5. EquipmentID1

6. [20] CheckInformation1

: n.L,6 1. [20] RecipeIDn

2. [20] VersionIDn

3. SecurityIDn

4. [20] TypeIDn

5. EquipmentIDn

6. [20] CheckInformationn

n=0 indicates no PreExeCheckStat takes place

SecurityIDn

L,2 1. ‘SecurityID’ 2. SecurityIDEquipmentIDn

L,2 1. ‘EquipmentID’ 2 EquipmentID

25.2 PRC Object SECS-II Attributes Definitions — The following table defines the SECS-II structure for PRCOBJ object of SEMI E170.

Table 9 PRCOBJ SECS-II Attribute Definitions


ObjID [20] <OBID> (Conforms to the restrictions of ObjID as specified in SEMI E39.1, § 6.)ObjType [20] ‘PRCObject’PRCSwitch [51]

PRCSwitch is enumerated as follows:0=Disabled1=Enabled

AutoClear [51]AutoClear is enumerated as follows:0=Disabled1=Enabled

MaxNumber L,n 1. [51] MaxNumber1

: n. [51] MaxNumbern





Date: 5/6/23


MaxTime [5()]0=Maximum Time function is not used>0 Maximum time

PRCPre-ExeCheck [51]PRCPre-ExeCheck is enumerated as follows:0=Disabled1=Enabled

Table 10 RACOBJ SECS-II Attribute Definitions


ObjID [20] <OBID> (Conforms to the restrictions of ObjID as specified in SEMI E39.1, § 6.) ObjType [20] ‘RACObject’RACSwitch [51]

RACSwitch is enumerated as follows:0=Disabled1=Enabled

AutoClose [51]AutoClear is enumerated as follows:0=AutoClose function is not used (Default)>1 Maximum time

OperatorID [20] Maximum 32 charactersOperatorPassword [20] Maximum 16 charactersCloseStatus [51]

CloseStatus is enumerated as follows:0=Normal1=AutoClosed2=Error

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.


