semi合集-English.pdf - 第2676页

SEMI E96-1101 © SEMI 1999 , 2001 16 6.6.12 The AC ID properties prov ided by either OTS or MT S may be used for CI M Fra mewor k tran sactio ns. Many implementation details are supplier sp ecific; however, th e major arc…

SEMI E96-1101 © SEMI 1999, 200115

equipment should change in order to accurately track

the state of the factory. Coordinating the lot and

equipment state changes as a transaction guarantees that

factory state can be recovered accurately.

6.6.4 Transactions are created by a user of a service

(the client) requesting an operation from a provider of a

service (the server). To maintain the ACID properties

of a transaction, the server should be able to return to

the state prior to the request for the operation in the

event of a failure. In this sense, the server should be

recoverable. Failures are either software or hardware

events that prevent the completion of the transaction.

The server is a recoverable server if it is able to main-

tain the ACID properties when faced with a failure.

6.6.5 Transactions should be designed in a manner

such that they do not span a period of interaction with

an external entity such as a person using a GUI or a

piece of equipment. Waiting for the response from an

external entity can result in locks being held for multi-

ple seconds, minutes, or longer. This can adversely

affect other transactions by causing time-outs or dead-

locks. These types of transactions can usually be split

into multiple serially executed transactions with some

small amount of extra revalidation of current states at

succeeding transactions.

6.6.6 Coordinating the completion of transactions may

involve multiple servers and may entail either commit-

ting the successfully completed transaction or rolling

back the unsuccessful transaction. This activity imposes

additional overhead on a system. Suppliers and

consumers should assess the impact of transactions on

system performance during component design and

selection of transactional events.

6.6.7 Transactions may cause physical effects in the

manufacturing system that cannot simply be rolled back

in accordance with the ACID properties. Application

and system designers should include ways to modify

the logical view of the system to match the physical

reality of the manufacturing floor if such a mismatch

occurs.

6.6.8 Transactions can create CIM Framework events

as state changes occur. As the transaction may not be

committed at the point of event creation, the event

should not be visible outside the transaction until the

final commit point. The details of performing this task

are implementation dependent. For example, the event

announcing the completion of a lot at a processing step

should not be published until the processing step

completion transaction is committed. Otherwise, the

event could be published, but the transaction subse-

quently rolled back, creating a system inconsistency.

6.6.9 Transactions should be able to be nested, thus

providing the ability to define transactions within other

transactions. These sub-transactions can generate addi-

tional sub-transactions, thus forming a hierarchy of

transactions. In the spirit of maintaining the ACID

properties, each sub-transaction can issue a commit or

rollback for its piece of work. The results of the sub-

transaction are only available to the parent transaction.

The sub-transactions commit becomes permanent only

after it issues a local commit and all ancestors commit.

If the parent transaction does a rollback, all descendent

transactions are rolled back regardless of any local

commits.

6.6.10 There are two types of transactions widely sup-

ported for distributed object infrastructures. The OMA

support for transactions is described in the OMG’s

Object Transaction Service (OTS). Microsoft provides

support for transactions with its Microsoft Transaction

Server (MTS) product. The OTS closely aligns with

other standards such as The Open Group Distributed

Transaction Processing (DTP) model.

Using industry

standard protocols as a base, the OTS supports inter-

facing with products from the major database suppliers.

Using the provided OTS interfaces and information

about The Open Group standards, non-ORB supplied

database interfaces could be developed to allow for

interoperability with other cooperating transaction

services. MTS also supports transactions with major

database suppliers through use of The Open Group XA

interface. Using the MTS Software Developer Kit,

transaction support can be extended to other resources.

6.6.11 Combining heterogeneous components based on

a combination of OTS and MTS is not straightfor-ward.

Although both rely on the XA interface for dis-tributed

transaction coordination, they are not designed to

operate with each other. Both OTS and MTS hide the

details of transactions from users. This makes either so-

lution very convenient, but makes linking them together

more difficult. For example, suppose a CORBA-based

component adhering to OTS should interact with an

MTS-based component. The scenario calls for the

CORBA based component to use the XA interface to

work with the MTS provided transaction coordinator

(see Gray

for additional information on distributed

transactions). However, in hiding XA complexity, OTS

also hides the ability to readily specify the transaction

coordinator (OTS does this behind the scenes). CIM

Framework component developers and consumers

should determine the relative need for distributed trans-

actions spanning OTS and MTS against the additional

complexity of developing a XA-based mechanism for

combined OTS and MTS transactions.

7 The Open Group, Distributed TP: The XA+ Specification, Version

2, The Open Group, 11 Cambridge Center, Cambridge MA, 1994.

SEMI E96-1101 © SEMI 1999, 2001 16

6.6.12 The ACID properties provided by either OTS or

MTS may be used for CIM Framework transactions.

Many implementation details are supplier specific;

however, the major architectural principles have been

described above.

6.7 Component Management

6.7.1 A component refers to a collection of related

interfaces that form a coherent subsystem. Components

may have a component manager to assist in the tracking

and management of the instantiated interfaces (objects).

The objects that are managed by a component manager

are called managed objects.

6.7.2 Component Level Interface

6.7.2.1 Component managers provide services such as

reporting on the collection of instances they manage

and creating object instances. The component manager

provides the following:

Object references to managed objects.

Collective queries for some aspect (usually a state)

across all the objects it manages.

Services for:

Creating a managed object and returning a

reference to it, or receiving an object reference

to a newly created object. The component

manager then “registers” the object reference.

Removing managed objects.

Finding managed objects.

6.7.3 Component Manager Classification

6.7.3.1 Component Managers are classified by their

allowable number of instances.

6.7.3.2 Unique Component Managers

6.7.3.2.1 A unique component manager describes a

component manager for which there is only one running

instance in an MES implementation. Unique component

managers are used when a single point of factory level

control or focus is required. An example use of this pat-

tern might be an interface within a Dispatcher compo-

nent called DispatchingManager. This might be a

unique component manager because multiple dispatch-

ing systems on the factory floor could create problems

with work scheduling.

6.7.3.3 Non-Unique Component Managers

6.7.3.3.1 A non-unique component manager describes

a component manager for which multiple instances may

be running in an installed MES system. The component

manager instances are derived from the same code base,

but have separate instance data for each running in-

stance. Non-unique component managers should be

registered with the factory with some selection criteria

in order for a requester to be able to obtain a handle to

the correct instance. An example use of this pattern is

the scenario in which several ProductManagers are

employed within a production system.

6.8 Architecture For Service Requests

6.8.1 Services are implemented by a factory object that

is the service provider. The productive entity in a

factory invokes the service methods on that factory

object.

6.8.1.1 For example, a recipe server could offer the

following interface:

interface RecipeManagementServer {

// upload a recipe

void acceptRecipe(

in string recipeName,

in Recipe recipe);

// download a recipe

Recipe provideRecipe(in string

recipeName);

};

6.8.1.2 The problem with service requests is that they

require a flow from the productive entity to the factory

object that provides the service. This kind of reverse

flow contradicts the principle of layered architecture by

which the productive entity is supposed to be a more

primitive entity, unaware of factory objects, their

locations and their structures. The trading service

addresses this problem.

6.8.2 Trading Service

6.8.2.1 Using Trading Service

6.8.2.1.1 A trading helps clients to locate services. An

object that must locate a service must know how to

access the trading service.

6.8.2.1.2 A trading service relies on the description of

the service itself, rather than any attribute relating to the

server that provides the service (such as the name of the

server). It must be able to describe the service it

requires. The trading server locates a server that fulfills

the required service profile.

NOTE 3: The trading service described here is based on the

CORBA COS Trading Object Service, implementations of

which are available from vendors of CORBA environments.

The solution however does not require the full generality of

the COS Trading Object Service, and can be viewed as a strict

subset of the latter.

6.8.2.2 The Trading Concept

6.8.2.2.1 A trading scenario is based on a server that

exports a service to a trader. The client then imports the

service from the trader, receiving a reference to the

server on which it can invoke the service.

6.8.2.2.2 This is depicted in the following diagram:

Trader

Client Server

export(1)import(2)

service interaction(3)

Figure 2

6.8.2.2.3 The diagram suggests that the server exports

its service to the trader. In practice any object aware of

the server and its provided services could assume this

job. For example, a factory configuration object could

be responsible for exporting all services to the trader.

6.8.2.3 Trading Service Models

6.8.2.3.1 The trader has to implement two interfaces:

• The Register interface allows other objects to

NOTE 4: This interface is used e.g. by the service

provider to inform the trader about the services the

service provider offers.

• The Lookup interface allows other objects to

lookup the trader for a required service.

NOTE 5: This interface is used by e.g. the productive

entity to find a service provider for a specific service.

6.8.2.4 Export Use Cases

6.8.2.4.1 The trader offers an interface named Register,

that allows a server to register its services with the

trader.

6.8.2.4.2 The IDL definitions given below are for

illustrative purposes. They are extracted from the COS

Trading Object Service specification [OMG]. For

clarity, not all services are included here.

6.8.2.4.3 Exporting a Service

6.8.2.4.4 To export a service, the server uses:

OfferId export (

in Object reference,

in ServiceTypeName type,

in PropertySeq properties

);

6.8.2.4.5 The server passes a reference to itself, and

describes its offer by passing in a service type name and

a list of properties of the service. The trader answers an

offer id, through which the server can further

manipulate its offer.

6.8.2.4.6 Factory service offers are described as

follows:

6.8.2.4.6.1 Service Type Name

6.8.2.4.6.2 The type is a string naming the service

itself. We are yet to agree upon the services supported

by this specification. The following are obvious

candidates:

• Recipe Service

• Wafer Map Service

• Fixtures Service

6.8.2.4.6.3 Properties

6.8.2.4.6.3.1 Properties are used to characterize and

specialize the service. A property is a name/value pair,

where the name is a string naming the property, and the

value specifies the property value offered by the server.

The constraint language defined by the COS Trading

Object Service [OMG] limits the type of values to the

basic data types (such as numbers, chars, booleans and

strings) and sequences of these.

6.8.2.4.6.3.2 The following properties are to be used

for registering factory services:

• “Serviced Productive entities”  The value of this

property is a list of the ids of the productive entities

serviced by this server. This allows multiple

servers of the same type to be installed, and

partition the productive entity service among the

available servers. Note that it does not require the

server to know the productive entities it serves,

since the server registration can be done by a

factory configuration service.

• “Serviced Areas”  The value of this property is a

string collection naming the factory areas serviced

by the server. This property is another means of

partitioning the service among multiple servers.

The area could be a name of a cell controller if

cellular manufacturing is practiced, or the name of

any organizational unit implemented by the

factory, and known to the factory configuration

service.

6.8.2.4.7 Withdrawing a Service

6.8.2.4.7.1 To withdraw a registered service, the server

(or the configuration service) uses:

void withdraw (

in OfferId Id);

8 In back end fixtures is a generic name for durables and consumable

materials