semi合集-English.pdf - 第2438页

SEMI E87-0705 © SEMI 1999, 2005 7 7.4 Alarm Requirements Definition 7.4.1 An alarm requirem ents definition table defines t he sp ecific set of alarms required by CMS. The table is divided up by equipment configurati on,…

100%1 / 7923
SEMI E87-0705 © SEMI 1999, 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 Rsp/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 E87-0705 © SEMI 1999, 2005 7
7.4 Alarm Requirements Definition
7.4.1 An alarm requirements definition table defines the specific set of alarms required by CMS. 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 CMS defines the behavior, data, and services required for equipment supporting automated carrier transfer. This
document provides a standard interface for host/equipment communications regarding the transfer of carriers. The
standardized carrier transfer host interface includes not only transfers to and from the external load ports, but also
transfers to and from the internal buffer positions on internal buffer type equipment.
8.2 Single Connection Requirement
8.2.1 The expectation of the production equipment supplier is that this standard be implemented in conjunction with
the GEM interface to their production equipment and without the use of a separate communication connection.
9 Load Port
9.1 A load port (port) is used by the factory to load and unload carriers to and from production equipment. A load
port may be used as an input load port, an output load port, or as an 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 load port is generally designed to handle one specific carrier type, such as substrate cassettes,
leadframe magazines, SMIF pods, or FOUPs.
9.2 Load Port Numbering
9.2.1 The load port number shall be assigned incrementally from the bottom left to bottom right, then top left to top
right when facing the front of the equipment. The load port numbering requirement is to provide a common
reference base to external entities, such as humans.
9.3 Carrier Slot Numbering
9.3.1 The slot numbers for a carrier shall be assigned incrementally from the bottom, starting with “1.”
9.4 Load Port Resource Sharing
9.4.1 A model of a load port must account for any mechanical assemblies that are either active during carrier
transfer or are capable of interacting with the transfer. The load port is responsible for such mechanisms when the
load port is in the TRANSFER READY state. If these mechanisms are shared with other load ports, then the sharing
must be coordinated.
9.5 Load Port Transfer State Model
9.5.1 The purpose of the Load Port Transfer State Model is to define the host view of a carrier transfer, which
includes the host interactions with the equipment necessary to transfer carriers to and from equipment load ports.
Each load port on the equipment shall maintain an independent instance of this state model.
9.5.2 Load Port Transfer State Model Diagram
9.5.2.1 Figure 1 is the diagram for the Load Port Transfer State Model.
SEMI E87-0705 © SEMI 1999, 2005 8
9.5.3 Load Port Transfer State Definitions
9.5.3.1 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 load port is disabled. A transition to IN SERVICE is required to
continue using this load port for transfers.
9.5.3.3 IN SERVICE — Transfer to/from this load port is enabled. A transition to OUT OF SERVICE disables the
load port for transfer use.
9.5.3.4 TRANSFER READY — A sub-state of IN SERVICE. The load port is available for carrier 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 carrier 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 carrier is not present on the specified load port, this is the active sub-state. In this state, the load port is
available to be loaded with an external carrier, or with a carrier that is currently located inside the equipment (i.e.
internal buffer).
9.5.3.6 READY TO UNLOAD — A sub-state of TRANSFER READY. When transitioning to the TRANSFER
READY state, if a carrier is present on the specified load port, this is the active sub-state. In this state, the load port
is available for unloading of a carrier from the loadport to material handling equipment. When the load port is being
used by the equipment, the state shall transition to TRANSFER BLOCKED.
9.5.3.7 TRANSFER BLOCKED — The carrier transfer state is neither READY TO LOAD nor READY TO
UNLOAD. Because of load port related activity being performed, transfer is not available to/from this load port at
this time.
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 2
Load Port Transfer State Model Diagram