semi合集-English.pdf - 第2292页

SEMI E81-0600 © 1999, 2 000 29 7.3.4.6 Jobs and Job Supervisors 7.3.4.6.1 Jobs are transient entities. The y a re created to perform a task and go awa y when the task i s complete. A job su pervisor i s the persistent ob…

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+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

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..*

tracks

progress

via

0..*0..*

supervises

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

configured to be limited to specific factory resources

that it can call on to perform work.

7.3.4.7.4 The job requestor has an interface so the

Job/Job Supervisor can report overall job progress. The

Job Requestor interface includes the methods

requesting that it be notified that a job has started,

completed, or been terminated. The requestor or other

components can subscribe to job state change events

and other events for a more detailed job status.

7.3.4.7.5 The Job Supervisor interface provides high

level information about the jobs it is currently

managing. The details of any specific job are provided

by the Job itself, not the Job Supervisor. From the Job

Supervisor, the Job Requestor is able to

• request activity,

• locate jobs that meet certain criteria,

• request lists of all jobs being performed, and

• control all the jobs as a group (e.g. “abort all

jobs”), but not individually (not “abort job X”—

this would be a responsibility of the Job interface).

NOTE 13: Much thought should be given to the use of these

“all jobs” commands since they can cause a great deal of harm

if not designed and used properly.

7.3.4.7.6 The Job interface is the sole source of all

public information about a job. It also provides all

specific control of the job (pause, abort, etc.).

7.3.4.8 Hierarchical Job Structure

7.3.4.8.1 The factory and task hierarchy of Figure 11

and Figure 12 results in a multi-level (hierarchical) job

control structure, with a given Job/Job Supervisor

requesting work through other (sub)Jobs. As Figure 16

illustrates, higher level job controllers specify and

request work from any number of lower level job

controllers and monitor job progress through status and

external feedback. At the lowest level, job control

results in directly manipulating equipment actuators

based on real-time sensor feedback. (Note, this lowest

level of job control is outside the MES scope of the

CIM Frameworkit is within the scope of the

equipment control.) The job request, status, and

feedback information are all candidates for storage in

job history.

Job

Control

Job

Control

Job

Status

Job

Request

External Feedback

(e.g. sensor data

or operator input)

Actuation

Sensor Feedback

Job

Status

Job

Request

Job

Control

External Feedback

(e.g. sensor data

or operator input)

Job

Control

Job

Control

Job

Status

Actuation

Job

Request

Job

Request

Job

Status

Feedback

Physical Processes

Figure 16

Hierarchical Job Control