semi合集-English.pdf - 第2265页

SEMI E81-0600 © 1999, 2 000 2 • Adjusting the functional partitio ning of the Do main Archit ecture to refl ect the final posit ioning of sub- compon e nts in the anticipated revis io ns of the oth er CIM Framework speci…

SEMI E81-0600

PROVISIONAL SPECIFICATION FOR CIM FRAMEWORK DOMAIN

ARCHITECTURE

This provisional specification was technically approved by the Global Information & Control Committee and

is the direct responsibility of the North American Information & Control Committee. Current edition

approved by the North American Regional Standards Committee on March 2, 2000. Initially available at

www.semi.org April 1999; to be published June 2000. Originally published June 1999.

1 Purpose

1.1 This document is an overview of the structure and

contents of a suite of documents representing an

application framework for the Computer Integrated

Manufacturing (CIM) systems as used in semiconductor

factories. A framework is a software infrastructure that

creates a common environment for integrating appli-

cations and sharing information in a given domain. The

purpose of this framework is to establish an industry

standard architecture for complex manufacturing

systems, leading to an open, multisupplier CIM system

environment. The framework described in this

specification is called the CIM Framework.

2 Scope

2.1 The intent of this document is to describe the

Manufacturing Execution Systems (MES) domain that

is the subject of the CIM Framework and to provide a

reference for concepts that are common to the set of

documents that specify the CIM Framework. The

Provisional Specification for CIM Framework Domain

Architecture defines the structure, relationships and

interworkings of the components that together comprise

the CIM Framework. This architecture defines the

partitioning of the CIM Framework components and the

responsibilities of each of those components. It also

specifies the common abstractions for manufacturing

jobs, material, and factory resources that are used

consistently throughout the CIM Framework as

unifying themes.

2.2 The CIM Framework Domain Architecture does

not address the dependencies on computing tech-

nologies needed to implement these components. These

aspects apply more to the realization of the components

as software artifacts than to their functionality in terms

of semiconductor manufacturing concepts. The

technical aspects of the CIM Framework architecture

are captured in a separate document, SEMI E96, Guide

for CIM Framework Technical Architecture.

2.3 This specification does not purport to address

safety issues, if any, associated with its use. It is the

responsibility of the users of this specification to

establish appropriate safety and health practices and

determine the applicability of regulatory limitations

prior to use.

3 Limitations

3.1 The CIM Framework Specification must continue

to evolve to meet the needs of a competitive and vital

industry. The content of this framework represents a

significant amount of real development experience from

a number of commercial software suppliers and their

customers. These specifications reflect the product

architectures of those companies, as well as the

requirements of their customers.

3.2 As a SEMI Provisional Standard, the Specification

for CIM Framework Domain Architecture has specific

deficiencies that must be addressed before it may be

upgraded to full SEMI Standard status. These

deficiencies are:

• Ensuring consistency with the details of subsequent

related specifications that are based on this domain

architecture.

• Evolving from coarse-grained component partitions

to fine-grained components that provide

substitutability of smaller components.

• Expanding interfaces to include build-time

configuration functions.

• Providing fully validated models using the standard

Unified Modeling Language (UML) notation.

• Aligning the CIM Framework representation of

equipment and interfaces for interactions with

equipment automation software with emerging

standards in areas such as Object-Based Equipment

Model (OBEM) and Automated Material Handling

Systems (AMHS).

• Modifying the CIM Framework use of the “in”

parameter mode and operation return value to

include also the “out” and “inout” modes to better

accommodate implementations based on Microsoft

DCOM and IDL enhancements for pass-by-value

of objects.

• Adjusting the functional partitioning of the Domain

Architecture to reflect the final positioning of sub-

components in the anticipated revisions of the other

CIM Framework specifications.

4 Referenced Standards

4.1 SEMI Standards

SEMI E5  SEMI Equipment Communications

Standard 2 Message Content (SECS-II)

SEMI E10  Standard for Definition and Measurement

of Equipment Reliability, Availability, and

Maintainability (RAM)

SEMI E30  Generic Model for Communications and

Control of Manufacturing Equipment (GEM)

SEMI E32  Material Movement Management

(MMM)

SEMI E42  Recipe Management Standard: Concepts,

Behavior, and Message Services

SEMI E58  Automated Reliability, Availability, and

Maintainability Standard (ARAMS): Concepts,

Behavior, and Services

SEMI E86  Provisional Specification for CIM

Framework Factory Labor Component

SEMI E93  Provisional Specification for CIM

Framework Advanced Process Control Component

SEMI E96  Guide for CIM Framework Technical

Architecture

SEMI E97  Provisional Specification for CIM

Framework Global Declarations and Abstract Interfaces

SEMI E102  Provisional Specification for CIM

Framework Material Transport and Storage Component

4.2 OMG Documents

CORBA  Common Object Request Broker Archi-

tecture, Version 2.3.1 (OMG Document formal/99-10-

07).

MfgDTF  Manufacturing Domain Task Force Road-

map, Version 3.1 (OMG Document mfg/98-06-11).

OMA  Object Management Architecture Guide,

Version 3.0 (OMG Document ab/97-05-05).

UML  UML Notation Guide, Version 1.1 (OMG

Document ad/97-08-05).

Workflow — Joint Workflow RFP Revised Submission

(OMG Document bom/98-06-07).

1 Object Management Group, 492 Old Connecticut Path,

Framingham, MA 01701, USA

4.3 SEMATECH Documents

CIMArch  Computer Integrated Manufacturing

(CIM) Framework Architecture Concepts, Principles,

and Guidelines, Version 1.0 (SEMATECH-Technology

Transfer #97103379A-ENG).

CIMFW  Computer Integrated Manufacturing (CIM)

Application Framework 2.0 (SEMATECH Technology

Transfer #93061697J-ENG).

4.4 Other References

ALBUS  J.S. Albus and A.M. Meystel, A reference

model architecture for design and implementation of

intelligent control in large and complex systems,

International Journal of Intelligent Control and Systems

vol. 1, no.1 p.15−30, World Scientific: Singapore,

March 1996.

ANSI  ANSI Standard ANSI/ISA-S88.01-1995,

Batch Control Part 1: Models and Terminology

COM+  http://www.microsoft.com/msj/1197/

complus.htm; http://www.microsoft.com/com/

DCOM  http://www.microsoft.com/windows/down-

loads/bin/nts/dcom_architecture.exe.

JAVA  http://www.javasoft.com.

WfMC  http://www.wfmc.org.

NOTE 1: As listed or revised, all documents cited shall be the

latest publications of adopted standards.

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 AMHS — Automated Material Handling System

5.1.2 APC — Advanced Process Control

5.1.3 APCFI — Advanced Process Control Framework

Initiative

5.1.4 API — Application Programming Interface

5.1.5 CIM — Computer Integrated Manufacturing

5.1.6 MES — Manufacturing Execution System

2 SEMATECH, 2706 Montopolis Dr., Austin, TX 78741, USA

3 World Scientific Publishing Co., 1060 Main St., River Edge, NJ

07661, USA

4 American National Standards Institute, 11 West 42nd St., New

York, NY 10036, USA

5 Microsoft, 10500 NE 8th St., Ste. 1300, Bellevue, WA 98004, USA

6 Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, CA

94303, USA

7 Workflow Management Coalition Office, 2 Crown Walk,

Winchester, Hampshire, S022 5XE, United Kingdom

5.1.7 MMMS — Material Movement Management

Services (SEMI)

5.1.8 OBEM — Object Based Equipment Model

5.1.9 OMA — Object Management Architecture

5.1.10 PFC — Process Flow Context

5.1.11 PFI — Process Flow Iterator

5.1.12 RFP — Request for Proposal

5.1.13 RMS — Recipe Management S ystem

5.1.14 UI — User Interface

5.1.15 WIP — Work In Process

5.2 Definitions

5.2.1 abstract interface — an interface defined outside

any component that generalizes common features of the

CIM Framework. The abstract interfaces are intended

for use in multiple components via interface inheritance

mechanisms.

5.2.2 application — 1. One or more programs

consisting of a collection of interoperating objects

which provide domain specific functionality to an end

user or other applications. 2. Functionality provided by

one or more programs consisting of a collection of

interoperating objects.

5.2.3 application framework — a framework that

constitutes an application or a set of applications for a

domain area.

5.2.4 application interface — the interface provided

by an application or application program.

5.2.5 application object — an object implementing an

application interface.

5.2.6 architecture — the structure of the components

of a program/system, their interrelationships, and

principles and guidelines governing their design and

evolution over time.

5.2.7 attribute — an identifiable association between

an object and a value. An attribute may have functions

to set and retrieve its value.

5.2.8 behavior — the effects of performing a

requested service including its results.

5.2.9 binding — a specific choice of platform

technologies and other implementation-specific criteria.

5.2.10 class — the shared common structure and

common behavior of a set of objects. Class often

implies an implementation of the common structure and

behavior while interface represents a specification of

those common features.

5.2.11 client — an object that uses the services of

another object by operating upon it or referencing its

state.

5.2.12 collection — an object containing references to

(collections of) other objects with services for

managing them and providing access to them as a

related group of objects.

5.2.13 component — a reusable package of

encapsulated objects and/or other components with

well-specified interfaces. The component is the element

of standardization and substitutability in the CIM

Framework.

5.2.14 Computer Integrated Manufacturing (CIM) —

an approach that leverages the information handling

capability of computers to manage manufacturing

information and support or automate the execution of

manufacturing operations.

5.2.15 conformance — adherence to a standard or

specification in the implementation of a product,

process, or service.

5.2.16 conformance requirement — identification in

the specification of behavior and/or capabilities

required by an implementation for it to conform to that

specification.

5.2.17 conforming implementation — an

implementation that satisfies all relevant specified

conformance requirements.

5.2.18 distributed system — an integrated collection of

several processing and memory components whose

distribution is transparent to the user so that the system

appears to be local.

5.2.19 domain interface — an interface specific to an

application subject area.

5.2.20 domain object — an object implementing a

domain interface.

5.2.21 events — an asynchronous message denoting

the occurrence of some incident of importance. For

example, state change or new object created.

5.2.22 event channel — the intermediate object that

forwards published events to interested subscribers.

5.2.23 exception — an infrastructure mechanism used

to notify a calling client of an operation that an unusual

condition occurred in carrying out the operation.

5.2.24 extensibility — the ability to extend or

specialize existing components and add new object

classes or components while preserving architectural

integrity and component conformance to standards.