semi合集-English.pdf - 第2680页

SEMI E96-1101 © SEMI 1999 , 2001 20 mechanisms for qu er y or look up of specific managed object instances. 7.7 General Rules for C IM Framework Conf ormance 7.7.1 T he follow ing rules define the gen eral expecta- tions…

SEMI E96-1101 © SEMI 1999, 200119

6.8.2.7 A Usage Scenario Example

6.8.2.7.1 Here is an example of a usage scenario.

6.8.2.7.2 In common factory practice, cellular

manufacturing has a factory configuration service

responsible (among other things) for exporting the

factory services to the trading service. The following

are some typical use cases:

1. The factory configuration service registers a wafer

map server to server two cells named CellA and

CellB.

The factory configuration service obtains an initial

reference to the trading service from the ORB:

trader =

orb.resolve_initial_refer

ences(“TradingService”);

The trader answers its Register

interface:

traderRegistry =

trader.register_if();

The factory configuration service builds properties

as a single-itemed sequence of containing one

name/value pair whose name is “ServicedAreas”

and whose value is a sequence of the cell names

{ “CellA”, ‚ CellB”} . It then uses the Register

interface of the Trading Service to register the

service offer:

traderRegistry.export(

waferMapServer,”Wafer Map

Service”, properties);

2. The configuration manager informs a Die Attach

equipment that it belongs to CellA.

ProductiveEntities.setArea(“CellA”);

3. The Die Attach needs a wafer map.

It obtains an initial reference to the trading service

from the ORB:

trader =

orb.resolve_initial_refer

ences(“TradingService”);

The trader answers its Lookup interface:

traderLookup = trader.lookup_if();

The productive entity looks up the trading service

for the wafer map service:

traderLookup.query(

“Wafer Map Service”,

“CellA in ServicedAreas”,

pref, policies, desired_props,

1, preference, offers,

offers_itr, limits_applied);

The wafer map server is returned as the first

element of the offers sequence. The productive

entity may keep the reference to the wafer map

server for future use.

4. The Die Attach can now invoke the service on the

wafer map server:

waferMapServer.getWaferMap(…);

7 Technical Architecture Conformance

7.1 Conformance is defined as “adherence to a stan-

dard or specification in the implementation of a pro-

duct, process, or service.” A conforming implementa-

tion should have an associated implementation con-

formance statement that details the capabilities that

have been implemented. While recognizing that the

CIM Framework is, by definition, not a complete speci-

fication of a MES, a guide for technical architecture

defines conformance for each of its major requirements

as follows.

7.2 Distributed Object Communications Conformance

7.2.1 The CIM Framework object model is based on

the ability to issue service requests to a component

object and to subscribe to events published by the

component object. Component suppliers should explain

how these two forms of communications are accom-

plished so consumers can assess the ease and feasibility

of integrating a component into the factory MES.

Example terminology specific to semiconductor manu-

facturing is provided for clarity. It does not preclude

application specialization for other industries.

7.3 Exception Conformance

7.3.1 Alerting operation requesters of abnormal out-

comes is essential for robust implementations. Compo-

nent suppliers should explain how their implementa-

tions support raising specified system and user-defined

exceptions.

7.4 Event Specification Conformance

7.4.1 Notification of asynchronous occurrences is a

cornerstone of distributed event-driven application

domains such as MES. Suppliers should explain how

their components support event delivery, including the

registration of event suppliers, event consumers and the

provision for Event Broker features for event filtering.

7.5 Distributed Transaction Conformance

7.5.1 Ensuring consistent state changes among compo-

nents is a key concern in the integration of a factory

MES. Component suppliers should explain how their

components support transactional units of work.

7.6 Component Management Conformance

7.6.1 Component suppliers should explain how object

instances are managed. This includes how the object is

identified, constructed, accessed, and destroyed (or flat-

tened in the case of a persistent object). It also includes

SEMI E96-1101 © SEMI 1999, 2001 20

mechanisms for query or lookup of specific managed

object instances.

7.7 General Rules for CIM Framework Conformance

7.7.1 The following rules define the general expecta-

tions for technical conformance to any CIM Frame-

work specification. Suppliers should provide document-

ation explaining any deviations from these general

rules.

• All CIM Framework-defined operations for an

interface should be supported.

• All exceptions and events for an interface should

be supported.

• A component should use component manager

interfaces for object instance creation and regis-

tration where these operations are specified.

• A component implementation should support all

interfaces specified for that component.

• An application may not add states and transitions

to the defined dynamic models that have external

interfacing ramifications. The application may still

further subdivide the states.

• A component implementation should explain how

it supports substitutability. For example, it may

support different degrees of substitutability

between the following levels:

• Strict — An application that supplies a CIM

Framework component should be reconfig-

urable so it can use another supplier’s imple-

mentation of that component. The application’s

interactions with the component are restricted

to CIM Framework defined interfaces.

• Weak — An application may use extended,

pro-prietary, or private interfaces of a

component. When the another supplier’s

implementation is substituted for an installed

component, any components using the

extended, proprietary, or private interfaces need

to be reassessed and possibly modified. The use

of the CIM Frame-work-defined interfaces does

not change.

NOTICE: SEMI makes no warranties or

representations as to the suitability of the standard set

forth herein for any particular application. The

determination of the suitability of the standard is solely

the responsibility of the user. Users are cautioned to

refer to manufacturer’s instructions, product labels,

product data sheets, and other relevant literature

respecting any materials mentioned herein. These

standards are subject to change without notice.

The user’s attention is called to the possibility that

compliance with this standard may require use of copy-

righted material or of an invention covered by patent

rights. By publication of this standard, SEMI takes no

position respecting the validity of any patent rights or

copyrights asserted in connection with any item

mentioned in this standard. Users of this standard are

expressly advised that determination of any such patent

rights or copyrights, and the risk of infringement of

such rights, are entirely their own responsibility.

International), 3081 Zanker Road, San Jose, CA 95134. Reproduction o

the contents in whole or in part is forbidden without express written

consent of SEMI.

SEMI E97-0200A © SEMI 20001

SEMI E97-0200A

PROVISIONAL SPECIFICATION FOR CIM FRAMEWORK GLOBAL

DECLARATIONS AND ABSTRACT INTERFACES

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

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

approved by the North American Regional Standards Committee on October 21 and December 15, 1999.

Initially available at www.semi.org January 2000; to be published February 2000.

NOTE: This document was published twice during the

February 2000 (0200) publishing cycle.

1 Purpose

1.1 This document defines the global declarations used

by all other components of the CIM Framework and

also specifies the common architecture patterns that

serve to functionally integrate CIM Framework

components. The material architecture defines

functionality common to product management, durables

management and consumables management

components. The factory resource architecture defines

relationships and common functionality of a variety of

factory resources. The job architecture defines a

factory-wide model for controlling factory jobs that

drive a variety of manufacturing tasks. These

specifications are separated into a distinct group to

enable them to be specified once and then logically

included or inherited wherever they are subsequently

needed.

2 Scope

2.1 This specification provides the common interfaces

required by Manufacturing Execution Systems to:

• Provide type definitions for common data

structures to ensure consistent representation.

These items include data types for common

concepts such as coordinates, priorities,

timestamps, and sequences of basic data types.

• Provide definitions for common exceptions used

consistently throughout the CIM Framework.

• Provide the material architecture interfaces

common to identifying, grouping, moving, locating

and tracking material in the factory.

• Provide the factory resource architecture interfaces

common to defining, organizing, tracking usage of

and maintaining factory resources including

equipment, sensors, durables, and people.

• Provide the job architecture interfaces common to

creating, executing and managing work in the

factory. The job architecture is specialized for

material processing jobs, material transport jobs,

resource maintenance jobs and factory jobs that

drive product material through their process flows.

2.2 This standard does not purport to address safety

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

responsibility of the users of this standard to establish

appropriate safety and health practices and determine

the applicability of regulatory limitations prior to use.

3 Limitations

3.1 Provisional Status

3.1.1 This specification is designated as provisional

due to known areas that need to be completed. The

following items summarize the deficiencies of the

provisional specification to be addressed before a

subsequent ballot to upgrade it to full standard status.

3.1.2 The specification uses the IDL typedef “any” in

several places. While this usage provides flexibility, it

can have the effect of reducing interoperability due to

differences in interpretation of the value provided by

separate implementations that interact through a

standard interface. The “any” typedefs should be

replaced with explicit data types prior to upgrade from

Provisional to full Standard status.

3.1.3 The definition of interfaces for retrieval of

history associated with CIM Framework objects may

need to be added to abstract interfaces in this document

after the complete specification for the history facility

within the CIM Framework Factory Services

Component.

3.1.4 The specification of CIM Framework states

reported through published state change events is

currently based on a type definition for an enumeration

of state values. There may be alternate representations

for states that are better able to capture the semantics of

nested and parallel states. The state representation used

for the CIM Framework will be reviewed and possibly

changed before upgrade to full standard status.

3.1.5 The Resource model defined in SEMI E81

includes several extensions that are not yet included in

this specification. These extensions include

composition of resources from other resources,

capabilities associated with resources, and associations

with tracking and maintenance functions for resources.