semi合集-English.pdf - 第2669页

SEMI E96-1101 © SEMI 1999 , 2001 9 6.3.18.3 T he description also includes all the side effects and exception s that ca n occur as a result of the interactions related to the aspect. 6.3.18.4 If the aspect has any relati…

SEMI E96-1101 © SEMI 1999, 2001 8

ways by which behavioral variation within an aspect

can be modeled: Parameters and Variants.

6.3.13 Parameterized Aspects  An aspect can have

parameters. Differences in productive entities behavior

are modeled by assigning different values to the

parameters. For example if a physical structure aspect

of the productive entity specifies that the productive

entity has a material buffer, the number of material

units (buffer size) that can be placed on the buffer is a

possible parameter. The number of buffers the

productive entity has can be another parameter.

6.3.14 Variants  While parameterization is a very

powerful tool, there are variations in behavior that

cannot be simply modeled as different parameter

values. In this case one can use variants. An aspect is

said to have variants if there are some different

behaviors related to the same aspect. For example the

process control aspect can have a discrete variant and a

continuous variant. In the discrete variant the

productive entity processes discrete units of material

(like the material within a magazine or a single wafer

carrier), while in the continuous variant the productive

entity processes continuously as long as there is

material to be processed.

6.3.14.1 Differences between productive entities are

best modeled as parameters when possible in order to

avoid an explosion of the number of variants, while at

the same time trying to maintain the clarity of the

model.

6.3.14.2 A complete specification of the behavior of a

piece of productive entity should specify variants for

these aspects that have them.

6.3.15 Where do aspects and variants come from? 

They leverage on previous work done by the industry.

GEM (Generic Equipment Model, SEMI E30) is a

primary source for identifying generic aspects. Various

SEMs (Specific Equipment Models) are a source for

specific aspects and very likely for variants. Other

SEMI standards like SEMI E-40 (Standard For

Processing Management) cover other aspects neglected

by GEM.

6.3.16 Specifying Productive Entity Interfaces in a

Factory  In order to specify the interface of a

productive entity it is necessary first to identify the

aspects (or variants of these aspects) supported by the

productive entity, then to specify the interfaces

associated with each aspect. The productive entity

interface specification is then the sum of the interface

specifications for all participating aspects.

6.3.16.1 The interface of an aspect (or variants of these

aspects) is the sum of its Queries, Commands, Event

Notifications and Service Requests and thus the

problem of defining productive entity interface is

reduced to the problem of defining the interfaces of

individual aspects (or variants of these aspects).

6.3.17 Architecture  The productive entity in a

factory is viewed as a composition of its aspects. The

total productive entity behavior is therefore represented

by the sum of all its aspects representing these

behaviors. Each aspect specifies a specific behavior of

productive entity and provides an interface for

incoming messages (queries and commands).

6.3.17.1 An aspect has a name. The productive entity

can answer a reference to one of its aspects given the

aspect name:

AspectInterface aspectNamed(in string

aspectName);

6.3.17.2 An AspectInterface is a virtual interface that

represents a generic aspect. All aspect interfaces inherit

from the generic AspectInterface. When an aspect has

variants, the aspect interface itself is virtual, and all its

variant interfaces inherit from it.

6.3.17.3 Additionally the productive entity answers a

list of the names of all its aspects:

StringList allAspectNames();

6.3.17.4 The usual scenario for a client is to acquire a

reference to the productive entity. It then acquires

references to the productive entity aspects of interest by

querying the productive entity. The client then invokes

methods on the aspect interfaces as required.

6.3.17.5 The client only needs to acquire aspect

interfaces once when it first establishes communication

with the productive entity. From then on it caches the

productive entity interface as well as the references to

the productive entity aspects for further use. The

procedure of acquiring references needs to be repeated

only in case the references become invalid (due to

productive entity restart for example).

6.3.18 How To Add A New Aspect  The definition of

an aspect follows the following aspect definition

pattern. It includes the following items:

6.3.18.1 Aspect Name  Each aspect has a name that

identifies it.

6.3.18.2 Aspect Description  The aspect description

explains the productive entity behavior covered by the

aspect. If the aspect has been derived from an existing

standard, the description includes a reference to this

standard. It explains the concepts and the used

terminology, adds state models and state transition

diagrams if required, and explains the interactions

between the productive entity and the factory elements

related to the aspect. If the interactions require certain

sequences of messages, they are also described (as use

cases or interaction diagrams).

SEMI E96-1101 © SEMI 1999, 20019

6.3.18.3 The description also includes all the side

effects and exceptions that can occur as a result of the

interactions related to the aspect.

6.3.18.4 If the aspect has any relation or effects related

to other aspects, they are also described here.

6.3.19 Variants  If the aspect has variants, each

variant is named and described.

6.3.19.1 IDL  Usually the IDL will include a special

module for the aspect. The module includes data type

definitions specific to the aspect and usually a single

interface that provides the various queries and

commands of the aspect. An aspect that has variants has

an interface per variant. The interfaces for the variants

can be inherited from a common (abstract) aspect

interface.

6.3.19.1.1 An aspect that deals with service requests

should also include an IDL definition for the server that

provides the services. Which is to be done in a separate

module.

6.3.19.2 Aspect Definition Example  Here the

Control State Aspect has been chosen as an example for

aspect definition.

6.3.19.2.1 Aspect Name  Control State

6.3.19.2.2 Aspect Description  The definition of the

Control State Aspect is based on Generic Equipment

Model (GEM) SEMI standard E30.

NOTE 2: The state diagram presented here is simpler than the

one in SEMI E30, since the internal sub-states are irrelevant

to the productive entity interface, and the concept of HOST

OFFLNE is obsolete in a distributed factory environment

6.3.19.2.2.1 The control state model defines the level

of cooperation between the productive entity and the

factory. It also specifies how the operator interacts in

the different levels of factory control.

6.3.19.2.2.2 The control state model provides the

factory with three levels of control over the productive

entity:

6.3.19.2.3 OFFLINE  In the OFFLINE state,

operation of the productive entity is done by the

operator. In the OFFLINE state the productive entity

accepts a query to find out the current control state and

the command to change its control state, but rejects all

other queries or commands (raising the rejected

exception). While in the OFFLINE state the productive

entity produces no events and no service requests.

6.3.19.2.4 LOCAL  In the LOCAL state the

productive entity is operated by the operator.

6.3.19.2.4.1 In the LOCAL state the productive entity

answers all queries from the factory and allows the

factory to execute a limited set of commands. The

commands that are prohibited are those that cause

movement or directly affect the process. The productive

entity sends events and asks for services from the

factory.

6.3.19.2.5 REMOTE  In the REMOTE state the

productive entity is controlled by the factory. The

factory has full access to all the necessary commands to

operate the productive entity through the full process

cycle in an automated manner. The degree of

automation can vary from productive entity to

productive entity and from factory to factory. Generally

operators are required to intervene in setup operations,

operator assist situations, etc. Therefore when in

REMOTE state, even though theoretically fully under

control of the factory, the productive entity should not

restrict the operator from executing essential operations

such as selecting a recipe, pausing or resuming the

process, operator assists, material movement to/from

the productive entity, initiating recipe download and

other productive entity specific commands on a

command by command basis as needed. At the very

least the operator should be able to change the control

state, actuate an emergency stop and interrupt

processing (stop, abort or pause).

6.3.19.2.6 The following diagram depicts the

productive entity Control State model.

OFFLINE

LOCAL REMOTE

12 3 4

Figure 1

6.3.19.2.7 As can be seen from the diagram, transition

from any state is allowed to the two others. The aspect

provides the factory methods for querying the current

state, for initiating a transition to any of the states, and

for events when state transitions occur.

SEMI E96-1101 © SEMI 1999, 2001 10

Variants : None

IDL

module ControlStateModule {

// Type Definitions

enum ControlState {OFFLINE, LOCAL,

REMOTE);

interface ControlState {

// Queries

ControlState getControlState()

raises (EqBasicTypesModule::

CommunicationFailure);

// Commands

void changeControlStateToOffline()

raises (EqBasicTypesModule::

CommunicationFailure);

void changeControlStateToLocal()

raises (EqBasicTypesModule::

CommunicationFailure);

void changeControlStateToRemote()

raises (EqBasicTypesModule::

CommunicationFailure);

};

6.3.19.2.8 The control state aspect can post the

following events:

ControlStateChangedToLocal

ControlStateChangedToRemote

controlStateChangedToOffline

6.3.20 Interface Composition Mapping

6.3.20.1 The DCOM interfaces do not support multi-

ple inheritance. When multiple inheritance is used to

extend functionality, the mapping is not very difficult.

When multiple inheritance is used to “mix in” orthogo-

nal behavior the mapping is more difficult. The CIM

Framework interfaces that only use single inheritance

provide the most reliable mapping. Interfaces that use

multiple inheritance should follow the detailed mapping

rules and ordering provided in the CORBA

Interworking Architecture.

6.3.20.2 OLE Automation also has problems directly

supporting the multiple inheritance of CORBA. The

CORBA Interworking Architecture

provides detailed

mapping rules for making the conversion where

multiple inheritance is used.

6.3.21 Identity Mapping

6.3.21.1 CORBA and DCOM/OLE Automation have

different notions of what object identity means.

CORBA defines an object as a combination of the state

and a set of operations that explicitly define the

instance. An object reference is defined as a name that

reliably and consistently denotes an instantiated object.

A CORBA object exists until it is destroyed; its

lifecycle is controlled by the server.

6.3.21.2 DCOM does not provide the same mechanism

for identifying a particular object. DCOM objects are

usually created when used and their state does not

persist as an object instance. DCOM objects exist while

they are referenced; their lifecycle is controlled by the

client. This is true of OLE Automation objects as well.

6.3.21.3 The CORBA Interworking Architecture

provides mapping solutions for managing the object

lifecycle. The lifecycle issues should be minimized with

the CIM Framework use of component managers to

control object lifecycles. The implementation of

DCOM lifecycle mapping should be encapsulated in the

component manager.

6.3.22 Naming

6.3.22.1 As a mechanism to support initialization

between collaborating components, the name of each

component manager should be registered in a publicly

available namespace along with the object reference for

the component manager. The same name may be reused

unambiguously as long as all occurrences belong to

distinct namespaces. Other objects should be able to

obtain a handle (object reference) to each component

manager by utilizing the namespace through the

operations of a naming service. A trader service may

also be used to perform lookup of component managers

and other objects based on well documented search

criteria. Additional objects may also be registered in the

namespace or trader as appropriate. The component

manager serves as the namespace for the objects it

manages, providing object references for named

objects. Implementations should provide documentation

on how to obtain available object references in either

the namespace or the trader.

6.3.23 Memory Management

6.3.23.1 ORB implementations’ memory allocation

and deallocation services should handle all three types

of OMG IDL parameter passing:

• in –– Memory is caller-allocated and read-only.

The caller is responsible for memory deallocation.

• out –– Memory deallocation depends on the

specific usage of the argument.

• inout –– Memory allocation and deallocation

depend on the specific usage of the argument.

6.3.23.2 The CIM Framework uses only the in para-

meter passing mechanism. Within operations that have

had objects passed by reference, any modification of

the object occurs by using the in parameter as a refer-

ence. Supplier provided extensions to the CIM Frame-

work that use either the out or inout parameter passing

mechanism should document the caller and callee

responsibilities with respect to memory allocation and

deallocation.