semi合集-English.pdf - 第2621页
SEMI E94-0705 © SEMI 2000, 2005 4 6.3.4.3 The fo llowing codes appear in the REQ/IND and RSP/CNF co lumns and are used in the definition of the parameters (e.g., how each param eter is used in each direction): M Mandator…
SEMI E94-0705 © SEMI 2000, 2005 3
6.2.4 The state models included in this standard are a requirement for Control Job Management 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.2.5 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 Control Job Management 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 Control Job Management state models for transition to another state. In the case, the
equipment makes the required transition without any additional actions in this situation.
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
6.3.2.2 Type can be either “N” = Notification or “R” = Request & Response.
6.3.2.3 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:
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.4.1 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.2 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”.
SEMI E94-0705 © SEMI 2000, 2005 4
6.3.4.3 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 Overview
7.1 This section provides an overview of the control job functionality. It does not contain the specifications which
define that functionality.
7.1.1 Control jobs provide a supervisory level of control for process jobs on material processing equipment. They
can be used to reduce the amount of host level interaction required for material processing. A factory host is
provided with methods for instructing the equipment to provide only significant factory level events, such as, a
carrier complete. The ControlJob also supplies methods for the disposition of material after processing.
7.2 User Requirements
7.2.1 To handle the complexity required for manufacturing, equipment must support the ability to coordinate its
processing services with the factory’s needs. The ControlJob provides the services that the factory needs to
accomplish this coordination. The requirements that the ControlJob satisfies include: (1) a method by which the
equipment coordinates related work, for instance, all process jobs associated with a carrier, and (2) a method by
which the equipment can be informed of material destination after processing. The ControlJob is not a type of
process job. It is not responsible for the coordination of the processing resource and the material to be processed.
7.2.2 Initiate and Monitor Process Jobs
7.2.2.1 ControlJobs are queued. ProcessJobs are not queued by equipment that supports control jobs, rather they
are pooled waiting to be scheduled by their respective ControlJob. The ControlJob specifies the order for process
jobs. The equipment follows that order as the equipment’s resources become available (and when material is
available).
7.3 Supplier Requirements
7.3.1 Management of Process Materials
7.3.1.1 Suppliers need to implement an operational model for managing material and processing in a manner
consistent with factory expectations. For instance, the equipment must know when it is finished with a carrier so
that it can either allow or signal the factory for the removal of the carrier. This standard provides mechanisms to
meet this requirement. While the model implies some implementation it is only the external events that are required
by this standard.
7.3.2 Control Job Events
7.3.2.1 Control jobs supply information to host systems as either responses to request messages or as events which
are sent to the host. Typically the equipment can implement the event mechanisms either in GEM (SEMI E30) or
the Event Reporting standard (SEMI E53).
7.3.2.2 All state transitions defined for state models in this document must be able to be reported by separate
collection events as defined in ¶6.2, State Model Methodology. The state model is the Control Job State Model
(Figure 2). The data required for each state model transition event is defined per the following. This data is the
minimum required per event. The host may assign other variable, as applicable, from §13, Variable Data, of this
document, or from other equipment variable data.
7.3.2.3 The following data is required to be available for the Control Job State Model transition collection events:
CtrlJobID
SEMI E94-0705 © SEMI 2000, 2005 5
7.4 Operational Descriptions
7.4.1 The ProcessJob as referenced in the specification of the control job model is the SEMI E40 process job.
Within a ProcessJob the material processing order is managed by the equipment. For some equipment types, the
user may be able to configure the material processing order. If available, this feature shall be fully documented by
the supplier (see SEMI E40).
7.4.2 To support a simpler interface for single substrate processing, it is suggested to use the PRJobMultiCreate (see
SEMI E40) service.
7.4.3 The use of control jobs restricts some SEMI E40 functionality. In particular, the equipment’s queue
management functionality for process jobs is super-seded by the job order as defined in the control job.
7.4.4 The relationship between control jobs and process jobs varies by equipment type. The equipment supplier
should document this relationship. In general aborting or stopping a process job does not stop or abort the control
job. Equipment is responsible to disposition material correctly depending on how a process job ends. In the case of
equipment types that always have a one to one relationship between a control job and a process job it may be
convenient for a process job abort or stop to automatically abort the respective control job. In the same sense, if a
control job specifies more than one process job, it may be convenient for an abort or stop of all process jobs to
automatically abort or stop the respective control job.
8 ControlJob Object Model
8.1 This specification only standardizes the ControlJob object’s interface. The other objects provide a context for
the ControlJob interface. Since only the interface is standardized, it is not a requirement for equipment to
implement a control job object, it is only required that the equipment provide an external interface that provides the
services and behavior defined for the ControlJob.
8.2 Material to Job Linkage
8.2.1 The equipment has relationships with many other components not illustrated in Figure 1. In particular, from
its knowledge based on substrate and carrier tracking capabilities, the equipment shall connect the process job
material list to the materials in the carriers that it has. It is the responsibility of the factory host to make sure that the
description or identifiers of material contained in carriers can be mapped to the material identifiers in the process job
definition.
8.3 Control Jobs and Carriers
8.3.1 A control job may specify work for several carriers. The supplier shall document the behavior of the
equipment in the case where a carrier is specified for use in more than one control job.
8.4 Attribute Definitions
8.4.1 The attributes in Table 1 shall be accessible using the Object Services standard (SEMI E39). Object services
is a set of messages which may be required of any service provider which is modeled by objects. An object model
for a service provides a consistent naming convention for exchanging information between the service provider and
user. Object services implementations shall be consistent with the service’s object and state models. For instance, if
an attribute can only be modified in a certain state, then a request to set that attribute when the model is in the wrong
state shall be rejected (fail). ControlJob Attributes shall be modifiable if and only if the ControlJob is not in either
the EXECUTING or COMPLETED states by using OSS to change them (see ¶14.3.1).