semi合集-English.pdf - 第3585页

SEMI E139-0705 © SEMI 2005 9 execute. These are the recipes that RaP proposes to m ana ge. RaP does not require use of or compliance with SEMI E120. However, if SEMI E120 compliance exists, th en th e source Equip mentEl…

SEMI E139-0705 © SEMI 2005 8

7 Overview of RaP

7.1 The RaP specification is focused on the definition, management, and transfer of equipment recipes. In RaP, the

recipe components are called ProcessDefinitionElements

or PDEs. This section describes the high level view of the

concepts and the requirements that contribute to meet the purpose of this specification as described in §1.

7.2 This RaP overview makes reference to requirements defined later in the document. However, no statement in

this overview section defines a requirement. This overview is intended to provide a general understanding of the

RaP concepts so that the detailed requirements that follow can be more easily understood.

7.3 RaP Participants

7.4 RaP assumes that there are three participants in the management of recipes – the FICS, the Equipment, and the

PDEeditor. When these provide RaP services, they become “RaPnodes” – the FICS becomes an FICSnode, the

Equipment becomes an EquipmentNode, and the PDEeditor becomes an EditorNode.

7.5 These three participants must work together to achieve the goals of recipe management. They may exist as

independent entities using defined message services (RaPnodes) or may be combined in some cases (as the editor is

often integrated into the equipment). Since integrated modules need no standardized communications, RaP defines

the services and data needed for these participants to exist independently as shown in Figure 2.

Equipment

Node

Equipment

Node

Editor

Node

Editor

Node

Equipment

Node

Editor

Node

FICS

Node

Equipment

Node

Equipment

Node

Editor

Node

Editor

Node

Equipment

Node

Editor

Node

FICS

Node

Figure 2

RaPnodes

7.6 RaP Environment

7.6.1 In discussing recipe management, one can divide the topic into three logically separate activities:

 Execution of recipes

 Creation and editing of recipes

 Tracking and storage of recipes

7.6.2 RaP does not specify exactly how to perform any of these three activities. However, these activities define the

context in which RaP defined services and concepts are to be applied. The recipes themselves must reflect certain

aspects of these activities.

7.7 Execution of Recipes

7.7.1 When an activity is performed on an equipment, that activity must be fully specified in order for execution to

occur. RaP describes the main specification (recipe) and also parameters that can be set to amend the recipe. It does

not define the process for execution of the recipe.

7.7.2 RaP assumes that the equipment or some component of the equipment represents the target for the execution

of a recipe. In this document, that target is referred to as a Process Module. RaP assumes that there is a way to

identify a Process Module and that certain characteristics of that Process Module are known to the factory (make,

model, supplier, etc.).

7.7.3 RaP is compatible with SEMI E120. In terms of SEMI E120, the Process Module corresponds to the

“AbstractModule” class. The AbstractModule class models parts of the equipment structure capable of processing

material. Its attributes include “recipeType” which specifies the type of recipes that the AbstractModule can

SEMI E139-0705 © SEMI 2005 9

execute. These are the recipes that RaP proposes to manage. RaP does not require use of or compliance with SEMI

E120. However, if SEMI E120 compliance exists, then the source EquipmentElement of much of the RaP related

data (both input and output) would be more explicitly identified.

7.7.4 From the FICS point of view, enough must be known about the recipe so that it can select the correct one for

each situation (combination of machine, substrate, process step, etc.).

7.8 Creation and Editing of Recipes

7.8.1 RaP considers creation and editing of recipes to be an independent concept. This means that the editing

capability can reside on the equipment, within the factory system, as a separate entity independent of both, or in

combinations of all of these. There are advantages and disadvantages to each and these will change over time.

Therefore, RaP makes no requirement on where the PDEeditor must reside.

7.9 Tracking and Storage of Recipes

7.9.1 Storage of at least some recipes on the equipment is necessary to support processing. Storage of recipes at the

PDEeditor is also necessary, for example, to support creation of multi-part recipes. Most factories would also be

expected to store a copy of most recipes for safekeeping. So all participants in recipe management might reasonably

be expected to store at least some recipes.

7.9.2 RaP also makes available characteristics of the recipes that support tracking and validation (id, checksum,

creation date, etc.).

7.10 Communication Overview

7.10.1 RaP is focused on the communications among the three “RaPnodes” defined above: FICSnode,

EquipmentNode, and EditorNode. There are three types of functions that can be performed via a RaP interface:

 Transfer PDEs — request PDEs from or send PDEs to a node.

 Manage PDEs — obtain information about the PDEs on a node and delete them when desired.

 Verify — determine which PDEs are needed for a job and check that all are present and well-formed.

7.10.2 These three categories represent the eight services defined by RaP. Detailed definition of the communication

services is provided in ¶8.4. That section also defines which RaPnodes must support which of these functions. ¶8.5

defines additional requirements on the RaPnodes.

7.11 Key Recipe Concepts

7.11.1 In order to fulfill its purpose, RaP must provide more than simple recipe transfer services. This section

describes key concepts used in this specification to enhance the basic functions above to yield a robust “Recipe and

Parameter Management” capability.

7.12 ProcessDefinitionElement

7.12.1 A recipe can be a single component or it can be made up of multiple components. The components of a

recipe are called ProcessDefinitionElements or PDEs. The PDE is the central artifact of RaP. This section

describes the PDE.

7.12.1.1 PDE –Two Parts

7.12.1.1.1 One barrier to automation of recipe handling is the opaque nature of the contents. For several reasons,

suppliers have been reluctant to allow the user (and thus the automation system) visibility to the recipe contents.

RaP addresses that problem by dividing the recipe component (or now, PDE) into two parts: documentation and

executable. This is illustrated in Figure 3.

7.12.1.1.2 The documentation part of the PDE includes the PDEheader. This part is always public and available to

the user. The PDEheader contains such information as the name, description, and author of the PDE as well as its

antecedents (PDEs upon which this one was based) and the Process Module(s) for which it is intended. More detail

about the PDEheader content can be found in ¶8.3.2.

SEMI E139-0705 © SEMI 2005 10

7.12.1.1.3 The second part of the PDE contains the settings and executable instructions. The format of the

PDEbody is not specified and is allowed to be private (that is, proprietary and opaque). Note that during job

execution, the equipment relies upon the content of the PDEbody, not the PDEheader.

PDE

• Checksum

PDEheader

<<Documentation Part>>

• Name

• Identifier

• Group ID

• Description

• Author

PDEbody

<<Executable Part>>

Content is not specified

and may be ke pt private

• Target Equipment

• Antecedents

• PDE References

• Input Parameters

• . . .

PDE

• Checksum

PDEheader

<<Documentation Part>>

• Name

• Identifier

• Group ID

• Description

• Author

PDEbody

<<Executable Part>>

Content is not specified

and may be ke pt private

• Target Equipment

• Antecedents

• PDE References

• Input Parameters

• . . .

Figure 3

PDE Contents

7.12.1.2 Assuring Identity

7.12.1.2.1 An important aspect of the PDEheader information is that it can provide assurance that this PDE is

exactly the one that the factory expects it to be. This is done primarily with two data values: uid and checksum.

The uid is a universally unique identifier that contains a uuid value as defined in the referenced ISO standard (see

¶4.2). Each time a PDE is modified, the uid of that PDE is required to be changed. Therefore, if the uid is matched,

the PDE is guaranteed to be the expected one.

7.12.1.2.2 There are checksum values provided for the PDE as an additional assurance that no changes to the PDE

have occurred. The checksum for a given item is calculated using the MD5 technique defined by the IETF (see

§10). This computed value could be compared with the previously calculated value stored within the PDE to ensure

that no changes have been made.

7.12.1.3 Separate PDEbody

7.12.1.3.1 When the PDEbody is contained within the PDE, it is of the same format

as the PDEheader and its

contents are typically comprehensible to the user. When the PDEbody is opaque to the user or of a format that is not

compatible with the header information, that PDEbody is stored separately from the PDE. This is illustrated in

Figure 4. In this case, the separate PDEbody has its checksum stored in the PDE.

5 The definition of the format of the PDEheader is an implementation issue and will be defined in a subordinate specification to this one.