Background Statement for SEMI Draft Document 5821 New...

Background Statement for SEMI Draft Document 5821 New Standard: Specification for Subsystem Energy Saving Mode Communication (SESMC)

Notice: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this Document. Notice: Recipients of this Document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, “patented technology” is defined as technology for which a patent has issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided. What is the problem being solved? The industry has just approved a new standard for energy saving communication between the factory and the semiconductor production equipment. However, there is no standard communication between semiconductor production equipment and sub-systems (e.g., vacuum pumps and abatement systems) capable of reduced energy operation. A standard for commanding and communicating energy conservation status between production equipment and such sub-systems is needed. Many sub-systems are capable for a reduced energy operation but implementations have stalled by the absence of standards to enable communication and exchange of information between various manufactures of sub-systems and semiconductor production equipment. Currently, there are proprietary solutions used to interface and communicate energy conservation information within production equipment and subsystems in a non-standard way. The purpose of this activity is to define energy conservation communication between production equipment and sub-systems in a standard way. What is the history of this issue and ballot? This is the first proposal of this new specification. Who will this affect? How? Why? This new specification will not conflict with existing standards. Is this a change to an existing solution, or, is it a new activity? This is a new activity. Revision Control This revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force.

Date Version Name Edits 10/23/2014 0.1 Gino Crispieri First working draft 11/10/2014 0.2 Gino Crispieri Corrected state machine and transition tables from History entry to

Conditional entry 12/04/2014 0.4 Gino Crispieri Changed “Energy” with “Utilities” term throughout document 12/11/2014 0.5 Gino Crispieri Removed transition 11 and capability for energy savings during

process mode 12/18/2014 0.6 Gino Crispieri State machine back with transition 11 1/20/2015 0.7 Gino Crispieri Simplified state machine removing WakingUp state 1/24/2015 0.8 Gino Crispieri Appendix 2 and 3 added 1/29/2015 0.9 Gino Crispieri Term Energy used throughout the document

A Note on Requirements ID’s Requirements ID’s are included in the proposed new standard by direction of the North America Information & Control Committee. The requirements are delimited by [Vsss.ss-RQ-nnnnn-nn] at the beginning and [/RQ] at the end. In tables where requirements are contained, a row designates a requirement with the designation [Vsss.ss-RQ-nnnnn-nn] in column 1. All requirements are delimited in one of these two ways. No other text should be considered a requirement. Sections near a requirement may provide examples or other supporting text that can help with interpreting the requirement. Note that the word “should” is used in some non-requirements text and it denotes a recommendation or a best practice, not a requirement. Each requirement has a requirement ID as contained in the [Vsss.ss-RQ-nnnnn-nn] delimiter. The Vsss.ss is the specification identifier and will be replaced by SEMI in the published version with the actual standard number (for example E167.00), which cannot be known before approval is achieved. The “nnnnn” string is the requirement number within this specification. The authors of this proposal have suggested requirement numbers, but the final assignment will be made by SEMI. Corrections to the requirement numbers are considered editorial.

Review and Adjudication Information

Task Force Review Committee Adjudication Group: Energy Saving Equipment Communication

Task Force North America I&C Committee

Date: NA Standards Spring 2015 Meetings Tuesday, March 31, 2015

NA Standards Spring 2015 Meetings Wednesday, April 1, 2015

Time & Timezone: 8:00 AM to 10:00 AM, Pacific Time 8:00 AM to 4:30 PM, Pacific Time Location: SEMI Headquarters

3081 Zanker Road SEMI Headquarters 3081 Zanker Road

City, State/Country: San Jose, California / USA San Jose, California / USA Leader(s): Gino Crispieri (Consultant)

Mike Czerniak (Edwards) Jack Ghiselli (Ghiselli Consulting) Brian Rubow (Cimetrix) Lance Rist (Industry Consultant)

Standards Staff: Paul Trio (SEMI NA) 408.943.7041 /[email protected]

Paul Trio (SEMI NA) 408.943.7041 / [email protected]

This meeting’s details are subject to change, and additional review sessions may be scheduled if necessary. Contact Standards staff for confirmation. Telephone and web information will be distributed to interested parties as the meeting date approaches. If you will not be able to attend these meetings in person but would like to participate by telephone/web, please contact Standards staff.

This is a Draft Document of the SEMI International Standards program. No material on this page is to be construed as an official or adopted Standard or Safety Guideline. Permission is granted to reproduce and/or distribute this document, in whole or in part, only within the scope of SEMI International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of SEMI is prohibited.

Page 1 Doc. 5821 SEMI

Semiconductor Equipment and Materials International 3081 Zanker Road San Jose, CA 95134-2127 Phone: 408.943.6900, Fax: 408.943.7943

LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT

DRAFTDocument Number: 5821

Date: 2/5/2015

SEMI Draft Document 5821 New Standard: Specification for Subsystem Energy Saving Mode Communication (SESMC)

Table of Contents

REVIEW AND ADJUDICATION INFORMATION ..................................................................................... 0

1 PURPOSE ............................................................................................................................................ 2

2 SCOPE ................................................................................................................................................ 2

3 LIMITATIONS ...................................................................................................................................... 2

4 REFERENCED STANDARDS AND DOCUMENTS .............................................................................. 2

4.1 SEMI Standards and Safety Guidelines ......................................................................................................................... 2

5 TERMINOLOGY ................................................................................................................................... 2

5.1 Abbreviations and Acronyms ....................................................................................................................................... 2

5.2 Definitions.................................................................................................................................................................. 2

6 CONVENTIONS ................................................................................................................................... 3

6.1 Requirements Identification ........................................................................................................................................ 3

6.2 State Model Methodology ........................................................................................................................................... 5

6.3 Parameter Listings ...................................................................................................................................................... 5

6.4 Service Message Representation .................................................................................................................................. 6

7 OVERVIEW .......................................................................................................................................... 6

7.2 Basic Concepts ............................................................................................................................................................ 6

7.3 Energy Saving Operation ............................................................................................................................................ 7

7.4 Coordination of Remote and Local Operation ............................................................................................................... 7

7.5 Subsystem Sleep Levels ............................................................................................................................................... 7

7.6 Communication Signals or Protocol .............................................................................................................................. 7

7.7 Simple Usage Scenario ................................................................................................................................................ 7

8 PREREQUISITES ................................................................................................................................ 8

9 REQUIREMENTS ................................................................................................................................. 8

9.2 Subsystem Energy Saving State Model ......................................................................................................................... 8

9.3 Subsystem Energy Saving Mode Message Services ...................................................................................................... 14

10 TEST METHODS ............................................................................................................................. 16

11 RELATED DOCUMENTS ................................................................................................................. 16

11.1 D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231--274, 1987. .. 16




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

1 Purpose

1.1 The purpose of this specification is to define communication between production equipment and subsystem to enable reduced energy consumption of subsystems. A means to manage and communicate status is provided for the production equipment to initiate (and terminate) subsystem energy saving mode in a coordinated manner.

2 Scope

2.1 This standard defines communication and behavior between the production equipment and subsystems to facilitate an overall reduced rate of energy consumption in the equipment.

2.2 This standard addresses:

• Definition of subsystem energy saving mode behavior in the form of a state model

• Communication required to manage the subsystem’s energy saving modes

NOTICE: SEMI Standards and Safety Guidelines do not purport to address all safety issues associated with their use. It is the responsibility of the users of the Documents to establish appropriate safety and health practices, and determine the applicability of regulatory or other limitations prior to use.

3 Limitations

3.1 This specification applies only to subsystems capable of providing a reduced rate of energy consumption on command. Other subsystems that do not provide or are capable of reduced energy consumption will not be capable of complying with the requirements contained within.

3.2 This standard does not specify the amount of energy savings to be attained or how that energy savings is to be achieved. Each subsystem must specify the amount and rates of energy savings based on each energy consumption models. This approach gives the subsystem supplier the freedom to optimize the reduction in energy use.

3.3 The specific protocol for messaging between equipment and subsystems including the detailed message structure is not part in this specification.

3.4 The internal controls and communication of equipment and its subsystems are beyond the scope of this specification. The energy savings levels of equipment subsystems are not specified in this document and reporting of each supplier subsystem’s defined energy savings levels is not part of this specification.

4 Referenced Standards and Documents

4.1 SEMI Standards and Safety Guidelines

SEMI E73 – Specification for Vacuum Pump Interfaces – Dry Pumps

SEMI E74 – Specification for Vacuum Pump Interfaces – Turbo Pumps

SEMI E167 — Specification for Equipment Energy Savings Mode Communication (EESM)

SEMI S23 — Guide for Conservation of Utilities, Utility and Materials Used by Semiconductor Manufacturing Equipment

NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions.

5 Terminology

5.1 Abbreviations and Acronyms

5.1.1 SESM — Subsystem Energy Saving Mode

5.2 Definitions

5.2.1 collection event — an event (or grouping of related events) on the equipment that is considered to be significant to the host. A collection event may be used to initiate the collection and reporting of data to the host. (refer to SEMI E87, E109)




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

5.2.2 dry pump (DRP) —dry pumps are a type of mechanical vacuum pump. Dry pumps can work at atmospheric pressure. They are called dry pumps because no liquid sealing materials are used on any surface contacted by gases. Hereafter, the term ‘DRP’ is substituted for ‘dry pump (refer to SEMI E73).

5.2.3 host — the factory computer system or an intermediate system that represents the factory and the user to the equipment. (refer to SEMI E87, E109)

5.2.4 idle mode — The condition where the equipment is energized and readied for process mode (all systems ready and temperatures controlled) but is not actually performing any active function such as material movement or processing. (refer to SEMI S23)

5.2.5 process mode – the condition where the equipment is energized and performing its intended function on target materials (such as implanting wafers, pumping gas, or inspecting photo-masks). (refer to SEMI S23)

5.2.6 production equipment — equipment used to produce semiconductor devices, including wafer sorting, process, and metrology equipment and excluding material handling equipment. (refer to SEMI E82, E88, E153, E157, E167)

5.2.7 sleep mode — the condition where the equipment is energized but it is using less energy than in idle mode. The sleep mode is primarily differentiated from idle mode in that it is initiated by a specific single command signal provided to equipment, either from an equipment actuator, from an equipment electric interface, or a message received through factory control software (e.g. SECS). Other than the possible initiation of the sleep mode by an equipment actuator, entry into the sleep mode does not require manual actions. (refer to SEMI S23)

5.2.8 sleep level — one or more reduced energy consumption rates that are provided by the production equipment or subsystem with the purpose of additional savings based on the amount of time the production equipment or subsystem are not needed for normal operation. Sleep levels are based on the amount of time needed by the production equipment or subsystem to return to a state where is ready to perform its intended function. Sleep levels are differentiated in title by a very simple designation such as S1, S2, and so on.

5.2.9 subsystem — a subsystem is an intelligent aggregate that behaves as a unit and capable of performing one or more specific functions required by the production equipment. A subsystem in this specification is capable of lower energy consumption when operating under production equipment control.

5.2.10 subsystem idle mode — the condition where the subsystem is energized and the equipment can rely on subsystem returning to process state in the reaction time of the system when requested. The subsystem is not performing any of the intended process functions on the equipment load or target materials, such as abating gas, pumping gas, or controlling temperature.

5.2.11 subsystem process mode — the condition where the subsystem is energized, and performing its intended function on target materials such as abating gas, pumping gas, or controlling temperature.

5.2.12 subsystem sleep mode — the condition where the subsystem is energized but it is operating under lower energy consumption rate and requires a wake up time to return to subsystem idle mode. The subsystem sleep mode is initiated by a specific request or command provided to the subsystem by the production equipment. Some subsystems may provide multiple levels of energy consumption during subsystem sleep mode. These levels are subsystem dependent and are based on the amount of time needed to return to the subsystem idle mode.

5.2.13 subsystem energy saving mode — a capability provided by the subsystem that allows the equipment to manage the entry and exit of a subsystem energy conservation mode for the purpose of reduction of the rate of energy consumption.

5.2.14 turbomolecular pump (TMP) —equipment used to create a high vacuum. Rapidly rotating blades force molecules to the bottom for removal by a mechanical pump (refer to SEMI E74).

5.2.15 vacuum pump — a pumping apparatus which exhausts gas or air from an enclosed space to achieve a desired degree of vacuum (refer to SEMI E 73).

6 Conventions

6.1 Requirements Identification

6.1.1 The following notation specifies the structure of requirement identifiers.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

6.1.1.1 The following requirements prefix format is used at the beginning of requirement text. See Table 1 for the format notation of the requirements prefix.

• [Vsss.ss-RQ-nnnnn-nn]

6.1.1.2 To mark the end of the requirement text the following suffix format is used.

• [/RQ]

6.1.1.3 Requirements in the body text are highlighted with a border and light green background (may appear gray in black and white printouts)

[Esss.ss-RQ-nnnnn-nn] Requirement text. [/RQ]

Table 1 Requirement Identifiers

Format Notation Purpose

Esss.ss SEMI standards specification identifier. Examples: E087.00, E087.01, E134.00

RQ Indicates this is a requirement identifier.

Nnnnn Unique five-digit number within this specification. 90000-99999 are reserved for use by SEMI.

.nn Two-digit number that indicates version level of the requirement (.00 is used for the first version of a requirement)

/RQ Indicates the end of a requirement

6.1.2 Requirements in tables are delimited in one of two ways.

6.1.2.1 Where the requirement occupies an entire row in the table, the requirement ID is placed in column 1. No "[/RQ]" is used to mark the end of the requirements text in this case. The table may also contain rows that are not requirements. In this case, the column 1 cell is left blank.

6.1.2.2 Non-requirements text related to a requirements row may be included in an adjacent row. The relationship between the rows is indicated by a broken line separating the two.

6.1.2.3 Where the requirement occupies only one cell, the text in the cell includes the requirement ID prefix and suffix similar to requirements in the body text.

6.1.2.4 No cell in a table will contain both requirement and non-requirement text.

6.1.2.5 Cells that contain requirements are shaded light green.

6.1.2.6 Table 2 provides an example of requirements in a table. Note that in this example, the same requirement is presented in two alternative formats. In practice, mixing the two approaches in the same table is not typically done.

Table 2 Example Table With Requirements

RequirementID Statement Additional Detail

Esss.ss-RQ-nnnnn-nn The light shall be blue There shall be no similar color in the light panel.

The blue light is typically placed at the leftmost position in the light panel.

[Esss.ss-RQ-nnnnn-nn]The light shall be blue. There shall be no similar color in the light panel. [/RQ]

The blue light is typically placed at the leftmost position in the light panel.

6.1.3 Only text marked with the requirement identifier is a requirement of this specification.

6.1.3.1 Clarification, examples, and related recommendations may be provided near a requirement, but are not part of the requirement.

6.1.3.2 Note that the word “should” is used in some non-requirements text, where it denotes a recommendation or a best practice, not a requirement.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

6.1.4 Parent-child relationships of requirements are noted in the tables in Table 2. Where a parent requirement includes conditions or selection criteria, these are passed to their children. For example, if a parent requirement is stated to apply only to photolithography equipment, any child requirements also apply only to such equipment. The condition need not be restated for each child requirement.

6.1.5 The following is the top level parent requirement of all others in this specification.

[Esss.00-RQ-00001-00] Conformance to this specification requires conformance to all other identified requirements in this document as stated conditions apply. [/RQ]

6.2 State Model Methodology

6.2.1 This document uses the Harel state chart convention for describing dynamic operation of defined objects. The outline of this convention is described in an attachment of SEMI E30. The official definition of this convention is described in “State Charts: A Visual Formalism for Complex Systems” written by David Harel in Science of Computer Programming 8, 1987.

6.2.2 The Harel convention does not have the concept of “creation” and “extinction” of state models for a temporary entity. In this document, a filled, black circle denotes the entry to the state model (entity creation). If needed, a circle with a filled, black circle inside is used for expressing extinction of an entity.

6.2.3 Transition tables are provided in conjunction with the state diagrams to describe explicitly the nature of each state transition. A transition table contains columns for RequirementID, Transition number (#), Previous State, Trigger, New State, and Actions (see Table 3). The “trigger” (column 4) for the transition occurs while in the “previous” state. The “actions” (column 5) includes a combination of:

1. Actions taken upon exit of the previous state.

2. Actions taken upon entry of the new state.

3. Actions taken which are most closely associated with the transition.

6.2.3.1 When reporting to the host, no differentiation is made between these cases.

Table 3 Example Transition Table

Requirement ID # Previous State Trigger New State Action(s)

6.2.4 A state model consists of a state model diagram, state definitions, and a state transition table.

[Vsss.ss-RQ-00002-00] All state transitions in this standard, unless otherwise specified, shall correspond to collection events. [/RQ]

6.2.5 A state model represents the host’s view of the equipment, and does not necessarily describe the internal equipment operation.

[Vsss.ss-RQ-00003-00] All state model transitions shall be mapped into the appropriate internal equipment events that satisfy the requirements of those transitions. [/RQ]

6.2.6 In certain implementations, the equipment may enter a state and have already satisfied all of the conditions required by the state models for transition to another state. In that case, the next state transition may occur immediately.

6.3 Parameter Listings

6.3.1 Parameters that can be included with collection events corresponding to state model transitions are represented in table form using the format of Table 4. Table 5 explains the contents of each column in the example parameter table.

Table 4 Example Parameter Table

Requirement ID Data Parameter Req Description Data Type




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

Table 5 Parameter Table Columns

Column Description

RequirementID Requirement identifier defined according to ¶6.1

Data Parameter Name of the parameter.

Req

Whether the parameter is required: Y – Required N – Not Required C – Conditional (required in specified circumstances)

Description Explanation of the parameters contents. For data parameters, the description includes whether the parameter is transient.

Data Type The format of the parameter’s contents (integer, string, etc.)

6.3.2 A data parameter is noted as transient in the description column if its value is assured to be valid only on specified collection events. A non-transient parameter has a valid value at any time and can be reported with any collection event.

6.4 Service Message Representation

6.4.1 A message service definition table defines the specific set of message services for this specification.

Table 6 Example Message Service Definition Table

RequirementID Message Service Name Type Description

[Vsss.ss-RQ-00xxx-00] Message name N or R Purpose of the message service

6.4.1.1 Type can be either N = Notification or R = Request. Notification type message services are initiated by a service provider and the provider does not need to get a response from the service user or requester. Request message services ask for data or an activity from the provider. Each request message expects a specific response message to return data or confirm acceptance or completion of a command.

7 Overview

7.1 This section provides an overview of the energy saving mode capability in production equipment controlled subsystems. This overview refers to requirements defined later in the document. However, no statement in this overview section is intended to specify a requirement. The overview is intended to provide a general understanding of the subsystem energy saving mode concepts so that the detailed requirements that follow can be more easily understood.

7.2 Basic Concepts

7.2.1 The subsystem energy saving mode capability provides the opportunity for the production equipment to manage the reduction of energy use by a subsystem and achieve different levels of energy savings depending on the length of time the production equipment does not require the subsystem for production or a related task.

7.2.2 The amount of energy consumed by a subsystem varies over time depending on the process load and mode of operation. A subsystem is likely to consume the most energy when the production equipment is processing material. However a significant amount of energy is still being consumed when the production equipment is idle. This specification addresses the opportunities of subsystem reduced energy operation based on equipment specific situation and use cases. In particular when the equipment is idle or the factory has no plans to use the production equipment resources for an extended amount of time.

7.2.3 In a semiconductor factory, not all production equipment is in continuous use. Usually, the factory expects that the production equipment must be ready for normal operation at the instant product appears on the load port. This specification enables the production equipment to manage and notify its subsystem resources capable of lower energy consumption to operate at a lower energy rate while material to process will not appear for an estimated time period or an opportunity for reduced energy operation is allowed. When SEMI E167 is used, the host will indicate how long the production equipment will not be needed for production. This allows the production equipment to reduce the rate of energy usage during this time. The SEMI Guideline S23 calls this condition “sleep mode.” There are also additional scenarios where the production equipment is capable of a reduced energy operation without the implementation of




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

SEMI E167. This specification provides an opportunity for energy savings that the production equipment may gain by standardizing the request for reduced energy operation to its subsystems on a needed basis. This specification does not specify how these savings are achieved but provides with a mechanism to coordinate such savings.

7.2.4 It is assumed that idle production equipment consume energy at lower rates while still maintaining the ability to respond immediately to a command to process new material. It is expected that further reduction of energy usage could come at the price of a time delay to achieve the lower consumption rate of energy use and to recover from it.

7.3 Energy Saving Operation

7.3.1 This specification standardizes communications related to subsystems energy saving mode. It does not attempt to constrain the amount of energy savings or the methods used to achieve a reduction in the rate of energy consumption. This specification allows the production equipment and suppliers of subsystems as much leeway as possible to optimize the implementation.

7.4 Coordination of Remote and Local Operation

7.4.1 Some subsystems may provide the user with the capability to control the subsystem energy savings mode locally. In this case, the implementer should consider potential conflicts that may occur between the production equipment and the subsystem.

7.4.2 With local control, it is possible for the state of the subsystem to change without the knowledge of the production equipment. This may be due to either the production equipment or the subsystem being off-line. When using software communication protocol, the subsystem includes a non-transient parameter that provides the current subsystem energy saving mode. When using a hardware interface, the subsystem provides a signal that informs the production equipment of its energy saving mode state. Thus, the production equipment can synchronize with the subsystem’s “Subsystem Energy Saving State Model” as needed.

7.4.3 An important element of energy conservation management is the determination of when to sleep and wake up. This specification recognizes that there are some situations when subsystem sleep mode may be initiated at the subsystem. The production equipment may allow a user at the subsystem user interface to initiate sleep and/or to initiate the waking up process. In such a case, both production equipment and subsystem should follow the mechanisms in this specification to report and manage the respective energy saving mode states.

7.5 Subsystem Sleep Levels

7.5.1 SEMI S23 suggests that more than one level of sleep within the production equipment sleep mode might exist which implies that subsystems controlled and managed by the production equipment could provide further energy savings if such capabilities are also provided by the subsystem. If this is the case, a subsystem is allowed more time for returning to normal operation and a higher degree of energy savings might be feasible. While this specification does not require the support of sleep levels, it does provide a mechanism for reporting sleep level if the subsystem supports that concept.

7.5.2 Where multiple levels of sleep are supported, the production equipment selects the level of sleep to be utilized in each case. To aid the selection of sleep level, each subsystem defines the estimated required time for waking up. It is expected that such estimates are known when a request is made by the subsystem design specification.

7.6 Communication Signals or Protocol

7.6.1 The requests or message services in this specification are defined independently of the mechanism or protocol to be used. Additional specification of how these requests or message services and the related data are mapped to a specific signal or protocol is necessary in order to implement the subsystem energy conservation capability.

7.7 Simple Usage Scenario

7.7.1 This document provides a very simple base scenario for managing subsystem sleep mode. It begins when the subsystem is idle and the production equipment determines based on a host request that no material will be processed for a given amount of time.

• The production equipment decides that one or more subsystems are not needed for material processing for a time period sufficient to support energy savings.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

• The production equipment requests one or more subsystems to operate at reduced energy consumption rate or at a subsystem sleep level based on the estimated time the subsystem will not be required for production.

• Each subsystem accepts and acknowledges the production equipment sleep level request.

• Each subsystem transitions to the requested subsystem sleep level. An event or signal transition from each subsystem reports the arrival to the requested sleep level. Subsystem energy consumption reduction rate begins. Each subsystem remains in sleep mode until requested or commanded to wake up (assuming no fault occurs).

• The production equipment determines the actual time that each of the subsystems will be needed for processing or the subsystem’s intended operation.

• Allowing enough lead time for the subsystem to wake up, the production equipment issues a wake up request or command to each of the subsystems in sleep mode state.

• Each subsystem begins the waking up process.

• When the subsystem is ready for normal operation, it transitions to the subsystem idle mode and acknowledges or reports the transition completion to the production equipment.

• Once all subsystems are ready for normal operation, the production equipment becomes ready to process.

8 Prerequisites

8.1 The Subsystem Energy Saving Mode capability requires a communication protocol or signals to support exchange of requests or messages between production equipment and subsystem to manage energy reduction. The specific communication mechanism or protocol is not specified in this document.

[Vsss.ss-RQ-00004-00] Subsystem shall provide hardware signals or software communications protocol to exchange the message services defined elsewhere in this specification. [/RQ]

8.2 Required Standards — No specific standards required as prerequisites. Some SEMI standards can be used to meet certain prerequisites. Support for these standards is not mandatory for compliance with this standard.

9 Requirements

9.1 The requirements for this specification can be divided into two parts: behavior and message services. The behavior is specified in the form of a state model as specified in ¶9.2 . Message services are specified in ¶9.3 .

[Vsss.ss-RQ-00005-00] The Subsystem Energy Saving Mode capability shall not affect the subsystem’s ability to communicate or to accept and process commands. [/RQ]

9.2 Subsystem Energy Saving State Model

9.2.1 This state model specifies the subsystem behavior related to the Subsystem Energy Saving Mode. Figure 1 shows the diagram of the Subsystem Energy Saving State Model. The states are described in ¶9.2.2 and the transitions are specified in Table 7.

[Vsss.ss-RQ-00006-00] Subsystems capable of energy savings shall implement one instance of the Subsystem Energy Saving State Model according to the descriptions of its states, transitions, and associated collection events and data parameters. [/RQ]




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

Figure 1

Subsystem Energy Saving State Model

9.2.2 Subsystem Energy Saving States

9.2.2.1 The following subsections describe each state defined for the Subsystem Energy Saving State Model.

9.2.2.2 The current state of the subsystem with respect to the Subsystem Energy Saving State Model can be obtained via software by using the data parameter EnergySavingState as specified in ¶9.3 or by reading the interface signals set in the hardware communication interface respectively.

9.2.2.3 NoState

9.2.2.3.1 The initial state of the Subsystem Energy Saving State Model, referred to as “NoState” is represented in Figure 1 as a ring with a solid black dot. NoState is not a true state. It is a pseudostate representing the time when the production equipment is powered off or the control system is in the process of starting up or shutting down.

9.2.2.4 SubsystemEnergySaving State

[Vsss.ss-RQ-00007-00] The SubsystemEnergySaving state is the top-level super-state that holds all the sub-states of the state model. [/RQ]

9.2.2.4.1 The sub-states of the SubsystemEnergySaving state are EquipmentOperated and NotEquipmentOperated.

9.2.2.4.2 In the SubsystemEnergySaving state the subsystem provides subsystem energy saving mode capability if the subsystem is in the EquipmentOperated state only (see definition in ¶5.2.2 ).

[Vsss.ss-RQ-00008-00] The SubsystemEnergySaving state shall be in effect only when the subsystem is powered up and the subsystem’s control system is operational. [/RQ]

9.2.2.5 EquipmentOperated State

[Vsss.ss-RQ-00009-00] The EquipmentOperated state is a sub-state of the SubsystemEnergySaving state. [/RQ]

9.2.2.5.1 The substates of the EquipmentOperated state are SubsystemProcess, SubsystemIdle and SubsystemSleep.

9.2.2.5.2 The EquipmentOperated state represents the time the subsystem is providing energy saving mode capability.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

9.2.2.6 SubsystemProcess State

[Vsss.ss-RQ-00010-00] The SubsystemProcess state is a substate of EquipmentOperated. [/RQ]

9.2.2.6.1 When in the SubsystemProcess state, the subsystem is busy performing its intended function. This includes operation on product or by-product material or with no material.

9.2.2.6.2 The SubsystemProcess state represents that the subsystem is in the subsystem process mode (see definition in ¶5.2.5 ).

9.2.2.6.3 In the SubsystemProcess state, subsystem is busy and unavailable for sleep. Therefore, the subsystem energy savings capability to initiate SubsystemSleep state is not available.

9.2.2.6.4 In some special cases, a subsystem may provide additional energy saving modes while in SubsystemProcess state. Some subsystems may operate under lower energy consumption rate when the equipment load or process function changes. For example, if one subsystem is connected with multiple chambers it may be possible to provide energy savings when one or more chambers are idle due to a change of process load. Transition 9 is used to indicate that a different process mode of operation has started by the subsystem. This transition depends on whether or not the subsystem supports this type of capability.

[Vsss.ss-RQ-00011-00] When in the SubsystemProcess state, subsystem shall ignore or reject all Sleep request received. [/RQ]

[Vsss.ss-RQ-00012-00] When in the SubsystemProcess state, subsystem shall ignore or reject all WakeUp requests received. [/RQ]

9.2.2.7 SubsystemIdle State

[Vsss.ss-RQ-00013-00] The SubsystemIdle state is a sub-state of EquipmentOperated. [/RQ]

9.2.2.7.1 In the SubsystemIdle state the subsystem is ready to return to process mode in the subsystem’s defined reaction time.

9.2.2.7.2 The SubsystemIdle state represents that the subsystem is in the Subsystem Idle Mode (see definition in ¶5.2.4 ).

9.2.2.7.3 Subsystems in the SubsystemIdle state can accept a Sleep command in most circumstances. See the definition of the Sleep command in ¶9.3.2 for more detail.

[Vsss.ss-RQ-00014-00] When in the SubsystemIdle state, subsystem shall accept any valid Sleep requests received with the exception of those covered by the reject conditions specified for the Sleep command. [/RQ]

9.2.2.7.4 See ¶9.3.2.4 for reject conditions for Sleep requests.

[Vsss.ss-RQ-00015-00] When in the SubsystemIdle state, a subsystem shall ignore or reject all WakeUp requests received. [/RQ]

9.2.2.8 SubsystemSleep State

[Vsss.ss-RQ-00016-00] The SubsystemSleep state is a sub-state of EquipmentOperated. [/RQ]

9.2.2.8.1 While in the SubsystemSleep state, the subsystem is operating at a reduced rate of energy consumption.

9.2.2.8.2 The SubsystemSleep state represents that the subsystem is in the subsystem sleep mode (see definition in ¶5.2.7 ).

[Vsss.ss-RQ-00017-00] Under normal conditions, the energy savings achieved in the SubsystemSleep state shall not cause the need for external assistance in order to return to the SubsystemIdle state or the need for requalification, calibration or other maintenance. [/RQ]

9.2.2.8.3 The subsystem is responsible for achieving the optimal energy savings possible within the limits implied by the parameters specified in the Sleep request.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

9.2.2.8.4 The sleep conditions can be modified by sending a new Sleep request to the subsystem while it is in the SubsystemSleep state.

[Vsss.ss-RQ-00018-00] When in the SubsystemSleep state, the subsystem shall accept any valid Sleep request received with the exception of those covered by the reject conditions specified for the Sleep request. The subsystem shall adjust its energy saving conditions according to the request type or parameters. [/RQ]

9.2.2.8.5 In some cases, the new Sleep request will not change the energy savings or sleep level condition of the subsystem (see SleepLevel in Table 14). In this case, the subsystem will remain in the SubsystemSleep state and no event messages or signal changes will be reported. Transition 10 indicates when the sleep level request has changed the current sleep level. If an sleep level change occurred and event or signal change is reported by the subsystem

[Vsss.ss-RQ-00019-00] When in the SubsystemSleep state, subsystem shall accept any valid WakeUp request received. [/RQ]

9.2.2.8.6 When a request to wake up is received while in the SubsystemSleep state, the subsystem indicates that is to move from its reduced rate of energy consumption back to the SubsytemIdle state where it is ready to transition normal process operation.

[Vsss.ss-RQ-00020-00] The subsystem shall acknowledge acceptance of a WakeUp request and remain in the SubsystemSleep state until it reaches the conditions necessary for transition back to normal operation or a subsystem failure is encountered. [/RQ]

9.2.2.8.7 The process of SubsystemWakingUp concludes with the restoration of the designed SubsystemIdle state and its rate of energy use. The rate of energy used during the waking up period might exceed that of the SubsytemIdle state. This energy consumption rate is subsystem specific.

[Vsss.ss-RQ-00021-00] When in the waking up, the subsystem shall accept any valid Sleep requests received. [/RQ]

[Vsss.ss-RQ-00022-00] When in the SubsystemWakingUp state, the subsystem shall ignore or reject all WakeUp requests received. [/RQ]

9.2.2.9 NotEquipmentOperated State

[Vsss.ss-RQ-00023-00] The NotEquipmentOperated state is a sub-state of SubsystemEnergySaving state. [/RQ]

9.2.2.9.1 The NotEquipmentOperated state encompasses all conditions where the subsystem may be active but it is not under control by the production equipment. The subsystem may be in the NotEquipmentOperated state due to a subsystem detected problem with itself, or the production equipment, or a communication problem with the production equipment, or due to a user initiated activity.

9.2.2.9.2 The NotEquipmentOperated state is not intended to include all subsystem activities performed on the subsystem. Many such activities require the subsystem to be off-line or powered down. In this case, the Subsystem Energy Saving State Model would not apply.

9.2.2.9.3 Although the energy consumption rate of the subsystem while in the NotEquipmentOperated state may be reduced under some conditions, such reductions are not in the scope of this specification and are not covered by the SubsystemEnergySaving state model.

9.2.3 SubsystemEnergySaving State Model Transitions

9.2.3.1 Table 7 defines the state transitions for the SubsystemEnergySaving state model.

9.2.3.2 Note that RQ-00002 in ¶6.2.4 requires that there be a collection event for each transition defined in Table 7. In some cases when interface signals are used between the production equipment and the subsystem, the subsystem sets the appropriate signals to indicate its status.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

Table 7 SubsystemEnergySaving State Transition Table

Requirement ID # Previous

State Trigger

New State

Action(s)

[Vsss.ss-RQ-00024-00] 1 NoState

Subsystem initialization is completed and the subsystem is operational but it is not communicating with the equipment due to a subsystem detected problem with itself or the production equipment or due to a user initiated activity.

NotEquipment Operated

Subsystems that have no provision for NotEquipmentOperated are not required to provide the transition to that state. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00025-00] 2 NoState

Subsystem initialization is completed and subsystem is operational

Conditional: The appropriate sub-state of the Equipment Operated state: SubsystemProcess (2a), SubsystemIdle (2b), SubsystemSleep (2c)

Conditions for selection of the current subsystem state are subsystem specific. The subsystem shall choose the appropriate new state. The subsystem transitions to the state it is in. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00026-00] 3 SubsystemProcess

Subsystem completes processing or a main intended function task and pauses

SubsystemIdle

An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00027-00] 4 SubsystemIdle Subsystem returns to perform its intended function after a pause

SubsystemProcess


[Vsss.ss-RQ-00028-00] 5 SubsystemIdle

A Sleep command is accepted by the subsystem and initiates its energy conservation rate level

SubsystemSleep


[Vsss.ss-RQ-00029-00] 6 SubsystemSleep

WakeUp command is accepted by the subsystem and the subsystem terminates its energy conservation rate. Subsystem begins the process of moving from reduced energy consumption to a condition where it is ready for normal operation.

SubsystemIdle

Length of time the subsystem stays in this state is subsystem specific and varies based on the sleep level the subsystem is coming back from. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

Requirement ID # Previous

State Trigger

New State

Action(s)

[Vsss.ss-RQ-00030-00] 7

Any of the Equipment Operated sub-states

Subsystem has determined that the NotEquipmentOperated transition is required. Subsystems that have no provision for NotEquipmentOperated while the subsystem is operational are not required to provide this transition.

NotEquipment Operated

This transition is subsystem specific. The subsystem determines that it needs to communicate that it is no longer under control of the production equipment. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00031-00] 8 NotEquipment Operated

Subsystems that have no provision for NotEquipmentOperated are not required to provide this transition.

Conditional: Any of the Equipment Operated state: SubsystemProcess (8a), SubsystemIdle (8b), SubsystemSleep (8c)

Subsystem determines the appropriate EquipmentOperated substate. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter:

EnergySavingState

[Vsss.ss-RQ-00032-00] 9 Subsystem Process

In some special cases, a subsystem may provide additional energy saving modes while in SubsystemProcess state. This transition is used to indicate that a different mode of operation has started by the subsystem

SubsystemProcess

Subsystems that have no provision for this mode of operation are not required to provide this transition. An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00033-00] 10 SubsystemSleep

A new request or command for sleep has been received and accepted by the subsystem.

SubsystemSleep

Subsystems that have no provision to provide multiple sleep levels are not required to provide this transition An event or appropriate condition signals are set to reflect the subsystem status. Required event data parameter: EnergySavingState

[Vsss.ss-RQ-00034-00] 11 Any of the Subsystem Energy Saving States

The subsystem is no longer operational or has been powered down

No state

An event or appropriate condition signals are set to indicate this change. Required event data parameter: EnergySavingState

9.2.3.3 Transition 2 is a conditional transition with 4 possible endpoints. RQ-00025 designates the four variations as 2a, 2b, and 2c for those messaging systems that require separate naming for the four transitions.

9.2.3.4 Transition 8 is a conditional transition with 4 possible endpoints. RQ-00031 designates the four variations as 8a, 8b, and 8c for those messaging systems that require separate naming for the four transitions.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

9.3 Subsystem Energy Saving Mode Message Services

9.3.1 The three message services required to support subsystem energy saving mode capability are listed in Table 8.

Table 8 Subsystem Energy Saving Mode Message Services

RequirementID Signal or Message Service Name

Type Description

[Vsss.ss-RQ-00035-00] Sleep R Request signal or command from the production equipment to the subsystem to transition to the SubsystemSleep state for the purpose of reduced energy consumption.

[Vsss.ss-RQ-00036-00] WakeUp R Request Signal or command from the production equipment to the subsystem to transition from SubsystemSleep state to the SubsystemIdle state via the SubsystemWakingUp state

[Vsss.ss-RQ-00037-00] Acknowledge N Notification from the subsystem to the production equipment that the SubsystemEnergySaving state model has transitioned to a new state.

9.3.2 Sleep Request Signal and Command

9.3.2.1 The Sleep request signal or command from the production equipment requests the subsystem to transition from the SubsystemIdle state to the SubsystemSleep state (see ¶9.2.2.8 and Transition 5 in Table 7. The subsystem can accept the Sleep command only in selected states of the Subsystem Energy Saving State Model. For more detail, see the descriptions of the individual states in ¶9.2.2 .

9.3.2.2 When a software protocol is used; the Sleep command includes one input parameter, SleepLevel, defined in Table 9. This value is provided such that the subsystem can transition to the appropriate energy reduction rate level based on its defined wake up time thresholds when multiple sleep levels are provided by the subsystem.

9.3.2.3 When request signals are used; a binary combination code of independent control signals may be used mapping to the corresponding energy saving rate or sleep level. See Table 10.

9.3.2.3.1 When a SleepLevel is provided to the subsystem by the production equipment; the subsystem transitions to the requested sleep level as a result of this request. If the subsystem only implements one sleep level, the subsystem transition to the default sleep level.

9.3.2.4 The response or acknowledgement to the Sleep command indicates whether the request is accepted or rejected. Acceptance does not mean that a reduced rate of energy use has been reached, but rather that the change has been initiated. If rejected, the subsystem either acknowledges via a signal acknowledge or via an AcknowledgeCode (see Table 9) for the reason for rejection.

Table 9 Sleep Command Service Parameters

RequirementID Parameter In / Out Description Format

[Vsss.ss-RQ-00038-00] SleepLevel In

The amount of time in minutes the production equipment estimates it will not require the subsystem to perform its intended function (Ex. 60 for 1 hour, 360 for 6 hours, 2880 for 48 hours or 2 days, etc.).

Integer

If binary signal is used, the SleepLevel zero instructs the subsystem to choose a default set of energy saving conditions. The implementer shall document the energy saving conditions that will result in each case.

[Vsss.ss-RQ-00039-00] AcknowledgeCode Out

Acknowledgement of the success or reason for rejection of the Sleep command. Used with software protocols only. Codes: Command accepted, Cannot perform now, Invalid parameter

Protocol specific




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

9.3.2.5 The “Cannot perform now” reject code is intended to cover the case where the SubsystemEnergySaving state model is in a state which does not allow this command.

Table 10 Sleep Software Protocol Signals

RequirementID Signal In / Out Description Format

[Vsss.ss-RQ-00040-00] S0, S1, S2, S3 In One or more subsystem defined time thresholds that are required to return to SubsystemIdle state.

Binary

If the signal is S0, it instructs the subsystem to choose a default set of energy saving conditions. The implementer shall document the energy saving conditions that will result in each case.

[Vsss.ss-RQ-00041-00] ACK Out Acknowledgement of the acceptance or rejection of the Sleep request.

9.3.2.6 The information specified in RQ-00040 should be included in the subsystem documentation for the interface that implements this standard.

9.3.2.7 The acknowledgement signal to the Sleep request indicates if the request is accepted or rejected. Acceptance does not mean that a reduced rate of energy use has been reached, but rather that the change has been initiated. The subsystem must indicate via another signal when the subsystem has reached the requested sleep level.

9.3.3 WakeUp Request signal and Command

9.3.3.1 The WakeUp request signal or command asks that the subsystem begin the process of transitioning from the SubsystemSleep state back to the SubsystemIdle state (see Transition 6 in Table 7). There are no input parameters for the WakeUp command.

9.3.3.2 The response to the WakeUp request or command indicates whether the command is accepted or rejected. If rejected, the AcknowledgeCode (see Table 11) gives the reason for rejection. When signals are used, the equipment waits until the subsystem returns to SubsystemIdle or ready to process.

Table 11 WakeUp Command Service Parameters

RequirementID Parameter In / Out Description Format

[Vsss.ss-RQ-00042-00] AcknowledgeCode Out Acknowledgement of the success or reason for rejection of the WakeUp command. Codes: Command accepted, Cannot perform now

Protocol specific

9.3.3.3 The “Cannot perform now” reject code is intended to cover the case where the SubsystemEnergySaving state model is in a state which does not allow this command.

Table 12 WakeUp Signals

RequirementID Signal In / Out Description Format

[Vsss.ss-RQ-00043-00] ACK Out Acknowledgement of the acceptance or rejection of the WakeUp request.

9.3.3.4 The acknowledgement signal to the WakeUp request indicates if the request is accepted or rejected. Acceptance does not mean that SubsystemIdle state has been reached, but rather that the change has been initiated. The subsystem must indicate via another signal when the subsystem has reached the SubsystemIdle state.

9.3.4 Software Notification

[Vsss.ss-RQ-00044-00] When a software protocol is used; an event report message shall notify the equipment of every occurrence of each collection event if reporting is enabled by the equipment. The equipment shall have the capability to disable and enable the reporting of selected collection events. [/RQ]

9.3.4.1 The mechanism for enabling and disabling the reporting of collection events is protocol specific.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

Table 13 Event Report Service Parameters

RequirementID Parameter Description Format

[Vsss.ss-RQ-00045-00] EventID Identifier for the collection event. Protocol dependent

[Vsss.ss-RQ-00046-00] TimeStamp Time at which the collection event occurred Protocol dependent

[Vsss.ss-RQ-00047-00] DataParameters List of data parameters (if any) selected by the user to be included with the event

Protocol dependent

9.3.4.2 Data Parameters

[Vsss.ss-RQ-00048-00] A mechanism shall be provided to allow the equipment to select the data parameters reported for each collection event. [/RQ]

9.3.4.2.1 The mechanism for selecting data parameters to be reported with each collection event is protocol specific.

9.3.4.2.2 The data parameters defined in Table 14 are intended to be made available for the reporting of collection events corresponding to transitions of the SubsystemEnergySaving State Model. See Table 7 (Action(s) column) for specification of which data parameters are required to be available for the collection event corresponding to each transition in the Subsystem Energy Saving State Model.

Table 14 Subsystem Energy Saving Mode Data Parameters

Requirement ID Data Parameter Req Description Data Type

[Vsss.ss-RQ-00049-00] EnergySavingState Y

Current state of the subsystem with respect to the Subsystem Energy Saving state model. This is a non-transient parameter. When included in an event report related to a transition of the Subsystem Energy Saving State Model, it shall reflect the new state of the transition as shown in Table 7.

Protocol dependent

9.3.5 Hardware Notifications

[Vsss.ss-RQ-00050-00] When a physical interface is used; a signal or combination of signals to each of the requests shall be used by the subsystem to notify the production equipment when a new state has been reached. [/RQ]

9.3.5.1 The logic used to indicate and confirm the arrival to a new state is based on current standard practices. Equipment and subsystem must follow all safety protocols such that the production equipment and subsystem are synchronized at all times. See Appendix 2 and 3 for I/O signal definitions.

10 Test Methods

10.1 No test methods are defined for this specification

11 Related Documents

11.1 D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231--274, 1987.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

APPENDIX 1 STATEMENT OF COMPLIANCE NOTICE: The material in this Appendix is an official part of SEMI [designation number] and was approved by full letter ballot procedures on [A&R approval date].

A1-1 Statement of Compliance

[Vsss.ss-RQ-90001-00] A supplier shall submit a completed Capability Requirements Compliance Table per Table A1-1, Vsss.ss Capability Requirements, when reporting on compliance of equipment or an application to this specification to a customer. [/RQ]

A1-2 Compliance Table: Capability Requirements

[Esss.00-RQ-90002-00] Each supplier shall document compliance to Esss.ss capabilities requirements per Table A1-1, Esss.ss Capability Requirements, with the following values: C – Comply, NC – Not Comply, WC – Will Comply, NA – Not Applicable. [/RQ]

[Esss.00-RQ-90003-00] The NA code for Not Applicable shall be used only in the case where a requirement is conditional and the condition evaluates to render the requirement not applicable for the current implementation. [/RQ]

A1-2.1 Child requirements inherit the conditional status of the parent requirement. Where a parent requirement is marked NA, the child requirements should also be marked NA.

[Esss.00-RQ-90004-00] An explanation for NC shall be provided by the supplier. [/RQ]

A1-2.2 If WC is assigned, supplier should provide a date for implementation.

Table A1-1 Vsss.ss Capability Requirements

Section Requirement ID Parent Requirement ID Condition / Selection Criteria

Compliance

(C/NC/WC)

Capability: Statement of Compliance

A.1-1 Vsss.ss-RQ-90001-00 - -

A.1-2 Vsss.ss-RQ-90002-00 Vsss.ss –RQ-90001-00 -

A.1-2 Vsss.ss-RQ-90003-00 Vsss.ss -RQ-90002-00 -

Capability: 6 Conventions

6.1.5 Vsss.ss-RQ-00001-00 - -

6.2.4 Vsss.ss-RQ-00002-00 Vsss.ss-RQ-00001-00 -


Capability: 8 Prerequisites

8.1 Vsss.ss-RQ-00004-00 Vsss.ss-RQ-00001-00 -

Capability: 9 Requirements





LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015


Compliance

(C/NC/WC)

Capability: 9.2 SubsystemEnergySaving State Model


Capability: 9.2.2 Subsystem Energy Saving States


















Capability: 9.2.3 SubsystemEnergySaving Transitions

9.2.2.9 Vsss.ss-RQ-00024-00 Vsss.ss-RQ-00006-00 SleepLevelDefined =, UserInterfaceSleep =

9.2.2.9 Vsss.ss-RQ-00025-00 Vsss.ss-RQ-00006-00 -







9.2.2.9 Vsss.ss-RQ-00032-00 Vsss.ss-RQ-00006-00 ProcessLevelDefined=



Capability: 9.3 Subsystem Energy Saving Mode Message Services




Capability: 9.3.2 Sleep Request signal or Command





LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015


Compliance

(C/NC/WC)


9.3.2 Vsss.ss-RQ-00040-00 Vsss.ss-RQ-00035-00


Capability: 9.3.3 Wakeup Request Signal or Command



Capability: 9.3.4 Event Report Notification








A1-3 Compliance Table: Equipment Conditional Criteria

[Esss.00-RQ-90005-00] Each equipment supplier shall document Esss.ss specific conditional criteria per Table A1-2, Equipment Conditional Criteria. [/RQ]

A1-3.1 Conditional criteria are used to identify when Conditional requirements are to be implemented on the equipment.

Table A1-2 Conditional Criteria

Name Values Description Section

SleepLevelDefined

True False

True – Implementer has defined sleep levels and elected to report them using the SleepLevel data parameter. False – Implementer does not provide the SleepLevel data parameter. Note that this condition applies only to the inclusion of the SleepLevel data parameter in the requirement.

9.3.4.2

ProcessLevelDefined True False

True – Implementer has defined process levels and elected to report them using an event. False – Implementer does not provide the ProcessLevel event.

9.2.2.6

UserInterfaceSleep

True False

True – The subsystem provides Sleep and Wakeup commands via its user interface. False – The Sleep and Wakeup command are available only remotely.

9.3.5




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

RELATED INFORMATION 1

Energy Savings Signal Connections for Pump Systems NOTICE : This related information is not an official part of SEMI [insert designation, without publication date (month-year) code] and was derived from [insert origin of the information]. This related information was approved for publication by [insert the method by which publication was authorized, Regulations, ¶12.2] on [insert date of approval].

R1-1 Introduction

R1-1.1 The purpose of this related information section is to define signal communication between production equipment and vacuum pumps to enable reduced energy consumption. Dry and Turbo pumps are referenced when the term pump is used in this document. The signals defined in this related information section provide a means to manage and communicate pump energy saving state status for the production equipment such that it can initiate (and terminate) the pump energy saving mode in a coordinated and safe manner.

R1-1.2 It is understood that additional detail information may be required to fully specify the actual physical and electrical connections. Such specification it is outside of the scope of this document and needs to be defined and addressed by the Physical Interfaces & Carriers Committee.

R1-2 Energy Savings Control Signals for Pumps

R1-2.1 Dry Pump Control Signals

R1-2.1.1 Table R1-1 specifies the required Dry Pump I/O control signals. For additional information on requirements and recommendations for signal timing, see SEMI E73.

Table R1-1 Dry Pump I/O Signals

No. Signal Name Direction Type Remarks

1 Start (Run)/Stop Input signal to Pump Alternate Pump runs when closed

2 Start (Run)/Stop Output signal from Pump Alternate Close on pump start Running status signals When input power is OFF, output status signals should become open (normally open).

3 Remote/Local Output signal from Pump Alternate Close during remote operation

4 Pump Warning Output signal from Pump Alternate Open at warning

5 Pump Alarm Output signal from Pump Alternate Open at alarm

6 Ready For Process Output signal from Pump Alternate Closed when ready to process and open when Idle or while sleep

7 Go to Sleep Input signal to Pump Alternate Pump goes to sleep when closed if pump accepts the request otherwise a warning is raised

8 Sleep Level Bit 1 Input signal to Pump Alternate Optional. When sleep levels are provided these two signals indicate the sleep levels 00 = Default Sleep Level 01 = Sleep Level 1 10 = Sleep Level 2 11 = Sleep Level 3

9 Sleep Level Bit 2 Input signal to Pump Alternate

NOTE 1: A separate physical connection is recommended for the energy savings related signals shown shaded in this table.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

R1-2.2 Turbomolecular Pump Control Signals

R1-2.2.1 Table R1-2 specifies the required Turbomolecular Pump I/O control signals. For additional information on requirements and recommendations for signal timing, see SEMI E74.

Table R1-2 Turbomolecular I/O Signals


1 Start (Run)/Stop Input signal to Pump Alternate Pump runs when closed

2 Acceleration Output signal from Pump Alternate Closed during acceleration Running status signals When input power is OFF, output status signals should become open (normally open).

3 Normal Operation Output signal from Pump Alternate Close during normal operation

4 Deceleration Output signal from Pump Alternate Closed during deceleration

5 Remote/Local Output signal from Pump Alternate Closed during remote operation

6 Pump Alarm Output signal from pump Alternate Open at alarm

7 Ready For Process Output signal from Pump Alternate Closed when ready to process or idle and open while sleep

8 Go to Sleep Input signal to Pump Alternate Pump goes to sleep when closed if pump accepts the request

9 Sleep Level Bit 1 Input signal to Pump Alternate Optional. When sleep levels are provided these two signals indicate the sleep levels 00 = Default Sleep Level 01 = Sleep Level 1 10 = Sleep Level 2 11 = Sleep Level 3

10 Sleep Level Bit 2 Input signal to Pump Alternate

NOTE 2: A separate physical connection is recommended for the energy savings related signals shown shaded in this table.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015

RELATED INFORMATION 2

Energy Savings Signal Connections for Abatement Systems NOTICE : This related information is not an official part of SEMI [insert designation, without publication date (month-year) code] and was derived from [insert origin of the information]. This related information was approved for publication by [insert the method by which publication was authorized, Regulations, ¶12.2] on [insert date of approval].

R2-1 Introduction

R2-1.1 The purpose of this related information section is to define signal communication between production equipment and abatement systems to enable reduced energy consumption. The signals defined in this related information section provide a means to manage and communicate abatement energy saving state status for the production equipment such that it can initiate (and terminate) the abatement energy saving mode in a coordinated and safe manner.

R2-1.1.1 It is understood that additional detail information may be required to fully specify the actual physical and electrical connections. Such specification is outside of the scope of this document and needs to be defined and addressed by the Physical Interfaces & Carriers Committee.

R2-2 Energy Savings Control Signals for Abatement Systems

R2-2.1 Abatement Control Signals

R2-2.1.1 Table R2-1 specifies the required Abatement I/O control signals. For additional information on requirements and recommendations for signal timing, see SEMI E73 and SEMI E74.

Table R2-1 Abatement I/O Signals


1 Abatement Run Mode 1 (Deposition) Request (1..n)

Input signal to abatement

Alternate Abatement runs Mode 1 when closed

Separate signals are required for each of the systems that are connected to the abatement.

2 Abatement Run Mode 2 (Clean) Request (1..n)

Input signal to abatement

Alternate Abatement runs Mode 2 when closed

Separate signals are required for each of the systems that are connected to the abatement.

3 Abatement Run/(Stop) Confirmation (1..n)

Output signal from Abatement

Alternate Close on abatement start and when the abatement is treating gases.

Running status signals When input power is OFF, output status signals should become open (normally open). 4 Remote/Local Output signal from

Abatement Alternate Close during remote

operation and open when serviced or local operation.

5 Abatement Warning Output signal from Abatement

Alternate Open at warning or when a critical condition is reached. Process is possible.

6 Abatement Alarm Output signal from Abatement

Alternate Open at failure or alarm

7 Abatement Redundancy Signal (1..n)


Alternate Only for redundant systems. Open when a service or one redundant unit failed.

8 Ready For Process (1..n)


Alternate Closed when ready to process or idle and open when sleep. It is also closed when inlet is ready.




LE

TT

ER

(Y

EL

LO

W)

BA

LL

OT


Date: 2/5/2015


8 Pump Failure (1..n)

Input signal to Abatement

Alternate Input from pump alarm. Open when alarm occurred.

Separate signals are required for each of the pump systems that are connected to the abatement.

9 Go to Sleep (1..n) Input signal to Abatement

Alternate Abatement goes to sleep when closed if pump accepts the request otherwise a warning is raised.

10 Sleep Level Bit 1(1..n) Input signal to Abatement

Alternate Optional. When sleep levels are provided these two signals indicate the sleep levels 00 = Default Sleep Level 01 = Sleep Level 1 10 = Sleep Level 2 11 = Sleep Level 3

11 Sleep Level Bit 2(1..n) Input signal to Abatement

Alternate

NOTE 3: A separate physical connection is recommended for the energy savings related signals shown shaded in this table. Additional signals may be added when Abatement systems provide

NOTICE: Semiconductor Equipment and Materials International (SEMI) makes no warranties or representations as to the suitability of the Standards and Safety Guidelines set forth herein for any particular application. The determination of the suitability of the Standard or Safety Guideline is solely the responsibility of the user. Users are cautioned to refer to manufacturer’s instructions, product labels, product data sheets, and other relevant literature, respecting any materials or equipment mentioned herein. Standards and Safety Guidelines are subject to change without notice.

By publication of this Standard or Safety Guideline, SEMI takes no position respecting the validity of any patent rights or copyrights asserted in connection with any items mentioned in this Standard or Safety Guideline. Users of this Standard or Safety Guideline are expressly advised that determination of any such patent rights or copyrights, and the risk of infringement of such rights are entirely their own responsibility.

Date post:	14-Mar-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times