semi合集-English.pdf - 第3616页

SEMI E139-0705 © SEMI 2005 40 Ed i t o r FI C S E q ui pm e nt Us e r ge tP D E di r e ctory() D is p lay PD E L is t de lete P D E () D e le t e Se le ct e d PD E ' s D is p lay PD E lis t Figure R1-3 R1-4.1.1 .2 N…

100%1 / 7923
SEMI E139-0705 © SEMI 2005 39
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.
SEMI E139-0705 © SEMI 2005 40
Ed it o r FICSEquipmentUs e r
getPDEdirectory()
Display PDE List
deletePDE()
Delete Selected PDE's
Display PDE list
Figure R1-3
R1-4.1.1.2 Notes:
The getPDEdirectory() service can return basic information about the PDEs, including name, uid, description,
createDate, etc. as needed to support the identification of PDEs.
Systems that track which recipes are on the equipment may not need to request a directory listing. Such
tracking is possible by monitoring the event reports when the recipe collection changes and checking the status
variable that notes the last time the recipe collection changed.
R1-5 Scenario – Create PDE
R1-5.1 There are many different ways to approach this scenario. This is just one of those ways. It is intended to
demonstrate most of the services that might be used.
R1-5.1.1 Assumptions:
The equipment is the “system of record” for PDEs in this example.
This PDE is created based on an existing PDE that is stored on the equipment.
PDEeditor FICSEquipmentUs e r
getPDEdirectory()
Create A New PDE
getPDE()
sendPDE()
Select Base PDE
Perform Editing
Figure R1-4
R1-5.1.1.2 Notes:
If the existing & resulting PDEs were stored by the FICS, the scenario would be similar (replace Equipment
with FICS).
SEMI E139-0705 © SEMI 2005 41
“Editing” a PDE is the same as creating a new PDE, since each new version must be given a new unique
identifier.
The PDEeditor is responsible for verification of the new PDE. Resolution of verification issues is between
PDEeditor and User.
R1-6 Scenario – Preparation for Processing (1)
R1-6.1 This scenario represents a central recipe management system with off-tool system of record.
R1-6.1.1 Assumptions:
The equipment is configured to never resolve gid references in recipes. The host must/will supply all needed
resolutions.
The FICS (per its Recipe Management System) knows exactly which PDEs should be used in any processing
situation.
All PDEs used the last time that this process was run are on the equipment.
The user has updated one PDE that must replace an older version; this PDE and its uses are managed by an
FICS-level recipe management system.
The automatic verification of the downloaded PDE is assumed to succeed.
While RaP recommends that an equipment perform a verification of the full recipe before executing it, this
equipment does not perform that task.
A Process Job will soon use this newly verified Master PDE.
Ed it o r FICSEquipment
User
sendPDE()
Prepare For Run
Identify Needed PDE's
and Create PDEmap
Create TransferContainer
verifyPDE()
getPDEdirectory()
verifyPDE() - rsp
Check Status
Unpack TransportContainer
and Verify New PDE
Confirm Presence of
Needed PDE's
Get Missing PDE
sendPDE()- rsp
Verify PDE's
Figure R1-5