semi合集-English.pdf - 第3619页

SEMI E139-0705 © SEMI 2005 43  The getPDEdirectory() servi ce is used to get further i nformat ion about the new PDE found in the outputM ap of the resolvePDE() service. Alternately, the get PDEheader() service coul d h…

SEMI E139-0705 © SEMI 2005 42

R1-6.1.1.2 Notes:

 The getPDEdirectory() service is used to determine what PDEs are on the equipment.

 The FICS accesses the recipe management system to obtain the list of “needed PDEs” This is compared with

the PDE directory to determine which, if any, are needed.

 The TransferContainer contains only the PDE not currently on the equipment.

 The verifyPDE() service refers to the Master PDE for the intended process job and has verifyType = Checksum

and verifyDepth = All. A full inputMap is supplied.

 The PDEmap is used as the inputMap for the verifyPDE() service.

 In this scenario, the “requestToSendPDE()” message is omitted. Its use is at the option of the client to ensure a

PDE download will not be rejected.

R1-7 Scenario – Preparation for Processing (2)

R1-7.1 This scenario is intended to represent some aspects of early stage recipe management where recipes are

stored on the equipment and central control and tracking is not available.

R1-7.1.1 Assumptions:

 PDEs are created at the equipment, which serves as the system of record.

 The business practice of the FICS is that the latest version of each PDE available on the equipment should

always be used. For that reason, PDEs are referenced by gid and the equipment always resolves these gids.

 The FICS records which PDEs were last used with each Master PDE. It detects when the current set differs

from the previous execution of this Master PDE and seeks confirmation from the user that the change is

appropriate.

 All PDEs used the last time that this Master PDE

was executed are on the equipment.

 The user has updated one PDE that must now be used in place of an older version.

 The equipment follows the RaP recommendation that an equipment perform a verification of the full recipe

before executing. Therefore, such verification is not necessary in this scenario.

 A Process Job will soon use this newly verified Master PDE.

Ed it o r FICSEquipmentUser

Request Confirmation For Use Of New PDE

Prepare For Run

Compare With Previous Run

getPDEdirectory()

resolvePDE()

Confirm Use of New PDE

Figure R1-6

R1-7.1.1.2 Notes:

 The Master PDE is specified as the targetPDE in the resolvePDE() message.

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)

 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

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.