semi合集-English.pdf - 第2620页
SEMI E94-0705 © SEMI 2000, 2005 3 6.2.4 The state models included i n this standard are a re quirement f or Control Job Management com pliance. A state model consists of a state model di agram , sta te definitions, and a…
SEMI E94-0705 © SEMI 2000, 2005 2
5.1.3 equipment — the intelligent system that communicates with the host.
5.1.4 host — the intelligent system that communicates with the equipment.
5.1.5 life cycle — the processes and activities of something from its beginning (creation) to its ending.
5.1.6 multi-module equipment — equipment that has more than one distinct processing resource (e.g., chamber).
5.1.7 production equipment — equipment that measures or adds value to the product.
5.1.8 protocol independent — for software, this means that the message descriptions are independent of delivery
mechanisms.
5.1.9 set-up — a description of the current process capability of an equipment.
5.1.10 substrate — basic unit of material on which work is performed to create a product. Examples include
wafers, lead frames, CD’s, die, flat panel displays, circuit boards, and disks.
5.1.11 substrate port — the carrier location from which substrates are accessed by the equipment.
5.1.12 uni-carrier — term for an equipment mode of operation in which all material is returned to the source carrier
after processing.
5.1.13 user start — activities that are initiated on a system by another system or operator.
6 Conventions
6.1 Object Models
6.1.1 This standard uses object models to specify the control job interface.
6.1.2 Object Services Standard
6.1.2.1 This document conforms to the conventions established by SEMI E39.
6.1.3 Formal Name of an Object
6.1.3.1 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.
6.2 State Model Methodology
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.
1
6.2.2 The Harel convention does not have the concept of state models of “creation” and “extinction” for expressing
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).
6.2.3 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:
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.
6.2.3.1 No differentiation is made between these cases.
1 Elsevier Science, P.O. Box 945, New York, NY 10159-0945, http://www.elsevier.nl/homepage/browse.htt
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