semi合集-English.pdf - 第2741页
SEMI E98-1102 © SEMI 2000, 2002 6 6.2.3 Names of OBEM Objects — The names of abstract object types st art with the word “Abstract” and are not intended t o be directly impl emented. All other object s define d in OBEM ar…
SEMI E98-1102 © SEMI 2000, 2002 5
one location in the factory to another location.
Transport equipment may also provide short-term
storage for material. (See also AMHS.)
5.2.49 virtual sensor (synthetic sensor, derived sensor)
— one or more calculated measured values that are
based on one or more sensor readings. This may
include results based on neural nets, statistical analysis,
etc. or may be based on a single sensor value.
5.2.50 work — a group of one or more substrates that
undergo processing in a factory. Something that may be
work in one kind of factory, such as reticles and
leadframes, may have a different role in other types of
factories. Work includes, but is not limited to, material
intended as product. For example, it may include
product substrates, test substrates, and filler substrates.
5.2.50.1 From the point of view of the equipment,
work is either new (processing has not started),
completed (all intended processing has been performed,
terminated, or aborted, including rejected and resorted
work, and no further processing is to be done) or
incomplete (work in progress, on hold).
6 Conventions
6.1 This section defines the conventions followed by
this document.
6.2 Object Conventions — This document conforms to
the conventions for objects established by SEMI E39,
including object diagrams, object terminology, and re-
quirements for standardized objects. Accordingly, not-
ation is based on Object Modeling Technique (OMT) as
described in Object Oriented Modeling Design
.
2
6.2.1 Formal Name of an Object — The text capitalizes
formal object name references. Similar to the way
capitalization is normally used when discussing entities.
When describing something in the general (like cities)
lower case is used, but when a specific entity is of
interest (New York City), then first letters are
capitalized.
6.2.2 Components of Complex Attributes — The names
of object attributes defined in tables are left-justified.
The individual elements of complex attributes are right-
justified in order of appearance below the complex
attribute.
2 Rumbaugh, James, et al, Object Oriented Modeling Design,
Prentice Hall, Englewood Cliffs, NJ, c1991.
SEMI E98-1102 © SEMI 2000, 2002 6
6.2.3 Names of OBEM Objects — The names of abstract object types start with the word “Abstract” and are not
intended to be directly implemented. All other objects defined in OBEM are concrete types that may be directly
implemented.
6.3 State Model Conventions
6.3.1 This document uses the Harel state chart convention for describing dynamic operation of defined objects. The
outline of this convention is described in an attachment of SEMI E30. The official definition of this convention is
described in “State charts: A Visual Formalism for Complex Systems”
3
.
6.3.2 The Harel convention has not the concept of state models of “creation” and “extinction” for expressing a
temporary entity. The “job” described in this document is such an entity, and a copy of the same state model is used
for an independent job newly created. In this document, a circle with a black circle inside is used for expressing
extinction of an entity. A filled black circle denotes the entry to the state model (the entity creation).
6.3.3 Transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each
state transition. A transition table contains columns for Transition number, Previous State, Trigger, New State,
Actions, and Comments. The “trigger” (column 3) for the transition occurs while in the “previous” state. The
“actions” (column 5) includes a combination of:
1. Actions taken upon exit of the previous state.
2. Actions taken upon entry of the new state.
3. Actions taken which are most closely associated with the transition.
6.3.3.1 No differentiation is made between these cases.
Num Previous State Trigger New State Actions Comments
6.4 Service Message Representation — Services are functions or methods that may be provided by either the
equipment or the host. A service message may be either a request message, which always requires a response, or a
notification message, that does not require a response.
6.4.1 Service Definition
6.4.1.1 A service definition table defines the specific set of messages for a given service resource, as shown in the
following table:
Message Service Name Type Description
6.4.1.2 Type can be either “N” = Notification or “R” = Request & Response.
6.4.1.3 Notification type messages are initiated by the service provider (e.g., the equipment) and the provider does
not expect to get a response from the service user. Request messages are initiated by a service user (e.g., the host).
Request messages ask for data or an activity from the provider. Request messages expect a specific response
message (no presumption on the message content).
6.4.2 Service Parameter Dictionary
6.4.2.1 A service parameter dictionary table defines the description, format and its possible value for parameters
used by services, as shown in the following table:
Parameter Name Description Format: Possible Value
6.4.2.2 A row is provided in the table for each parameter of a service.
3 D. Harel, “State charts: A Visual Formalism for Complex Systems”, Science of Computer Programming 8,
1987.
SEMI E98-1102 © SEMI 2000, 2002 7
6.4.3 Service Message Definition
6.4.3.1 A service message definition table defines the parameters used in a service, as shown in the following table:
Parameter Req/Ind Res/Cnf Comment
6.4.3.2 The columns labeled REQ/IND and RSP/CNF link the parameters to the direction of the message. The
message sent by the initiator is called the “Request”. The receiver terms this message the “Indication” or the request.
The receiver may then send a “Response” which the original sender terms the “Confirmation”.
6.4.3.3 The following codes appear in the REQ/IND and RSP/CNF columns and are used in the definition of the
parameters (eg., how each parameter is used in each direction):
M Mandatory Parameter — Must be given a valid value.
C Conditional Parameter — May be defined in some circumstances and undefined in others. Whether a value is
given may be completely optional or may depend on the value of the other parameter.
U User-Defined Parameter.
- The parameter is not used.
= (For response only.) Indicates that the value of this parameter in the response must match that in the primary (if
defined).
6.5 OBEM Standard Structure
6.5.1 The remaining part of this document is organized as follows:
6.5.1.1 Section 7 contains background information to provide a context for the Object-Based Equipment Model.
6.5.1.2 Sections 8 provides an overview of two major views of the equipment: the functional view and the internal
composition view.
6.5.1.3 Section 9 introduces the OBEM object model: the interface inheritance hierarchy and the rules of
aggregation that together form the foundation of the OBEM model of equipment.
6.5.1.4 Section 11 defines the requirements for the component objects within the equipment interface hierarchy: and
other related objects of significance not defined elsewhere.
6.5.1.5 Section 12 defines the message services used in OBEM that are not defined in other standards.
6.5.1.6 Section 13 defines the services that are required of the user (factory system, remote access, and operator).
6.5.1.7 Section 14 specifies the minimum requirements and optional capabilities for compliance to the OBEM
standard.
6.5.1.8 Section 15 provides scenarios showing typical message flows during operation.
6.5.2 Additional sections are provided as related information: examples and additional material that are not part of
the standard itself. These include models for linked litho, 300 mm equipment, the relationship of OBEM and the
CIM Framework, and representations of date and time.
7 Background
7.1 Both modern manufacturing processes and modern manufacturing equipment are increasingly complex. A
single installation of equipment may have hundreds or thousands of sensors and actuators. In order to manage this
complexity, better methods of referencing the internal components of equipment are needed. Use of the object
paradigm provides a means for the equipment to describe its internal composition to the factory in a natural way.
7.2 Definition of standardized objects allows the factory to be specific about its requirements and its need for
information.