PLEASE NOTE: This ballot contains a proposal for a revision to an existing standard.

Transcription

1 Background Statement for SEMI Draft Document 5274AInfo REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR SENSOR/ACTUATOR NETWORK SPECIFIC DEVICE MODEL OF A GENERIC EQUIPMENT ADD-ON SENSOR (ADDON) TO SEMI E , SENSOR/ACTUATOR NETWORK STANDARD Note: 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. Note: 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. PLEASE NOTE: This ballot contains a proposal for a revision to an existing standard. Purpose Provide for the addition of a dot standard to the E54 standard suite for a Generic Equipment add-on sensor (ADDON). Background There are many types of sensors that could be part of a sensor/actuator network (SAN) that might be added to semiconductor manufacturing equipment as an add-on sensor, but don t have, have yet, or a require a specific device model (SDM). To meet the requirements of interoperability and interchangeability however there should be a standard interface available in addition to what is provided by the common device model (CDM) to include additional sensors into the SAN environment. The E54 standard suite provides a mechanism for specifying structure and behavior common to a specific device type or group of device types, called a specific device model (SDM). Control data usually provided from the equipment such as rf-generator power and chamber pressure does often not allow a sufficient characterization of the process in terms of Advanced Process Control (APC), e-diagnostic, or Enhanced Equipment Quality Assurance (EEQA). Legacy equipment is often limited in its capability to deliver the required amount of data via a SECS I interface. Add- on sensors can overcome this lack providing data directly into the FDC system using a unified interface. A SDM could be used to provide a model that would facilitate providing sensor data with appropriate context (e.g., RecipeID) to support its use in these applications. Every add-on sensor with the property to be also a generic sensor device can benefit from even a very basic specific device model. This basic model can establish a level of interoperability and interchangeability that represents an enhancement over the Common Device Model, e.g., by specifying the communication of certain context or other characterization data.

2 This is a revised ballot: Issues brought up in earlier rounds of voting have been addressed with the modifications including: Attributes of the ASM - EnableReportRate, ReportInhibitTimer and ReportRate are not required (optional). All Attibutes of the CXT, which is a Substrate Object, refer to SEMI E90, i.e. the form of of the substateid might be a list related to that document. The description of CXT refers now to SEMI 90 which allows the usage of lists without defining each list of an attribute. LotIDList and SubstrateIDList may be supported concerning the convention of SEMI E90. Change in labeling in Figure 1. Added sentence in 5.2.1, "This generic sensor may provide more than one value. The ASM of the sensor contains all values including descriptors and data types the device produces." Analogue Input Object renamed to Sensor Analogue Input Object Terminology added SAI Sensor Analogue Input Object and deleted description of AI. Sentence changed in 7.1.4, The Assembly Object of the ADDON contains a data attribute which is a structure. including the values of all instances of the SAI, a single data time stamp and the exception status both as attributes of the DM. Time stamp changed to data time stamp. Changed the identifier of the data array attribute of ASM into data Changed the data type of the data attribute to structure. Changed section 7.2.2, Data structure of three items; contains all values the sensor can deliver. The first item is the data time stamp. The data array is represented by an array of double words data. Each subsequent element of this array relates to an instance of the SaiA16 (attribute value ).. The third item of the structure is related to the exception status attribute of DM (See Table 2). Rename type array to data type array. Changed section Inserted (SaiA1) to indicate the CDM tag which relate to the name attribute. Figure 1- Changed name of the attributes of ASM: DataTypeArray. Table 2 changed: Introduced data structure including items; DataTimeStamp, DataArray, ExceptionStatus. Changed section 7.3 CMD into CDM. Referenced Standards inserted: E39 Object Services Standard Section Scope changed New Tables for Add-on device, DMAttributes, ASMAttributes, Proposal and Impact This will only impact the E54 standard. It will provide for the addition of a dot standard to the E54 standard suite for a Generic Equipment add-on sensor (ADDON). Review Information Task Force Review Group: Sensor Bus Task Force Date: Tuesday, July 8, 2014 Time & Timezone: 1:00 PM to 3:00 PM (US Pacific Time) Location: San Francisco Marriott Marquis Hotel, 780 Mission Street City, State/Country: San Francisco, California Leader(s): James Moyne (University of Michigan), Dirk Suchland (Plasmetrex, author) Standards Staff: Paul Trio (SEMI NA), , ptrio@semi.org 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. The ballot begins on the next page

3 SEMI Draft Document 5274AInfo REVISION TO ADD A NEW SUBORDINATE STANDARD: SPECIFICATION FOR SENSOR/ACTUATOR NETWORK SPECIFIC DEVICE MODEL OF A GENERIC EQUIPMENT ADD-ON SENSOR (ADDON) TO SEMI E , SENSOR/ACTUATOR NETWORK STANDARD 1 Purpose 1.1 This specification is part of a suite of standards which specify the implementation of SEMI standards for the Sensor/Actuator Network. The specific purpose of this specification is to describe a network-independent application model of a generic sensor device attached to a Sensor/Actuator communication network. There are many types of sensors that could be part of a Sensor/Actuator Network which can be modeled common objects of the Common Device Model. A data structure as an attribute of the Assembly Object is specified which unique from the point of view of the network. To meet the requirements of interoperability and interchangeability however there should be a standard interface available in addition to what is provided by the Common Device Model to include additional sensors into the Sensor/Actuator Network environment. 2 Scope 2.1 This document describes a specific device structure and behavior of a generic equipment add-on sensor. 2.2 This document is applicable to add-on sensors which are regarded as data producer only. A configuration or control of the sensor device (e.g., described by a third entity) is outside the scope of this standard. 2.3 This document does not define terms which have been defined already in other referenced documents. 2.4 This document does not apply to sensors for which a Specific Device Model (SDM) is specified in E54. 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 Referenced Standards and Documents 3.1 SEMI Standards SEMI E39 Object Services Standard SEMI E54 Sensor/Actuator Network Standard SEMI E54.1 Standard for Sensor/Actuator Network Common Device Model SEMI E90 Specification for Substrate Tracking NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. 4 Terminology 4.1 Abbreviations and Acronyms ADDON Generic Equipment add-on Sensor CXT Context Object FDC Fault Detection and Classification NCS Network Communication Standard 4.2 Definition Context data data which identify a specific manufacturing process or a sub process and the substrate which is processed and its location within the manufacturing equipment. Page 1 D5274AINFO SEMI

4 4.2.2 Data report a list of attributes for a single object. Data reports may be pre-defined Generic equipment add-on sensor device additional measurement device which is connected to a manufacturing equipment optionally or temporally in order to measure values which are relevant for processing. It delivers data without the need of further control or configuration. Therefore it has common properties only.the data delivered by the add-on sensor are transferred via a SAN according to SEMI E54. The sensor does not yet have, or does not require a SDM RecipeID an identifier of a pre-planned and reusable portion of the set of instructions, settings, and parameters under control of a processing agent that determines the processing environment seen by the material (e.g., wafer) Recipe step a distinct subset of process specification of the recipe that represents a significant change in the recipe execution conditions or instructions from the steps that precede or follow. A recipe step is completely contained within a single recipe component. 5 Device High Level Structure 5.1 General Description A generic add-on sensor device is made up of objects and attributes that are defined within the Common Device Model. A data structure as an attribute of the Assembly object is defined which contains all available data together with a data time stamp and the exception status. The data type and the descriptor of each value which the add-on sensor delivers can be derived from the sensor itself. A data consumer may read the data attribute of the Assembly Object to get all the data of the sensor. The consumer may also read the Names Array of the Assembly Object and the Data Type Array which give all information to interpret the data. That means the data consumer, i.e. the client, does not need any information about the sensor. The add-on sensor identifies itself by its descriptors of the data values and its data types. The add-on sensor measures values relevant for processing, e.g., from manufacturing equipment. It is a data producer only and does not need any control or configuration. Every add-on sensor can benefit from even a very basic specific device model. Control data usually provided from the equipment such as rf-power and chamber pressure does often not allow a sufficient characterization of the process in terms of Advanced Process Control, e-diagnostic, or Enhanced Equipment Quality Assurance. Legacy equipment is often limited in its capability to deliver the required amount of data via a SECS I interface. Add-on sensors can overcome this lack of capability by providing data directly into the FDC system using a unified interface. A SDM could be used to provide a model that would facilitate providing sensor data with appropriate context (e.g., RecipeID) to support its use in these applications. This basic model can establish a level of interoperability and interchangeability that represents an enhancement over the Common Device Model (CDM), e.g., by specifying the communication of certain context or other characterization data. The add-on sensor has a Context Object optionally. The attributes of the Context Object can be written by a client to transfer context data to the sensor. It may use the context data, e.g. algorithms selected based on the process recipe used Add-on Sensor (ADDON) Device Description The high-level object view of a Generic Sensor Device (ADDON) is shown in Figure 1. The ADDON is built up of objects as described in Figure 1defined in the CDM and an optional Context Object. Page 2 D5274AINFO SEMI

5 1 1 ADDON 1+ DM SAC SAI Value Type Name Get Assembly Data NamesArray DataTypeArray EnableReportRate ReportInhibitTimer Get Set Figure 1 High-level Object View of a Generic Sensor Device (ADDON) 1 Context RecipeID Recipe Step Get Set Substrate (defined in E90) Each data value delivered by the ADDON is referred to as an attribute value of an instance of the Sensor Analogue Input. If the ADDON delivers n values n instances of the SAI have to be established. The Assembly Object of the ADDON contains a data attribute which is a structure that includes the values of all instances of the SAI, a single data time stamp and the exception status both as attributes of the DM. Additionally it contains arrays of descriptors and of data types referring to the values the ADDON delivers. All relevant information about the sensor parameters is concentrated in the Assembly Object (ASM) General Requirements Device Objects All objects are defined in terms of their object name and instance identifier. Identifiers for all objects described in this document are summarized in Table 1. Table 1 Add-on Sensor Objects Referenced Document Section Object Name Object Identifier Minimum Instances Maximum Instances 5.2 Device Manager (DM) ADDON Sensor Actuator Controller (SAC) ADDON Assembly (ASM) ADDON Sensor Analogue Input (SAI) ADDON4 1 Manufacturer-Specified 5.6 Context (CXT) ADDON5 0 1 Page 3 D5274AINFO SEMI

6 5.2 Device Manager Object DM The Device Manager Object instance is the device component responsible for managing and consolidating the device operation as specified in SEMI E54.1. The following sections specify the components of DM that are not specified in the Common Device Model Device Manager Object Attributes Table 2 Device Manager Object Attributes Attribute Name Attribute Identifier Rqmt Access Form Device Type DmA01 Y RO Refer to CDM (E54.1) Device Type An attribute which uniquely identifies the type of the device on the network. The device type attribute is assigned as follows: Add-on sensor device= ADDON. 5.3 Sensor/Actuator Controller Object SAC The Sensor/Actuator Controller object instance is the device component responsible for coordinating the interaction of the add-on sensor device with the sensory/actuation/control environment as specified in SEMI E54.1. NOTE 1: The Assembly Object is embedded in the SAC. 5.4 Assembly Object ASM The ASM inherits all properties, services, and behavior from the assembly object of the CDM. Additional attributes are defined in this document. It consolidates all data values of the sensor. The data can be polled by a data consuming entity or a data report can be initiated. The data set includes data time stamp and status information which indicates errors or warnings. The descriptor and the data type of each value are contained also in the ASM as attributes. A data consumer could read all necessary information to interpret the measured values Assembly Object Attributes Table 3 Assembly Object Attributes Attribute Name Attribute ID Rqmt Access Form Description of Attribute Data* A01 Y RO Structure of: Structure of four items: DATE AND TIME, refer to SEMI E54.1 DataTimeStamp UDINT Length ARRAY of DOUBLE WORD DataArray DOUBLE WORD ExceptionStatusExt NamesArray A02 Y RO ARRAY of TEXT STRING Each element refers to SaiIn01** DataTypeArray A03 Y RO ARRAY of USINT Each element refers to SaiInA66** EnableReportRate A05 N RW BOOLEAN Activation of a data report ReportInhibitTimer A04 N RO INT Minimum report rate [ms] ReportRate A06 N RW INT Report rate [ms] #1 * The structure of the Data Attribute is described in Table 5. #2 ** In is used to indicate the instance number of the object; n is a non-negative integer, see E54.1. Page 4 D5274AINFO SEMI

7 Data is a structure which has four items, 1. Data time Stamp, 2. The Length of the Array containing the measured values, 3. The array which contains the values of the SAI, 4. Error Status Extended Data Structure Items DataTimeStamp is time of data origin and refers to the Date and Time Attribut of the DM. It is represented by two double words (8 bytes). The form is the Date and Time structure defined in SEMI E54.1. This document limits the applicable Date and Time Types, defined in SEMI E54.1, to those which have maximum length of 8 bytes. If DataTimeStamp is not supported, the default value zero (8 bytes) shall be used instead Length is the number of elements which the DataArray contains. It is of the form unsigned double integer as described in SEMI E54.1. NOTE 2: Length is equal to the number of instances of the SAI DataArray is represented by an array of double words data. Each subsequent element of this array relates to an instance of the SaiA16 (attribute value ), where the number of the instance is related to the number of the element of the array, i.e the n-th element represents the data value of the n-th instance of the SAI. The form of an element is defined by the related element of the DataTypeArray ExceptionStatusExt a double word which contains the status of alarms and warnings of the device as described in SEMI E54.1. The byte following the last element of the DataArray is the 1.Byte as indicated in Table 4. The 4.Byte is the Exception Status. The form of the Exception Status is formatted byte, see SEMI E54.1. Table 4 Position of Exception Status in the Double Word 1. Byte 2.Byte 3.Byte 4.Byte Reserved Reserved Reserved Exception Status NamesArray is array of text string. Each element of the array relates to the attribute Name of an instance of SAI (SaiA01) with the same order, i.e. the first element is linked to the first instance of SAI DataTypeArray array of integer where each integer represents a data type according to SEMI E54.1 Each element of the array relates to the attribute DataType (SaiA66) of an instance of SAI with the same order, i.e. the first element is linked to the first instance of SAI ReportInhibitTimre (optional) an attribute defined in SEMI E54.1. It is used to identify the absolute minimal time interval for reporting the attribute Data of the ASM EnableReportRate (optional) is an attribute defined in SEMI E54.1. It is used to enable the publishing of the attribute DataArray of the ASM based on the ReportRate attribute value; a value of TRUE signifies that the reporting at the ReportRate is enabled ReportRate (optional) is an attribute defined as in SEMI E54.1. It is used to set the time interval between two subsequent reports in which the attribute Data of the ASM will be reported. NOTE 3: The Data attribute only will be reported, because only this attribute shall be contained in the data report of ASM. The report is performed by the Publish Attribute Service of the SAC (refer to SEMI E54.1) were the ASM is embedded in. Page 5 D5274AINFO SEMI

8 Table 5 Structure of the Data Attribute of ASM Number of structure item Structure item Reference to CDM Tag Form Descripton 1 DataTimeStamp DmA22 refers to SEMI E54.1 Time of data origin 2 Length - UDINT 3 DataArray - ARRAY of DOUBLE WORD Value of 1. Instance of SAI SaiI1A16 1. Element of DataTypeArray* 1. Element of NamesArray** Value of n. Instance of SAI SaiInA16*** n. Element of DataTypeArray* n. Element of NamesArray 4 ExceptionStatusExt DmA12 UDINT Exception Status of the ADDON #1 * The form of an element of the DataArray is specified by the associated element of the DataTypArray, i.e. the element with the same index. #2 ** The descriptor of an element of the DataArray is specified by the associated element of the NamesArray, i.e. the element with the same index. #3 *** In is used to indicate the instance number of the object; n is a non-negative integer, see SEMI E Sensor Analogue Input Object SAI The SAI represents the measured values of the ADDON. It inherits attributes, services, and behavior from the Analog Input Object of the CDM. Each data value delivered by the sensor is characterized by a corresponding instance of SAI Sensor Analogue Input Object Attributes Attributes specified are listed in Table DataType The DataType Attribute of an instance of the SAI has the form USINT according to SEMI E54.1-Section 5. The DataType Attribute is mandatory for an add-on sensor. Table 6 Sensor Analogue Input Attributes Attribute Name Attribute Identifier DataType SaiA66 Y RW USINT Rqmt Access Form 5.6 Context Object CXT (optional) The CXT is optional and contains the context data of the process and the substrate which the ADDON monitors. CXT inherits attributes, services, and behavior from the Substrate Object according to SEMI E90 and adds the attributes RecipeID and Recipe Step. The ADDON may have the possibility to use alternative algorithms of measurement depending on attributes of CXT. Process start and stop can be indicated by setting the attribute Process State Context Object Attributes Substrate ID (optional) identifier of the processed material, e.g., wafer according to SEMI E Lot ID (optional) identifier of a group of one or more substrates of the same type. The group may be referred to for tracking of substrates in the factory according to SEMI E Substrate Location ID (optional) identifier of the location of the processed substrate the add-on sensor relates to, e.g., chamber identifier according to SEMI E Substrate Process State (optional) indicates if the process has started or finished according to SEMI E Recipe ID identifier of the recent process recipe Recipe Step (optional) recent recipe step number. Page 6 D5274AINFO SEMI

9 Table 7 Context Object Attributes Name Attribute Identifier Rqmt Access Form Substrate ID CxtA01 N RW Refer to Substrate Object SEMI E90 Lot ID CxtA02 N RW Refer to Substrate Object SEMI E90* Substrate Location ID CxtA03 N RW Refer to Substrate Object SEMI E90 Substrate Process State CxtA04 N RW Refer to Substrate Object SEMI E90 Recipe ID CxtA05 Y RW STRING Recipe Step CxtA06 N RW INT #1 * A list of Lot ID is specified as well, see SEMI E 90. Table 8 Context Object Services Service Service Identifier Support required in Device Type Description of Service GET CxtS04 Required R Return the contents of the specified attribute. SET CxtS05 Required R Write the contents of the specified attribute. < End of Change Proposals > The rest of this Document is material that is required for inclusion in a ballot by the SEMI Standards Procedure Guide ( ), but it does not contain any proposed Document changes. Page 7 D5274AINFO SEMI

10 SEMI E SENSOR/ACTUATOR NETWORK STANDARD This Standard was technically approved by the Information & Control Global Technical Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on March 14, Available at and in April 2013; originally published in 1997; previously published July NOTICE: The designation of SEMI E54 was updated during the 0413 publishing cycle to reflect the reapproval of SEMI E54.1. NOTICE: The Standard that was previously designated as SEMI E54 (Standard for Sensor/Actuator Network Common Device Model) has been re-designated as SEMI E54.1. Because the Sensor/Actuator Network Standard is the parent document, it has been designated as SEMI E54. 1 Purpose 1.1 This Specification provides the structure of SEMIs Sensor/Actuator Network (SAN) standard. It provides the definition for interoperability with respect to SEMI SAN standard-compliant Sensor/Actuator devices. 2 Scope 2.1 This Standard specifies how devices interoperate on a network as part of the control system for equipment. 2.2 This Specification, which is the root of the SAN standard, defines the relationships of each of the other specifications that are components of the SEMI SAN standard. 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 Referenced Standards and Documents 3.1 SEMI Standards and Safety Guidelines SEMI E30 Generic Model for Communications and Control of SEMI Equipment (GEM) SEMI E39 Object Services Standard: Concepts, Behavior, and Services SEMI E54.1 Standard for Sensor/Actuator Network Common Device Model 3.2 ISO Standard 1 ISO 7498 Basic Reference Model for Open Systems Interconnection (OSI) 3.3 Other Documents James Rumbaugh, Michael Blaha, William Premerlani, Frederic Eddy, William Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, New Jersey: Prentice-Hall, NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. 4 Terminology 4.1 Abbreviations and Acronyms API Applications Programming Interface CDM Common Device Model. The root object application model for devices on the sensor bus DM DeviceManager. An object specified in SEMI E54.1, Standard for Sensor/Actuator Network Common Device Model. 1 International Organization for Standardization, ISO Central Secretariat, 1 rue de Varembé, Case postale 56, CH-1211 Geneva 20, Switzerland; Telephone: , Fax: , Page 8 D5274AINFO SEMI

11 4.1.4 IDL Interface Definition Language. A programming language-independent notation for specifying interfaces ISO International Organization for Standardization NCS Network Communication Standard. Provides the specification for mapping the CDM and SDM to specific network technologies. These standards will be incorporated as parts of the SEMI SAN standard OEM Original Equipment Manufacturer. They are usually the control system developer, but in any case they are almost always responsible for the control system OMT Object Modeling Technique. A methodology developed by James Rumbaugh, et al., for using objects to model systems OSI Open System Interconnection. A seven-layer model for communications developed by ISO OSS Object Services Standard [SEMI E39] SAN Sensor/Actuator Network. It is frequently used to reference this Standard SDM Specific Device Model. This is an application model for a specific type of sensor, actuator, or entity. 4.2 Definitions application for software, this is a working series of computer instructions that provide end user services applications model a formal description of the software elements and interactions that perform an end user task entity in software engineering, this is something that is recognizable as distinct and particular from the other things that make up a software system or program interface in information modeling, it is the boundary between two entities from which information will flow user layer in communications, this is a set software function connected to the communication protocol s top layer, usually called the applications layer, from the user s application environment. It typically allows the user application to be protocol-independent. 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. Page 9 D5274AINFO SEMI