semi合集-English.pdf - 第3617页

SEMI E139-0705 © SEMI 2005 41  “Editing” a PDE is the same as creating a new PDE , since each new version must be gi ven a new unique identifier.  The PDEeditor is responsible for verification of the ne w PDE . R esolu…

100%1 / 7923
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
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.