semi合集-English.pdf - 第3620页
SEMI E139-0705 © SEMI 2005 44 RELATED INFORMATION 2 NOTICE : This rel ated inform ation is not a n official part of SEMI E139 and was derived from t he North Am erican Information and Control Committee. This r elated inf…
SEMI E139-0705 © SEMI 2005 43
The getPDEdirectory() service is used to get further information about the new PDE found in the outputMap of
the resolvePDE() service. Alternately, the getPDEheader() service could have been used if more detailed
information were required.
SEMI E139-0705 © SEMI 2005 44
RELATED INFORMATION 2
NOTICE: This related information is not an official part of SEMI E139 and was derived from the North American
Information and Control Committee. This related information was approved for publication by full letter ballot on
December 10, 2004.
R2-1 Implementation Suggestions
R2-1.1 This related information is included to supplement the specification with some suggestions about the use of
RaP and its capabilities. Its purpose is a) to promote more uniform application of RaP and b) to share some insights
of the creators of RaP that may lead to improved results from its use.
R2-2 Combining RaPnodes
R2-2.1 ¶8.5.2.3 mentions the possibility of combining RaPnodes. This section will briefly discuss this topic to
outline when and why this might be appropriate.
R2-2.1.1 In general, when multiple nodes are combined, efficiency can be gained by:
Coding the individual services only once (since most are common to all RaPnodes)
6
.
Sharing the computing platform where the software is run.
Eliminating the communication between the two separate RaPnodes by designing them to be a single entity.
R2-2.1.1.1 Not all RapNode combinations are practical. In particular, the combination of EquipmentNode with
FICSnode is not commercially feasible due to the many different suppliers’ equipment that must communicate with
one FICS. The other two combinations may be useful in the some situations.
R2-2.1.1.2 Combining the EquipmentNode and the EditorNode mirrors the traditional equipment “on-tool” editing
capability. This approach might provide the easiest transition to RaP for some equipment suppliers. It also ensures
that the equipment will function “out of the box” without integration. Since multiple PDEeditors are allowed, the
“off-tool” version could be provided later or as an add-on.
R2-2.1.1.3 The combination of FICSnode with EditorNode might represent the integration of an off-tool editor with
an off-tool recipe management capability. In the long term, there might be a movement to general PDEeditors that
are compatible with many suppliers’ equipment recipes. Integrating a recipe management capability with that
general editor would be a logical next step.
R2-2.1.1.4 If the implementation for messaging is SECS-II only, then any equipment with an on-tool editor must
combine the EquipmentNode and EditorNode. This is necessary since multiple SECS-II sessions are not well
supported.
R2-2.1.1.5 When two RaPnodes are combined, they are expected to act as a single entity with a union of the
capabilities of the two types of RaPnodes. The combined RaPnodes are expected to share resources, including the
recipe storage area. Messages to the combined RaPnodes will not differentiate which node type is being addressed.
R2-3 RaP Support For SEMI E40 and SEMI E30
R2-3.1 RaP can be used in conjunction with SEMI E40 Process Job Management or with SEMI E30 GEM. This
section discusses how to map the key recipe-related parameters from those two standards to the RaP attributes. In
both cases, the management of the recipes uses RaP services. This section discusses how the recipe is specified for
the processing activity and how the Variable Parameters are communicated.
R2-3.2 In SEMI E40, recipe information is specified as part of the job specification in the Stream 16 messages as
RCPSPEC (recipe identifier - text) and RCPPARNM (recipe variable name - text). To satisfy RCPSPEC, a RaP
implementation should supply the identifier (uid or gid) of the Master PDE.
R2-3.3 The Variable Parameters defined in RaP were intended to correspond directly with the RecipeVariables
7
defined in SEMI E40. The PDEparameters of the Master PDE should be mapped directly to RecipeVariables. The
6 Note that even if the RaPnodes are not combined, a single body of code could be created, with internal switches to enable the proper services
for the particular type of RapNode.
SEMI E139-0705 © SEMI 2005 45
RaP PDEparameter class includes a name attribute. This name value can be supplied in the Steam 16 messages as
the value of an RCPPARNM parameter.
R2-3.4 Support for SEMI E30 works differently. In this case, there is no concept of a process job. Instead, it is a
two step process: 1) the recipe is “selected” for execution, and then 2) a START command is given to begin
execution. Both of these requests are made using the S2,F49 message (Enhanced Remote Command – see SEMI
E5). The Remote Command message accepts parameter values (called CEPVAL’s). Each CEPVAL has a
corresponding identifier called CPNAME.
R2-3.5 In the first step, the RCMD (remote command) is RCP-SELECT. The identifier of the recipe is contained
in a CEPVAL. The uid (or gid) of the Master PDE is supplied as the CEPVAL to identify the recipe. The supplier
determines the CPNAME of this parameter.
R2-3.6 In the second step, the S2,F49 message requests the START remote command. In this message, the
CEPVAL’s contain parameters that apply to the activity. The equipment may have some pre-defined parameters.
The PDEparameter values may also be specified here as CEPVAL’s. The name of the PDEparameter should be
specified as the CPNAME.
R2-4 Factory Assigned Recipe Attributes
R2-4.1 Some factory systems track various attributes of specifications within their factory. Recipes are one type of
specification and often have important attributes associated with them. For example, a recipe may need to undergo
certain tests before it is qualified to use in production. Also, there may be some sort of management sign-off
process. These and other such attributes are used by the factory to help determine what recipe can be run in a given
situation.
R2-4.2 The definition of recipe management practices of the factory is beyond the scope of RaP. However, a place
has been provided within the PDEheader for the factory to store (and later retrieve) such information. The userInfo
attribute provides a list of text strings that the factory can use for this purpose.
R2-4.3 Any attribute that can be represented as a text string can be included. Using common text formatting
approaches (for example, comma separated values), both simple and complex attributes can be stored. For example,
one userInfo field might contain a name/value pair something like this: “Approved, True”.
R2-4.4 It is expected that the userInfo will not be used for very large data structures, such as photographic images.
An attempt to include data much larger than the original PDE might cause unexpected results.
R2-4.5 Since the equipment will not try to interpret these values and undocumented changes to the recipe are not
possible, this provides a secure place to store these values.
R2-4.5.1 Some examples of userInfo strings include:
Comment — The user can enter a detailed explanation of the need for this PDE, the conditions that led to its
creation, etc. This can help when transfer of duties to a new engineer occurs.
Approval Level — is the recipe approved for use?; what use is it approved for?
Version — what version number will the host assign to this PDE for tracking purposes?
Classification — there are many ways to classify recipe components – the factory area of use, which step in the
process, which process (or process version), etc.
R2-5 Supplier Assigned Recipe Attributes
R2-5.1 The equipment supplier may need to provide information about each PDE that is not standardized. The
supplierInfo attribute is provided to allow the supplier to include this information. The format is the same as for
userInfo – a list of text strings.
7 SEMI E40 also uses the term “Recipe Variable Parameters” to refer to RecipeVariables.