semi合集-English.pdf - 第2677页

SEMI E96-1101 © SEMI 1999 , 2001 17 Trade r Clien t Serv er export(1) import( 2) service in teraction(3) Figure 2 6.8.2.2.3 T he diagram suggests th at the server exports its service to the trader. In practice any object…

100%1 / 7923
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:
SEMI E96-1101 © SEMI 1999, 200117
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
register export service offers to the trader.
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
8
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
SEMI E96-1101 © SEMI 1999, 2001 18
6.8.2.4.8 Querying a Registered Service
6.8.2.4.8.1 A server may query the trader the details of
a registered service by passing in the offer id.
Struct OfferInfo {
Object reference;
ServiceTYpeName type;
PropertySeq properties;
};
OfferInfo describe (
in OfferId id);
6.8.2.4.9 Modifying a Registered Service
6.8.2.4.9.1 The server may modify the properties of a
registered service. It may add new properties, delete
existing properties, or modify the value of existing
properties. This is done using the following method:
void modify (
in OfferId id,
in PropertyNameSeq del_list,
in PropertySeq modify_list
);
6.8.2.4.9.2 The properties named in the del_list are
deleted. Properties in the modify_list that do not exist
are added. Properties in the modify_list that exist,
receive a new value.
6.8.2.4.9.3 The modify method can be used to support
changes in the factory configuration, such as new
productive entity being added or deleted, a productive
entity being migrated from one cell to another, a new
load balancing policy for the servers installed, etc.
6.8.2.5 Import Use Cases
6.8.2.5.1 Importing a Service The trader offers an
interface named Lookup that clients can use in order to
locate a service:
void query (
in ServiceTypeName type,
in Constraint constr,
in Preference pref,
in PolicySeq policies,
in SpecifiedProps desired_props,
in unsigned long how_many,
out OfferSeq offers,
out OfferIterator offer_itr,
out PolicyNameSeq limits_applied
);
6.8.2.5.1.1 The Query in Parameters The “in”
parameters are used by the client to specify the service
it needs and the policies for searching it.
• The “type” parameter is key to the central purpose
of trading. It specifies the name of the service type
the client is interested in.
• The “constraint” guides the trader on how to select
a server based on its registered properties. It is a
string that describes the selection in some given
constraint language. The typical constraints will
select a server for a specific productive entity or for
the area the productive entity belongs to. Both
possibilities use the “in” operator for testing the
inclusion of an element in a set. Some examples
follow:
“DieAttachXYZ in ServicedProductive-
Entities”
“Cell22 in ServicedAreas”
6.8.2.5.1.2 “Preferences” specify how should a server
be selected in case the query results in more than one
answer. It is suggested that this parameter be ignored,
which means that the default of first is always used.
6.8.2.5.1.3 The “policies” parameter guides the trader
on how to choose a policy for performing the search.
Search policies are a rather complicated issue, which
can be ignored in the Simple Trader case.
6.8.2.5.1.4 The “desired_props” parameter instructs the
trader which properties are to be returned as part of the
answer (it does not affect the selection itself). This does
not make much sense with the limited set of properties
which has been defined, and can also be ignored (use
none as the parameter value).
6.8.2.5.1.5 The “how_many” parameter is another way
to restrict the number of answers. It is proposed that 1
always be used as the value of this parameter.
NOTE 6: Should areas be used as the selection criteria, the
equipment must be aware of its area within the factory. This
should be supported through the productive entity
“Configuration” aspect.
6.8.2.5.1.6 The Query out Parameters
6.8.2.5.1.6.1 The query returns the selected servers in
one of two forms: a collection of services or a reference
to an iterator through which the returned servers can be
obtained. The second method is designed for queries
that may return a large number of offers. One can
always assume that results are returned within the first
out parameter (out OfferSeq offers), namely a sequence
of offers. Furthermore, having specified 1 as the value
of the “how_many” parameter, it is ensured that the
answered sequence contains at most one element.
6.8.2.6 Locating the Trading Service
6.8.2.6.1 The productive entity locates the services it
requires using a trading service.
6.8.2.6.2 A client can obtain a reference to the trading
service by invoking the following method on the ORB:
Object resolve_initial_references (
in ObjectId identifier)^
raises (InvalidName);
Where:
the reserved name “TradingService” is passed as the
identifier.