semi合集-English.pdf - 第2667页
SEMI E96-1101 © SEMI 1999 , 2001 7 Architecture 4 (Ch apter 15, “Interworking Architecture,” Chapte r 16, “Mapping COM to CORBA,” and Ch apter 17, “Mappin g OLE Automati on to CORBA ”) defines mapping approaches covering…
SEMI E96-1101 © SEMI 1999, 2001 6
internal logic and provides a software interface to
access this logic
5.2.38 query a message sent to a server (e.g. the
productive entity) by a client interested in some
information from the server (state of the productive
entity). A query may or may not have arguments and it
always has an answer. The semantics of a query is that
some information from the server is returned, but the
query cannot effect any change to the state of the
server.
5.2.39 service a function provided by a service
provider that is performed through an operation
specified by the provider.
5.2.40 service provider, server an object providing
services to other objects as specified by its published
operations.
5.2.41 signature — a signature is the name,
parameters, return values, and exceptions for a specific
operation.
5.2.42 substitutability — the ability to replace a given
component from one supplier with a functionally
equivalent component from another supplier without
impacting the other components or its clients in the
system.
5.2.43 trader service — a collection of names with
associated properties of features for each name and
methods for manipulating and inspection that
collection.
5.2.44 type — a declaration that describes the common
properties and behavior for a collection of objects.
Types classify objects according to a common inter-
face; classes classify objects according to a common
implementation.
6 Technical Architecture Guidance
6.1 The computing infrastructure provides the distrib-
uted computing environment for CIM Framework
applications. This infrastructure includes the operating
system, networking and communications, data storage
and access, user interface and presentation services,
event distribution, systems management, and many
other elements. Of these many infrastructure elements,
a guide for technical architecture specifies a small
subset of key services that need to be standardized in
order to facilitate and streamline system integration
between conformant CIM Framework implementations.
6.2 The CIM Framework relies on publicly available
specifications to define the use of infrastructure
services wherever such published specifications exist.
The largest single source for openly defined specifica-
tions for distributed object services is the Object Man-
agement Architecture.
5
Reference to this guide does not
imply that CIM Framework conformant implement-
ations should implement the referenced services. The
implementations that realize these infrastructure
technologies are outside the scope of this guide. The
technology choices made by implementers should be
kept transparent to the CIM Framework to the greatest
extent possible.
6.3 Distributed Object Communication
6.3.1 The CIM Framework documents assume the use
of software infrastructure to provide distributed com-
munication between objects in an implementation. The
acronym ORB was originated by the OMG to describe
its distributed object communication infrastructure, but
is sometimes used in a more general sense. In this doc-
ument ORB is used only to refer to the OMG specified
technology and the more general term “message bus” is
used for the diverse class of distributed communication
mechanisms for communication between objects. The
message bus is used to allow objects to make requests
and receive responses from other objects. An object can
communicate through the message bus with objects that
are local or remote. Location transparency allows the
object to remain ignorant of the actual location of the
object with which it communicates.
6.3.2 A primary criterion for a message bus imple-
mentation is its ability to deliver all messages specified
by the interfaces of the CIM Framework components.
To accomplish this, the message bus should provide the
ability to support or map a specified interface, including
its inherited features, data types, operations, object
references, and exceptions to and from runtime
marshaled transport formats.
6.3.3 Alternate message bus implementation technolo-
gies are supported by the CIM Framework by mapping
the OMG IDL for the CIM Framework interfaces into a
specific message bus implementation. The Common
Object Request Broker: Architecture and Specification
4
contains sections that define this mapping from
CORBA to COM and from CORBA to OLE Automa-
tion. These sections, called the “Interworking Architec-
ture,” cover detailed rules for mapping OMG IDL,
types, and exceptions to compatible interfaces in COM
and OLE Automation.
6.3.4 From a high level perspective, the DCOM and
CORBA message buses are comparable. The DCOM
capabilities are roughly equivalent to those of an ORB.
However, with a lower level analysis, differences show
up in data types, inheritance, object identity, and the
handling of exceptions. The CORBA Interworking
5 Object Management Group. The Object Management Architecture
Guide, Revision 3.0, John Wiley and Sons, New York NY, 1995.
SEMI E96-1101 © SEMI 1999, 20017
Architecture
4
(Chapter 15, “Interworking Architecture,”
Chapter 16, “Mapping COM to CORBA,” and Chapter
17, “Mapping OLE Automation to CORBA”) defines
mapping approaches covering:
Interface Mapping,
Interface Composition Mapping, and
Identity Mapping.
6.3.5 These areas should be addressed in order to pro-
vide a mapping between the OMG IDL used to specify
CIM Framework interfaces and the message bus used
for implementation. If the mapping is not specific (i.e.,
can occur in multiple ways) then two implementations
may not necessarily be able to communicate even if
they use the same message bus type. Although the
CORBA Interworking Architecture is specific to
Microsoft technologies, it could provide the foundation
for future interworking mappings.
6.3.6 The current CIM Framework interfaces are
specified in OMG IDL. The interfaces can be directly
compiled and used with any of the available ORB
implementations on the market.
6.3.7 The only way to provide such a direct solution
using Microsoft DCOM would be to create additional
CIM Framework interface specifications in DCOM
MIDL and/or OLE Automation ODL. This would allow
direct support for message bus functionality using
DCOM. For example, the CIM Framework memory
management requirement of “in” for parameter passing
(see Section 6.3.15) would be directly supported by
MIDL and DCOM but since the CORBA exception
model is significantly richer than the DCOM exception
model, mapping CORBA exceptions to COM would
require an additional protocol to be defined for DCOM.
6.3.8 The CORBA Interworking Architecture supports
mapping the current CIM Framework interfaces defined
in OMG IDL to DCOM MIDL or OLE Automation
ODL. This mapping is detailed enough that the map-
ping should always provide the same MIDL/ODL solu-
tion. Even though the current scope does not include
interoperability between implementations on DCOM
and CORBA (see Section 3.2), the issue of mapping the
interface is still the same. This would also provide a
step towards true interoperability using CORBA/
DCOM bridge products that are beginning to become
available.
6.3.9 Microsoft also provides an extension called OLE
Automation. These interfaces are described in Object
Definition Language (ODL). The OLE interfaces can be
invoked dynamically by a client with no compile-time
interface knowledge. The OLE data types are a subset
of the types supported in DCOM, and there is no sup-
port for user-defined constructed types. The mapping
solution differs for the DCOM and the OLE Automa-
tion. OLE Automation does not provide as clean a map-
ping from OMG IDL as DCOM does. This limitation
may not allow some of the interfaces to translate com-
pletely to an OLE Automation implementation. Thus,
component suppliers using an OLE Automation imple-
mentation should explain impact on interfaces that were
not fully supported due to the Automation restrictions.
6.3.10 The CORBA Interworking Architecture covers
mapping issues for the major areas of concern for the
CIM Framework. The areas of primary importance are
the Interface mapping, Interface composition mapping,
Identity mapping, and Exception mapping. The
CORBA Interworking Architecture gives detailed map-
pings for each of these areas and deals with the DCOM
and OLE Automation mappings separately. The follow-
ing five subsections summarize these mapping issues.
6.3.11 Interface Mapping
6.3.11.1 The OMG IDL primitives, constructed data
types, and object references map closely to DCOM. The
inherited CORBA interfaces may be represented as
multiple DCOM interfaces. The CORBA attributes may
be mapped to get and set operations in DCOM
interfaces.
6.3.11.2 The OMG IDL primitives map to OLE
primitives except for special cases. The OLE interfaces
do not support constructed data types and should be
mapped to specially constructed interfaces. CORBA
object references map to OLE Automation interface
pointers. There are difficulties in mapping CORBA
multiple inheritance to OLE Automation interfaces
documented in the CORBA specification.
4
CORBA
attributes may be mapped to get and set operations in
OLE Automation interfaces.
6.3.12 Aspects The total behavior of a piece of a
productive entity in a factory can be viewed as the
union of distinct behaviors. Each such isolated behavior
(or functional area) is called an aspect of the productive
entity.
6.3.12.1 There is great variety in productive entity
behavior. There are generic aspects that are shared by
all or most productive entities (such as recipe
management or process state model or material
tracking) and there are aspects that are specific to one
productive entity type or to a particular productive
entity model. The behavior of each productive entity is
the union of the particular aspects of that productive
entity.
6.3.12.2 Saying that two pieces of productive entities
have a certain aspect does not necessarily mean that
they behave absolutely the same way. There are two
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).