semi合集-English.pdf - 第2678页

SEMI E96-1101 © SEMI 1999 , 2001 18 6.8.2.4.8 Querying a Registered Servi ce 6.8.2.4.8.1 A server may query the trader t he details of a registered s ervice b y passing in the offe r id. Struct OfferInfo { Object referen…

100%1 / 7923
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.
SEMI E96-1101 © SEMI 1999, 200119
6.8.2.7 A Usage Scenario Example
6.8.2.7.1 Here is an example of a usage scenario.
6.8.2.7.2 In common factory practice, cellular
manufacturing has a factory configuration service
responsible (among other things) for exporting the
factory services to the trading service. The following
are some typical use cases:
1. The factory configuration service registers a wafer
map server to server two cells named CellA and
CellB.
The factory configuration service obtains an initial
reference to the trading service from the ORB:
trader =
orb.resolve_initial_refer
ences(“TradingService”);
The trader answers its Register
interface:
traderRegistry =
trader.register_if();
The factory configuration service builds properties
as a single-itemed sequence of containing one
name/value pair whose name is “ServicedAreas”
and whose value is a sequence of the cell names
{ “CellA”, ‚ CellB”} . It then uses the Register
interface of the Trading Service to register the
service offer:
traderRegistry.export(
waferMapServer,”Wafer Map
Service”, properties);
2. The configuration manager informs a Die Attach
equipment that it belongs to CellA.
ProductiveEntities.setArea(“CellA”);
3. The Die Attach needs a wafer map.
It obtains an initial reference to the trading service
from the ORB:
trader =
orb.resolve_initial_refer
ences(“TradingService”);
The trader answers its Lookup interface:
traderLookup = trader.lookup_if();
The productive entity looks up the trading service
for the wafer map service:
traderLookup.query(
“Wafer Map Service”,
“CellA in ServicedAreas”,
pref, policies, desired_props,
1, preference, offers,
offers_itr, limits_applied);
The wafer map server is returned as the first
element of the offers sequence. The productive
entity may keep the reference to the wafer map
server for future use.
4. The Die Attach can now invoke the service on the
wafer map server:
waferMapServer.getWaferMap(…);
7 Technical Architecture Conformance
7.1 Conformance is defined as “adherence to a stan-
dard or specification in the implementation of a pro-
duct, process, or service.” A conforming implementa-
tion should have an associated implementation con-
formance statement that details the capabilities that
have been implemented. While recognizing that the
CIM Framework is, by definition, not a complete speci-
fication of a MES, a guide for technical architecture
defines conformance for each of its major requirements
as follows.
7.2 Distributed Object Communications Conformance
7.2.1 The CIM Framework object model is based on
the ability to issue service requests to a component
object and to subscribe to events published by the
component object. Component suppliers should explain
how these two forms of communications are accom-
plished so consumers can assess the ease and feasibility
of integrating a component into the factory MES.
Example terminology specific to semiconductor manu-
facturing is provided for clarity. It does not preclude
application specialization for other industries.
7.3 Exception Conformance
7.3.1 Alerting operation requesters of abnormal out-
comes is essential for robust implementations. Compo-
nent suppliers should explain how their implementa-
tions support raising specified system and user-defined
exceptions.
7.4 Event Specification Conformance
7.4.1 Notification of asynchronous occurrences is a
cornerstone of distributed event-driven application
domains such as MES. Suppliers should explain how
their components support event delivery, including the
registration of event suppliers, event consumers and the
provision for Event Broker features for event filtering.
7.5 Distributed Transaction Conformance
7.5.1 Ensuring consistent state changes among compo-
nents is a key concern in the integration of a factory
MES. Component suppliers should explain how their
components support transactional units of work.
7.6 Component Management Conformance
7.6.1 Component suppliers should explain how object
instances are managed. This includes how the object is
identified, constructed, accessed, and destroyed (or flat-
tened in the case of a persistent object). It also includes