semi合集-English.pdf - 第2291页

SEMI E81-0600 © 1999, 2 000 28 Task Start Ev ent End Event Sub-Task Sub-Task Sub-Task St art Even t End Event Start Even t End Even t Sta rt Event End Even t Requ est Sub -Req uest Sub - Req uest Sub- Reque st ID: w Spec…

100%1 / 7923
SEMI E81-0600 © 1999, 200027
It does not bury job control into material management
functions for driving process flows, nor does it bury job
control into machine management functions for driving
process operations. The CIM Framework makes job
control explicit, providing an architectural structure to
attach decision support logic (such as scheduling
utilities), business processes (workflow) and business
rules that enforce operational policy. Further, the CIM
Framework distributes and coordinates job control
among factory jobs, production machine jobs, transport
jobs, and maintenance jobs. This allows job control to
manage “local” complexity while coordinating factory-
wide operations toward “global” objectives.
7.3.4.3 Hierarchical Task Structure
7.3.4.3.1 At the lowest level of the factory hierarchy
(the resource level in Figure 7), the tasks are single
process or metrology operations or material
movements. Through a complex, context-dependent
combination of single tasks, products are manufactured
and delivered to customers. This complex combination
of single tasks is a task structure as shown in Figure 11.
In manufacturing operations, these structures are pre-
defined as task procedures, work flows, process
specifications, etc. To accommodate manufacturing
variability and exceptions, though, the structures must
also be adjusted and modified as they are executed. For
example, as factory operations selects specific machine
resources to perform process steps, it may insert
machine-dependent setup tasks and operation
sequences, it may modify step specifications (recipes)
with machine-dependents settings, or it may insert
transport steps to get the material to the machine.
7.3.4.3.2 Notice in Figure 11 that tasks of a higher
level are decomposed into combinations of tasks for
lower level resources. Each manufacturing resource has
a thread of tasks that must be coordinated with the tasks
of other resources. The higher level task is completed
when the combination of lower level tasks is completed.
Figure 11 illustrates this with the coordination of
material movement and processing operations and with
the coordination of operations within the processing
equipment. Resource maintenance, advanced process
control calculations and other tasks must also be
coordinated with material processing, inspection and
movement tasks. The role of job control is to
decompose, coordinate, monitor, adjust, and report on
this hierarchical structure of tasks.
M
a
c
h
i
n
e
R
e
s
o
u
r
c
e
Task: Fill Order
Task: Produce Lot 1
Task: Produce Lot 2 Task: Produce Lot 4
Task: Produce Lot 3
Process
. . .
Move Move
Process
Operations
M
a
c
h
i
n
e
R
e
s
o
u
r
c
e
E
n
t
e
r
p
r
i
s
e
F
a
c
t
o
r
y
Time
Level
T
r
a
n
s
p
o
r
t
. . .
. . .
Resource
Process
Transport Machine
activity thread
Production Machine
activity thread
Machine Resource
activity thread
Figure 11
Hierarchical Task Structure
SEMI E81-0600 © 1999, 2000 28
Task
Start
Event
End
Event
Sub-Task Sub-Task Sub-Task
Start
Event
End
Event
Start
Event
End
Event
Start
Event
End
Event
Request
Sub-RequestSub-
Request
Sub-
Request
ID: w
Spec: x
Inputs: y
Results: z
ID: q
Spec: r
Inputs: s
Results: t
ID:
Spec:
Inputs:
Results:
Task
Specification
ID: a
Spec: b
Inputs: c
Results: d
time: now
Job History
Time
Level
Now
n
n+1
n-1
Figure 12
Elements of a Hierarchical Task
7.3.4.4 Elements of a Task
7.3.4.4.1 The Hierarchical Task Structure of Figure 11
defines the requirements for a multi-level task model.
Figure 12 shows the elements of a hierarchical task,
indicating some of the additional data for an overall job
control structure. A task is requested from a superior
level. Along with the request is a task specification,
which is often a template or procedure for how to carry
out the task, including a combination of subtasks and
monitor and adjustment checkpoints along the way.
7.3.4.4.2 As each task is started, completed, modified
or aborted, the job control for the task publishes
appropriate events or other notifications. The task
endpoints illustrated in Figure 12 as triangles represent
factory states or some specific aspect of a factory state.
When a task is completed, the factory state is changed
in the specified way. For example, after a wafer
deposition task, the product state is changed, with a
layer of oxide deposited on all the wafers in a lot. When
a movement task is completed, the product location
state is changed to the load port for a machine to
perform the next process operation. These intended
factory states often have side effects on other factory
states. For example, after a process operation, the
equipment state changes to reflect its utilization,
consumables consumption, etc. Job control achieves
orderly, coordinated, efficient changes to factory state
that result in products, that is, that efficiently turn raw
wafers into product wafers.
7.3.4.4.3 As the job control executes the task, task
results are collected in a job history that includes a job
identifier, the (modified) specification used, and
recorded inputs and results. Higher level job results
could be a roll-up, an abstraction, or simply pointers to
lower level job results.
7.3.4.5 Job Structure
7.3.4.5.1 A job is a relationship between all the
elements necessary to perform a task with specific
control functionality to carry out the task in light of
manufacturing variability. A job implements a specified
task on specified material using specific resources. The
job structure of Figure 13 is the relationship mechanism
for controlling and changing factory material and
resource states and recording job results in associated
job histories. That is, the job instantiates and manages
the relationships in the structure of Figure 13.
Resources Materials
Job Control
Job Requestor
Requested
Task
Material HistoryJob Control
History
Resource History
Job
Figure 13
Job Structure
SEMI E81-0600 © 1999, 200029
7.3.4.6 Jobs and Job Supervisors
7.3.4.6.1 Jobs are transient entities. They are created to
perform a task and go away when the task is complete.
A job supervisor is the persistent object that responds to
job requests by creating jobs. Figure 14 shows an
information model for the generic Job Supervision
architecture.
7.3.4.6.2 There is a corresponding job supervisor
which specializes the generic job supervisor; a Factory
Job Supervisor manages Factory Jobs; an Area Job
Supervisor manages Area Jobs; and a Production
Machine Job Supervisor manages Production Machine
Jobs. There is also a Maintenance Job Supervisor and
an Advance Process Control job supervisor (the Control
Execution Manager in the Advanced Process Control
component).
Resource
OwnedEntity
Job Requestor
Job Supervisor
1..*
0..*
1..*
0..*
contracts
work
from
Job
1..*
1
1..*
1
tracks
progress
via
0..*0..*
supervises
1
Job Specification
Figure 14
Job Requestors, Job Supervisors, and Jobs
7.3.4.6.3 The entities in Figure 14 are as follows:
• Job.
• A unit of work that takes time and may fail.
• Has state (see Figure 15).
• Job Supervisor.
• Receives requests for work, facilitates creation
of a job for the task and returns a reference to
that job to the requestor.
• Manages all jobs within the component that
implements it.
• Job Requestor.
• Requests work.
• Receives job progress through interface meth-
ods (informJobStarted, informJobCompleted,
informJobTerminated) and published events.
• Job Specification.
• Job description (process flow, recipe, transport
destination, maintenance spec, etc.).
• Priority and deadline.
Queued
Active
Canceled
Finished
Executing
Aborting
Stopping
Aborted
Stopped
Not Paused
Paused
Pausing
Completed
Figure 15
Job State Model (CIMFW)
7.3.4.7 Job Supervision Design Principles
7.3.4.7.1 Jobs and Job Supervision are encapsulated
within a component. Their interaction and the division
of responsibility between them is hidden. At any level,
the requestor of activity will request work of a Job
Supervisor and receive in return the handle to a Job
which represents this work. This requestor will not have
visibility to how the Job Supervisor performs the work
beyond what is specified in the original activity
specification and what is reported later as data. Not
visible or accessible are the Job Supervisor’s internal
and lower-level activity requests (and resulting jobs).
7.3.4.7.2 A job requestor does not micromanage the
job. Instead, the job requestor creates a specification of
the work to be done and hands it to the Job Supervisor
when requesting the work. Once the work request is
accepted, the Job Supervisor’s component controls the
execution of that job within the limitations of the job
specification and its business rules. The only exceptions
are coarse commands such as job abort or pause. The
responsibility of the Job Supervisor and Job is to
perform the activity and report back to the requestor on
the success or failure of the effort.
7.3.4.7.3 There is no predefined limitation on the
facilities within the factory that may be used to satisfy a
job request. However, a Job Supervisor may be