semi合集-English.pdf - 第2897页
SEMI E109-0305 © SEMI 2001, 2005 7 7.4 Alarm Requirements Definition 7.4.1 An alarm requ irements definition tabl e defines t he specific set of alarms re quired by RPMS. The table is divided up by equipment configurat i…
SEMI E109-0305 © SEMI 2001, 2005 6
7.3 Services
7.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.
7.3.2 Service Message Description
7.3.2.1 A service message description table defines the parameters used in a service, as shown in the following
table:
Table 3 Service Message Description Table
Service Name Type Description
#1
Type can be either “N” = Notification or “R” = Request & Response.
7.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).
7.3.3 Service Message Parameter Definition
7.3.3.1 A service parameter dictionary table defines the description, range, and type for parameters used by
services, as shown in the following table:
Table 4 Service Message Parameter Definition Table
Parameter Name Form Description
#1
A row is provided in the table for each parameter used on a service.
7.3.4 Service Message Definition
7.3.4.1 A service message description table defines the parameters used in a service message. It also describes each
message and its cause/effect to the equipment. The columns labeled Req/Ind and Resp/Conf link the parameters to
the direction of the message.
Service Parameter Req/Ind Resp/Conf Description
7.3.4.2 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”.
7.3.4.3 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 must match that in the primary (if
defined).
SEMI E109-0305 © SEMI 2001, 2005 7
7.4 Alarm Requirements Definition
7.4.1 An alarm requirements definition table defines the specific set of alarms required by RPMS. The table is
divided up by equipment configuration, and then by alarm. The danger and affected columns are marked with “X”
characters to show each alarm and its possible impact to operators, equipment, and material. The table format is
shown in the following example:
Equipment Danger Affected
Configuration Alarm Text Potential Imminent Operator Equipment Material
Configuration 1 Alarm 1 X X X X
Alarm 2 X X
Configuration 2 Alarm 3 X X X
Alarm 4 X X X
8 Overview
8.1 The Reticle and Pod Management standard defines the behavior, data, and services required for equipment
supporting automated reticle pod transfer, reticle pod management, and reticle management. This document
provides a standard interface for host/equipment communications regarding the transfer of reticle pods, reticle pod
identification and verification, transfer of reticles to and from equipment, reticle identification and verification,
reticle inspection and qualification, and tracking of reticles. The standardized reticle pod transfer host interface
include transfers to and from the external reticle load ports and internal reticle pod locations, the standardized reticle
host interface include transfers to and from the reticle pod, transfers to and from the internal reticle library positions,
and reticle identification, inspection, verification, qualification and tracking of reticles.
8.2 Single Connection Requirement
8.2.1 The expectation of the production and storage equipment supplier is that this standard be implemented in con-
junction with the GEM interface to their production equipment and without the use of a separate communication
connection.
9 Load Port
9.1 A reticle pod load port (port) is used by the factory to load and unload reticle pods to and from Lithography,
reticle inspection, and bare reticle storage equipment. A reticle pod load port may be used as a reticle pod input load
port, a reticle pod output load port, or as a reticle pod input/output load port, depending upon equipment type,
configuration and/or factory practices. This classification may be fixed or it may be programmable by the user. A
reticle pod load port is generally designed to handle one specific carrier type, reticle SMIF pods (RSP).
9.1.1 The equipment supplier is free to implement Load Ports as objects, but this is not a requirement for
compliance to this standard.
9.2 Load Port Numbering
9.2.1 The reticle pod load port number shall be assigned incrementally from the bottom left to bottom right, then
top left to top right when facing the reticle load ports. The numbering system should start with 101 to differentiate
from FOUP load ports. The reticle pod load port-numbering requirement is to provide a common reference base to
external entities, such as humans.
9.3 Reticle Pod Slot Numbering
9.3.1 The slot numbers for a reticle pod shall be assigned incrementally from the bottom, starting with “1.”
9.4 Reticle Pod Load Port Resource Sharing
9.4.1 A model of a reticle pod load port must account for any mechanical assemblies that are either active during
reticle pod transfer or are capable of interacting with the transfer. The reticle pod load port is responsible for such
mechanisms when the reticle pod load port is in the TRANSFER READY state. If these mechanisms are shared
with other reticle pod load ports, then the sharing must be coordinated.
SEMI E109-0305 © SEMI 2001, 2005 8
9.5 Reticle Pod Load Port Transfer State Model
9.5.1 The purpose of the Reticle Pod Load Port Transfer State Model is to define the host view of a reticle pod
transfer, which includes the host interactions with the equipment necessary to transfer reticle pods to and from
equipment reticle pod load ports. Each reticle pod load port on the equipment shall maintain an independent
instance of this state model.
9.5.2 Reticle Pod Load Port Transfer State Model Diagram
9.5.2.1 Figure 1 is the diagram for the Reticle Pod Load Port Transfer State Model.
9.5.3 Reticle Pod Load Port Transfer State Definitions
9.5.3.1 RETICLE POD LOAD PORT TRANSFER — The super state for the IN SERVICE and OUT OF SERVICE
states.
9.5.3.2 OUT OF SERVICE — Transfer to/from this reticle pod load port is disabled. A transition to IN SERVICE
is required to continue using this reticle pod load port for transfers.
9.5.3.3 IN SERVICE — Transfer to/from this reticle pod load port is enabled. A transition to OUT OF SERVICE
disables the reticle pod load port for transfer use.
9.5.3.4 TRANSFER READY — A sub-state of IN SERVICE. The reticle pod
load port is available for pod transfer.
The transfer can either be manual or automated, and can be a load or an unload. This state contains two sub-states,
which are used depending on whether or not a reticle
pod is present on the load port (READY TO LOAD and
READY TO UNLOAD).
9.5.3.5 READY TO LOAD — A sub-state of TRANSFER READY. When transitioning to the TRANSFER
READY state, if a reticle pod is not present on the specified reticle pod load port, this is the active sub-state. In this
state, the reticle pod load port is available to be loaded with an external reticle pod.
9.5.3.6 READY TO UNLOAD — A sub-state of TRANSFER READY. When transitioning to the TRANSFER
READY state, if a reticle pod is present on the specified reticle pod load port, this is the active sub-state. In this
state, the reticle pod load port is available for unloading of a reticle pod from the reticle pod load port to material
handling equipment. When the reticle pod load port is being used by the equipment, the state shall transition to
TRANSFER BLOCKED.
9.5.3.7 TRANSFER BLOCKED — The reticle pod transfer state is neither READY TO LOAD nor READY TO
UNLOAD. Because of reticle pod load port related activity being performed, transfer is not available to/from this
reticle pod load port at this time.
RETICLE POD LOAD PORT TRANSFER
OUT OF SERVICE
IN SERVICE
TRANSFER BLOCKED
TRANSFER READY
READY TO
LOAD
READY TO
UNLOAD
2 3
6
8 97
10
4 C
5 C
1 H
Figure 1
Reticle Pod Load Port Transfer State Model Diagram