semi合集-English.pdf - 第2238页
SEMI E58-0703 © SEMI 1997, 2003 19 other. The table’s identifier provides a method fo r differe ntiating between the three sets of information (g eneric definitions, user-defined definitions, an d supplier-defined de fin…
SEMI E58-0703 © SEMI 1997, 2003
18
Text string for column position. Definition of data element at the corresponding column position. Valid form for data element.
1.16.3.1 The order of elements within a row shall be invariant for a given table instance and shall strictly conform
to the order in which column headers are presented. The length of any given row (the number of elements within the
row) may not exceed the number of defined positions (columns). Partial rows that omit elements at the end of the
row are permitted by the general definition, so long as they retain the meaning of the column positions included.
That is, if a complete row consists of n columns, then an individual row may consist of the first m elements, for m ≤
n.
1.16.3.2 The first element (first column position) of a row must contain a value that is unique for all rows within a
specific table instance. This value may be used as a key to identify a specific row within the table and therefore shall
be a single item (e.g., not a list or structure) and may not be a floating point number. Other elements within the row
may be simple lists or simple structures that do not themselves contain embedded (nested) lists or structures.
10.1.2 Table Attributes — It is also important to be able to exchange information about the table itself. In addition
to the definition of data elements and columns, tables also have predefined attributes. The general table definition
specifies three attributes: the number of columns, the number of rows, and the size of the table exclusive of
formatting used for storing or transferring the table. (See Section 13.2.)
10.1.3 Additional Requirements — Specific table types may have additional requirements and restrictions.
1.16.3.3 ARAMS tables, defined in Sections 10.3 and 10.4, have additional requirements as follows:
• Tables shall be stored in non-volatile memory and shall be capable of subsequent modifications.
• Elements within a row shall follow the order specified in the table definitions.
• All rows shall consist of the full number of columns specified. Partial rows are prohibited.
1.16.3.4 A table is considered structurally valid if it conforms to the requirements in this section and to the row
format defined for its specific type. A structurally valid table may or may not have correct content — that is, the
values within any given row may or may not meet other requirements or expectations.
1.16.3.5 ARAMS tables are provided only for use by the operator and the associated data sent to the host.
Equipment shall not reject a user-defined table that is structurally valid for its table type because of its contents.
Equipment shall not use the contents of tables to validate ARAMS Substate Codes or symptom information
provided by the host.
1.16.3.6 Certain errors in the contents may cause the tables to not work properly in some way. For example, if a
row identifier is used more than once, then the equipment may fail to find any but the first occurrence. However, the
user shall accept responsibilities for any errors in the contents of ARAMS tables.
10.2 ARAMS Substate Table — The ARAMS Substate Table provides extensions to the generic substate definitions
contained in Section 9.
1.16.4 Each row in an ARAMS Substate Table consists of a four-character ARAMS Substate Code as the first
element of the row, and a corresponding text string containing a brief description of the state as the second element.
Table 4 defines the ARAMS Substate Table row format.
Table 4 Table 4 ARAMS Substate Table Row Definition
Column Header Data Element Definition Form
“Code” ARAMS Substate Code. Four-character text string.
“Text” Brief description of ARAMS Substate Code. Formatted text, Sections 9.1, 9.2.
1.16.5 The descriptive text is displayed as a prompt or selection item for the operator when selecting a new
ARAMS state. The description selected is placed in the variable ARAMSText and the corresponding ARAMS
Substate Code is placed in the variable ARAMSState as the new ARAMS state (see Section 11.2).
1.16.6 Extensions to ARAMS codes may be defined by either the user or supplier according to the rules in Section
9.3. The ARAMS Substate Table provides a formal method for each to obtain the codes and text defined by the
SEMI E58-0703 © SEMI 1997, 2003 19
other. The table’s identifier provides a method for differentiating between the three sets of information (generic
definitions, user-defined definitions, and supplier-defined definitions) when necessary to remove ambiguity in
communications. The user at all times shall be able to select an ARAMS state or substate based on the combination
of the three sources of definitions.
1.16.7 An ARAMS Substate Table has a table type of “TableARAMSCode”. The row format is defined in Table 4.
10.3 ARAMS Symptom Table — The user may define an optional table of common human-observable symptoms
called the ARAMS Symptom Table, with a table type of “TableARAMSSymptom”. The row of this table is defined
in Table 5 below.
Table 5 Table 5 ARAMS Symptom Table Row Definition
Column Header Data Element Definition Form
“ID” Identifier of ARAMS symptom. Unsigned integer.
“Indicator” First one to four characters of ARAMS code to which symptom may be
applied.
Formatted text. 1 to 4 characters.
(See Sections 9.2–9.3.)
“Text” Brief description of ARAMS symptom. Text. Maximum length is 80
characters.
1.16.8 Each table row consists of three items: a symptom identifier, an ARAMS substate indicator, and a text string
describing the symptom.
1.16.9 The symptom identifier and text are analogous to the equipment’s alarm or exception identifier and
corresponding text description. The identifier and text should each be unique. A symptom identifier with a value of
zero is reserved to indicate “no symptom”.
1.16.10 The substate indicator consists of the first one to four characters of an ARAMS Substate Code and
indicates the ARAMS state or state/substate where the symptom is to be applied. For example, a symptom that is to
be applied whenever the user requests a change to the UNSCHEDULED DOWNTIME state, including any of its
substates, is assigned an indicator of “5”. A symptom that is to be applied in any case of “UDT/change of
consumable” would use an indicator of “55” as the first two digits of the corresponding ARAMS code.
1.16.11 Whenever the operator requests a change in the ARAMS state or substate, the operator shall be presented
with the text descriptions from the appropriate Symptom Table. The text description of the selection is placed in the
status variable SymptomText, and the corresponding identifier is placed in SymptomID.
11 ARAMS Data
1.17 This section defines the data requirements for ARAMS. This includes requirements for retaining data across a
powerdown or reset. Data retention requirements are classified for each item of ARAMS data in one of the
following ways:
Class 1 — A “soft” value that is reset to a default value as part of system initialization (e.g., DowntimeAlarm)
Class 2 — A “hard” value that never changes (e.g., “EqpSerialNum”)
Class 3 — A “firm” value that changes infrequently and is to be retained in non-volatile memory (e.g.,
“EqpName”)
Class 4 — A “dynamic” value that is retained in non-volatile memory and changes whenever an ARAMS state
transition occurs.
Class 5 — A “very dynamic” value that may change rapidly and is important to retain but does not require absolute
accuracy (e.g., CycleCtr for high throughput equipment). Current values shall be saved in non-volatile memory
periodically at least once per minute.
1.17.1 Except where otherwise specified, data is assumed to be Class 1.
1.17.2 Variables within each section are presented in alphabetical order.
SEMI E58-0703 © SEMI 1997, 2003
20
11.1 Status Information — Status data is information
that is maintained by equipment and in general cannot
be changed by the host. This section defines specific
elements of status data that the user is able to read upon
request and that may be included in event report
messages to the host.
1.17.3 A mechanism shall be provided for the user to
read these values.
1.17.4 All date/time values are text strings with a
timestamp format (see Section 4).
NOTE 16: The timestamp format is not a requirement for
clock precision.
NOTE 17: Subsequent references to subsections of 11.2
below are using the original numbers.
11.1.1 ARAMSInfo — Additional information set or
cleared by the equipment at the time an ARAMS state
transition occurs. Optional. Form: text. 0–80 characters.
11.1.2 ARAMSState — The ARAMS Substate Code
corresponding to the ARAMS state/substate that
became active following the most recent ARAMS state
transition. When an ARAMS state transition occurs,
ARAMSState is the specific code representing the new
ARAMS state/substate. It shall be retained as Class 4
data. The value of “0000” is prohibited. Form:
formatted alphanumeric text. 4 characters.
11.1.3 ARAMSText — The descriptive text
corresponding to the code in ARAMSState. Form: text.
5–80 characters.
11.1.4 Clock — Contains the current value of the date
and time at the equipment. When included in an event
report, Clock represents the timestamp for the
occurrence of the event. Clock may represent the
current value of a real-time date/time clock available
upon demand. Form: formatted text.
11.1.5 CycleCtr — The number of cycles (equipment
cycles) during the lifetime of the equipment (not
resettable). It shall be retained as Class 5 data. Form:
unsigned integer.
NOTE 18: See SEMI E10 for a formal definition of cycle.
11.1.6 DowntimeAlarm — Identifier of the most recent
alarm or exception triggering an equipment-initiated
transition to SCHEDULED DOWNTIME or
UNSCHEDULED DOWNTIME from the PRODUC-
TIVE or STANDBY states. This value is reset to zero
for all other ARAMS state transitions to indicate “no
associated alarm/exception”. Form: unsigned integer.
11.1.7 DowntimeAlarmText — Text associated with
DowntimeAlarm. This value is cleared (set to a zero-
length string) for all ARAMS state transitions except
the transition to SCHEDULED DOWNTIME or UN-
SCHEDULED DOWNTIME from the PRODUCTIVE
or STANDBY states. Form: text. 0–80 characters.
11.1.8 DowntimeData — Text associated with tran-
sitions to, or within, the SCHEDULED or UNSCHED-
ULED DOWNTIME states. For transitions following
powerup/reset (see Section 8.5.2), the value in Down-
timeData shall be set to “Power Loss”. This value is
reset to a zero length (empty) string for other ARAMS
state transitions. When associated with equipment initi-
ated transitions, this may be used to carry fault infor-
mation (e.g., the component serial number of a repaired
component, as defined by the equipment supplied).
When associated with operator-initiated transitions, it
may consist of comments entered at the equipment’s
control panel. Form: text. 0–256 characters.
11.1.9 LastPowerdown — Contains a date/time time-
stamp that estimates the time when the last loss of
power or reset occurred (Transition 11), based on the
value in PowerdownTime on powerup. It shall be
retained as Class 3 data. Form: formatted text.
11.1.10 PowerdownTime — Contains a date/time
timestamp used as an estimate for the timestamp for
loss of power or reset and used for reports associated
with ARAMS state Transition 11. It shall be retained as
Class 5 data. Form: formatted text.
11.1.11 PrdState — The ARAMS code corresponding
to the last user-specified ARAMS Substate Code for
PRODUCTIVE. Used as the default substate for
PRODUCTIVE. Initialized to “1000” at Transition 1.
Form: formatted alphanumeric text. 4 characters.
11.1.12 PrevARAMSState — The ARAMS code
corresponding to the ARAMS state/substate that was
active immediately preceding the most recent ARAMS
state transition. This value is useful for
resynchronization after a period of inability to
communicate. It shall be retained as Class 4 data. Form:
formatted alphanumeric text. 4 characters.
11.1.13 SymptomID — A numeric identifier of a
symptom selected by the user when requesting the
equipment to change states. A value of zero is
equivalent to a selection of “no symptom”. Form:
unsigned integer.
11.1.14 SymptomText — The descriptive text for the
symptom selected by the user when requesting the
equipment to change states. A zero-length string
corresponds to a selection of “no symptom”. Form: text.
0–80 characters.
11.2 Constant Data — Equipment shall provide and
maintain the following values as class 2 data. These
values are set by the equipment manufacturer and shall
not be changeable by the user. These data elements are
required for equipment with formally defined