SEMI E058-00-0703

SEMI E58-0703 © SEMI 1997, 2003 1 SEMI E58-0703 AUTOMATED RELIABILITY, AVAILABILITY, AND MAINTAINABILITY STANDARD (ARAMS): CONCEPTS, BEHAVIOR, AND SERVICES This standard was technically approved by the Global Information & Control Committee and is the direct responsibility of the North American Information & Control Committee. Current edition approved by the North American Regional Standards Committee on October 19, 2000. Initially available at www.semi.org January 2001; to be published March 2001. Originally published June 1997. NOTICE: The designation of SEMI E58 was updated during the 0703 publishing cycle to reflect the reapproval of SEMI E58.1. CONTENTS 1 Purpose 1.2 Background and Motivations 2 Scope 3 Referenced Documents 4 Terminology 4.1 Acronyms 4.2 General Terms 4.3 Data Types 5 Basic Requirements 6 Conventions 6.1 State Model Methodology 6.2 Object Attribute Representation 6.3 Service Message Representation 6.3.1 Service Resource Definition 6.3.2 Service Parameter Dictionary 6.3.3 Service Message Definition 7 Overview 8 State Models 8.2 SEMI E10 Equipment States 8.3 ARAMS State Model Definition 8.3.1 ARAMS State Model Diagram 8.3.2 Descriptions of ARAMS States 8.3.2.1 TOTAL TIME 8.3.2.2 MANUFACTURING 8.3.2.3 PRODUCTIVE 8.3.2.4 STANDBY 8.3.2.5 ENGINEERING 8.3.2.6 UNSCHEDULED DOWNTIME 8.3.2.7 SCHEDULED DOWNTIME 8.3.2.8 NON-SCHEDULDED TIME 8.3.3 ARAMS Substates 8.3.4 State Transitions 8.4 General Equipment Operations Model 8.4.2 State Definitions 8.4.2.1 POWER-OFF 8.4.2.2 POWER-ON 8.4.2.3 INITIALIZING 8.4.2.4 READY 8.4.2.5 IDLE 8.4.2.6 BUSY 8.4.3 General Equipment Operations Model Table of Transitions 8.5 State Model Relationships 8.5.2 IDLE and BUSY 8.5.3 Non-Manufacturing States 9 ARAMS Substate Codes 9.2 Reserved Codes 9.3 Additional Codes 9.4 Valid ARAMS Substate Code 9.5 Manufacturing Code 10 ARAMS Tables 10.2 Definition of Tables 10.2.1 Table Types and Identifiers 10.2.2 Table Row Definition 10.2.3 Table Attributes 10.2.4 Additional Requirements 10.3 ARAMS Substate Table SEMI E58-0703 © SEMI 1997, 2003 2 10.4 ARAMS Symptom Table 11 ARAMS Data 11.2 Status Information 11.2.3 ARAMSInfo 11.2.4 ARAMSState 11.2.5 ARAMSText 11.2.6 Clock 11.2.7 CycleCtr 11.2.8 DowntimeAlarm 11.2.9 DowntimeAlarmText 11.2.10 DowntimeData 11.2.11 LastPowerdown 11.2.12 PowerdownTime 11.2.13 PrdState 11.2.14 PrevARAMSState 11.2.15 SymptomID 11.2.16 SymptomText 11.3 Constant Data 11.3.1 EqpModel 11.3.2 EqpSerialNum 11.4 User-Configurable Data 11.4.1 EngInterrupt (optional) 11.4.2 EngRecovery (optional) 11.4.3 EqpName (required) 11.4.4 PowerupState (optional) 11.4.5 PrdRecovery (optional) 11.4.6 SbyRecovery (optional) 11.4.7 SubstateSelect (optional) 11.5 Accumulators 11.5.2 ARAMSAccumReset 11.5.3 ARAMSTimestamp 11.5.4 EngTime 11.5.5 InterruptionPrd 11.5.6 InterruptionTotal 11.5.7 NSTime 11.5.8 PrdTime 11.5.9 SbyTime 11.5.10 SDTime 11.5.11 UDTime 12 Events and Pre-Defined Event Reports 13 Object Services Compliance 13.1 Equipment Object 13.2 Table Objects 14 Human Interface Requirements 14.1 Data Access 14.2 Selection of an ARAMS State/Substate 14.3 User-Defined ARAMS Symptom Tables 14.4 Table Access 14.5 Color Codes 15 Services 15.2 Services Parameter Dictionary 15.3 TableSend 15.4 TableRequest 15.5 ARAMSStateChange 15.6 ResetAccumulators 16 ARAMS Behavioral Requirements 16.1 ARAMS State Transitions 16.2 Powerup Entry 16.3 Powerup and Powerdown States 16.3.2 PowerupState 16.4 User-Initiated State Change Requests 16.5 Production and Standby Substates 16.6 Equipment-Selected Substates 16.7 Equipment-Detected Exceptions 16.7.4 Fault Detection in ENGINEERING 16.8 Equipment-Initiated Recovery 16.8.2 Automatic Recovery 17 Requirements for Compliance 17.1 Fundamental Requirements 17.1.1 Event Notification 17.1.2 Clock Services 17.1.3 Read-Only Data Access 17.1.4 User-Configurable Data Access 17.1.5 Alarm/Exception Management SEMI E58-0703 © SEMI 1997, 2003 3 17.1.6 ARAMS State Model 17.1.7 ARAMS State Transition Notification 17.1.8 ARAMS Substate Codes 17.1.9 ARAMS Status Data 17.1.10 ARAMS Constant Data 17.1.11 ARAMS Event Report Data 17.1.12 Host State Change Request 17.1.13 Estimation of Powerdown Time 17.1.14 ARAMS Behavioral Requirements 17.2 Additional Capabilities 17.2.1 User-Configurable Powerup State 17.2.2 User-Configurable Fault Recovery to Manufacturing 17.2.3 Accumulator Data 17.2.4 User-Generated ARAMS Substate Table(s) 17.2.5 Equipment-Generated ARAMS Substate Table(s) 17.2.6 User-Generated Symptom Table(s) 17.2.7 Human Interface Requirements 17.2.8 Equipment-Selected Substates 17.2.9 User-Configurable Fault Detection in ENGINEERING 17.2.10 User-Configurable Fault Recovery to ENGINEERING 17.2.11 Human Interface Requirements 17.3 Requirements for Compliance 18 ARAMS States for Multi-Module Equipment Related Information 1 R1-1 Estimating Powerdown Time R1-1.2 UpdatePeriod R1-2 Powerup Scenario R1-3 Equipment-Initiated Transition R1-4 Operator-Initiated Transition R1-5 Host-Initiated Transition Related Information 2 R2-1 User-Initiated Transitions to UNSCHEDULED DOWNTIME SEMI E58-0703 © SEMI 1997, 2003 4 SEMI E58-0703 AUTOMATED RELIABILITY, AVAILABILITY, AND MAINTAINABILITY STANDARD (ARAMS): CONCEPTS, BEHAVIOR, AND SERVICES This standard was technically approved by the Global Information & Control Committee and is the direct responsibility of the North American Information & Control Committee. Current edition approved by the North American Regional Standards Committee on October 19, 2000. Initially available at www.semi.org January 2001; to be published March 2001. Originally published June 1997. NOTICE: The designation of SEMI E58 was updated during the 0703 publishing cycle to reflect the reapproval of SEMI E58.1. 1 Purpose 1.1 This document provides standards for implementing and collecting SEMI E10 state changes at the equipment level per SEMI E10. 1.1.1 SEMI E10 defines various terms and equipment states but was not written specifically for application by automated equipment. This document is intended to provide a consistent interpretation of these equipment states through formal state model methodology. 1.1.2 ARAMS defines concepts, behavior, and message services to support the integration of automated systems within a semiconductor factory. 1.1 Background and Motivations — To implement the integration of SEMI E10 states on automated equipment, integration of definitions and requirements must be detailed and precise to ensure interpretations are consistent across equipment suppliers. This provides an opportunity to automatically retain information at the equipment itself. 1.1.3 Both equipment supplier and equipment user benefit from the automation of SEMI E10 data collection at the equipment through application of a consistent state model. 1.1.4 SEMI E10 defines specific states but does not address transitions between states. The ARAMS standard specifies the triggers for state transitions made by automated equipment. Extensions to SEMI E10 described in this document apply to decisions made by automated equipment only. 2 Scope 2.1 This standard is applicable to the following relationships: traditional host/equipment, operator/equipment, and cluster tool controller/attached module. The scope of this document is to define standards which facilitate equipment-level capture and communication of SEMI E10 related data. Specifically, this document provides the following: • An equipment state model that defines the rules for equipment state changes, • A set of standard equipment codes for representing substates of the six basic equipment states defined in SEMI E10, • Definition of equipment-generated data, • Concepts and messages required to exchange information, and • Requirements for fundamental compliance to ARAMS • Additional optional specifications. 2.2 This standard is intended as a supplement to SEMI E10 to be used for equipment support of SEMI E10. Formal definitions of all terms common to both documents are provided solely by SEMI E10. 2.3 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 limitations prior to use. 3 Referenced Standards 3.1 SEMI Standards SEMI E10 — Standard for Definition and Measurement of Equipment Reliability, Availability, and Maintainability (RAM) SEMI E30 — Generic Model for Communications and Control of SEMI Equipment (GEM) SEMI E38 — Cluster Tool Module Communications (CTMC) SEMI E39 — Object Services Standard: Concepts, Behavior, and Services SEMI E41 — Exception Management (EM) Standard SEMI E42 — Recipe Management Standard: Concepts, Behavior, and Message Services SEMI E53 — Event Reporting SEMI E58-0703 © SEMI 1997, 2003 5 3.2 Other Document Harel, D., “Statecharts: A Visual Formalism for Complex Systems,” Science of Computer Programming 8 (1987) 231–274 NOTE 1: As listed or revised, all documents cited shall be the latest publications of adopted standards. 4 Terminology 4.1 Acronyms — The following acronyms are used in this document. 4.1.1 ARAMS — Automated Reliability, Availability, and Maintainability Standard, as defined by this document. 4.1.2 CTMC — Cluster Tool Module Communications [SEMI E38]. 4.1.3 EMS — Exception Management Standard [SEMI E41]. 4.1.4 ERS — Event Reporting Standard [SEMI E53]. 4.1.5 GEM — Generic Equipment Model [SEMI E30]. 4.1.6 OSS — Object Services Standard [SEMI E39]. 4.1.7 RAM — Reliability, Availability, and Maintainability. 4.2 General Terms — The following definitions for general terms are used in this document. References are given in brackets. 4.2.1 alarm — Related to any abnormal situation on the equipment that may endanger people, equipment, or material being processed [SEMI E30, SEMI E41]. 4.2.2 collection event — An event (or grouping of related events) on the equipment that is considered to be significant to the host [SEMI E30]. NOTE 2: A state transition in a formal state model always represents a collection event unless explicitly stated otherwise. 4.2.3 equipment production criteria — The set of conditions and operating specifications that must be satisfied for the equipment to consider itself as performing its intended function. This includes basic requirements for information, material to process, and the absence of any detectable exception conditions (e.g., no alarms). It also includes criteria specific to the equipment model, such as a required level for vacuum pressure and availability of consumables and support tools required for its process. 4.2.4 event — A detectable occurrence significant to the equipment. NOTE 3: Within the context of ARAMS, an event may be detected by either the equipment or the user. 4.2.5 event report — A message the equipment sends to the host on the occurrence of a collection event. 4.2.6 exception — An alarm or error that is reported to the user and that may or may not be recoverable. 4.2.7 fault — An exception. 4.2.8 host — The intelligent system that communicates with the equipment, acts as a supervisory agent, and represents the factory and the user to the equipment. 4.2.9 intended function — A manufacturing function that the equipment was built to perform. This includes transport functions for transport equipment and measurement functions for metrology equipment as well as process functions such as physical vapor deposition and wire bonding. Complex equipment may have more than one intended function. 4.2.10 interrupt (interruption) — A failure [SEMI E10]. 4.2.11 operator — Any person who communicates locally with the equipment through the equipment’s control panel. 4.2.12 state — A static set of conditions and associated behavior. While all of its conditions are met, the state is current (active). Behavior within a given state includes the response to various stimuli. NOTE 4: Within the scope of this document, the term “state” generally refers to one of the six equipment states defined by SEMI E10 and used in the ARAMS State Model: productive, standby, engineering, scheduled downtime, unscheduled downtime, and non-scheduled time. 4.2.13 state model — A collection of states and state transitions that combine to describe the behavior of a system. This model includes a definition of the conditions that delineate a state, the activities possible within a state, the events that trigger transitions to other states, and the process of transitioning between states. 4.2.14 state transition — A change from one state to another state. 4.2.15 standby condition — Any condition during manufacturing time when the equipment’s production criteria are not satisfied, and it is fault free and otherwise able to perform its intended function. 4.2.16 substate — A refinement of a state. NOTE 5: States may be subdivided into substates to facilitate more concise definition of behavior. Thus, a hierarchy is defined whereby any state may be a substate of some parent state and in turn be the parent of its own substates [SEMI E30, Appendix]. 4.2.17 superstate — The parent state of two or more states. 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 5.1 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 5.2 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. 6.1.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 # 6.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 Reqd Form The formal text name of the attribute. Description of the information contained. RO or RW Y or N (see below) 6.2.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. 6.2.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. 6.2.3 The Form column is used to indicate the format of the attribute (see Section 4 for definitions). 6.3 Service Message Representation 6.3.1 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