semi合集-English.pdf - 第2237页

SEMI E58-0703 © SEMI 1997, 2003 18 Text string for column position. Definition of data element at the corresponding colum n position. Valid form for data element. 1.16.3.1 The order of elem ents within a row shall be inv…

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

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 ≤

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

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.