semi合集-English.pdf - 第2236页

SEMI E58-0703 © SEMI 1997, 2003 17 • The new code defines a refinement of a primary ARAMS state, as defi ned in Section 9, throug h use of the characters in the third an d fourth positions. • Alphabetic characters are pe…

100%1 / 7923
SEMI E58-0703 © SEMI 1997, 2003
16
alternative text strings. This provides the consistency,
across different equipment, that is important to the user.
PRODUCTIVE
1000 “PRD” (default productive code)
1100 “PRD/Regular production”
1200 “PRD/Work for third parties”
1300 “PRD/Rework”
1400 “PRD/Engineering runs”
1500 “PRD/Reserved*”
1600 “PRD/Reserved”
1700 “PRD/Reserved”
1800 “PRD/Reserved”
1900 “PRD/Reserved”
STANDBY
2000 “SBY” (default standby code)
2100 “SBY/No operator”
2200 “SBY/No product”
2300 “SBY/No support tool”*
2400 “SBY/Associated cluster module down”
2500 “SBY/No host”
2600 “SBY/Reserved”
2700 “SBY/Reserved”
2800 “SBY/Reserved”
2900 “SBY/Reserved”
* NOTE: A support tool is a mechanical device used by, but
not part of, the equipment. This includes cassettes, probe
cards, etc.
ENGINEERING
3000 “ENG” (default engineering code)
3100 “ENG/Process experiments”
3200 “ENG/Equipment experiments”
3300 “ENG/Reserved”
3400 “ENG/Reserved”
3500 “ENG/Reserved”
3600 “ENG/Reserved”
3700 “ENG/Reserved”
3800 “ENG/Reserved”
3900 “ENG/Reserved”
SCHEDULED DOWNTIME
4000 “SDT” (default scheduled downtime code)
4100 “SDT/User maintenance delay”
4200 “SDT/Supplier maintenance delay”
4300 “SDT/Preventive maintenance”
4400 “SDT/Change of consumables”
4500 “SDT/Setup”
4600 “SDT/Production test”
4700 “SDT/Facilities-related”
4800 “SDT/Reserved”
4900 “SDT/Reserved”
UNSCHEDULED DOWNTIME
5000 “UDT” (default unscheduled downtime
code)
5100 “UDT/User maintenance delay”
5200 “UDT/Supplier maintenance delay”
5300 “UDT/Repair”
5400 “UDT/Out-of-spec input material”
5500 “UDT/Change of consumables”
5600 “UDT/Facilities-related”
5700 “UDT/Reserved”
5800 “UDT/Reserved”
5900 “UDT/Reserved”
NON-SCHEDULED TIME
6000 “NST” (default non-scheduled
downtime code)
6100 “NST/Unworked shifts”
6200 “NST/Equipment installation”
6300 “NST/Equipment modifications” (modify,
rebuild, upgrade)
6400 “NST/Off-line training”
6500 “NST/Shutdown/startup”
6600 “NST/Reserved”
6700 “NST/Reserved”
6800 “NST/Reserved”
6900 “NST/Reserved”
9.2 Additional Codes — Additional codes may be
defined by both the user and supplier, subject to the
following constraints:
SEMI E58-0703 © SEMI 1997, 2003 17
• The new code defines a refinement of a primary
ARAMS state, as defined in Section 9, through use
of the characters in the third and fourth positions.
•
Alphabetic characters are permitted in the third and
fourth positions. For purposes of sorting, these
characters are assumed to be case-sensitive. All
characters other than alphanumeric are prohibited.
• The third character is used to differentiate between
codes defined by the user (factory) and those
defined by the equipment supplier. If the third
character is a digit, then the code is user defined.
Otherwise, the code is supplier-defined. The user is
free to assign values between “01” and “9z” as the
third and fourth characters, while the supplier may
assign values between “A0” and “zz”.
* NOTE: Additional reserved codes may be added to Section
9.2 in the future.
1.15.7 Code definitions are exchanged as ARAMS
Substate Tables, described in Section 10.3.
9.3 Valid ARAMS Substate Code — A valid ARAMS
Substate Code is defined as any code with four
alphanumeric characters where the first character is a
digit between 1 and 6 and the second character is a digit
between 0 and 9.
9.4 Manufacturing Code — A user request for the
equipment to go to manufacturing specifies a special
code of “0000”. The code “0000” is not itself an
ARAMS Substate Code and shall not be used as a code
representing the current ARAMS state/substate in the
variable ARAMSState.
10 ARAMS Tables
1.16 The information in this section is not required
unless the equipment supports one or both of the two
ARAMS Tables defined in Sections 10.3 and 10.4
respectively.
1.16.1 ARAMS defines two sets of data that are to be
exchanged between equipment and host. These sets of
data are transferred as “tables”. A table is a vehicle for
exchanging information and is independent of actual
storage mechanisms.
1.16.2 This section introduces the concept and
definitions of a generic table and defines the two
specific types of tables required by ARAMS, the
ARAMS Substate Table, and the ARAMS Symptom
Table.
10.1 Definition of Tables — A table represents a
general way of exchanging sets of data arranged in a
tabular format. A table consists of one or more ordered
sets of data, called rows, where the format and
interpretation of each element of data within a row
depends upon its relative position within the row, called
column. Tables are transferred by providing:
• An ordered list of predefined text strings, called
column headers, that identify the data element at
the corresponding column position within each
row,
• one or more rows of data, where each row is an
ordered set of individual data elements, presented
in the order specified by the column headers, and
• a set of information (attributes) about the table as a
whole.
10.1.1 Table Types and Identifiers — Each instance of
a table has a formally defined table type and a table
identifier. This allows definition of general-purpose
services for exchanging tables. It also allows multiple
instances of a specific type of table to be referenced.
OSS-compliant applications consider a table as a type
of object, and a table type as a specialization of a table.
1.16.2.1 The table type definition includes
specification of a reserved text string that begins with
the string “Table”. Table services (Section 15) and OSS
services (SEMI E39) use the reserved text string as the
ObjType attribute of the table object. The general table
definition does not specify requirements for assigning
identifiers to individual tables.
1.16.2.2 The table identifier is a text string that
conforms to the requirements for an object identifier
(ObjID) as specified in SEMI E39, which prohibits
specific characters in ASCII. The identifier is used to
identify a specific instance of a given table type and
shall be unique for all tables of a given type.
1.16.2.3 A column in a table refers to all data elements
at a given position across all rows of the table. Column
headers are pre-defined text strings that identify the
individual elements used and their relative order within
each row.
1.16.3 Table Row Definition — A formal table type
requires definition of the individual data elements
within a row of the table and the specification of the
column header. This information is provided in Table 3.
Table 3 Table 3 Definition for Table Row Format
Column Header Data Element Definition Form
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