semi合集-English.pdf - 第2268页

SEMI E81-0600 © 1999, 2 000 5 They determine the proces sing environment seen by a manufactured product (e.g., w afer). Processing recipes may be subject to chang e betw een product runs or processing c ycles. 5.2.46 sub…

5.2.25 framework — a collection of classes or

components that provide a set of services and

functionality for a particular domain.

5.2.26 implementation — the internal view of a class,

object or module, including any non-public behavior.

The specific code and functionality that implements an

interface.

5.2.27 infrastructure — the services, facilities, and

communications mechanisms that support the collabor-

ation between and lifecycle of distributed objects.

5.2.28 inheritance — a relationship among classes

wherein one class (a subclass) shares the structure or

behavior defined in one or more other classes

(superclass). A subclass typically specializes its

superclasses by augmenting or redefining existing

structure and behavior.

5.2.29 instance — a software entity that has state,

behavior and identity. The terms instance and object are

interchangeable. An object is an instance of an interface

if it provides the operations, signatures and semantics

specified by that interface. An object is an instance of

an implementation if its behavior is provided by that

implementation.

5.2.30 interface — the external view of a class, object,

or module that emphasizes its abstraction while hiding

its structure and internal behavior. An interface

definition ideally includes the semantics.

5.2.31 interface inheritance — the construction of an

interface by incremental modification of other

interfaces (see implementation inheritance). The CIM

Framework specifies interface inheritance but not

implementation inheritance.

5.2.32 interoperability — the ability for two

applications or the parts of an application to cooperate.

In the CIM Framework, interoperability requires that

application components be able to share data, invoke

each others’ behavior (services), exchange events, and

publish service exceptions.

5.2.33 job — some system level operation whose

execution may be requested by an entity whose

responsibility it is to manage jobs. The job concept is

analogous to operations performed on the “factory

floor” in a physical factory. There, operators are

requested to perform operations (jobs) requested by

their managing supervisors or some other managing

source. A job often spans a significant amount of time

and multiple resources within the system. In the CIM

Framework, the job construct is intended for

specialization to enable specific job supervisors and

jobs to provide system solutions.

5.2.34 lifecycle — the life of an object, including

creation, deletion, copy, and equivalence.

5.2.35 method — an operation upon an object defined

as part of the declaration of a class. In general, the

terms message, method and operation can be used

interchangeably. Technically, a method is defined

within a class and an operation is defined within the

IDL. An operation is implemented by a method.

5.2.36 object — an identifiable encapsulated entity

that implements one or more services that can be

requested by a client. An instance of a class.

5.2.37 object services — interfaces for general

services that are likely to be used in any program based

on distributed objects.

5.2.38 Object Management Group (OMG) — an

international consortium dedicated to the development

of open specifications for distributed, heterogeneous,

object-oriented systems.

5.2.39 operation — an operation is an entity, identi-

fied by an operation identifier that denotes a service that

can be requested. An operation has a signature that

describes the legitimate values of request parameters

and returned results, including any exceptions.

5.2.40 persistent object — an object that can survive

the process or thread that created it. A persistent object

exists until it is explicitly deleted.

5.2.41 process definition — information characterizing

manufacturing processes including an estimate for the

time a process resource will be engaged in the process;

process resource settings; and the process capabilities

required for the process.

5.2.42 process flow — the part of a product

specification that defines the sequence of process steps

for the manufacturing of a specific product. The data

structure for representing a process flow is the directed

graph; specifically, a tree structure. The nodes of the

tree are called process flow nodes (see below). Services

are required to navigate the process flow.

5.2.43 process flow context — naviga tional

information pertaining to a product’s progress as it

traverses its context process flow.

5.2.44 process step — the smallest unit of processing

activity that can be defined in a process flow. One or

more process steps are sequenced to define an operation

set.

5.2.45 recipe — the pre-planned and reusable portion

of the set of instructions, settings and parameters that

determine how a job is to be performed. For example,

recipes are used to describe Process Steps and are

typically contained within a Product Specification.

They determine the processing environment seen by a

manufactured product (e.g., wafer). Processing recipes

may be subject to change between product runs or

processing cycles.

5.2.46 sub-component — a component that is fully

contained within a larger component. The interfaces of

the sub-component may be exposed or hidden by the

encapsulating component.

5.2.47 substitutability — the ability to replace a given

component from one supplier with a functionally

equivalent component from another supplier without

impacting the other components or its clients in the

system.

5.2.48 type — a declaration that describes the common

properties and behavior for a collection of objects.

Types classify objects according to a common interface;

classes classify objects according to a common

implementation.

6 Overview

6.1 This section provides background information that

will help readers get the most from the content of this

specification.

6.2 Intended Audience

6.2.1 The framework specification is intended to

address the needs of the following CIM technologists:

• Technical CIM managers.

• System architects and engineers.

• Application developers and integrators.

• Standards developers.

6.2.2 These groups may be found in a variety of

organizations, including semiconductor manufacturers,

software product suppliers, system integrators,

equipment suppliers, standards organizations,

universities, national laboratories, and other research

organizations.

6.2.3 Technical CIM Managers

6.2.3.1 Technical CIM managers are responsible for

managing the development, delivery, and integration of

complex manufacturing software applications. They can

use the CIM Framework specification to plan and

organize the development activities and guide

component testing and validation. Moreover, those who

buy some of their software from external sources can

use it as a purchasing guide when discussing system

architecture and integration requirements with potential

suppliers.

6.2.4 System Architects and Engineers

6.2.4.1 System architects and engineers are

responsible for overall system design, including

selection of industry standards for computing and

communications infrastructure, software development

processes, product roadmaps, and related topics. They

can make extensive use of the CIM Framework as a

starting point for many of their activities, including the

• partitioning and allocation of application functions

to specific modules,

• definition of the boundary between the distributed

system infrastructure and the rest of the system,

and

• specification of open interfaces between the

portions of the system they are designing and the

external environment.

6.2.4.2 They can also use the CIM Framework

specifications to define a strategic system roadmap for

migration to an open, distributed system environment.

6.2.5 Application Developers and Integrators

6.2.5.1 Application developers and integrators must

produce, install, and support software applications for

semiconductor manufacturing. The CIM Framework

specification, in conjunction with a specific framework

“binding” (i.e., target computer system hardware and

software technologies), represents a set of detailed

design requirements for the application developer. At a

minimum, the CIM Framework defines the scope and

boundaries of the essential standard components of a

manufacturing execution system, and can be used

principally as an interface specification. The object

models can also be used in the internal design of new

applications and/or legacy integration “wrappers,”

accelerating the development process even further.

Finally, the specification can form the basis for creating

an independent set of tests necessary to verify

conformance.

6.2.6 Standards Developers

6.2.6.1 Developers of CIM software standards are

responsible for specifying the public interfaces and

shared information models that allow the many

software products found in a modern semiconductor

factory to work together. They can use the CIM

Framework as an open source of information for

establishing precise definitions for the many items in a

factory that must be represented in multiple suppliers’

products, including

• standards for partitioning and communicating with

complex equipment,

• product and raw material attributes and

relationships,

• process definitions and routings,

• equipment data sampling schemes and storage

schema,

• personnel qualifications,

• and many others.

6.3 CIM Framework Foundational Concepts

6.3.1 This section provides an explanation of the basic

concepts of framework, component, and sub-component

as used in the CIM Framework Domain Architecture.

6.3.2 Framework

6.3.2.1 A framework is a software infrastructure that

provides a common environment for the development

and integration of applications and sharing of

information in a given problem domain. The CIM

Framework is a particular type of framework based on

an object-oriented model of semiconductor wafer

manufacturing. It specifies manufacturing objects and

object interaction protocols that enable building

semiconductor CIM applications from a framework of

compatible, substitutable application components.

6.3.2.2 The heart of the framework is a set of

semiconductor manufacturing abstractions (e.g., Wafer,

Specification, Machine) and services (e.g., get wafer

location, set specification parameter, get machine

utilization) that are typically embodied in applications

(e.g., material management, specification management,

machine control). The implementations of these

abstractions are delivered on distributed computer

platforms (e.g., workstations, servers) which use

standard software system technologies (e.g.,

communications, database, and user interface). The

current CIM Framework is specifically targeted at

manufacturing information management and control for

both the planning and operational phases of

semiconductor wafer fabrication.

6.3.3 Component Architecture

6.3.3.1 The CIM Framework specifies software

functions that are common across MES applications and

serve to integrate those MES applications into a

coherent system. The CIM Framework software

architecture is based on components. Components are

software building blocks—“chunks” of functionality

that make up software applications. By specifying

standard interfaces and behavior of common MES

components, manufacturers can assemble systems from

components from multiple suppliers and they can

evolve those systems by extending the common

components and by substituting old components with

improved components that implement the same

interfaces and behavior in improved and extended

ways. The CIM Framework defines a manufacturing

execution system architecture whose components can

be assembled in many ways and driven by many

business processes and operational policies.

6.3.3.2 Figure 1 shows the CIM Framework architec-

ture as a layered system, with the CIM Framework cov-

ering the middle layer of that system. Figure 2 details

the layers, showing the components and their interact-

ion and extension. The following subsections provide

an introduction to the CIM Framework architecture.

Infrastructure

Common

Components

Application

Objects

CIM Framework

Domain Specifications

Figure 1

CIM Framework Layering

6.3.3.3 Infrastructure

6.3.3.3.1 The infrastructure provides the distributed

computing environment for the application. These

services include operating system, communications,

data storage, user interface, event distribution,

exception management, etc. The CIM Framework

assumes infrastructure services and facilities defined by

the Object Management Group®’s (OMG) Object

Management Architecture (OMA) or by the Microsoft®

DCOM and COM+ architecture and it can be mapped to

other infrastructures such as those for Java™. SEMI

E96 addresses the infrastructure layer.

6.3.3.4 Common Components

6.3.3.4.1 Common components are the functional

entities common across MES applications. For

example, material tracking, machine management, and

scheduling applications all need a common, shareable

concept of wafer groups (lots), machines, and process

recipes. The common components provide a shared

model for these entities, enabling quicker development

and integration of material tracking, machine

management, scheduling and other applications. They

specify the data and behavior of these components

required for interoperability between the applications.

6.3.3.5 Application Objects

6.3.3.5.1 The application objects provide the applica-

tion functionality beyond the common components.

These application objects provide application-specific

data and behavior (such as the specific scheduling

algorithms or the specific recipe management

functions), building on the common component data

and behavior that allows the application to interoperate

with other applications. The application objects also