semi合集-English.pdf - 第1691页

SEMI E40-0705 © SEMI 1995, 2005 3 4.2.14 service-user — the software control entity that is the user of any of the related services. 4.2.15 supervisor — an entity or entities hav ing supervisory control responsibilities …

100%1 / 7923
SEMI E40-0705 © SEMI 1995, 2005 2
NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the
responsibility of the users of this standard to establish appropriate safety and health practices and determine the
applicability of regulatory or other limitations prior to use.
3 Referenced Standards and Documents
3.1 SEMI Standards
SEMI E5 — SEMI Equipment Communications Standard 2 Message Content (SECS-II)
SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM)
SEMI E39 — Object Services Standard: Concepts, Behavior, and Services
SEMI E53 — Event Reporting
NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.
4 Terminology
4.1 The following definitions are arranged in alphabetical order. Some definitions use terms defined elsewhere
within this section. No references beyond this section should be necessary for a basic understanding of these terms.
4.2 Definitions
4.2.1 agent — an intelligent system within a factory that provides one or more service resources and uses the
services of other agents. A generalization of host, equipment, cell, cluster, cluster module, station controller, and
work station. Agents are associated with a physical system or a collection of physical systems, including computer
platforms.
4.2.2 form — type of data representing information contained in an object attribute or service message parameter.
4.2.3 fundamental requirements — the requirements for information and behavior that must be satisfied for
compliance to a standard. Fundamental requirements apply to specific areas of application, objects, or services.
4.2.4 post-conditioning — activities performed by the processing resource after departure of the material being
processed but related to the processing of that material (e.g., cleanup).
4.2.5 pre-conditioning — activities performed by the processing resource before arrival of the material being
processed but related to the processing of that material.
4.2.6 processing agent — an intelligent system within a factory which is independently capable of providing
manufacturing value added to material.
4.2.7 processing resource — an entity within a processing agent which provides the manufacturing value added to
material.
4.2.8 process job — a material processing job for a processing resource specifying and tracking the processing to be
applied to the material.
4.2.9 recipe — the pre-planned and reusable portion of the set of instructions, settings, and parameters under control
of a processing resource that determines the processing environment seen by the material. Recipes may be subject to
change between runs or processing cycles.
4.2.10 recipe executor — a component of a module that stores and executes recipes.
4.2.11 recipe namespace — a logical management domain with the responsibility for the storage and management
of recipes. It ensures the uniqueness of recipe identifiers and provides services pertaining to recipes stored within
that domain.
4.2.12 service — the set of messages and definition of the behavior of a service-provider that enables remote access
to a particular functionality.
4.2.13 service-provider — the software control entity that is the provider of a particular functionality which may be
accessible remotely.
SEMI E40-0705 © SEMI 1995, 2005 3
4.2.14 service-user — the software control entity that is the user of any of the related services.
4.2.15 supervisor — an entity or entities having supervisory control responsibilities for one or more processing
resource. It is the service-user of the processing management services.
4.2.16 tuning — specification of information which supplements the pre-defined recipe used to achieve the
particular process goals.
4.3 Data Type
4.3.1 boolean — may take on one of two possible values, equating to TRUE or FALSE.
4.3.2 enumerated — may take on one of a limited set of possible values. These values may be given logical names,
but they may be represented by any single-item data type.
4.3.3 form — type of data: positive integer, unsigned integer, integer, enumerated, boolean, text, formatted text,
structure, list, ordered list.
4.3.4 formatted text — a text string with an imposed format. This could be by position, by use of special characters,
or both.
4.3.5 integer — may take on the value of any negative or unsigned integer. Messaging protocol may impose a limit
on the range of possible values.
4.3.6 list — a set of one or more items that are all of the same form (one of the above forms).
4.3.7 ordered list — a list for which the order in which items appear is significant.
4.3.8 positive integer — may take the value of any positive whole number. Messaging protocol may impose a limit
on the range of possible values.
4.3.9 structure — a complex structure consisting of a specific set of items, of possibly mixed data types, in a
specified arrangement.
4.3.10 text — a text string. Messaging protocol may impose restrictions, such as length or ASCII representation.
4.3.11 unsigned integer — may take the value of any positive integer or zero. Messaging protocol may impose a
limit on the range of possible values.
5 Conventions
5.1 Harel State Model — This document uses the Harel State Chart notation to describe the dynamic behavior of the
objects defined. An overview of this notation is presented in an appendix of SEMI E30. The formal definition of this
notation is presented in Science of Computer Programming 8, “Statecharts: A Visual Formalism for Complex
Systems,” by D. Harel, 1987.
5.1.1 The Harel notation does not include the concept of “creation” and “deletion” of state models to represent
transient entities. The “job” described in this document is such an entity, where each new job created uses a copy of
the same state model. In this document, an oval is used to denote the creation of an entity and also the deletion of
that entity.
5.1.2 Transition tables are provided in conjunction with the state diagrams to describe explicitly the nature of each
state transition. A transition contains columns for Transition #, Current State, Trigger, New State, Action(s). The
“trigger” (column 3) for the transition occurs while in the “current” state. The “actions” (column 5) include a
combination of (1) actions taken upon exit of the current state, (2) actions taken upon entry of the new state, and (3)
actions taken which are most closely associated with the transition. No differentiation is made.
5.1.3 The state models included in this standard are a requirement for Processing Management compliance. A state
model consists of a state model diagram, state definitions, and a state transition table. When using SEMI E30, E53
or similar style collection events, all state transitions in this standard, unless otherwise specified, shall correspond to
collection events.
5.1.4 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 Processing Management state model transitions shall be
mapped sequentially into the appropriate internal equipment collection events that satisfy the requirements of those
SEMI E40-0705 © SEMI 1995, 2005 4
transitions. In certain implementations, the equipment may enter a state and have already satisfied all of the
conditions required by the Processing Management state models for transition to another state. In the case, the
equipment makes the required transition without any additional actions in this situation.
5.2 Object Attribute Representation — The object information models for standardized objects will be supported by
an attribute definition table with the following column headings:
Attribute Name Definition Access Requirement Form
The formal text name of the attribute. Description of the information contained. RO or RW Y or N (see below)
5.2.1 The Access column uses RO (Read Only) or RW (Read and Write) to indicate the access that service-users
have to the attribute.
5.2.2 A ‘Y’ or ‘N’ in the requirement (Rqmt) column indicates if this attribute must be supported in order to meet
fundamental compliance for the service.
5.2.3 The Form column is used to indicate the format of the attribute. (See ¶4.1 for definitions.)
5.3 Service Message Representation
5.3.1 Service Resource Definition — A service resource definition table defines the specific set of messages for a
given service group, as shown in the following table:
Message Service Name Type Description
Message Name N or R The intent of the service.
5.3.1.1 Type can be either N = Notification or R = Request.
5.3.1.2 Notification type messages are initiated by the service provider, and the provider does not expect to get a
response from the consumer/subscriber.
5.3.1.3 Request messages are initiated by a service consumer or subscriber. Request messages ask for data or an
activity from the provider. Request messages expect a specific response message (no presumption on the message
content).
5.3.2 Service Parameter Dictionary — A service parameter dictionary table defines the parameters used in a
service, as shown in the following table:
Parameter Form Description
Parameter X Data Type A parameter called X is B in A.
5.3.2.1 A row is provided in the table for each parameter of the service. The first column contains the name of the
parameter. This is followed by columns describing the form and contents of the corresponding primitive.
5.3.2.2 The Form column is used to indicate the type of data contained in a parameter. (See ¶4.2 for definitions.)
5.3.2.3 The Description column in the Service Parameter Dictionary table describes the meaning of the parameter,
the values it can take on, and any inter-relationships with other parameters.
5.3.2.4 To prevent the definition of numerous parameters named “XxxList,” this document adopts the convention of
referring to the list as “(List of) Xxx.” In this case, the definition of the variable Xxx will be given, not of the list.
The term “list” indicates a collection (or set) of zero or more items of the same data type. Where a list is used in both
the request and the response, the list order in the request is retained in the response. A list must contain at least one
element unless zero elements are specifically allowed.