semi合集-English.pdf - 第910页

SEMI E118-1104 E © SEMI 2002, 2004 4 Parameter Name Description Format: Possible Value 6.3.3.2 A row is provided in the table for each pa rameter of a service. 6.3.4 Service Message Definition 6.3.5 A service me ssage de…

100%1 / 7923
SEMI E118-1104
E
© SEMI 2002, 2004 3
6 Conventions
6.1 State Model Methodology
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 “State Charts: A Visual Formalism for Complex Systems” written by D. Harel in Science of Computer
Programming 8, 1987
2
.
6.1.2 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:
Actions taken upon exit of the previous state.
Actions taken upon entry of the new state.
Actions taken which are most closely associated with the transition.
6.1.2.1 No differentiation is made between these cases.
6.2 Object Notation
6.2.1 The object models in Related Information 2 use the Object Modeling Technique (OMT) developed by
Rumbaugh, James, et al, in Object-Oriented Modeling and Design
3
. An overview of this notation is provided in
SEMI E39, Object Services Standard: Concepts, Behavior, and Services.
Num Previous State Trigger New State Actions Comments
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, that does not
require a response.
6.3.2 Service Definition
6.3.2.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
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
6.3.3.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:
2 Elsevier Science, P.O. Box 945, New York, NY 10159-0945, http://www.elsevier.nl/homepage/browse.htt
3 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen, Object-Oriented Modeling and Design
, Englewood
Cliffs, New Jersey: Prentice-Hall, 1991.
SEMI E118-1104
E
© SEMI 2002, 2004 4
Parameter Name Description Format: Possible Value
6.3.3.2 A row is provided in the table for each parameter of a service.
6.3.4 Service Message Definition
6.3.5 A service message definition table defines the parameters used in a service, as shown in the following table:
Parameter Req/Ind Rsp/Cnf Comment
6.3.5.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.5.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):
Code Description
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 Overview
7.1 The Wafer ID Reader Model defines the behavior and services (functions). The Wafer ID Reader is a small
intelligent system, typically used as a subsystem within equipment.
7.1.1 The primary functionality of the Wafer ID Reader is to read the identifier of the wafer (Wafer ID).
7.1.2 The acronym WIDR is used to refer to the Wafer ID Reader.
7.1.3 An object model for the WIDR is provided in Related Information 2 – Object Model.
7.2 Number of Heads
7.2.1 A WIDR provides one or more ID reader heads and is connected to an upstream controller by a single
interface. This allows the upstream controller to control either one head or multiple heads using the same interface
specification.
7.2.2 Single Head Configuration
7.2.2.1 In the case of a single head, the head may be presented as an integrated part of the WIDR.
7.2.3 Multiple Head Configuration
7.2.3.1 In the case of multiple heads, some services are logically performed by the WIDR, and the individual heads
logically perform others. The individual heads are numbered sequentially and may be referenced individually by the
upstream controller. Note that the upstream controller does not communicate directly with the heads. All
communications are between the upstream controller and the WIDR unit.
7.2.3.2 In the multi-head case, the WIDR shall allow independent control of the heads. Multiple transactions
invoking services performed by the individual heads may be open at the same time. For example, when a read
SEMI E118-1104
E
© SEMI 2002, 2004 5
command is sent to one head, the host can send additional commands such as a read command and a status
confirmation command to another head before the first head sends the response to the first command.
7.3 Upstream Controller
7.3.1 The WIDR provides certain services when requested by the upstream controller. The upstream controller
sends a message requesting the specified service, and the WIDR sends a message with the response.
7.3.2 This standard assumes that an upstream controller initiates each service message to the WIDR, and the WIDR
sends its response to the upstream controller. The upstream controller must watch the response time to monitor the
communication timeout. This standard will define the recommended method for handling exceptions caused by
timeouts.
7.3.3 In addition, some WIDR may provide asynchronous notification to the upstream controller. Examples of this
include, but are not limited to, the detection of a fault condition resulting in an alarm. Asynchronous notification is
not required for compliance to this standard.
8 Attributes
8.1 An attribute is an item of information about an entity that is maintained and is available by request. There is
certain information concerning the WIDR that is of potential interest to the upstream controller, including the
manufacturer, the model, and the serial number of the device. This information is considered as attributes of the
WIDR and is available on request.
8.2 WIDR Attribute Definition Table
8.2.1 Table 1 defines the attributes of the WIDR subsystem.
Table 1 WIDR Attribute Definitions
Attribute Name Description Access Reqd Form
Fundamental
Configuration Number of heads. RO Y Text
AlarmStatus Current WIDR substate of ALARM
STATUS.
RO Y Enumerated:
0 = NO ALARMS
1 = ALARMS
OperationalStatus Current WIDR substate of
OPERATIONAL.
RO
Y Enumerated:
IDLE
BUSY
MAINTENANCE
SoftwareRevisionLevel Revision (version) of software. RO Y Text
Optional
DateInstalled Date the subsystem was installed. RO N Protocol dependent.
DeviceType Identifiers subsystem as a WIDR. RO N WIDR (Text)
HardwareRevisionLevel Revision number of the hardware. RO N Text
MaintenanceData Supplier dependent. RO N Text
Manufacturer The name or identifier of the
manufacturer.
RO N Protocol dependent.
ModelNumber The manufacturers model designation. RO N Text
SerialNumber Subsystem serial number assigned by
manufacturer.
RO N Protocol dependent.
8.3 Reader Head Attributes
8.3.1 Table 2 defines the attributes for the Reader Head.
NOTE 2: In the case of an integrated single head, the attributes in Table 2 are regarded as an extension of Table 1.