semi合集-English.pdf - 第2298页

SEMI E81-0600 © 1999, 2 000 35 7.3.4.11.2 In general, each task specificat i o n is a defin ition of a business process and a task workflow to carry out that business process. There is a diversity of informat ion that co…

overall maintenance job supervision functions (see

Section 7.3.3.5), and the various resource types

implement these functions in the Equipment Tracking

and Maintenance, Durables Management, Consumables

Management, and Factory Labor components.

7.3.4.9.2.6 Advanced Process Control (APC): APC

includes lengthy calculation activities that may not

succeed and which impact the performance of other

jobs. For example, an algorithm may not converge, a

sensor may emit bad data, or process recipes and job

specifications may be modified. The CIM Framework

APC component leverages the overall job architecture,

where control strategies and scripts are the job

specifications, sensor analysis and control execution

environments are scheduled resources, and the state of

process specifications (machine settings, modified

process flows) are the result of APC job execution.

7.3.4.9.2.7 Enterprise and Process Resource: The job

control hierarchy of Figure 19 provides interfaces to the

enterprise at the top level and the equipment at the

bottom level. The enterprise level is the requestor of

work for the factory. Enterprise control is outside the

MES functional scope of the CIM Framework. The

equipment level is also outside the scope of control of

the CIM Framework. It is usually implemented by

process controllers embedded in or piggyback on

equipment. The equipment level is modeled for the

MES to allow process data to be collected and

organized for specific equipment resources such as a

specific chamber in a cluster tool.

7.3.4.10 Job History

7.3.4.10.1 Any entity can have an associated CIM

Framework History. The CIM Framework defines some

specific named histories, as Figure 21 illustrates.

Product-oriented data is captured in production history

associated with the material hierarchy and is used, for

example, for material traceability and defect analysis.

Process-oriented data is captured in process history

associated with the job supervision hierarchy and is

used, for example, for run-to-run process control.

Equipment and other resource-oriented data is captured

in resource history associated with the resource

hierarchy and is used, for example, for preventive

maintenance and warranty tracking.

7.3.4.10.2 As jobs are executed (and possibly broken

down into sub-tasks as shown in Figure 12), their

results are captured as various types of histories. For

example, an Area Job’s history may be captured within

an InventoryRegionHistory. A Resource Level Job’s

history may be captured within an E10Perform-

anceHistory or within a ResourceMaintenance-

LogHistory.

7.3.4.11 Task Specification and Workflow

7.3.4.11.1 The specification of a task takes various

forms. For Factory Jobs, the specification is the process

flow defining the process steps to transform material

into products. For Production Machine Jobs, the

specification is the specific steps in the process flow

that this production machine is to perform, along with

process recipes. For Transport Jobs, the specification

defines the destination location for the material

transport group. For maintenance jobs, the specification

defines the specific maintenance tasks for the resource.

For advanced process control jobs, the specification

defines a script that includes the sensor processing and

algorithm steps of a control strategy.

ProcessResourceHistory

(sequence of ProcessRun data)

productionHistory

E10PerformanceHistory

ControlDatabase

ControlArchive

InventoryRegionHistory

ResourceMaintenanceLogHistory

Production

Machine

Process

Resource

Factory Job

Area Job

Production

Machine

Job

Resource-

level job

Product Group

Lot, LotFamily

Inventory Region

Process

Resource

Group

Process Operation

Any object can have an

associated history

Person

QualificationHistory

Process Definition

Figure 21

History Structure

7.3.4.11.2 In general, each task specification is a

definition of a business process and a task workflow to

carry out that business process. There is a diversity of

information that could appear in a business process,

including associated operational business rules and

constraints, workflow traversal logic, and data

structures for tasks, recipes, steps, etc. There is not

industry consensus on representing these generic task

specification details. For each specific job type, the

CIM Framework defines some specification structure,

but leaves room for suppliers and users to define

additional data and behavior and to leverage workflow

engines and evolving workflow standards [Workflow,

WfMC].

7.4 Specification Conventions

7.4.1 This section provides an overview of the

notations required to express the CIM Framework

specifications. These notations provide the

representational formalisms for all CIM Framework

specifications. This section is a reference rather than a

tutorial. Hence, those unfamiliar with these topics are

strongly encouraged to consult the materials listed in

the references for a more thorough explanation.

7.4.2 CIM systems requirements and the architectural

principles upon which the CIM Framework was

founded were derived through use of industry

standards, practices reported in the literature, and other

state-of-the-art information. The requirements of the

CIM Framework are specified using a combination of

graphical and textual notations. Where applicable,

methods were employed and notations applied that were

supported by the automation of computer-aided

software engineering tools.

7.4.3 Model Specification and Graphical Notation

Usage

7.4.3.1 This section briefly describes the graphical

notations used to specify the semantics of the

framework, including the following:

• Component Relationship Model.

• Component Information Model.

• Component Interaction Diagram.

• State Model.

7.4.3.2 Component Relationship Model

7.4.3.2.1 The Component Relationship Model was

developed specifically for the framework specification

as a mechanism to show relationships among

framework components. It shows the logical

combination of components and the relationships

among the component parts. Figure 22 depicts the

Component Relationship Model.

7.4.3.2.2 This model is based on the Unified Modeling

Language (UML) Class Diagram [UML] with added

stereotypes to represent the components. The UML

Association concept is abstracted to represent the high-

level relationships between components of the

framework.

7.4.3.3 Component Information Model

7.4.3.3.1 The Component Information Model shows

the specified CIM Framework interfaces along with the

relationships between those interfaces. This model is

based on the UML Class Diagram [UML] with the

stereotype «Interface» to indicate that the classes are

interfaces rather than implementation artifacts. This

model shows generalization as applied to interface

inheritance, aggregation of interfaces, and the use of an

Association Class to represent data associated with an

association between two interfaces. The associations

also capture specific semantics of the relationship,

including multiplicity and optionality as shown in

Figure 23.

<<Component>>

Association

Figure 22

Component Relationship Model

<<In te r fa c e >>

<<Interface>>

Association Class

<<Interface >>

0..1

Association Nam e

<<Interface>>

<<Interface >>

1..*

Association Name

<<Interface>>

Zero or

One

Subtype

Relationship

Part-Whole

Relationshop

Data-

Carrying

RelationshipExactly

Two

One

One or

Many

Figure 23

Information Model Example

7.4.3.4 Component Interaction Model

7.4.3.4.1 The Component Interaction Model expresses

framework dynamics by describing the sequence of

collaborations between objects supporting CIM

Framework interfaces. This model is represented using

the UML Sequence Diagram [UML]. The vertical lines

each represent an object that conforms to a role

specified by a CIM Framework interface. This is called

a “lifeline.” The connecting arrows represent messages

that flow between these objects and the data they

convey. Each message must map to a defined operation

on the interface of the message recipient. The example

shown in Figure 24 of a Sequence Diagram models a

portion of the interaction between a bank customer and

an Automated Teller Machine (ATM).

7.4.3.5 State Model

7.4.3.5.1 The State Model shows behavior associated

with CIM Framework interfaces as changes in state that

result from specific events. The required behavior for

an interface is conveyed through UML State Diagrams

[UML] and textual tables that offer supporting details.

Under this notation which is based on Harel Statecharts,

states may be divided into substates, thereby forming a

hierarchy of states. Substates must be one of two types,

termed AND substates (representing concurrency) and

exclusive OR substates (representing a finer breakdown

of a parent state).

7.4.3.5.2 Object State Tables provide supplementary

(to the State Diagram) state information including

descriptive state definitions, state query mechanisms,

the triggers effecting state transition, and the actions

resulting from state transitions.

7.4.3.5.3 Object State Definitions and Query Table

7.4.3.5.3.1 The Object State Definition and Query

Table provide supplementary information to the State

Diagram.