semi合集-English.pdf - 第2226页
SEMI E58-0703 © SEMI 1997, 2003 7 diagram of the states and the transitions between states, and a state transition table. The diagram of the state model uses the Harel State Chart notation . An overview of this notation …
SEMI E58-0703 © SEMI 1997, 2003
6
4.2.18 symptom — A user-detected event (e.g., smoke
observed).
4.2.19 timestamp — The notation of the date and time
of the occurrence of an event [SEMI E42].
4.2.20 timestamp format — A text string of the form
“YYYYMMDDhhmmsscc”, where:
YYYY = year (e.g., 1995)
MM = month (01–12)
DD = day (01–31)
hh = hour (00–23)
mm = minute (00–59)
ss = second (00–59)
cc = centisecond (00–99)
4.2.21 trigger — An event that causes a change in the
state of the equipment. Examples are changes in sensor
readings, alarms, messages received from the host, and
operator commands.
4.2.22 user — Any entity interacting with the
equipment, either locally as an operator or remotely via
the host. From the equipment’s viewpoint, both the
operator and the host represent the user.
4.3 data types — The following terms are used to
represent valid types of data.
4.3.1 form — Type of data: positive integer, unsigned
integer, integer, floating point (float) enumerated,
Boolean, text, formatted text, structure, list, ordered list.
4.3.2 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.3 unsigned integer — May take the value of any
positive integer or zero. Messaging protocol may
impose a limit on the range of possible values.
4.3.4 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.5 floating point (float) — May take on any single
(real) numeric value, positive or negative. Messaging
protocol may impose a limit on the range of possible
values.
4.3.6 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.7 boolean — May take on one of two possible
values, equating to TRUE and FALSE.
4.3.8 text — A character string. Messaging protocol
may impose restrictions, such as length or ASCII
representation.
4.3.9 formatted text — A character string with an
imposed format. This could be by position, by use of
special characters, or both.
4.3.10 structure — A specific set of items, of possibly
mixed data types, in a specified arrangement.
4.3.11 list — A set of one or more items that are all of
the same form (one of the above forms).
4.3.12 ordered list — A set of items in specific
sequence.
5 Basic Requirements
1.5 An ARAMS-compliant implementation requires
provision of certain capabilities defined by other
standards: accessibility to status information, event
reporting, alarm management, and provision of an
internal time-and-date clock. These requirements may
be satisfied through compliance to one of the following
sets of requirements:
• The Generic Equipment Model (GEM):
• Clock Services
• Event Notification
• Status Data Collection
• Equipment Constants
• Alarm Management
• The following set of standards:
• Object Services Standard
• Clock Services, Cluster Tool Module
Communications
• Event Reporting Standard
• Exception Management Standard
1.6 The developer is expected to be familiar with the
appropriate documents before attempting to implement
ARAMS (see Section 16.1).
6 Conventions
This document follows the conventions for state model
methodology and service definitions used by the SEMI
standards referenced in Section 3.
6.1 State Model Methodology — This document uses
the state model methodology in SEMI E30 to describe
the behavior of equipment. A state model has three
elements: definitions of each state and substate, a
SEMI E58-0703 © SEMI 1997, 2003 7
diagram of the states and the transitions between states,
and a state transition table. The diagram of the state
model uses the Harel State Chart notation. 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.
1.6.1 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 #, Current State, Trigger, New
State, Action(s), and Comment. The “trigger” (column
3) for the transition occurs while in the “current” state.
The “actions” (column 5) includes 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 between these cases.
#
Current
State
Trigger
New
State
Action(s)
Comment
Transition #
1.7 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
Reqd
Form
The formal
text name of
the attribute.
Description of
the information
contained.
RO or RW Y or N (see
below)
1.7.1 The Access column uses RO (Read Only) or RW
(Read and Write) to indicate the access that users of the
service have to the attribute.
1.7.2 A ‘Y’ or ‘N’ in the Required (Reqd) column
indicates if this attribute must be supported in order to
meet fundamental compliance for the service.
1.7.3 The Form column is used to indicate the format
of the attribute (see Section 4 for definitions).
6.2 Service Message Representation
1.7.4 Service Resource Definition — 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
Message name N or R The intent of the service
1.7.4.1 Type can be either N = Notification or R =
Request.
1.7.4.2 Notification type messages are initiated by the
service provider and the provider does not expect to get
a response from the service user (consumer/subscriber).
1.7.4.3 Request messages are initiated by a service
user. Request messages ask for data or an activity from
the provider. Request messages expect a specific
response message (no presumption on the message
content).
1.7.5 Service Parameter Dictionary — A service
parameter dictionary table defines the parameters for
one or more services, as shown in the following table:
Parameter Description Form
Parameter X A parameter called X is B in A. Data type.
1.7.5.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
parameter.
1.7.5.2 The Form column is used to indicate the type
of data contained in a parameter (see Section 4 for
definitions).
1.7.5.3 The Description column in the Service
Parameter Dictionary table describes the meaning of the
parameter, the allowed values, and any
interrelationships with other parameters.
1.7.5.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.
1.7.5.5 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.
1.7.6 Service Message Definition — A service
message definition table defines the parameters used
in a service, as shown in the following table:
Parameter Req/Ind Rsp/Conf Description
Parameter X (see below) (see below) A description of the
parameter.
SEMI E58-0703 © SEMI 1997, 2003
8
1.7.6.1 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”.
1.7.6.2 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 a completely
optional or may depend on the value 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).
7 Overview
1.8 This section provides an overview of how
ARAMS will be applied and the capabilities that
ARAMS defines.
1.9 Systems that are used to track equipment
performance should be based on SEMI E10’s
definitions of the six basic equipment states. The
tracking systems typically rely on factory personnel to
manually enter SEMI E10 state changes. Individual
factories may have further company-specific and/or
facilities-specific refinements of the states. For
example, the basic equipment state may be
“unscheduled downtime” with a refinement of “waiting
for parts”. In addition to entering a state change, the
operator (who may be the production operator, a
process engineer, an equipment engineer, or a supplier
field service engineer) may select from a pre-defined
set of behaviors (symptoms) that prompted the change
of state, such as “smoke observed”.
1.10 Specifications provided by ARAMS are intended
to support the integration of equipment systems with
factory tracking systems. For this purpose, equipment
needs to be cognizant of the ARAMS states and
substates, must know its current state, and must follow
common rules for determining if equipment-initiated
transitions can be made. In addition, the user needs to
be able to interact with the tracking system at either the
host system’s console or the equipment’s operator
console. This requires that the operator be able to enter
certain information at the equipment’s console: a new
state or substate request, and specific observed behavior
that prompted the request. The host system is then
notified that a change in state has occurred.
1.11 Integrated systems are able to provide more
accurate data for those state changes than the equipment
alone is able to detect. While the user is still required to
initiate state changes for other conditions, this can be
accomplished either directly at the equipment’s console
or remotely at the host tracking system terminal.
1.12 Exchange of information is accomplished
through standardization of the meaning and form of
data and the specification of the message services for
the exchange. ARAMS provides generic definitions for
the common substates described in SEMI E10. ARAMS
also defines two tables and the message services
required for the equipment and host to exchange tables.
The first table contains a set of ARAMS substate
definitions (an ARAMS code identifying the substate)
and a corresponding description. The second table
defines a set of symptoms with a numeric symptom
identifier and a corresponding description.
1.13 While the above discussion assumes that the
equipment is interacting with host systems, the
ARAMS state model only requires interactions with a
“user”, which might be either a local operator or a host
system.
8 State Models
1.14 This section defines the formal state model for
ARAMS, called the ARAMS State Model, which is
required for ARAMS compliance. To clarify the
relationships between this state model and the
equipment’s operations, it introduces a second state
model, called the General Equipment Operations
Model, which is used for purposes of illustration. The
General Equipment Operations Model is assumed to
exist in some form but is not required for ARAMS
compliance.
1.14.1 This document follows the convention of using
upper-case to denote the formal names of states.
Informal references may use lower case. For example,
the ARAMS states SCHEDULED DOWNTIME and
UNSCHEDULED DOWNTIME may be referred to as
downtime states.
1.14.2 Detailed requirements for equipment behavior
are provided in Section 16.
NOTE 6: Although the equipment is unable to detect a
condition of no power, it is able to detect when the
INITIALIZING state has been entered and is able to
differentiate between a hard reset (Transition 6) and a soft re-
boot (Transition 5).