semi合集-English.pdf - 第2563页

SEMI E90-0705 © SEMI 1999, 2005 3 5.2.8 ordered list — a list for which the order in which items appear is significant. 5.2.9 positive integer — may take the v alue of any positive whole number. Messaging protocol may im…

100%1 / 7923
SEMI E90-0705 © SEMI 1999, 2005 2
5.1.3 batch container — a supporting structure that is used to hold substrates for processing, and it may visit
multiple locations in equipment with substrates in it. Whether a batch container is used or not depends on the type of
equipment. Typical example for a batch container is a “boat” used in furnace equipment.
5.1.4 carrier ID — the name to identify a specific substrate carrier.
5.1.5 carrier slot — physical location capable of holding a substrate within cassette type carrier.
5.1.6 carrier slot map — the registry of substrates to the substrate carrier slots.
5.1.7 carrier substrate location — a substrate location within a substrate carrier capable of holding a substrate.
5.1.8 default substrate ID (default ID) — the substrate ID assigned to the substrate when no substrate ID
information is given by the user but the carrier ID for the source carrier is known. The default ID is the combined
text of the source carrier ID and the slot number.
5.1.9 equipment substrate location — a substrate location on a equipment resource.
5.1.10 location ID — the name of a material location.
5.1.11 lot — a group of one or more substrates of the same type. A lot must be organized by the user. The group
may be referred to for tracking of substrates in the factory.
5.1.12 material location — an identifiable place within the equipment or carrier where material can be held.
5.1.13 register — an operation that adds the substrate object to the equipment’s database. This operation is
performed automatically when the equipment receives both a carrier and information from the host about the
contents of the carrier. The operation is also performed automatically when the equipment detects the substrate ID.
5.1.14 remove — the operation that removes a substrate from the equipment.
5.1.15 service — represents a function offered to a user by a provider. A service consists of a sequence of service
primitives, each described by a list of parameters.
5.1.16 substrate — the basic unit of material on which work is performed to create a product. Examples include
wafers, die, plates used for masks, flat panels, circuit boards, and leadframes.
5.1.17 substrate carrier — a carrier to hold substrates to be transferred to/from the equipment. A substrate carrier
has one or more position to hold substrates (carrier substrate location).
5.1.18 substrate history — ordered set of information about the locations visited by the substrate.
5.1.19 substrate ID — identifier of a substrate.
5.1.20
substrate location — a material location which is capable of holding a substrate. For example, but not
limited to, process modules, transfer subsystems, wafer chucks, robot end effecter, and carrier slots.
5.1.21 substrate type — represents the type of the substrate, such as wafers, CDs, flat panels, or masks.
5.2 Data Type
5.2.1 Boolean — may take on one of two possible values, equating to TRUE or FALSE.
5.2.2 enumerated — may take on one of a limited set of possible values. These values may be given logical names,
but they may be represented by any single-item data type except floating point.
5.2.3 floating point — may take on any single numeric value, positive or negative. Messaging protocol may impose
a limit on the range of possible values.
5.2.4 form — type of data: positive integer, unsigned integer, integer, floating point, enumerative, Boolean, text,
formatted text, structure, list, and ordered list.
5.2.5 formatted text — text with an imposed format. This could be by position, by use of special characters, or both.
5.2.6 integer — may take on the value of any negative or unsigned integer. Messaging protocol may impose a limit
on the range of possible values.
5.2.7 list — a set of one or more items that are all of the same form (one of the above forms).
SEMI E90-0705 © SEMI 1999, 2005 3
5.2.8 ordered list — a list for which the order in which items appear is significant.
5.2.9 positive integer — may take the value of any positive whole number. Messaging protocol may impose a limit
on the range of possible values.
5.2.10 structure — a complex set of information consisting of specific sets of items of possibly mixed data types, in
a specified arrangement.
5.2.11 text — a text string. The message protocol restricts its length or ASCII representation. Messaging protocol
may impose restrictions, such as length or ASCII representation.
5.2.12 unsigned integer — may take the value of any positive integer or zero. Messaging protocol may impose a
limit on the range of possible values.
6 Convention
6.1 Harel State Model
6.1.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 “Statecharts: A Visual Formalism for Complex Systems” written by D. Harel in Science of Computer
Programming 8, 1987.
1
6.1.2 A transition table is used with the state chart for clearly describing the character of each state transition. The
table contains the folllowing: a transition number, current state, trigger, new state, and operation in transition.
6.1.3 The state models included in this standard are a requirement for Substrate Tracking compliance. A state
model consists of a state model diagram, state definitions, and a state transition table. When using collection events,
all state transitions in this standard, unless otherwise specified, shall correspond to collection events.
6.1.4 A state model represents the host’s view of the equipment and does not necessarily describe the internal
equipment operation. When using collection events, all Substrate Tracking state model transitions shall be mapped
sequentially into the appropriate internal equipment collection events that satisfy the requirements of those
transitions. In certain implementations, the equipment may enter a state and have already satisfied all of the
conditions required by the Substrate Tracking state models for transition to another state. In this case, the equipment
makes the required transition without any additional actions.
6.2 OMT Object Information Model
6.2.1 The object models are represented using the Object Modeling Technique (OMT) developed by Rumbaugh,
James, et al, in Object Oriented Modeling Design, Prentice Hall, Englewood Cliffs, NJ, 1991.
2
6.2.2 An overview of this notation is provided in the Appendix 1 of SEMI E39.
6.3 Object Attributes Representation
6.3.1 The object information model for standardized objects will be supported by an attribute definition table with
the following column headings:
Attribute Name Definition Access Reqmt Format
The formal text name of the attributes. Description of
information contained.
RO or RW Y or N Refer to the description
below.
6.3.1.1 The Access column uses RO (read only) or RW (read/write) to indicate the access that a service user has to
the attribute.
6.3.1.2 A “Y” or “N” in the Requirement (Reqmt) column indicates if this attribute must be supported in order to
meet the fundamental requirement for the service.
6.3.1.3 The Format column is used for showing the data type of the attribute. (See ¶5.2.)
1 Elsevier Science, P.O. Box 945, New York, NY 10159-0945, http://www.elsevier.nl/homepage/browse.htt
2 Prentice Hall, Inc., Upper Saddle River, NJ 07458, http://www.prenhall.com/divisions/ecs/cscat.html
SEMI E90-0705 © SEMI 1999, 2005 4
6.4 Service Message Representation
6.4.1 Service Resource Definition — A service resource definition table defines the specific sets of messages for a
service group, as shown in the following table:
Message Service Name Type Description
Message name N or R Purpose of the service.
6.4.1.1 Type can be either N = Notification or R = Request. Notification type messages are initiated by a service
provider and the provider does not expect to get the response from the service user or requester.
6.4.1.2 Request messages are initiated by a service user or requester. The Request message asks for data or an
activity from the provider. Request messages expect a specific response message (no presumption on the message
context).
6.4.2 Service Parameter Dictionary — A service parameter dictionary table defines the parameters for one or more
services, as shown in the following table:
Parameter Form Description
Parameter X Data type The parameter called X is B in A.
6.4.2.1 A row is provided in the table for each parameter of the service. The first column contains the name of the
parameter. This is followed by columns describing form and contents of the corresponding primitive.
6.4.2.2 The Form column is used to indicate the type of data contained in a parameter. (See ¶5.2 for definitions.)
6.4.2.3 The Description column in the Service Parameter Dictionary table describes the meaning of the parameter,
the values it can assume, and any interrelationships with other parameters.
6.4.2.4 To prevent the definition of numerous parameters named “XxxList”, this document adopts the convention of
referring to the list as “(List of) Xxxx”. In this case, the definition of the variable Xxx will be given, not of the list.
The term “list” indicates a collection (or set) of zero or more items of the same data type. Where a list is used in
both the request and the response, the list order in the request is retained in the response. A list must contain at least
one element unless zero elements are specifically allowed.
6.4.3 Service Message Definition — A service message definition table defines the parameter used in a service, as
shown in the following table:
Parameter Req/Ind Rsp/Conf Description
Parameter X see below see below A description of the service.
6.4.3.1 The columns labeled Req/Ind and Rsp/Conf 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”. The receiver
may then send a “Response”, which the original sender terms the “Confirmation”.
6.4.3.2 The following codes appear in the Req/Ind and Rsp/Conf columns, and are used in the definition of the
parameters (e.g., 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 values of other parameters.
“U” — User-Defined Parameter
“-” — The parameter is not used.
“=”— (for response only) Indicates that the value of this parameter in the response shall match the value in the
primary (if defined).