semi合集-English.pdf - 第2301页

SEMI E81-0600 © 1999, 2 000 38 Table 1 Object State Definitions and Q uery Table Example State Definition Query for St ate Via ENGINE RUNNING In this state, the automobile's engine is runnin g. bo olean isEngineRunn…

Bank Customer : B ATM : A

1: requestSession( )

2: requestIdentification( )

3: provideIdentification(idNum ber)

4: verifyIdentification( )

Figure 24

Component Interaction Model Example

State Name

Composite State

State 1 State 2State 1 State 2

s ta t e tr a n si ti on

entry point

Figure 25

State Diagram

7.4.3.5.3.2 Table 1 provides a detailed description of

each object state and identifies the query mechanism for

determining if the object is in that state. Given the

example provided in this section, an entry in the State

Definitions and Query Table would appear as shown.

7.4.3.5.4 Object State Transition Tables

7.4.3.5.4.1 Another supplement to the state model is

the Object State Transition Table (Table 2).

7.4.3.5.4.2 It lists the transition from the state diagram

identified by the starting and ending states, and the

event that causes the transition between these states.

7.4.3.5.4.3 Within the CIM Framework specification,

only those triggers and state changes relevant to

external interfacing are shown to help define how an

external entity (in this case a driver) interoperates with

an object (in this example an automobile).

7.4.3.5.4.4 While this table defines triggers for state

transitions, there is no guarantee that the transition will

take place in response to the trigger. In the above

example, if the car is out of gas the engine will not go

to the running state; if the light is burned out, it will not

transition to the on state; depressing the accelerator

pedal when the auto is in the off state will have no

effect, etc. In the CIM Framework, object state can be

queried to ensure successful transitioning in response to

a triggering message. Events are also used in some

cases to inform the client of a transition or change of

state.

Table 1 Object State Definitions and Query Table Example

State Definition Query for State Via

ENGINE RUNNING In this state, the automobile's engine is running. boolean isEngineRunning ( );

sent to instance of Automobile.

Returns true.

Table 2 Object State Transition Table Example

Current State Trigger New State Action

ENGINE STOPPED turn ignition key to right ENGINE RUNNING tachometer indicates positive RPM

ENGINE RUNNING turn ignition key to left ENGINE STOPPED tachometer indicates zero RPM

LIGHTS OFF turn light switch on LIGHTS ON driving at night is enabled

LIGHTS ON turn light switch off LIGHTS OFF driving at night disabled

7.4.4 Textual Specification Language

7.4.4.1 The textual notations used to specify the

framework in this specification, include the following:

• Interface Definition Language (IDL).

• Interface Definition Format.

7.4.4.2 Interface Definition Language (IDL)

7.4.4.2.1 Specifications of CIM Framework

components are composed mainly of interfaces. The

specifics of each interface, while also represented in the

UML-based Component Information Model, are

rigorously specified using OMG IDL. The IDL for CIM

Framework interfaces shall be complete and consistent

as verified by automated IDL compilers. The IDL

portion of SEMI specifications will be available in a

text file format to facilitate such validation and use with

IDL compiler technologies.

7.4.4.2.2 This explanation of IDL is addressed to its

use as a rigorous specification tool. The considerations

of mapping the specifications to an implementation

infrastructure are addressed in SEMI E96.

7.4.4.2.3 Common Object Broker Architecture

(CORBA) [CORBA][CIMArch] defines the architecture

which enables and regulates interoperability between

objects and applications across heterogeneous

languages and computer boundaries. In all Object

Management Group (OMG) specifications, services are

defined as object interfaces expressed in the OMG's

IDL. CORBA standards define IDL and its mapping to

implementation languages (for example, C, C++,

Smalltalk, and Java).

7.4.4.2.4 IDL is a compilable language that describes

the operations that are specified for an interface. The

notation is independent of the language in which the

methods that implement an interface’s operations are

written. This goal is achieved by mapping between the

IDL syntax and whatever language is used to implement

client and server objects. Because IDL is designed

purely for interface specification, it omits the flow

control and operator constructs of an implementation

language. Object classes can implement an interface

differently as long as their behavior conforms to the

interface specification.

7.4.4.2.5 IDL obeys the same lexical rules as C, while

introducing a number of keywords specific to a

distributed system. As IDL is mapped to object-oriented

languages, new constructs will appear. A brief

discourse on some of the keywords and concepts used

in this specification follows. In the examples, words in

italics are user supplied, others are IDL-defined

keywords.

7.4.4.3 Interface Specification Format

7.4.4.3.1 The OMG defines an object’s interface as “a

listing of the operations and attributes that an object

provides. This includes the signatures of the operations,

and the types of the attributes. An interface

specification ideally includes the semantics as well”

[OMA]. The CIM Framework Specification builds

upon this definition to provide additional semantic

information for an interface. These semantics are

captured in an interface description. This section

describes the format of an interface. Each description of

an interface follows this format. The format includes

the following:

• Name — The capitalized noun following the word

“Interface:”

• Inherited Interface — The capitalized noun after

the words “Inherited Interface:”

• Description — A definition of the interface giving

its form and function.

• Exceptions — An IDL specification for reporting

user-defined, framework-related error conditions.

• Published Events — The name of the event

structure that must be placed on an event channel.

The event structure identifies the event through a

subject field. The subject is composed of the

component and interface issuing the event and data

describing the event, and filterable and non-

filterable information. Events are defined at the

interface level; neither posting services nor

subscribers are identified. Thus, events are not tied

to specific services and may be the result of an

internal (to the component) computation.

• Provided Services — A list of publicly available

services provided by this interface. In other words,

a list of non-private, named operations. Each is

given by a description in comment form (i.e.,

/*....*/) followed by its representation in the IDL

syntax.

• Contracted Services — A table of framework

services provided by other interfaces that are being

used by public and/or private services in this

interface. These methods must be available in order

for the documented interface to provide its

described services. Changes to contracted services

may result in changes to the behavior of the

interface making use of these services.

• State Model — See Section 7.4.3.5 for details.

7.4.4.3.2 If no Provided Services are defined for a

particular category, then “No public interfaces” will

appear after the category identifier. If no Exceptions,

Published Events, Contracted Services, or Dynamic

Model are provided, then the word “None” will appear.

State Transition Tables occur only in conjunction with

Dynamic Models.

7.4.4.4 Interface Specification Example

7.4.4.4.1 Table 3 provides a complete illustration of

IDL and CIM Framework interface specification format

usage within this specification. Words in italics are

user-supplied, others are either IDL or CIM

Framework-defined keywords.

8 Conformance to CIM Fram ework Domain

Specifications

8.1 The objective of the CIM Framework is to speed

the creation, use and improvement of a manufacturing

execution system for a semiconductor wafer fabrication

factory by enabling the integration of disparate

components into a cohesive system. The CIM

Framework achieves this objective by specifying a

domain model for MES components. MES component

suppliers use the specification to help establish the

boundaries and interfaces of their components.

Component customers first use the specification to

assess the capabilities of individual components and

then to facilitate the integration of components into a

working system.

8.2 The CIM Framework increases the value of the

MES components by enhancing their qualities of

interoperability, substitutability and extensibility.

• Interoperability is the ability of components to

work together through compatible interfaces.

• Substitutability implies the option to swap one

component with another because they support the

same interfaces.

• Extensibility means the planned capability to add

functionality to a component, again by leveraging

the support for predefined interface specifications.

8.3 Given both the scope and objectives of the CIM

Framework, conformance to the Framework can not be

reduced to a simple “yes or no” proposition. Rather,

component customers must assess component

conformance on a case-by-case basis. Potential buyers

assess conformance in terms of how well a component

supplier demonstrates use of the CIM Framework

specification to enable rapid component integration.

8.4 With this background, here then are factors for

consumers to consider in assessing MES components

and for suppliers to comprehend when building

components. These factors form the basis for

communication between buyers and sellers of

components regarding conformance to the CIM

Framework specifications.