semi合集-English.pdf - 第3614页

SEMI E139-0705 © SEMI 2005 38 RELATED INFORMATION 1 NOTICE : This rel ated infor mation is not an official pa rt of SEMI E139 and was derived from North American Information and Control Committee. This r elated informati…

SEMI E139-0705 © SEMI 2005 37

Table 28 RaP Compliance Table

RaPnode Type: EquipmentNode  EditorNode  FICSnode 

Section Topic RaP Compliant

PDE Content

8.3 PDE Class Diagram



8.3.1.1 PDE Class



8.3.2 PDEheader Class



8.3.3 AntecedentData Class



8.3.4 ReferencedPDE Class



8.3.5 ExecutionTarget Class



8.3.6 PDEparameter Class



8.3.7 PDEbody Class



8.3.8 PDEbodyReference Class



RaPnode Requirements

8.5.2 General RaPnode Requirements



8.5.3 FICSnode Requirements



8.5.4 EquipmentNode Requirements



8.5.5 EditorNode Requirements



RaP Services Requirements

8.4.2.1 RaPnodes



8.4.2.2 Required Services Per Node Compliance represented in service compliance below.

8.4.2.3 Service Message Parameters

Compliance noted below for each service using these

parameters.

8.4.2.5 getPDEdirectory()



8.4.2.6 deletePDE()



8.4.2.7 getPDEheader()



8.4.2.8 getPDE()



8.4.2.9 requestToSendPDE()



8.4.2.10 sendPDE()



8.4.2.11 resolvePDE()



8.4.2.12 verifyPDE()



8.4.2.13 TransferContainer



10 Related Documents

Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide,

Reading

Massachusetts, Addison Wesley: 1999 ISBN 0-201-57168-4.

Rivest, Ronald, The MD5 Message-Digest Algorithm,

IETF RFC: 1992 http://www.ietf.org/rfc/rfc1321.txt.

Uniform Resource Name (URN) Syntax, IETF RFC 2141, May 1997

http://www.ietf.org/rfc/rfc2141.txt.

SEMI E139-0705 © SEMI 2005 38

RELATED INFORMATION 1

NOTICE: This related information is not an official part of SEMI E139 and was derived from North American

Information and Control Committee. This related information was approved for publication by full letter ballot on

December 10, 2004.

R1-1 Scenarios

R1-1.1 This section contains example scenarios to illustrate how RaP services might be used in practice. They

represent only a subset of possible scenarios. The purpose of including these scenarios is to demonstrate how the

RaP services can work together to perform complex tasks.

R1-1.1.1 For these scenarios, certain assumptions were needed about how business rules of the FICS and about the

outcome of certain services. These assumptions are stated. The FICS business rules are not intended to represent

actual factory systems. Instead, they are designed to demonstrate possible combinations of services to perform a

task. RaP is intended to work with a wide range of FICS business rules. It is not possible to demonstrate all

situations.

R1-1.1.2 Assumptions for all scenarios: (unless otherwise noted in the individual scenario)

 Equipment, Editor, and FICS nodes are separate nodes that communicate via RaP services (note that Equipment

to Editor communications are not required to use RaP services).

 The "User" entity represents any source of stimulus, human or electronic.

 All message receive positive or "success" (response unless otherwise noted).

 The provided scenarios may not be the only way to accomplish each task. This set is not meant to be

exhaustive.

 Response messages are not shown unless they add information for the reader.

R1-2 Scenario – Download PDEs

R1-2.1 This scenario is representative of most uses of the sendPDE() service.

R1-2.1.1 Assumptions:

 The PDEs to be downloaded are not currently stored on the equipment.

Ed it o r FICSEquipmentUser

Create TransportContainer

requestToSendPDE()

sendPDE()

sendPDE()- rsp

Verify is automatic

with

verifyType=validity,

verifyDepth=single

Dow nload Unrelated PDE's

Unpack TransportContainer

Verify All New PDE's

Figure R1-1

R1-2.1.1.2 Notes:

 The EquipmentNode is the only one required to validate upon receipt of a TransportContainer. Transfer to FICS

or to Editor would be similar, but with the internal Verify step left off.

 Whether the PDEs are related (e.g. same recipe) or not does not affect this scenario. If all PDEs for a recipe are

available, a subsequent scenario to validate the full recipe can be executed.

R1-3 Scenario – Upload Selected PDEs

R1-3.1 This scenario is representative of most uses of the getPDE() service.

R1-3.1.1 Assumptions:

 The equipment stores some PDEs. It may or may not be the “System of Record”.

 The user is searching for particular PDEs, based on some unspecified criteria that is beyond what can be

returned in getPDEdirectory().

 Once the PDEs are identified, they are to be uploaded to the FICS.

PDEe ditor FICSEq u i p m e n tUs er

getPDEdirectory()

Upload Selected PDE's

Select subset of PDE's

getPDEheader()

Select subset of PDE's

getPDE()

getPDE() rsp

Create TransportContainer

Figure R1-2

R1-3.1.1.2 Notes:

 The getPDEdirectory() service is used to get a complete list of PDEs available.

 The getPDEheader() service is used to get detailed information about a subset of the PDEs available.

 The final PDEs uploaded are selected based on the PDEheader information.

R1-4 Scenario – Delete Selected PDEs

R1-4.1 This is a common usage of the deletePDE() service, but does not assume pre-knowledge of which PDEs are

actually on the equipment.

R1-4.1.1 Assumptions:

 The user knows which PDEs should be on the equipment. So he/she needs to see a list of PDEs actually on the

equipment and will delete those that are not needed.