semi合集-English.pdf - 第2679页

SEMI E96-1101 © SEMI 1999 , 2001 19 6.8.2.7 A Usage Scenario Example 6.8.2.7.1 Here is an example of a usage scen ario. 6.8.2.7.2 In common factory practice, ce llu lar manu fact uring ha s a fa ctor y co nfig urati on s…

SEMI E96-1101 © SEMI 1999, 2001 18

6.8.2.4.8 Querying a Registered Service

6.8.2.4.8.1 A server may query the trader the details of

a registered service by passing in the offer id.

Struct OfferInfo {

Object reference;

ServiceTYpeName type;

PropertySeq properties;

};

OfferInfo describe (

in OfferId id);

6.8.2.4.9 Modifying a Registered Service

6.8.2.4.9.1 The server may modify the properties of a

registered service. It may add new properties, delete

existing properties, or modify the value of existing

properties. This is done using the following method:

void modify (

in OfferId id,

in PropertyNameSeq del_list,

in PropertySeq modify_list

);

6.8.2.4.9.2 The properties named in the del_list are

deleted. Properties in the modify_list that do not exist

are added. Properties in the modify_list that exist,

receive a new value.

6.8.2.4.9.3 The modify method can be used to support

changes in the factory configuration, such as new

productive entity being added or deleted, a productive

entity being migrated from one cell to another, a new

load balancing policy for the servers installed, etc.

6.8.2.5 Import Use Cases

6.8.2.5.1 Importing a Service  The trader offers an

interface named Lookup that clients can use in order to

locate a service:

void query (

in ServiceTypeName type,

in Constraint constr,

in Preference pref,

in PolicySeq policies,

in SpecifiedProps desired_props,

in unsigned long how_many,

out OfferSeq offers,

out OfferIterator offer_itr,

out PolicyNameSeq limits_applied

);

6.8.2.5.1.1 The Query in Parameters  The “in”

parameters are used by the client to specify the service

it needs and the policies for searching it.

• The “type” parameter is key to the central purpose

of trading. It specifies the name of the service type

the client is interested in.

• The “constraint” guides the trader on how to select

a server based on its registered properties. It is a

string that describes the selection in some given

constraint language. The typical constraints will

select a server for a specific productive entity or for

the area the productive entity belongs to. Both

possibilities use the “in” operator for testing the

inclusion of an element in a set. Some examples

follow:

“DieAttachXYZ in ServicedProductive-

Entities”

“Cell22 in ServicedAreas”

6.8.2.5.1.2 “Preferences” specify how should a server

be selected in case the query results in more than one

answer. It is suggested that this parameter be ignored,

which means that the default of first is always used.

6.8.2.5.1.3 The “policies” parameter guides the trader

on how to choose a policy for performing the search.

Search policies are a rather complicated issue, which

can be ignored in the Simple Trader case.

6.8.2.5.1.4 The “desired_props” parameter instructs the

trader which properties are to be returned as part of the

answer (it does not affect the selection itself). This does

not make much sense with the limited set of properties

which has been defined, and can also be ignored (use

none as the parameter value).

6.8.2.5.1.5 The “how_many” parameter is another way

to restrict the number of answers. It is proposed that 1

always be used as the value of this parameter.

NOTE 6: Should areas be used as the selection criteria, the

equipment must be aware of its area within the factory. This

should be supported through the productive entity

“Configuration” aspect.

6.8.2.5.1.6 The Query out Parameters

6.8.2.5.1.6.1 The query returns the selected servers in

one of two forms: a collection of services or a reference

to an iterator through which the returned servers can be

obtained. The second method is designed for queries

that may return a large number of offers. One can

always assume that results are returned within the first

out parameter (out OfferSeq offers), namely a sequence

of offers. Furthermore, having specified 1 as the value

of the “how_many” parameter, it is ensured that the

answered sequence contains at most one element.

6.8.2.6 Locating the Trading Service

6.8.2.6.1 The productive entity locates the services it

requires using a trading service.

6.8.2.6.2 A client can obtain a reference to the trading

service by invoking the following method on the ORB:

Object resolve_initial_references (

in ObjectId identifier)^

raises (InvalidName);

Where:

the reserved name “TradingService” is passed as the

identifier.

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

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.