semi合集-English.pdf - 第3206页
SEMI E127-0705 © SEMI 2003, 2005 7 6.1.6 Lists of Data — Lists of data shall be identifie d as 0+ when a nu ll list is permitted. Otherwise, they shall be identified as 1+. 6.2 Stat e Model C onventions 6.2.1 This docum …
SEMI E127-0705 © SEMI 2003, 2005 6
5.2.5 inspection module, n. — a measurement module that inspects substrates and reports information regarding
anomalies. Inspection modules may determine the location of anomalies relative to a coordinate system and may
also provide other types of data related to the anomaly.
5.2.6 integrated measurement module, n. — a measurement module intended to be integrated into manufacturing
equipment, and with the capability of receiving substrates from the equipment, measuring those substrates, and
returning the substrates and the measurement results to the equipment and other concerned clients.
5.2.7 measurement module, n. — an equipment module whose intended function is to measure or inspect the
product and to report the results. Measurement of the product is the factory’s means of gaining feedback on the
manufacturing process.
5.2.8 measurement recipe, n. — a recipe or portion of a recipe intended for use during a measurement, that
describes among other things the locations for measurement. This does not need to be a physically separate recipe.
5.2.9 metrology module, n. — a measurement module that collects and reports information on specific
predetermined locations or features on a substrate with consistent data structure, or reports general information
about the entire substrate.
5.2.10 object-based, adj. — a programming language, or database, is called object-based if it supports the concept
of data abstraction, but partly or entirely lacks more advanced concepts such as class, inheritance, polymorphism,
and so on. [Oestereich, Bernd, “Developing Software with UML,” Addison-Wesley (1999)]
5.2.11 substrate context information, n. — information concerning the substrate that may be useful to for analysis,
such as process flow step, substrate orientation, the identifier of the process equipment/chamber most likely to have
affected results, the recipe run on that equipment/chamber, etc.
5.2.12 substrate orientation, n. — the angle of rotation from normal. For wafers, this is the angle of rotation from
the primary fiducial.
6 Conventions
6.1 Object Conventions
6.1.1 This document conforms to the conventions for objects established by SEMI E39, including object diagrams,
object terminology, and requirements for standardized objects. However, the notation used for object diagrams is
the Universal Modeling Language (UML) notation (see ¶4.2 for additional detail).
6.1.2 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. Where
words are concatenated, they retain their capitalization to enhance readability.
6.1.3 Object Attributes — Attribute tables define those public attributes that can be read and set through the basic
OSS services GetAttr and SetAttr. Simple attributes have a single data type as their value. Complex or compound
attributes are made up of an ordered set of other elements, either a list or a structure. See SEMI Compilation of
Terms for the definition of “form” for both the list of valid data type formats and for the different types of formats
themselves.
6.1.4 Attribute Definitions — Attributes are formally defined in an attribute definition table with the following
form:
Attribute Name Definition Access Reqd Form
The formal name of the
attribute.
Defines the requirements of the
attribute.
RO or RW Reqd or
Optional
Data type: see SEMI E39 ¶4.5.
Complex attributes must declare the
order of their components.
6.1.5 Complex Attribute Data — The individual data items of Complex attributes are defined in a separate Attribute
Definition Table as individual attributes. However, these data items are not Attributes and the SEMI E39 GetAttr
and SetAttr services are not valid for them.
SEMI E127-0705 © SEMI 2003, 2005 7
6.1.6 Lists of Data — Lists of data shall be identified as 0+ when a null list is permitted. Otherwise, they shall be
identified as 1+.
6.2 State Model Conventions
6.2.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” written by D. Harel in Science of Computer
Programming 8, 1987.
6.2.2 The Harel convention has no concepts of “creation” and “extinction” for expressing the state model of 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). This is the
convention used in the OMT notation as well.
6.2.3 Transition tables are provided in conjunction with the state diagrams to explicitly describe the nature of each
state transition as shown in the state model diagram. 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.
No differentiation is made between these cases.
# Previous State Trigger New State Actions Comments
6.2.4 State models are referred to in the Event Variables tables as an acronym consisting of the first letters of the
state model name, ending in “SM” for State Model. Specific transitions with the state model are represented with
the state model acronym plus “-Tn”, where n represents the number of the transition. State model transitions
without numbers are not expected to be reported.
6.3 Service Message Representation
6.3.1 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, which does
not require a response.
6.3.2 Service Definition Table — 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.3.2.1 Type can be either “N” = Notification or “R” = Request & Response.
6.3.2.2 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.3.3 Service Parameter Dictionary — A service parameter dictionary table defines the description, format and its
possible value for parameters used by services, as shown in the table below. A row is provided in the table for each
parameter of a service. See SEMI Compilation of Terms for the definition of “form” for both the list of valid data
type formats and for the different types of these formats.
SEMI E127-0705 © SEMI 2003, 2005 8
Parameter Name Description Format: Possible Value
6.3.4 Service Message Definition — 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.3.4.1 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.3.4.2 The following codes appear in the REQ/IND and RSP/CNF 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 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 ).
7 General Requirements
7.1 Protocol Requirements
7.1.1 The communication protocol used must support use of all data types, including lists, structures, and arrays.
7.2 Required Standards
7.2.1 This section discusses specific SEMI standards that have been assumed for the proper operation of an
integrated measurement module (IMM) as specified in this document.
7.2.2 SEMI E40 — Fundamental compliance to SEMI E40 for Processing Management is required. A process job
queue is not required unless the IMM is capable of holding multiple substrates.
7.2.3 SEMI E90 — Fundamental compliance to SEMI E90 for Substrate Objects and Substrate Location Objects is
required.
7.2.4 SEMI E116 — Fundamental compliance to SEMI E116 (Equipment Performance Tracking) is required. The
IMM is to be considered an EPT Module. Guidance for implementing EPT for the IMM is provided in Related
Information 2.
7.3 Required Basic Capabilities
7.3.1 The requirements in this section are concerned with basic capabilities that may be satisfied in different ways.
Because of this flexibility, the method supported must be clearly documented by the IMM supplier. The IMM
Control Client should allow on-line configuration by a user to achieve seamless “plug and play” integration.
NOTE 2: New standards are evolving and may become the required method for satisfying these basic capabilities in the future.
7.3.1.1 These capabilities are specified between the IMM and its control client. If, as expected for integrated
measurement modules, the client is located within or near the process tool, it is up to the client to have the ability to
communicate the appropriate information (alarm reporting, recipe upload/download) to the host.