semi合集-English.pdf - 第2675页

SEMI E96-1101 © SEMI 1999 , 2001 15 equipment shou ld change in order to accurately track the s tate of th e factor y. C oordinati ng the lot and equipment state changes as a transaction guarantees that factory st a te c…

SEMI E96-1101 © SEMI 1999, 2001 14

6.5.5.2 The event header is constructed by the supplier

of the event and is used by an Event Notification

System (ENS) to route the event to any consumer

registering interest in the event. Note that the structure

of the header may be specific to a particular ENS. The

body of the event is constructed by the event supplier

and is intended for use by the event consumer.

Consumers of events express interest in an event type

by passing the subject name and associated filter data

along to the ENS. The ENS returns an original

connection, called an event channel, to the consumer.

6.5.5.3 Name-value pairs are one mechanism that

should be used to define data either in the header or

body. Specific information within the body varies

according to event type; issues such as allocation are

implementation dependent.

6.5.6 Subject String

6.5.6.1 The event subject string should be defined as a

multi-level hierarchy to assist in event classification

and filtering. The levels designate the CIM Framework

issuing the event component, the issuing interface

within that component, and the event type. Each level

should be delimited by a special character (e.g., a

forward slash: “/”). An example of this syntax is

/RecipeManagement/MachineRecipe/ParameterChanged.

6.5.7 Filter Data and News

6.5.7.1 Filter data are attribute names, values, and

operators that are specified by the consumer and are

used by the filter subsystem to further qualify an event.

News consists of additional attributes and values that

are received by the consumer but not used in the

filtering process and thus are not specified by the

consumer. The consumer specifies the attributes,

values, and operators upon which the event data is

filtered. The actual filtering is performed after the

supplier sends an event but prior to the consumer

receiving the event. The filterable data should be well

known and standardized. News may be used by the

consumer to further filter the event, but the attributes

and values are not standardized. Additionally, news

may be used to convey the identity of the object

generating the event to any consumer of the event.

6.5.7.2 An Event Broker is required to support

subscription to an event channel that has the specified

subject and supports filtering. The actual filtering

mechanism is an implementation dependency. Filter

data is passed to the Event Broker by the consumer to

qualify the particular events that the consumer is

interested in receiving. The filter data specifies

filterable items in which the consumer is interested plus

operators and operands to perform the filtering. The

filtering sub-system should use the filter data to ensure

that a specific event is passed to the consumer. The

interface is simple and does not try to construct

advanced logic to build the filter. The results of the

filtering are anded together, such that the passed event

should meet all of the filter criteria. The need to

specify logical operators (e.g., “or”) on the filter criteria

or the use of query languages should be evaluated.

Extensions to the filter structures would be required to

support these additional capabilities.

NOTE 2: The location of the filtering subsystem is an

implementation detail.

6.6 Distributed Transactions

6.6.1 Many operations defined in the CIM Framework

are related to one another in complex ways that require

multiple operations to be treated as a single unit of

work. For example, grouping operations are combined

with the ability to make an explicit decision to commit

the aggregation of changes, or to abort all of the opera-

tions and return to the prior state. These grouping of

operations are consistent with the familiar concept of a

transaction (most commonly encountered in the context

of database management systems). CIM Framework

objects should be capable of participating in trans-

actions as described below. However, the choice of how

an object participates is implementation specific. For

example, the implementer chooses the implementation

technology and whether a change in object state is

recoverable (that is, whether a change in state can be

rolled back).

6.6.2 A transaction is a contract between two or more

objects to perform some action based upon one or more

requests in some context and having the ACID

properties as follows:

• Atomicity –– State changes are atomic; either all

happen or none happen. These changes include

database changes, messages and events.

• Consistency –– A correct transformation of state.

Actions taken as a group do not violate any of the

integrity constraints associated with the state.

• Isolation –– Even though transactions execute

concurrently, it appears to each transaction T that

others executed either before T or after T, but not

both.

• Durability –– Once a transaction completes

successfully (commits), its changes to state survive

failures.

6.6.3 For example, consider a lot that starts processing

in a piece of equipment. The states of the lot and the

6 J. Gray, Transaction Processing Concepts and Techniques, Morgan

Kaufmann Publishers/Harcourt Brace and Co., 6277 Sea Harbor Dr.,

Orlando, FL, 1993.

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: