Background Statement for SEMI Draft Document 5716

Transcription

1 Background Statement for Draft Document 5716 Revision to E133, SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE and E133.1, PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEMS (PCS) 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 ballot. NOTICE: For each Reject Vote, the Voter shall provide text or other supportive material indicating the reason(s) for disapproval (i.e., Negative[s]), referenced to the applicable section(s) and/or paragraph(s), to accompany the vote. NOTICE: Recipients of this ballot 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 been 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. NOTICE: Additions are indicated by underline and deletions are indicated by strikethrough. PLEASE NOTE: This ballot contains a proposal for a revision to an existing standard. Purpose Adjustments are needed to existing E133 and E133.1 standards content to better align with the XML style guidelines document [ E (reapproved 1111): Guide for Style and Usage of XML for Semiconductor Manufacturing Applications]. Technical changes are needed to clarify the implementation of the PCS analysis engine. E133.1 still contains the term Provisional that is no longer used in Standards. Background E133 Specification for Automated Process Control Systems Interface Standard includes a dot standard, E133.1, which is a provisional specification for the implementation of the E133 standard utilizing XML. In reviewing these specifications issues of alignment with the XML specification were identified. An update to the standard is needed to address these issues and improve the overall XML and associated UML for improved alignment and usability. Impact This ballot will only impact the standards E133 and E This ballot will be a major revision to E133 and E Proposal This ballot proposes changes to E133 and E The ballot includes a Complementary File: the XML Schema file. This ballot will propose the following changes: E133: Changes to E133 to improve alignment with the aforementioned XML guidelines document, and maintain alignment between E133 and E133.1.

2 E133.1: Enhancements to XML specification. Adjustments will be made to existing E133 and E133.1 standards content to better align with the XML guidelines document, as necessary. Technical changes will be made to clarify the implementation of the PCS analysis engine type. E133.1: Changes to the schema and addition of Complementary file, the XML Schema file: E133-1-Vmmyy- PCSAE-Schema.xsd E133.1: Removal of Provisional. E133 and E133.1: Changes to clarify the implementation of the PCS analysis engine and improve usability. Editorial staff will provide at minimum the following editorial support of these documents: The editorial staff shall correct occurrences of mmyy in the document and in the Complementary file as listed below with the standard numerical designation (Esss) and publication date (mm month, yy year) of the specification. For example, if the publication date is August 2016, the mmyy becomes This includes the following: o o o o Update all occurrences of E133-1-Vmmyy-PCSAE-Schema.xsd Update the name of the Complementary File Esss-mmyy-SECSIIMessageNotation-Schema.xsd Insert the standard designation in the Related Information Notice. Update all references to Esss, such as in the Appendix. A summary of some of the more significant changes being proposed is provided in the remainder of this background section. This is followed by the ballot. Background Discussion On a Portion of the Proposed Changes NOTE: This section of the document is not part of the ballot. It is part of the ballot background section. Introduction The Analysis Engine data structure model for a complete message associated with a PCS job provided in E133 has been modified to address a number of issues of clarity and alignment as mentioned above. The following is the new data structure model. The discussion section that follows provides insight into some of the issues that are addressed with this modification.

3 Discussion AE Data Structure Model for a Complete Message Associated with a PCS Job ISSUE: Multiple similar elements in AnalysisEngineDataSet Currently AnalysisEngineDataSet defines Globals, AnalysisParameters, CalculatedOutputs, LogMessages, ModuleData, ProcessData, and SubstrateData all effectively have the same structure of a class with two members of DataItemType (Context and Data) Challenge Does not follow XML TF standards Create multiple duplicate classes where the only item that is different is the class name Forces implementations to branch on the existence of a member as opposed to the data of a member Solution (Changes to E133 and E133.1) Create a standard DataCollectionType that has 3 elements Context and Data of type DataItemType BinCategory as an enumerated list indicating the type of data ISSUE: Status Element Ambiguity Currently Status is member of AnalysisEngineDataSet This provides an overall status for the AnalysisEngineDataSet Challenge The AnalysisEngineDataSet contains a list of PCSAETargets

4 Each PCSAETargets could succeed or fail and need to convey information to the caller In the case of more than one target the way to convey multiple status messages is ambiguous Solution Move the status message to the PCSAETarget class This way each function that processes data has its own unique status ISSUE: PCSAETargets Ordering Currently PCSAETargets is an ordered list of PCSAETarget Challenge The order in which the PCSAETarget in PCSAETargets should be invoked is ambiguous Left to right, right to left Order may not be preserved throughout calling chain Should a PCSAETarget be moved to the end once executed Solution Create an AEOrder element to PCSAETargetType to indicate what order the PCSAETarget should execute This also allows the PCSAETarget determine if the prior PCSAETarget has completed by checking its Status object ISSUE: PCSAETargetType Multiple Algorithm Support Currently PCSAETargetType contains AEType which specifies which type of algorithm is being invoked PCS, R2R, FDD, FCC, FPP, or SPC Challenge PCSAETargetType does not support different algorithms within a AEType Therefore a PCSAE service can only have one type of each type of algorithm Ex. an implementation would need a separate service for each WECO rule Solution Add an AEAlgorithm element to PCSAETargetType to allow selection of different algorithms within a specified PCSAETargetType ISSUE: PCSAETargetType Parameter Support Currently PCSAETargetType contains Extension which is a freeform data element Challenge Extension as a freeform data element is difficult to programmatically predict and support The service code needs to handle all possible instantiations of Extension Solution Convert Extension to a DataItemType to give it the common Name/Value structure

5 ISSUE: PCSAETargetType Multiple Instruction Support Currently PCSAETargetType contains a list of actions to perform, Instructions Challenge This is only a list of actions with no context or parameters to act on and no defined order of execution Ex. running the same algorithm 3 times with different sets of parameter/limits would be difficult to specify Solution Create a InstructionType class with members Instruction, Order, Extension and Status Convert Instructions to 1-n of InstructionType Note it is up to the implementation of PCSAETargetType to consolidate the individual InstructionType statuses ISSUE: StatusElementType Output Parameter Support Currently StatusElementType contains Extension which is a freeform data element Challenge Extension as a freeform data element is difficult to programmatically predict and support The service and client code need to handle all possible instantiations of Extension Solution Convert Extension to a DataItemType to give it the common Name/Value structure

6 The ballot begins on the next page and includes an attached.xsd file The ballot results will be reviewed and adjudicated at the meetings indicated in the table below. Check under Standards Calendar for the latest update. Review and Adjudication Information Task Force Review Committee Adjudication Group: PCS Task Force Information and Control NA TC Chapter Date: July 10, 2017 July 12, 2017 Time & Time zone: 15:00 17:00 Pacific Time 8:00 14:00 Pacific Time Location: Marriott Marquis Hotel Marriott Marquis Hotel City, San Francisco, CA/USA San Francisco, CA/USA State/Country: Leader(s): James Moyne (University of Michigan) Chris Maloney (Intel) Brian Rubow (Cimetrix) Jack Ghiselli (Ghiselli Consulting) James Moyne (University of Standards Staff: Inna Skvortsova () Michigan) Inna Skvortsova () This meeting s details are subject to change, and additional review sessions may be scheduled if necessary. Contact the task force leaders or 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.

7 Draft Document 5716 Revision to E133, SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE and E133.1, PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEMS (PCS) E SPECIFICATION FOR AUTOMATED PROCESS CONTROL SYSTEMS INTERFACE 1 Purpose 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 May 12, Available at and in October 2014; originally published March 2004; previously published February In order to more efficiently facilitate the integration of process control systems (PCS) such as run-to-run (R2R) control, fault detection (FD), fault classification (FC), fault prediction (FP), statistical process control (SPC), etc. into current and future fabs, there is a need to define interfaces for PCS that enable them to interact effectively and share data (1) among themselves and (2) with the other interdependent factory systems (including equipment data collection). This Standard is intended for use by equipment suppliers, semiconductor manufacturers, equipment subsystem suppliers and control system suppliers who will utilize the PCS standards in future developed products. 2 Scope 2.1 This Standard focuses on defining PCS capabilities, functional groups (FGs), and FG interfaces. The Standard is structured so that new FGs can be added to the Standard through future balloting. The components in this document include: Definitions of key terms and concepts pertinent to this domain, Description of the specification conventions used, Identification of the major FGs within the scope of PCS, Description of the capabilities expected in each FG (required and optional), and Definition of interfaces for these FGs, including: Data that is available across these interfaces. This includes the interface data descriptions (inputs and outputs). Future enhancements to this Specification will include detailed data structures in the form of inheritance and aggregation models that are common to all PCS FGs, as well as specific models for each, Services supported and Interface behavior assumed, and Description of an approach for compliance verification testing. 2.2 The specific format and protocol implementation of these interface specifications, which are technology specific, will be delineated in supporting dot specifications to this Standard. As an example a possible format is extensible markup language (XML) (which would include data type definitions and metamodel schemas). 2.3 In addition to the information embodied in this Standard, the Standard describes a validation process to identify and address real implementation issues as early as possible. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 1 Doc. 5716

8 NOTICE: 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 The proposed PCS standards will not focus on: Low-level communication mechanisms (e.g., hardware connection schemes, transport layer software, etc.) between PCS FGs, Methodology for implementing actual equipment or factory level control strategies, Specifying internal structure or implementation methods of PCS FGs, Capabilities of complementary applications (recipe management, data collection, engineering analysis, data storage, scheduling, change control, ), The management of information and collaboration between FGs. This is left to implementation, Communications within equipment or within factory systems, Determination of the proper control algorithm, model, or runtime selectable behavior. It is optional for a PCS function to contain context matching (CM), The creation and management of PCS jobs, or Defining test procedures required for validating the Standard. 4 Referenced Standards and Documents 4.1 Standards and Safety Guidelines E81 Provisional Specification for CIM Framework Domain Architecture E121 Guide for Style and Usage of XML for Semiconductor Manufacturing Applications E125 Specification for Equipment Self -Description (ESDEQSD) E134 Specification for Data Collection Management E148 Specification for Time Synchronization and Definition of the TS-Clock Object 4.2 IEC Standards 1 IEC Digital Data Communications for Measurement and Control Fieldbus for Use in Industrial Control Systems Part 5: Application Layer Service Definition 4.3 ISO Standards 2 ISO 8601 Data Elements and Interchange Formats Information Interchange Representation of Dates and Times 4.4 Other Documents SEMATECH Equipment Engineering Capabilities (EEC) Guidelines (Phase 2.0), Version 2.5 (July 2002) 3 Rumbaugh, James, Jacobson, Ivar, and Booch, Grady The Unified Modeling Language Reference Manual. Addison Wesley Professional, Booch, Grady, Rumbaugh, James, and Jacobson, Ivar The Unified Modeling Language User Guide. Addison Wesley Professional, International Electrotechnical Commission, 3 rue de Varembé, Case Postale 131, CH-1211 Geneva 20, Switzerland; Telephone: , Fax: , 2 International Organization for Standardization, ISO Central Secretariat, 1, ch. de la Voie-Creuse, CP 56, CH-1211 Geneva 20, Switzerland; Telephone: , Fax: , 3 SEMATECH, 257 Fuller Road, Suite 2200, Albany, NY 12203, USA; Telephone: , This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 2 Doc. 5716

9 Rumbaugh, James, et al. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ (1991). NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. 5 Terminology 5.1 Abbreviations and Acronyms AE analysis engine APC advanced process control CM context matching FC fault classification FD fault detection FDC fault detection and classification FG functional group FP fault prediction (or prognosis) PCS process control system PCS job process control system job R2R run-to-run SPC statistical process control W2W wafer-to-wafer XML extensible markup language 5.2 Definitions advanced process control (APC) 4 the manufacturing discipline for applying control strategies and/or employing analysis and computation mechanisms to recommend optimized machine settings and detect faults and determine their cause analysis engine (AE) a process that utilizes data and possibly operational instructions to produce a response. In the context of this Standard, this term is used to encompass the characteristics common to all PCS functional groups context a series of attributes that uniquely identifies a manufacturing entity (e.g., wafer, lot, module, tool, reticle) and its status in the manufacturing operation context matching (CM) the process of comparing and matching the values of a set of attributes that represent the state of a system (e.g., process, product and equipment) to a set of stored or computed values. This is usually done so that a unique action can be specified by the CM system fault classification (FC) the technique of determining the cause of a fault once it has been detected fault detection (FD) the technique of monitoring and analyzing variations in tool and/or process data to detect anomalies. FD includes both univariate and multivariate statistical analysis techniques fault detection and classification (FDC) combination of FD and FC fault prediction (or prognosis) (FP) the technique of monitoring and analyzing variations in process data to predict anomalies functional group (FG) a collection of closely related software capabilities that one would expect to be provided as an integrated product. 4 APC and PCS terms are used interchangeably in some companies. Both can be seen as the umbrella of components for process control. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 3 Doc. 5716

10 process control system (PCS) 3 a system capable of performing process control, which includes one or more of R2R control, FD, FC, FP, SPC, or any future process control functionality defined in this Standard for a PCS functional group process control system job (PCS job) a unit of work that could be tracked and have data associated with it. In the context of this Standard a PCS job is associated with a unit of work that a PCS AE performs; a unique identifier such as an ID number is often utilized to track the PCS job run-to-run (R2R) control the technique of modifying recipe parameters or the selection of control parameters between runs to improve processing performance. A run can be a batch, lot, or an individual wafer statistical process control (SPC) the technique of using statistical methods to analyze process or product metrics to take appropriate actions to achieve and maintain a state of statistical control and continuously improve the process capability wafer-to-wafer (W2W) control a form of R2R control in which a run is the processing of a single wafer. This is differentiated from wafer level control in which the recipe may be determined for multiple individual wafers before processing begins, but not necessarily modified from wafer to wafer; for example, between wafers. 6 Background 6.1 With the development of PCS applications at the factory level and inside the equipment, it is now apparent that the lack of interface standards for these applications has inhibited widespread adoption of process control at the factory level. Moreover, adding process control and integrated metrology capabilities inside the tool requires the ability for the factory level applications to collaborate with tool level applications. 7 Conventions 7.1 This section defines conventions followed in this Document. 7.2 Object Modeling Unified Modeling Language (UML) This Specification uses UML notation for all class diagrams and for object diagrams provided as examples. No other types of diagrams are used in this Specification UML class diagrams have clearly defined meanings and are a part of this Specification. Detail contained in these diagrams is not always repeated in the text Class Diagrams UML Class Charts Name of a Class The text capitalizes the beginning of class names Abstract and Concrete Classes Each class is specified as Abstract or Concrete. Abstract classes are not directly implemented. In this Specification implemented means represented to the factory through the communications interface. All classes defined as concrete may be directly implemented. This Specification does not attempt to define equipment control system implementation. In UML class diagrams, abstract class names are shown in italics Class Attribute Definition The attributes of a class are defined in table format as illustrated in the table below. Note that the + sign in front of attributes in UML class diagrams indicates public attributes. All attributes defined in this Specification are public. Table 1 Attribute Table Format Attribute Name Definition Access Reqd Form RO, RW, or NA Y, N or NC See list below Access Attributes may be settable (ReadWrite or RW) or not settable (ReadOnly or RO) through the interface services. If the attribute refers to a component of a message (e.g., that is communicated to/from a PCS analysis engine [AE]), the concept of access does not apply or is not specified in this standard and Not Applicable (NA) is used in the Access field. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 4 Doc. 5716

11 Reqd Is this attribute required? Y Yes, or N No, or C Conditional. If the attribute is conditional, terms of conditionality are specified Form Defines the data type of the attribute. Data types specified in the PCS specification are described in the subsections that follow. Data types in this Specification are high-level definitions and should be mapped to the data types of a specific technology as appropriate. Extensions to the PCS interface specifications are not limited to the list of data types defined in this Specification. See the definition of form in the International Standards Compilation of Terms for other form values commonly used in Documents Constraints Constraints in UML are shown with dotted lines, typically with a note attached to explain the constraint. Constraints shown in this way tend to clutter large UML diagrams. Therefore, in this Specification, constraints are shown only on the diagrams focusing on individual classes UML Associations The mechanism used for representing associations in UML between classes is implementation dependent. This Document is abstract in nature, and does not specify or imply any such mechanism. Any adjunct standard that provides an implementation of this Specification must include a description of the mechanism used for representing UML associations used in this Document Class Association Table This table provides an example of the tables used to list and describe associations between classes defined in this Specification. Table 2 Association Table Format Association Role Name Role Definition Comments Association Role Name The name of the association role being defined Role Definition Describes the function or purpose of the association Comments Any additional comments or notes regarding the association. 7.3 Data Types The following data types at minimum may be used in this Specification to describe the form of an attribute or other similar high level definitions. Note that extensions to the PCS interface specifications are not limited to the list of data types defined in this Specification. Any The format may be any of the others listed in this section. Format is determined by the implementation. Binary A sequence of bytes that may have any value. Binary values are sometimes called unformatted because their structure is not apparent. Boolean Takes the value of true or false. Checksum A checksum value calculated on a specific stream of data using a specific method of calculation. Enumeration A format that allows a specified list of possible values. In this Document, these values are represented as text strings, but may be implemented differently (e.g., as integers that correspond to the named values). Sequence An ordered set of related elements that are usually of the same type. Status The Status type is a structure that contains information about whether or not an error that has occurred in a transmission and information on the type of error. The form of the structure is given in 9. String An ordered sequence of characters. Limitations on length are left to the implementation technology unless otherwise specified in this Document. Strings are recommended to be implemented as UTF-8. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 5 Doc. 5716

12 Integer(int) A numeric value, Integers are always whole numbers. The form and number of bytes is left to the implementation definition. List of xxx An item that can hold multiple instances of a specified type (where xxx is the data type). Real A numeric value that may represent any whole or fractional number. The form and number of bytes is left to the implementation definition. Text A text string.text A string. Limitations on length are left to the implementation technology unless otherwise specified in this Document. Strings are recommended to be implemented as UTF-8. Time Refer to E148. Time Representation of the date and time of the occurrence of interest. The structure and form of items of this type is left to the implementation. 7.4 Service Message Representation Service Resource Definition The service resource definition table defines the specific set of messages for a given service group as shown in the following table Table 3: Table 3 Service Resource Definitions Table Format Service Reqd Type Description Service name Y/N N or R The intent of the service Reqd can be Yes (Y) or No (N). Type can be either Notification (N) or Request (R). A notification service consists of messages initiated by the service provider. No response is expected. A request service consists of a request message initiated by the service user which generally asks for data or for an operation to be performed, and a related response message returned by the service provider Service Parameter Definition The service parameter definition table defines parameter detail for each service in which parameters are explicitly specified, as shown in the following table Table 4: Table 4 Service Parameter Definitions Table Format Parameter Request Response Form Description Service parameter name (see below) (see below) Data type The intent of the parameter The Request and Response entries can take on the following values: M C Mandatory Parameter Must be given a valid value. Conditional Parameter May be defined in some circumstances and undefined in others. Whether a value is given may be completely optional or may depend on the value of the other parameter. - The parameter is not used. = The entries M and C in the response can be modified with (=) to indicate that the value in the response must match the request. 7.5 Behavior Representation General Behavior Narrative is used to describe behavior that could include sequence and state behavior. Other mechanisms such as flow diagrams may be used to describe message sequences. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 6 Doc. 5716

13 Sequence Behavior Where appropriate, this document uses themay also use Harel State Chart notation to describe the dynamic behavior of the AEs. An overview of this notation is presented in an Appendix of E30. The formal definition of this notation is presented in Science of Computer Programming 8, Statecharts: A Visual Formalism for Complex Systems, by D. Harel, State Behavior Where appropriate, transition tables aremay also be provided in conjunction with the state diagrams to explicitly describe the nature of each state transition. Each transition table contains columns for transition #, Previous State, Trigger, New State, Actions, and Comments. The trigger for the action occurs while in the Previous State. The Actions include a combination of: (1) actions taken upon exit of the Previous State, (2) Actions taken upon entry to the New State, and (3) actions taken which are most closely associated with the transition. No differentiation is made. 8 Overview 8.1 Using the simple definition of a FG given in the terminology section, the initial set of PCS FGs has been identified. To identify the proper scope (and therefore the boundaries) for these groups, the following criteria are applied to test whether or not a given set of capabilities constitutes a valid PCS FG. Specifically, a FG should satisfy one or more of the following requirements: Support a coherent set of tasks Share common set of data and must use it under similar constraints (performance, retention, etc.) Internal objects are tightly coupled Legacy implementation/integration constraints exist (e.g., the capabilities are inseparable because an external system must interact with them as an integrated whole) Strong associations exist in the market (i.e., one would expect these capabilities to be provided as an integrated product) 8.2 Based on these criteria, and the stated implementation priorities of the semiconductor manufacturers and suppliers involved on the task force, the following initial PCS FGs have been identified: R2R control FD FC FP SPC 8.3 R2R control includes W2W control. In this case a run is the processing of a single wafer. 8.4 Note that it is understood that other PCS FGs can be added as needed. Future versions of the document will describe procedures for adding a new group. 8.5 The aforementioned groups can be implemented at the tool or factory level or both. As a requirement, FG interfaces should be defined in a consistent way. Figure 1 represents the proposed FGs and an example of their interactions within the factory and tool environments PCSs may consist of a variety of capabilities or functions at both the factory and equipment level as shown in Figure 1. Moreover, this may include multiple instances of the same function type from different suppliers. In the example presented in Figure 1, several R2R controllers are running at the factory level with differences that are only visible as internal capabilities; these factory-level controllers could be providing R2R control at a lot-to-lot level of granularity, while the equipment level R2R controller could be providing W2W control, though any R2R control capability including W2W control can be provided inside or outside of the equipment as shown in Figure 1. This interface standard will facilitate easier collaboration between the tool level functions and factory level systems independent of the supplier that developed the internal function s capabilities. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 7 Doc. 5716

14 PCS Functions in the Factory R2R R2R FD FC FP SPC... Factory Specific Manufacturing Execution Systems - Recipe Management - Dispatch - Automated Material Handling - E-Diagnostics -... PCS PCS Functions in the in the Equipment R2R R2R FD FD FC FC FP FP SPC SPC Equipment Equipment Specific Specific Tool Tool Control Control System System - Process - Process Modules Modules - Integrated - Integrated Metrology Metrology - Sensors - Sensors - User - User Interface Interface - E-Diagnostics Figure 1 PCS Functions 9 PCS FG Capabilities and Interface Data Structures 9.1 FG Partitioning PCS are partitioned into FGs using the criteria defined in 8. This Standard defines the interface data structures, services and behavior associated with these FGs. In this section the capabilities of the PCS FGs are defined in more detail. First of all, the basic capabilities common to all FGs are presented. Then the additional basic capabilities unique to each FG are presented. A high level description of the specifications of data structures, services and behavior is provided in this section It is important to note that the specific implementations of these various FGs may differ greatly in the level of capability delivered, performance, quality of service, and internal architecture. Moreover, in a given factory, there may be multiple instances of the same FG running concurrently, from one or more suppliers. Some FGs may be completely independent of other PCS FGs (in other words, they can operate in relative isolation, depending only on information from systems external to PCS); others may depend heavily on other FGs, collaborating closely to provide a higher level of capability than they could on their own The goal of the PCS Interface Standards is to enable all of these implementation scenarios (and more) without dictating internal product architectures. 9.2 PCS AE As defined in 8, all FGs can be thought of as specializations of a PCS AE and therefore inherit the structure and behavior of a PCS AE. This section defines the common capabilities of a PCS AE General Capability Description All PCS AEs shall have inputs and outputs as shown in Figure 2. This means that the PCS AEs shall support the consumption of the specified inputs and production of the specified outputs as necessary to achieve the required capabilities of that analysis engine as specified in this Standard. These inputs and outputs are specified as aggregate data structures. The structures are aggregated into collection types according to the category of data. A definition of these collection types is provided in Table 4. The PCS AE shall have the general behavior of utilizing specified inputs, performing tasks based to some degree on these inputs, and generating outputs. Any additional structure and behavior of various PCS AEs are specified in the reminder of this section Note that, in addition to limitations of specification defined in 4, the following are beyond the scope of definition of the PCS AE: The level of synchronization of inputs with performance of tasks and/or generation of outputs, and The specification of any internal states of the PCS AE. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 8 Doc. 5716

15 All PCS AEs belonging to this FG shall have the capabilities listed in Table 5. Figure 2 PCS AE Common Input/Output Structure Note that based on the simple data model shown in Figure 2, Inputs are available as an Output from an AE. Data provided as input to an AE should be accessible as output from the AE for historical purposes A part of the specification of this standard is the designation of the access level to attributes and structures within the overall common I/O structure. This is defined in section with the terminology defined in section If access is specified as RW then it is RW if it is part of an AE Common Input Structure and RO if it is part of an AE Common Output Structure. If it is specified as RO then it is RO regardless of whether it is an Input or Output structure. If it is specified as NA then access level specification is beyond the scope of this standard. Note that if access is specified as NA then it is usually RO if it is part of an AE Common Output Structure. Table 3Table 5 PCS AE Inputs and Outputs Collection Type Definitions Collection Type Definition Comments Globals Information that applies globally across an entire job. A lot id, for example, could be specified once as a global so that it would not have to be specified with many other data sets. AnalysisParameters Information that identifies numeric data used by the AE to perform various calculations. Equation coefficients, feedforward data, etc. CalculatedOutputs Data representing the results of analysis from an AE. A calculation derived from various inputs to the AE indicating wafer state, process state or model state information, recommended machine settings, etc. LogMessages Data describing the activity of an AE as it executes its tasks. Data describing the activities of the AE. Note that this does not include log information on the communication protocol with the AE. An example that is acceptable is Algorithm #3 with model parameters A, B, and C. ModuleData ProcessData Information representing the current or last known physical state of a process module that will be used by an AE to process material. Information representing the process itself, such as the name and type of the process and the current or last known process state based on measurements from sensors of the processing environment. Machine, or module E10 state, RF hours, number of wafers processed, etc. Name of the process (CMP), in situ process measurements, trace data, and summary statistics etc. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 9 Doc. 5716

16 SubstrateData Collection Type Definition Comments Information about the substrate being associated with the AE. This could include data representing a single wafer, multiple wafers, or one or more lots, as well as attributes of the material. Table 4Table 6 PCS AE FG Capabilities Profile or topology data, and other characteristics measured physically or electrically. # Description Reqd Comments 3.1 Provide a PCS AE capability PCS AE shall be capable of performing one or more of R2R control, FD, FC, FP, SPC, or any future functionality defined in this Standard as a PCS FG. 3.2 Provide the required PCS AE methods The PCS AE shall provide the required interface services as defined in this Standard. 3.3 Maintain models of selected PCS environment The PCS AE shall maintain explicit or implicit models of the selected process control environment. These models shall be utilized to provide the analysis or control capability of the Analysis Engine. 3.4 Provide a mechanism to uniquely instruct the AE to perform an action The PCS AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action. 3.5 Interface with multiple external systems The PCS AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. 3.6 Edit configuration of models The PCS AE shall provide the capability to create/add, edit configuration, and delete models. 3.7 Interface with other AEs The PCS AE shall be capable of either accepting outputs from other AEes as inputs, or producing outputs that are utilized by other AEs. 3.8 Advanced model management The PCS AE may provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y Y Y Y N N These include PCSAnalyze and PCS UpdateModel. The specific form and behavior of these models is beyond the scope of this Standard. The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a PCS result, update of a model, or communication of model parameters. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the Analysis Engine interface. May be a requirement of AEs belonging to a specific FG Common Interface Data Structures Common Data Model Overview The common interface data structures from which all PCS FGs may inherit are shown in Figure 3. This figure shows the basic types of information ( classes in object terminology) that can be supported by the interface. This model applies to the structure of inputs as well as outputs of a PCS AE as shown in Figure 2. This model applies to a complete message associated with a PCS job. That is it applies to the complete set of information communicated to or from a PCS AE for a PCS job. Note that a complete message into or out of a PCS AE may be broken into multiple application-to-application communications as defined in This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 10 Doc. 5716

17 At least one of Data or Context AnalysisEngineDataSet PCSJobID: text DataCollections 0..* DataCollection BinCategory: Enumeration PCSAETargets {ordered} 0.. Status 0..* PCSAETarget AEType: Enumeration AEInstance: Integer Instructions: text Extension: any StatusElement Source: text Code: Integer Description: text Extension: any Data 0..* 0..* DataItem Context Name: text Value: any Figure 3 AE Data Structure Model for a Complete Message Associated with a PCS Job This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 11 Doc. 5716

18 Class Definitions Class definitions consist of a brief description of each class, a table defining anydescription of its attributes belonging to that classand structures, and further text as necessary to fully define the class AnalysisEngineDataSetAnalysisEngineDataSetType A composite data structure that represents the data associated with a single input or output message of an AE. Table 5Table 7 Attributes of AnalysisEngineDataSetAnalysisEngineDataSetType Attribute Name Description Access Reqd Form PCSJobID A unique identifier of a PCS job. NARO C ObjID Reference E39. PCSAETargets An attributea structure that indicates a list of AE types targeted by the AnalysisEngineDataSet. DataCollections Status An attributea structure formatted as an extensible data structure that relates propertiesconveys the data being passed into or out of the success or failure of a PCS AE, identified in PCSAETargets, to execute a PCS job. NARW Y An ordered list of structured data of type PCSAETargetPCSAE TargetType; see below. NARW CY An unordered list of structured data of type StatusElementDataCol lectiontype; see below PCSJobID The specification that PCSJobID is a requiredconditional attribute of AnalysisEngineDataSetAnalysisEngineDataSetType along with the specification that it is a unique identifier of a PCS job means that a unique PCSJobID shall be associated with each PCS job. The management of the uniqueness of the PCSJobID can be performed by an AE or by an application that wishes to utilize the capabilities of an AE. The application communicating with the AE is assumed to generate and manage PCSJobIDs for all PCS jobs, however the AE is required to provide this functionality in the event that the application does not wish to provide it. The existence of the PCSJobID attribute is conditional upon the following: If the application communicating with the AE is managing a PCSJobID for a PCS job, then that PCSJobID shall be provided as the value of the PCSJobID attribute for all interface data structures of type AnalysisEngineDataSetAnalysisEngineDataSetType associated with that PCS job. If the AE is providing the functionality of generating a PCSJobID for a PCS job, then the PCSJobID shall be provided in the first communication from the AE (to any consuming application) for this job and all subsequent communications associated with this job. The PCSJobID is not required for transactions that do not involve the AE executing a PCS job such as status checks, or pre-processing queries PCSAETargets This attributestructure indicates a list of AE types targeted by the AnalysisEngineDataSetAnalysisEngineDataSetType instance; it is structured as an ordered list of type PCSAETargetPCSAETargetType (see below). At most one PCSAETargets value shall be associated with Each PCSJobID. Thus any two messages received by a PCS AE with the same PCSJobID will have at most one value for PCSAETargets, which could be provided in either or both messages. Each AE that receives this parameter in an input AnalysisEngineDataSetAnalysisEngineDataSetType instance will echo the parameter and its value for all output AnalysisEngineDataSetAnalysisEngineDataSetType messages with that PCSJobID PCSAETarget This attribute classdatacollections This structure represents the data collections that are being passed into and out of the PCS AE Targets. Each DataCollection is a set of data and associated context for that data that conforms to the PCS AE common input/output structure as defined in PCSAETargetType A composite data structure that represents an AE targeted by the current PCS job. The PCSAETarget attribute is used to differentiate PCS AE targets when a single message travels between multiple AEs (often referred to as a daisy chain ). In this case the AEType and AEInstance attributes of the PCSAETargetPCSAETargetType instance (see below) can be utilized to identify a particular consumer for the This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 12 Doc. 5716

19 AnalysisEngineDataSetAnalysisEngineDataSetType data. Note that in many cases, such as point-to-point communications between an AE client and a single AE, the PCSAETarget attribute may not be necessary This attribute has the following form: PCSAETarget AEType AEInstance Instructions Extension Figure 4 AE Data Structure Model Highlighting PCSAETarget Data Structure This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 13 Doc. 5716

20 Table 6 PCSAETarget Attribute Definition Table 8 Attributes of PCSAETargetType Attribute Name Description Access Reqd Form AEType An enumeration that represents the AE type to which the instruction is targeted. AEAlgorithm A string indicating what algorithm name is being invoked NA Y String AEInstance AEOrder Instructions A number indicating the specific instance of an AE within a type that is targeted. An integer indicating the order of execution for this PCSAETarget in the collection of PCSAETargets An A structure that is ordered list of Instructions, where each instruction is of type text. StatusExtension This is the status of the PSCAETarget.. The This attribute allows the supplier to include additional information regarding the targeted AE instance.status attribute exists at two levels. First as an attribute PCSAEInstructionType (see below), indicating the status of the individual instruction, and second as an attribute of PCSAETargetType (here) where it is a summary status of all of the PCSAEInstructionType status attributes. NA NA NY EnumerationString that is an enumeration of AETypeSelector, with possible values being: fault detection (FDD), fault classification (FCC), fault prediction (FPP), run-to-run control (R2R), statistical process control (SPC), process control system (PCS). NY Integer. NA Y Integer NA Y Ordered list of elements of type text.pcsaeinstruction Type (see below). NA NY Any.An ordered list of structured data of StatusElementType; (see below) The specification of how the AEs will consume the information is beyond the scope of this Standard The AEType enumeration of PCS is used to indicate a generic PCS type, or is an unspecified type An AEAlgorithm value indicates the name of the algorithm that is being invoked from a group of algorithm types that are supported by the PCSAE. For example, a R2R PCSAE may have many different kinds of R2R algorithms to select from such as EWMA, or Predictor Corrector. The naming of the algorithms is beyond the scope of this document and is implementation specific An AEInstance value is not specified indicates that the instance of AEType is unspecified When multiple PCSAETarget instance values are specified, the target PCS application to which these values refer should execute the PCS job associated with the PCSJobID in sequence. The mechanism for ensuring this behavior is beyond the scope of this Standard AEOrder specifies the order in which to execute the PCSAETargetType instances. This removes any question as to reordering, or how PCSAETargets that have been executed are dispositioned Instructions A structure that is an ordered list of elements, each of which is an instruction and is of type text.pcsaeinstructiontype (see below). Note that no two elements in the ordered list can have the same value. An instruction is an attribute that relates a specific task that is being requested to be carried out by a targeted AEInstance. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 14 Doc. 5716

21 Status This conditional attribute classstructure relates properties of the success or failure of a PCS AE, identified in PCSAETargets, to execute a PCS job. The attribute hasthe structure form is described below PCSAEInstructionType A composite data structure that represents an Instruction associated with the following form:current PCS job. StatusElement Source Code Description Extension Figure 5 AE Data Structure Model Highlighting Instruction Data Structure This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 15 Doc. 5716

22 Table 9 Attributes of PCSAEInstructionType Attribute Name Description Access Reqd Form Instruction An enumeration that represents the instructions associated with the current PCS job. NA N String that is an enumeration of the available PCS services. This includes, but is not limited to: PCSAnalyze PCSStartJob PCSAddMoreData PCSEndJob PCSJobCompleted PCSAbortJob PCSJobAborted PCSUpdateModel PCSEvent PCSProduceLogData PCSProduceExcpetion Data PCSExceptionProvuce d PCSPing PCSCapabilitiesDisco very PCSEnable FDDFault Order An integer indicating the order of execution for the Instructions NA Y Integer Status Extension This is the status of the execution of the instruction. The Status attribute exists at two levels. First as an attribute of PCSAEInstructionType (here), indicating the status of the individual instruction, and second as an attribute of PCSAETargetType where it is a summary status of all of the PCSAEInstructionType status attributes. This structure allows the supplier to include additional information regarding the instruction. Details of this information are beyond the scope of this standard. NA Y An ordered list of structured data of StatusElementType; see below. NA N An ordered list of structured data of DataItemType; see below StatusElementType A composite data structure that represents the status of the stats of a PCS Job as it relates to a specific PCSAETarget. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 16 Doc. 5716

23 Figure 5Figure 6 AE Data Structure Model Highlighting StatusElement Data Structure Table 7 StatusElement Attribute Definition Table 10 Attributes of StatusElementType Attribute Name Description Access Reqd Form Source Code Description Represents the document from where the attribute code value is defined. For example Source could identify a Standards Document. For status codes defined by Standards, the content of Source is the urn representation of the Standard number. For status codes defined by a supplier, it is the urn representation of the supplier s name. (e.g., for E132 errors, the content of Source is: urn:semi-org:e132; for supplier company errors, for instance, where company name is Acme, the content is: urn:acme-com) additional information may be included by the supplier by adding such information after the : colon symbol and separating the fields with a. period symbol. Please refer to E121 for additional information. A value that directly maps to a particular specification status code list. The source of this list is beyond the specification of this document. A status code of zero indicates that no error has occurred, while any nonzero status indicates an error has occurred. Specific error codes defined for this Standard are provided in Table 814. A human readable description of the corresponding code attribute being reported. It maps directly to the definition of the Code attribute. NA N Text. NA Y Integer. NA N An unordered list of structured data; see below.string. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 17 Doc. 5716

24 Attribute Name Description Access Reqd Form Extension This attributestructure allows the supplier to include additional information regarding the status code encountered. Additional information may be supplied in this attributestructure to provide more detail about any error (e.g., Common Component, Code 5001: Insufficient Arguments Provided:Argument SessionID missing). Table 8Table 11 E133 Code Attribute Value Definitions StatusElement Parameter Source Code Description Extension E133 0 No error has occurred <manufacturer specific> E133 0 An error has occurred <manufacturer specific> E133 1 Message syntax error (e.g., XML validation error, see E133.1) <manufacturer specific> E133 2 Unknown or unexpected PCSJobID <manufacturer specific> E133 3 Unknown or unexpected service <manufacturer specific> E133 4 Unknown or unexpected PCSAETarget <manufacturer specific> E133 5 Service not supported <manufacturer specific> E133 6 Service unavailable at this time <manufacturer specific> E133 7 Unknown or unexpected data item <manufacturer specific> E133 8 to 31 <Not specified: reserved for future generic AE use> E to 99 <Reserved for specific AE type use; reserved unless otherwise indicated in AE FG specification> <manufacturer specific> <manufacturer specific> #1 < 99 Manufacturer specified <manufacturer specific> NA N Any.An ordered list of structured data of DataItemType; see below. #1 >0 Manufacturer specified <manufacturer specific> #1 Manufacturer Specific The existence of the StatusElementStatus attribute is conditional on the properties of the message containing a data structure of type AnalysisEngineDataSet. The StatusElement attribute shall exist if and only if the following conditions apply:analysisenginedatasettype. The Status object exists at two levels. First as an attribute of PCSAEInstructionType, indicating the status of the individual instruction, and as an attribute of PCSAETargetType where it is a summary status of all of the PCSAEInstructionType status attributes. The message is an output from an AE. The message is a response to a request for service(s) from that AE (e.g., a reply message) DataCollectionDataCollectionType A set of data and associated context for that data that conforms to the PCS AE common input/output structure as defined in This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 18 Doc. 5716

25 Figure 7 AE Data Structure Model Highlighting DataCollectionType Data Structure Table 9Table 12 Attributes of DataCollectionDataCollectionType Attribute Name Description Access Reqd Form BinCategory Context Data An enumerated identifier of the type of data collection among the possible types defined in the collection type enumeration, listed in Table 43. A structure that is a collection of DataItems providing context for the data contained in the Data attribute A structure that is a collection of items of DataItemType containing the data being passed in the AnalysisEngineDataSetType NA Y String that is an enumeration of the type of data collection among the possible collection types listed in Table 5. They are: Globals AnalysisParametersC ollectiontype As defined. CalculatedOutputs LogMessages ModuleData ProcessData SubstrateData NA C DataItemType NA C DataItemType CollectionType An enumeration of At least one of Context or Data structures must exist in a DataCollectionType. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 19 Doc. 5716

26 DataItemType A collection of BinCategory as defined in Table DataItem An individual componentcomponents of a data collection that, each of which has meaning in the PCS environment. Each data item hasall members in the collection have a role of either context or data as determined by the client of the PCS AE Figure 8 DataItemType Data Structure Table 10Table 13 Attributes of DataItemDataItemType Attribute Name Description Access Reqd Form Name Human-readable name for DataItem. NA Y StringValueString See rules for naming below. Value An assigned or calculated quantity. NA Y AbstractValue As defined in E134.Any Name This attribute is used to provide a level of understanding of the meaning and purpose of the DataItemDataItemType. Names shall consist of alphanumeric characters, spaces, hyphens and underscores. Names shall start with an alpha character, and shall not contain leading or trailing spaces Value This attribute type is Any as defined in Section 7.3. For example, see type AbstractValue (as defined in E134)). This is an abstract base class that is used to represent standard types including: Integer, Real, Boolean, String, Binary, Structure, Array, and Enumerations. In this way, parameter values collected via E134 may be passed directly into the PCS compliant AE via the value attribute of a DataItem. Refer to E134 for further definition of the AbstractValue type. AbstractValue base class allows for arbitrarily complex data items to be passed into the AE A DataItemDataItemType that belongs to a DataCollectionDataCollectionType whose CollectionTypeBinCategoryType is Globals may not serve a role of data (i.e., it can only serve the role of context) It is not required that the PCS AE utilize a data item in the same role (Data or Context) as is specified by the PCS AE client, however the PCS AE is required to maintain the role representation in I/O data structures produced or consumed across a PCS AE interface Ordering of Elements Within an AnalysisEngineDataSetAnalysisEngineDataSetType Instance In addition to compliance with a data structure model, this Standard also defines rules governing ordering of classes and attributes within each AnalysisEngineDataSetAnalysisEngineDataSetType instance, corresponding to the data content of an AE I/O message. Figure 6 provides a general illustration of this ordering. The following are rules governing that ordering The first attribute of any AnalysisEngineDataSetAnalysisEngineDataSetType instance shall be the PCSJobID, if the PCSJobID value has been determined as defined in The first attribute of any DataCollectionDataCollectionType shall be BinCategory The first member of DataCollection shall be of BinCategory Globals if the AnalysisEngineDataSetAnalysisEngineDataSetType contains a DataCollectionDataCollectionType of that kind. At most one member of DataCollection shall be of BinCategory Globals in any AnalysisEngineDataSet. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 20 Doc. 5716

27 In each DataCollection all DataItems whose role is Context shall occur before the first DataItem whose role is Data occurs Additional Requirements of an AnalysisEngineDataSetAnalysisEngineDataSetType Instance If multiple AnalysisEngineDataSet instances are related, as defined in and both contain the same DataCollection with the same value of BinCategory, and further contain the same DataItem (with the same Name ) within that DataCollection, the last DataItem shall be assumed to be correct. The interpretation of ordering of information as communicated by the underlying protocol is beyond the scope of this Document Within an AnalysisEngineDataSetAnalysisEngineDataSetType instance or a group of instances that are related, as defined in , a DataItemDataItemType may exist within multiple DataCollectionTypesDataCollections that has a role of context. If this condition exists, the following rules shall apply Any Context DataItemsDataItemType instances defined in a DataCollectionDataCollectionType with BinCategory = Globals should be used as a Context DataItemsDataItemType Instance for all other BinCategorysBinCategories in any related message except as defined in below If a DataCollectionDataCollectionType instance with a BinCategory other than Globals defines a Context DataItemDataItemType instance that is also defined in the Global BinCategory of the current message or a related message, the local BinCategory DataItemDataItemType value should be used as context (i.e., the local DataItemType Context DataItemvalue overrides the Global value inside this DataCollectionDataCollectionType) Using Multiple Application-to-Application to Communications to Communicate a PCS Message A PCS message may be broken into a number of application-to-application communications or partitions, however it is not required that a PCS AE support this partitioning capability. Each of these communication partitions must conform to the data model of FigureFigures 3-6, with the following modifications: PCSAETarget minimum cardinality is zero. PCSJobID == [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} PCSAETargets APCSAETarget: PCSAETarget AEType == R2R AEInstance == 1 Instructions Instruction == PCSAnalyze Extension == execute serially Status AStatusElement: StatusElement Source == urn:semi-org:e132 Code == 0 ADataCollection: DataCollection BinCategory == Globals Role == Context ADataItem: DataItem AName: (type == text) AValue: (type == any) ADataItem AName: (type == text) AValue: (type == any) BinCategory == ModuleData Role == Context ADataItem: DataItem AName: (type == text) AValue: (type == any) Role == Data ADataItem: DataItem This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 21 Doc. 5716

28 AName: (type == text) AValue: (type == any) BinCategory == ProcessData Role == Context ADataItem: DataItem AName: (type == text) AValue: (type == any) Role == Data ADataItem: DataItem AName: (type == text) AValue: (type == any) Figure 6 Illustration of Ordering of Information in an AnalysisEngineDataSet Instance (Partial example; is used to indicate possible continuation in the listed format; PCSJobID in this example is aligned with specifications in E120.1) Common Interface Services Except as specified in the EXCEPTIONS paragraph below, PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in PCS AEs shall support both Request and Notification services as specified herein. For Request services, both the Request and Response messages associated with the service shall comply with the common interface data structure specified in 9.2.3, which includes a specification of required and optional elements. The success or failure of performing this service is conveyed in the Response message utilizing the Code attribute (see ). The Code attribute is required in all response messages associated with request services. For Notification services, the message associated with the notification, whether produced or consumed by an AE, shall comply with the common interface data structure. Each service parameter, when provided in a service message, shall be provided as a DataItem in a data bin of the appropriate BinCategory (see FigureFigures 3, 6 and associated text), unless otherwise specified. EXCEPTIONS: The following services are not required to comply with aspects of the common interface data structure as specifically noted. PCSPing service: A Ping service response is not required to contain a PCSJobID parameter All PCS AEs shall support the following common interface services: A set of services shall exist to support access to data from the engine A set of services shall exist to support logging and exception handling Specific services of an AE are invoked utilizing the Instructions element of the PCSAETarget attribute, as defined in Specifically the service name is the value of an Instruction list element. For Request (Synchronous) services, the service name is the value of an Instruction list element for both the Request message and the corresponding Response message. For Notification services the service name is the value of an Instruction list element for the notification message. Utilizing this mechanism a set of services shall exist as defined in Table 11. Table 11Table 14 General AE Object Service Resource Definition #1 Service Reqd Type Description PCSAnalyze Y R Used to instruct an AE to compute and process a logical data sample. The results of the analysis are provided in the Response message. This service can be used for both synchronous and asynchronous PCS jobs. #2 PCSStartJob N R Used to instruct an AE to begin an asynchronous PCS job. #2 PCSAddMoreData N N Used to provide more raw data to an AE executing an asynchronous PCS job. #2 The AE consumes this notification message. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 22 Doc. 5716

29 Service Reqd Type Description PCSEndJob N R Used to instruct an AE to complete an asynchronous PCS job. #2 PCSJobCompleted N N Used by the AE to indicate that an asynchronous PCS job has been completed. #2 The AE produces this notification message. PCSAbortJob N N Used to abort (i.e., terminate) an asynchronous PCS job. #2 The AE consumes this notification message. PCSJobAborted N N Used by the AE to indicate that an asynchronous PCS job has been aborted. #2 The AE produces this notification message. PCSUpdateModel Y R Used to instruct the AE to update the analysis model with new information. This service can be used for both synchronous and asynchronous PCS jobs. #2 PCSEvent N N Used to provide an indication of detection of an event. An event could include the receipt of specific data. The specification of what constitutes the event is beyond the scope of this Standard. PCSProduceLogData N R Used to instruct the AE to produce log messages. Information passed with a log data request could relate the date range and context associated with the request, while information returned could include the requested log data. PCSProduceExceptionData N R Used to instruct the AE to provide information on the occurrence of exceptions raised by the AE. The exception information would be returned by the AE to the requestor, and could include a date range, similar to log data. PCSExceptionProduced N N Used by the AE to indicate that an exception has occurred. The exception information provided with the notification could include a date range, similar to log data. PCSPing Y R Used to ascertain the existence and communication health of the AE. PCSCapabilitiesDiscovery N R Use to query a PCS AE as to its support of capabilities, including those defined in this Standard, and whether or not each capability is currently enabled or disabled. The value of the Capabilities DataItem (as defined in ) in the service response indicates which capabilities are supported, and, among these, which are enabled and which are disabled. PCSEnable N R Used to put the PCS AE in a state where it is providing a subset of the capabilities it is specified as being capable of providing. The value of the Capabilities DataItem (as defined in ) indicates which capabilities are requested to be enabled or disabled. The value of the Capabilities DataItem in the corresponding response indicates which capabilities were actually enabled. #1 Except as specified in EXCEPTIONS following , PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in #2 See Service Parameters Parameters for these services are described in Table 12. Table 12Table 15 PCS Service Parameter DefinitionDescription BinCategory DataItem Name Description Role #1 Form Globals DataSource Indicates the source or sources of data associated with this PCS job. For example, it could indicate an EDA tool and data collection plan. D The form of the DataSource parameter is beyond the scope of this Standard. For example it could be a text string that identifies an EDA data source or context data to point to a particular interface on a particular tool. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 23 Doc. 5716

30 BinCategory DataItem Name Description Role #1 Form Analysis- Parameters Capabilities A complex data item containing: (1) a data element of Boolean form; a value of TRUE in a request service is an indication that ALL supported capabilities are to be enabled; a value of TRUE in a response service message is an indication that all capabilities are currently enabled; a value of FALSE in a request service is an indication that ALL supported capabilities are to be disabled; a value of FALSE in a response service message is an indication that not all capabilities are currently enabled. (2) A list of elements each of which provides information on each AE FG Capability, as listed in Tables 13 and 14, that is supported. Specifically each element in the list provides the following information; (2a) The number of the capability, as defined in this Standard, that is supported (e.g., R2R.A.1) (2b) The different ways in which the capability is supported. (2c) In a request message, an indication as to whether the capability is to be enabled or disabled; in a response message, an indication as to whether the capability is currently enabled or disabled. #1 Where, in the Role Column, D indicates Data and C indicates Context. D See description; additional specification of form is beyond the scope of this Standard. It is only required that this parameter be used to indicate which capabilities are supported. However, as desired indication of lack of support (e.g., via a value of FALSE) can be provided for 2b to indicate that a capability is not supported PCSStartJob Table 13 describes the parameters specified for this service. Table 13Table 16 PCSStartJob Service Parameter Definition Parameter Request Response Form Description DataSource C #1 - See See #1 Parameter provided in the Request message if the service requestor wishes to indicate the data source or sources to be utilized in this (asynchronous) PCS job PCSCapabilitiesDiscovery Table 14 describes the parameters specified for this service. Table 14Table 17 PCSSCapabilitiesDiscovery Service Parameter Definition Parameter Request Response Form Description Capabilities N R See See PCSEnable Table 15 describes the parameters specified for this service. Table 15Table 18 PCSEnable Service Parameter Definition Parameter Request Response Form Description Capabilities R R See See Common Behavior All PCS AEs shall be able to accept inputs and provide outputs through a combination of services which include those defined in Table 11, General AE Object Service Resource Definition. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 24 Doc. 5716

31 PCSJob Management Behavior A PCS AE provides PCS capabilities by executing PCS jobs. This section defines the behavior of the AE associated with the management of a PCS job in that AE. A PCS AE may manage multiple PCS jobs simultaneously. The maximum number of concurrent jobs that shall be maintained by an AE is beyond the scope of this Standard, however this section defines the behavior of each job that PCS AE is managing The following PCS job behavioral classes are specified. Synchronous PCS job: The AE responds to PCS job request message for a new job with a single response message produced that contains the response to the request that is the job output. After the response is issued by the AE, the job ends. Asynchronous PCS job: The AE responds to PCS job requests message for a new job by opening a session with the requestor. During that session, for messages associated with that particular PCS job, the AE may respond synchronously to request messages (by producing appropriate response messages), consume notification messages without providing a response, and/or asynchronously produce notification messages. The asynchronous PCS job ends at an AE if any of the following conditions are met: A request to end the job is received by the AE via a PCSEndJob service, the AE determines that it can and should end the job, and the AE sends a positive response to the request; The AE determines that the job is complete and it should end the job, and provides a notification via the PCSJobCompleted service that the job has ended; The AE receives a notification to abort the job via the PCSAbortJob service, and the AE can process the request; The AE determines that it should abort the job and sends a notification to abort the job via the PCSJobAborted service An AE may support one or both of these behavioral classes; additional specification as to this support may be provided in the individual AE type specification. The behavioral class to which the AE complies in executing a PCS job depends on the specific type of service request received (see 9.2.4) and the capabilities of the AE Additional specification of AE behavior can be found in the behavioral specifications for that specific analysis engine type. An AE may provide or specify additional behavior as long as it does not conflict with the behavior defined for that class in this Standard AE General Capability Description An AE module should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the AE Inputs The following data types and data values are used in AE input messages No data types or data values are specified for the general AE Outputs The following data types and data values are used in AE output messages No data types or data values are specified for the general AE. 9.3 R2R Control FG This section defines the common capabilities and interface data structures of the R2R control FG. Note that this includes W2W control capabilities Table 16 below describes the specialization for the R2R control FG of each inherited general capability described in Table Table 17 describes the additional capabilities unique to the R2R control FG R2R General Capability Description This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 25 Doc. 5716

32 A R2R module should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the R2R model. For example, R2R function may only need feedback data in the form of Substrate Data Inputs The following data types and data values are used in R2R control input messages: The R2R controller AE inherits the input data structure and data structure requirements from the PCS AE The following data types and data type values shall be supported by a R2R control AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data: PCSAETarget Class Attribute AEType with a value of R2R A list element of attribute Instructions with a value of PCSAnalyze A list element of attribute Instructions with a value of PCSUpdateModel Outputs The following data types and data type values are used in R2R control output messages: The R2R controller AE inherits the output data structure and data structure requirements from the PCS AE The following data types and data type values shall be supported by a R2R control AE when included in an output data structure, where supported means that the AE will be able to provide these data types and values when behavioral conditions warrant, as indicated below DataCollection Class The following DataItem Names or Name/Value pairs shall be supported for DataItems in the specified BinCategory ControlAdvice This attribute contains the control advice, structured as an unordered list of name-value pairs. The method in which the control advice is utilized is beyond the scope of this Document. Table 16Table 19 R2R Control FG Inherited Capabilities # Description Reqd Comments R2R.I.1 Provide a R2R control capability as defined in 5 The R2R control AE shall be able to accept process quality data, and utilize this data to generate advice on how to improve future processing; specifically, a R2R implementation shall provide a capability for modifying recipe parameters or the selection of control parameters between runs to improve processing performance. A run can be a batch, lot, or an individual wafer (specified in the context). R2R.I.2 R2R.I.3 Provide the required PCS AE Methods The R2R control AE shall provide the required interface services as defined in this Standard. Maintain R2R models of selected PCS environment The R2R control AE shall maintain explicit or implicit R2R models of the selected process control environment. These models shall be utilized to provide the R2R control capability. These models shall dynamically represent the state of the system based on information received by the AE relating to the selected process control environment as well as configuration information. Y Y Y Based on definition of R2R control. These include PCSAnalyze and PCSUpdateModel. The specific form and behavior of these models is beyond the scope of this Standard; however they generally model aspects of the process(es) or tool(s) being controlled. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 26 Doc. 5716

33 R2R.I.4 R2R.I.5 R2R.I.6 R2R.I.7 R2R.I.8 # Description Reqd Comments Provide a mechanism to uniquely instruct the AE to perform an action The R2R control AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action. Interface with multiple external systems The R2R control AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. Basic model management The R2R control AE shall provide the capability to create/add, edit configuration, and delete R2R control models. Interface with other AEs The R2R control AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs. Advanced model management The R2R control AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y N N The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a PCS result, update of a model, or communication of model parameters. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the AE interface. The R2R control AE is not required to interface with other AEs, however examples of use of interface capabilities would be utilizing SPC and/or FD information to determine model parameter updates or controller actions. R2R.A.1 R2R.A.2 R2R.A.3 Table 17Table 20 Additional R2R Control FG Capabilities # Description Reqd Comments Accept and utilize feedback data The R2R control AE shall be able to accept historical information about the target process control environment, and advice adjustments for improving processing based on this data; typical feedback data is post process metrology information from previous process events on the target process. In the context of R2R control, feedback data is defined as data that is utilized to improve capability for future process runs. Automatically configure internally for control of a target process The R2R control AE shall be able to request and/or accept information about the specific process control environment as necessary, and automatically configure to provide control of the process. For example, the R2R control AE may request and utilize experimental data to determine optimal baseline control models for the target process. Support manual configuration for control of a target process The R2R Control Analysis Engine shall be able to request and/or accept configuration information so that the Analysis Engine may be configured by an external system to provide control of the process. Y C #1 C #1 The controller must utilize feedback information to maintain dynamic models. Item R2R.A.2 and/or R2R.A.3, required. Item R2R.A.2 and/or R2R.A.3, required. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 27 Doc. 5716

34 R2R.A.4 R2R.A.5 R2R.A.6 R2R.A.7 R2R.A.8 R2R.A.9 # Description Reqd Comments Accept and utilize feedforward data The R2R control AE shall be able to accept information about current material to be processed and adjust recommendations for improving processing based on this data. In the context of R2R control, feedforward data is defined as data that is utilized to improve capability for the current process run. Support enabling and disabling of providing the control capability as defined in R2R.I.1 Accept and utilize overrides of recipe advices The R2R control AE shall be able accept and utilized overrides of recipe advices, originally generated as a result of providing capability R2R.I.1. The method in which the override information is utilized is beyond the scope of this document. Provide W2W control The R2R control AE shall be able to generate R2R control advices, as defined in R2R.I.1, for each wafer before processing of each wafer begins. Support of this capability can be provided in one or more ways that are itemized as follows: Provides capability R2R.I.1 for a number of wafers in a group before the processing of the first wafer in that group begins. Provides capability R2R.I.1 for each wafer after the processing of the previous wafer. Supports coordinated control with another R2R AE ( coordinating controller ) The R2R control AE shall support the utilization of R2R advice (as defined in R2R.I.1) provided by another R2R AE. The manner in which the AE utilizes R2R control advices is beyond the scope of this document. Provide publishing of R2R control advices generated The R2R control AE shall be able to provide information of control advices generated for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows: Provide the capability upon request Provide the capability as a notification R2R.A.10 Provide publishing of R2R control advices used The R2R control AE shall be able to provide information of control advices used for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows: Provide the capability upon request Provide the capability as a notification N N N N N N N Enabling/disabling is supported by the PCSEnable and PCSDisable services respectively. Both the originally generated and override results are provided utilizing the ControlAdvice Data Type. This W2W control capability is often restricted to on-tool R2R AEs. Support of this capability does not dictate how the control advice is provided (e.g., as a differential from a baseline, or as an absolute value) or how the settings are utilized. This capability is usually associated with W2W control and is often restricted to on-tool R2R AEs. Support of this capability could mean for example that the on-tool W2W controller could utilize off-tool setting recommendations as a starting point or baseline for W2W control. Note that the advice information as specified here could be considered as a portion of the configuration information specified in R2R.A.3. This capability would be provided utilizing the R2RInformationLog service in request or notification form. This capability would be provided utilizing the R2RInformationLog service in request or notification form. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 28 Doc. 5716

35 # Description Reqd Comments R2R.A.11 Provide publishing of process control targets The R2R control AE shall be able to provide information of control targets used by the AE for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows: Provide the capability upon request Provide the capability as a notification R2R.A.12 Provide publishing of control model parameters The R2R control AE shall be able to provide information about the control model used by the AE for a particular PCS job; this information is provided via the LogMessages collection type as defined in Table 3. Support of this capability can be provided in one or more ways utilizing the R2RInformationLog service that are itemized as follows: Provide the capability upon request Provide the capability as a notification Details as to the type of control model information that should be provided as part of this capability are beyond the scope of this Standard. #1 C indicates conditional with the conditions specified in the Comment column. N N This capability would be provided utilizing the R2RInformationLog service in request or notification form. This capability would be provided utilizing the R2RInformationLog service in request or notification form. Control model parameter information could include controller gain, controller noise filtering, control limits, parameter weights, and algorithm selection. Table 18Table 21 Data Types Required to be Supported by an Input Message for an AE BinCategory DataItem Name Value Description Role #1 Reqd Form Calculated Outputs ControlAdvice NA #2 A set of name-value pairs that constitute a control advice. Context associated with the AnalysisEngineDataSet Input may identify the system to which the R2R control recipe advice parameters are expected to be applied. LogMessages R2RInformation NA #2 A set of name-value pairs that provide, at minimum, one or more of the following: R2R Control Advice generated R2R Control Advice used R2R Control targets R2R Control gain used R2R Control model used An indication of data not available can be conveyed through a specific value in each namevalue pair. #1 Where, in the Role column, D indicates data and C indicated context. #2 NA indicates not applicable, because specification is on DataItem as opposed to a specific value of DataItem. D Y Any. D N R2R Control Advice values provided in form of ControlAdvice; Form of other components of DataItem not specified Note that an indication of Data Not Available could be a possible value for a particular parameter R2R Interface Services The R2R control AE inherits Common Interface Services as specified in The R2R AE shall additionally support the following services. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 29 Doc. 5716

36 Table 19Table 22 Additional R2R AE Object Service Resource Definition #1 Service Reqd Type 2 Description R2RInformationLog N R or N Used to determine information provided by or utilized by the R2R AE in the past in providing capability R2R.I.1, as specified in Table 13. The log information is communicated through the R2RInformation DataItem as defined in Table 15. This service can be provided as a Request/Response service, or as a Notification service. A PCSJobID parameter is used to indicate the PCS job associated with the information being provided. #1 Except as specified in EXCEPTIONS following , PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in The PCSCapabilitiesDiscovery and PCSEnable services are required R2R Interface Behavior The R2R AE inherits Common Interface Behavior as specified in The R2R AE shall additionally support the following behavior The R2R AE shall support the Synchronous PCS job behavioral class and optionally support the Asynchronous PCS job behavioral class, as specified in If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a PCSAETarget attribute, one of the list of instructions in the Instructions attribute has a value of PCSAnalyze, then the R2R control shall provide capability R2R.I.1 (see Table 16). Specifically the AE shall provide an output message of type AnalysisEngineDataSet that contains the data item name ControlAdvice in a DataCollection where BinCategory = CalculatedOutputs If a R2R AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in a PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of PCSUpdateModel, then the R2R control AE shall utilize information provided as part of the associated PCS job to update control models as necessary. The determination of need to update models and the method in which these models are updated is beyond the scope of this Standard. 9.4 FD FG This section defines the common capabilities of the FD FG Table 20 describes the specialization for FD of each inherited general capability described in Table 5. Table 20Table 23 FD FG Inherited Capabilities # Description Reqd Comments FDD.I.1 Provide a FD capability as described in 5 The FD system shall analyze provided input data with the purpose of detecting anomalies/faults. FDD.I.2 FDD.I.3 Provide the required PCS AE methods The FD AE shall provide the required interface services as defined in this Standard. Maintain models of selected PCS environment(s) The FD AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to detect anomalies in the supplied data. Y Y Y Detailed inputs and outputs to be defined in a future version of the Standard. However it is expected that the FD engine will provide output sufficient to analyze why the engine determined there was a fault. These include PCSAnalyze and PCSUpdateModel. The specific form and behavior of these models is beyond the scope of this Standard. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 30 Doc. 5716

37 FDD.I.4 FDD.I.5 FDD.I.6 # Description Reqd Comments Provide a mechanism to uniquely instruct the AE to perform an action The FD AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action. Interface with multiple external systems FD AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. Basic model management The FD AE shall provide the capability to create/add models, edit configuration of models, and delete models. FDD.I.7.1 Interface with FC AE The FD AE shall be capable of providing output that can be used by a PCS-compliant FC AE. FDD.I.7.2 Interface with other AEs FD AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs. FDD.I.8 Advanced model management The FD AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y Y N N The mechanism could be a single key variable, e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FD result. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the FD Analysis Engine interface. Output to FC is required. Other interfaces are optional. For example, using R2R outputs to distinguish between controller changes and faults Table 21 describes the additional capabilities unique to the FD FG. Table 21Table 24 Additional FD FG Capabilities # Description Reqd Comments FDD.A.1 Provide an interface for automatic notification of detected faults The FD AE shall provide an interface to automatically notify an external system when a fault is detected. The interface must provide enough information about the detected fault for the external system to make decisions about notification. FDD.A.2 Ability to test against reference/simulation data The system should provide the ability to test and evaluate FD models against historic, reference or simulated data without affecting the production environment. FDD.A.3 Ability to interdict process/tool The system should be capable of initiating the interdiction of a process, either directly or indirectly, in a timely manner, in order to prevent or prohibit the creation of out-of-spec material. This is needed when the general event notification and/or interdiction system(s) cannot respond fast enough to protect people, plant, or product. Y N N The external system may for example: page or an engineer, or take the tool in question off-line. Information provided in the interface should include: context, severity, and any fault details (TBD in a future version of the Standard). This capability could be provided offline; i.e., as a capability that is available in a mode when other required FD capabilities are not necessarily available. NOTE: This would be in addition to the capability defined in FD.I.1 above FD General Capability Description This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 31 Doc. 5716

38 An FD module should accept the following inputs and outputs using the common interface structure described in Figure 52. Not all inputs and outputs are required depending on the functionality needed by the FD AE Inputs The following data types and data values are used in FD input messages: The FD AE inherits the input data structure and data structure requirements from the PCS AE The following data types and data type values shall be supported by a FD AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data: PCSAETarget Class Attribute AEType with a value of FDD Outputs The following data types and data type values are used in FD output messages: The FD analysis engine inherits the output data structure and data structure requirements from the PCS Analysis Engine FD Interface Services The FD AE inherits Common Interface Services as specified in The inherited PCSEvent service shall be required The FD AE shall additionally support the following services. Table 22Table 25 Additional FD AE Object Service Resource Definition #1 Service Reqd Type #2 Description FDDFault Y N Used to provide a FD capability through notification of an anomaly or fault event as specified in 5 and Table 20. #1 Except as specified in EXCEPTIONS following , PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in #2 See FD Interface Behavior The FD AE inherits Common Interface Behavior as specified in The FD AE shall additionally support the following behavior The FD AE shall support both the Synchronous PCSJob and Asynchronous PCSJob behavioral classes as specified in FC FG This section defines the common capabilities of the FC FG Table 23 describes the specialization for FC of each inherited general capability described in Table 5 above Table 24 describes the additional capabilities unique to the FC FG. Table 23Table 26 FC FG Inherited Capabilities # Description Reqd Comments FCC.I.1 Provide a FC capability as described in 5 The FC system shall analyze provided input detected or predicted fault data with the purpose of determining the root cause of the fault. Y Detailed inputs and outputs to be defined in a future version of the Standard. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 32 Doc. 5716

39 FCC.I.2 FCC.I.3 FCC.I.4 FCC.I.5 FCC.I.6 # Description Reqd Comments Provide the required PCS AE methods The FC AE shall provide the required interface services as defined in this Standard. Maintain models of selected PCS environment(s) FC AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to classify the input fault data into probable root cause categories. Provide a mechanism to uniquely instruct the AE to perform an action The FC AE shall support an input mechanism whereby the analysis engine can be instructed to take a specific unique action. Interface with multiple external systems FC AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. Basic model management The FC AE shall provide the capability to create/add models, edit configuration of models, and delete models. FCC.I.7.1 Interface with FD AE The FC AE shall be capable of accepting the appropriate output of a PCS-compliant FD AE. FCC.I.7.2 Interface with FP AE The FC AE shall be capable of accepting the appropriate output of any PCS-compliant FP AE. FCC.I.7.3 Interface with other AEs The FC AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs. FCC.I.8 Advanced model management The FC AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y Y Y Y N N N These include PCSAnalyze and PCSUpdateModel. The specific form and behavior of these models is beyond the scope of this Standard. The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FC result. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the FD AE interface. FC AE may require additional inputs to perform classification operation (i.e., FD output may not be sufficient as sole input). FC AE may require additional inputs to perform classification operation (i.e., FP output may not be sufficient as sole input). Table 24Table 27 Additional FC FG Capabilities # Description Reqd Comments FCC.A.1 Ability to perform automated classification Automated classification allows for classification to occur automatically after a fault is detected or predicted (in-line). This ability results in faults classified with some degree of confidence without user intervention. FCC.A.2 Ability to perform manual classification Manual classification allows classification to occur manually after a fault is detected or predicted (inline). This ability may result in a new classification being defined or a new association to an existing classification established. R O This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 33 Doc. 5716

40 # Description Reqd Comments FCC.A.3 Ability to perform remote reclassification of production and archived faults Re-classification should be required offline. This allows for new association to be made that may not be the result of an online classification. FCC.A.4 Ability to communicate references to agents that might make use of the information such as troubleshooting guides (TSGs), out of control action plan (OCAP) systems, and computerized maintenance management systems (CMMSs) Classification should allow users to link to outside agents such as TSG, OCAP systems and CMMSs. This means that, in addition to application-to-application communication, the classification information provided by the FC engine can be interpreted by the outside agent; e.g., a classification can be mapped to a maintenance activity in a CMMS or an action plan in an OCAP system. FCC.A.5 Ability to indicate that a fault cannot be classified, and to tag unclassified faults for future classification In some cases, data analysis does not reveal a classification of a fault, or does not reveal a classification that is appropriate for reporting. Also, to avoid inline delays it is often necessary to defer classification until further studies are made. This may be the result of automated, manual, or re-classification tasks. FCC.A.6 Produce list of classifications by a method such as confidence or probability Metric to identify the classification confidence must be the result of classification. Optionally all the classifications that have any nominal confidence should be listed. FCC.A.7 Ability to provide for FC of a non-equipment system FC does not have to be limited to classification of equipment faults. FCC.A.8 Ability to accept data on the fault that was classified, and adapt to or learn from this information The classification system should accept feedback that provides the results of investigation of a particular FC that was communicated, and adapt or improve internal classification capabilities. The method for adapting or improving is beyond the scope of this Standard. FCC.A.9 Ability to support further investigation of a reported FC The classification system should provide a capability for further inquiry into details associated with a reported FC. N N N N N N N An example is a Pareto presentation, such as classification candidates along with their probability of being the source of the fault. Examples include FC of a R2R control AE or a software system. As an example, if the FC AE reports a Pareto of possible FCs, the client of the FC system might report back the actual cause of the problem among the possibilities. This capability is often referred to as drill-down and could include reporting of raw and processed data associated with the classification, classification calculations, and data quality indicators. It could also include transactions to support step-wise decision-tree style analysis of classification information FC General Capability Description An FC module should accept the following inputs and outputs using the common interface structure described in Figure 52. Not all inputs and outputs are required depending on the functionality needed by the FC AE Inputs The following data types and data values are used in FC input messages: The FC AE inherits the input data structure and data structure requirements from the PCS AE. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 34 Doc. 5716

41 The following data types and data type values shall be supported by a FC AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data: PCSAETarget Class Attribute AEType with a value of FCC A List element of attribute Instructions with a value of PCSAnalyze (Optional) A List element of attribute Instructions with a value of PCSUpdateModel Outputs The following data types and data type values are used in FC output messages: The FC AE inherits the output data structure and data structure requirements from the PCS AE The following data types and data type values shall be supported by a FC AE when included in an output data structure, where supported means that the AE will be able to provide these data types and values when behavioral conditions warrant, as indicated below E133 Code Attribute Value Definitions The following additional Code attribute value definitions shall be supported (see Table 8 also). Table 25Table 28 FC FG Code Attribute Value Definitions Source Code Description Extension E Unable to provide classification information. <manufacturer specific> E Unable to provide classification information at this time. <manufacturer specific> DataCollection Class The following DataItem Names or Name/Value pairs shall be supported for DataItems in the specified BinCategory. Table 26Table 29 Data Types Required to be Supported by an Input Message for an Analysis Engine BinCategory DataItem Name Value Description Role #1 Reqd Form Calculated- Outputs FaultClassificationAdvice NA #2 #1 Where, in the Role column, D indicates data and C indicated context. The FC information. The structure of this attribute is beyond the scope of this Standard. For example, the information could be an ordered list of a structure that contains the classification and the classification probability, as a Pareto report. Context associated with the AnalysisEngineDataSet Input may identify the system to which the FC information applies. #2 NA indicates not applicable, because specification is on DataItem as opposed to a specific value of DataItem. D Y Any FaultClassificationAdvice This attribute contains the FC information. The structure of this attribute as well as the method in which the FC advice is utilized is beyond the scope of this Document FC Interface Services The FC analysis engine inherits Common Interface Services as specified in The inherited PCSEvent service shall be required The FC analysis engine shall additionally support the following services. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 35 Doc. 5716

42 Table 27Table 30 Additional FC AE Object Service Resource Definition #1 Service Reqd Type #2 Description FCCClassification N N Used to provide a FC capability through notification of a classification event as defined in 5 and Table 21. This notification service is only utilized if the FCC AE is operating in an Asynchronous behavioral mode, as defined in #1 Except as specified in EXCEPTIONS following , PCS AEs shall provide services by accepting and producing messages that are compliant with the common interface data structure as defined in #2 See The following parameters are specified for this service: Table 28Table 31 FCCClassification Service Parameter Definition Parameter #1 Requirement Form Description FaultClassificationAdvice Y See Table 22. See Table 22. #1 Parameter provided in the Notification message if the AE can provide the appropriate classification information. See for further information FC Interface Behavior The FC AE inherits Common Interface Behavior as specified in The FC AE shall additionally support the following behavior The FC AE shall support both the Synchronous PCSJob and optionally support Asynchronous PCSJob behavioral classes as specified in If the FC AE receives an input message of type AnalysisEngineDataSet for a process control job, and, in the PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of PCSAnalyze, then the FC AE shall provide capability FCC.I.1 (see Table 23). Specifically the AE shall provide an output message of type AnalysisEngineDataSet that contains the data item name FaultClassificationaAdvice in a DataCollection where BinCategory == Calculated Outputs If the FC AE receives an input message of type AnalysisEngineDataSet for a PCS job, and, in the PCSAETarget attribute of that message, one of the list of instructions in the Instructions attribute has a value of PCSUpdateModel, and, further, if the FCC.I.8 or FCC.A.8 (see Tables 23 and 24) capabilities are supported, then the FC AE shall utilize the information provided as part of the associated PCS job to update classification models as necessary. The determination of the need to update models and the method in which these models are updated is beyond the scope of this Standard If the FC AE supports asynchronous PCS job behavior it will utilize the FCCClassification notification service to report classification information associated with an open asynchronous PCS Job. Specific classification information is reported utilizing the FaultClassificationAdvice service parameter. Indication of the lack of capability to provide classification information is communicated by utilizing the appropriate Status Element Code attribute value (see Table 8). The utilization of the FaultClassificationAdvice service parameter in this case is beyond the scope of the Standard, though the parameter may be used to communicate details regarding the lack of ability to provide classification information. 9.6 FP FG This section defines the common capabilities of the FP FG Table 29 describes the specialization for FP of each inherited general capability described in Table 5 above Table 30 describes the additional capabilities unique to the FP FG. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 36 Doc. 5716

43 Table 29Table 32 FP FG Inherited Capabilities # Description Reqd Comments FPP.I.1 Provide a FP capability as described in 5 The FP system shall analyze provided input data with the purpose of determining if a fault will occur in a future run. FPP.I.2 FPP.I.3 FPP.I.4 FPP.I.5 FPP.I.6 Provide the required PCS AE methods The FP AE shall provide the required interface services as defined in this Standard. Maintain models of selected PCS environment(s) FP AE shall maintain explicit or implicit models of the selected process control environment. These models shall be used to predict faults based on the supplied input data. Provide a mechanism to uniquely instruct the AE to perform an action The FP AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action. Interface with multiple external systems FP AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. Basic model management The FP AE shall provide the capability to create/add models, edit configuration of models, and delete models. FPP.I.7.1 Interface with FC AE The FP AE shall be capable of providing output that can be used by any PCS-compliant FC AE. FPP.I.7.2 Interface with other AEs The FP AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs. FPP.I.8 Advanced model management The FP AE shall provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y Y Y Y Y N N Detailed inputs and outputs to be defined in a future version of the Standard. However, it is expected that the FP output will provide enough information to determine why and when the engine determined a fault will occur. These include PCSAnalyze and PCSUpdateModel. The specific form and behavior of these models is beyond the scope of this Standard. The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model and generation of a FP result. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the FD AE interface. Table 30Table 33 Additional FP FG Capabilities # Description Reqd Comments FPP.A.1 Provide an interface for automatic notification of predicted faults The system must provide an interface to automatically notify an external system when a fault is predicted. The interface must provide enough information about the predicted fault for the external system to make decisions about notification. Y The external system may for example: page or an engineer, or take the tool in question off-line. Information provided in the interface should include: context, severity, and any fault details (TBD in a future version of the Standard). This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 37 Doc. 5716

44 # Description Reqd Comments FPP.A.2 FPP.A.3 FPP.A.4 Ability to perform advanced statistical/prediction algorithms on data to enable FP after a specific number of runs, tool time or products What is the probability that a specific fault will happen, when, what are action plans that can be taken, which tools, what is the predictive classification of a specific fault. Ability to build a prediction model from historical data Based on the historical data, a learning-based model may be developed. A specific pattern of historical data may give information about a future fault possibility. Ability to predict preventive maintenance scheduling based on tool/substrate information This will reduce tool downtime. N N N 9.7 SPC FG This section defines the common capabilities of the SPC FG Table 31 below describes the specialization for SPC of each inherited general capability described in Table 5 above Table 32 describes the additional capabilities unique to the SPC FG SPC General Capability Description An SPC engine should accept the following inputs and outputs using the common interface structure described in Figure 2. Not all inputs and outputs are required depending on the functionality needed by the SPC AE Inputs The following data types and data type values are used in SPC input messages: The SPC engine inherits the input data structure and data structure requirements from the PCS AE The following data types and data type values shall be supported by an SPC AE when included in an input data structure, where supported means that the AE will be able to utilize the information provided by the data type and perform any indicated action associated with that data: PCSAETarget Class Attribute AEType with a value of SPC A list element of attribute Instructions with the possible values of the instructions supporting the synchronous methods inherited from the PCS AE DataCollection Class: data types and data type values for SPC input parameters are SPC AE vendor specific and beyond the scope of this Standard Outputs The following data types and data type values are used in SPC AE output messages: The SPC AE inherits the output data structure and data structure requirements from the PCS AE SPC Interface Services The SPC AE inherits Common Interface Services as specified in SPC Interface Behavior The SPC AE inherits Common Interface Behavior as specified in The SPC AE shall additionally support the following behavior: The SPC AE shall support the Synchronous PCSJob behavioral class and optionally support the Asynchronous behavioral class as specified in This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 38 Doc. 5716

45 Table 31Table 34 SPC FG Inherited Capabilities # Description Reqd Comments SPC.I.1 Provide a SPC capability as described in 5 The SPC system shall analyze provided input data with the purpose of determining if statistically significant deviations from normal have occurred. SPC.I.2 SPC.I.3 SPC.I.4 SPC.I.5 SPC.I.6 SPC.I.7 SPC.I.8 Provide the required PCS AE methods The SPC AE shall provide the required interface services as defined in this Standard. Maintain models of selected PCS environment(s) The SPC AE shall maintain statistical distribution models. Such models can be selected automatically during gathering of input data and can be selected for the specific process to be monitored. Provide a mechanism to uniquely instruct the AE to perform an action The SPC AE shall support an input mechanism whereby the AE can be instructed to take a specific unique action. Interface with multiple external systems SPC AE shall be capable of accepting inputs from, or generating outputs to multiple external systems. Basic model management The SPC AE shall provide the capability to create/add models, edit configuration of models, and delete models. Interface with other AEs The SPC AE shall be capable of either accepting outputs from other AEs as inputs, or producing outputs that are utilized by other AEs. Advanced model management The SPC AE may provide advanced model management capabilities including but not limited to: secure access to models, and automatic updating of models based on process control environment changes. Y Y Y Y Y Y N N Based on the definition of SPC. These include PCSAnalyze and PCSUpdateModel. The SPC AE supports normal and various non-normal statistical deviation models. The specific form and behavior of these models is beyond the scope of this Standard. The mechanism could be a single key variable; e.g., model name or a complex set of context data utilized internally to perform CM, etc. The action could include application of a specific model (SPC rule) and generation of a SPC result. The definition of these systems will be a function of the application environment; these could include process tool or metrology systems, or user interfaces. This capability will be supported through the FD AE interface. Table 32Table 35 Additional SPC FG Capabilities # Description Reqd Comments SPC.A.1 Functionality to perform trend analysis The SPC AE shall provide an automated analysis of data for the identification of undesired trends using industry standard run rules such as (for example) Western Electric. #1 One result of these calculations and comparisons should be a decision of whether or not the new data caused the chart to go out of control. The mathematics available must include those items listed in item #SPC.A.4 below. SPC.A.2 Functionality to support standard control charts The SPC AE shall provide the ability to plot data as well as display traditional variables charts, and attributes charts. The system should also provide access to the data to enable a third party system to display control charts. N N More flexible rules may be required but are subject to the specific implementation. Typical charts would include Shewart and CuSum Charts optionally with smoothing such as exponential weighted mean average charts (EWMA). #1 This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 39 Doc. 5716

46 # Description Reqd Comments SPC.A.3 Functionality to perform statistical analysis The SPC AE shall provide tools for statistical analysis. SPC.A.4 Functionality to calculate control limits The SPC AE shall provide abilities to calculate control limits for control charts from historical data using at minimum industry standard techniques for calculating upper and lower control limits for variables and attributes charts based on sub-group size, sample size, etc. Other techniques can be utilized as desired to augment the standard techniques. Elimination of outliers is an integral part for control limits calculation and the SPC AE shall have an algorithm to support that capability. SPC.A.5 Provide an interface for automatic notification of processing anomalies The SPC AE shall provide an interface to automatically notify an external system when an assignable cause statistical anomaly is detected. The interface must provide enough information about the detected problem to the external system to make decisions about notification. SPC.A.6 Functionality to provide a reference to an Out-of-Control Action Plan (OCAP) The SPC AE shall store a reference to an action plan that is to be put into effect in the case of the trend analysis determining that an out of control condition exists. SPC.A.7 Ability to store user problem resolution comments The SPC AE shall provide a place for users to put in comments on how the problem was corrected. This may also be used by the statistical analysis system to store information related to the OOC point to speed up diagnosis and problem resolution. Y N N N This may include the ability to calculate statistical metrics, normal analysis, and non-normal analysis. This is subject to the specific implementation. The external system may for example page or an engineer, or take a tool off-line. Information provided in the interface should include: context, severity, and any fault details. The kind of interface and the way of setting up the notification target is beyond the scope of this Standard. The information provided should allow the consumer of that information to understand the context of the problem; thus the information should include as necessary information on tools, chambers, wafers, processes and products. The OCAP maybemay be a part of the SPC AE or part of another system accessible from the SPC AE. In either case, for this requirement to be met, the SPC AE must have a capability to trigger a specific OCAP. The OCAP implementation specification is outside the scope of this Standard. #1 For an explanation of the Western Electric Company Rules (WECO) see, for example, the NIST/SEMATECH e-handbook of Statistical Methods; 7/18/2006. N 10 Compliance to PCS Standard 10.1 This section defines requirements placed on PCSs for claiming compliance with this Standard and verifying compliance with this Standard. The Standard does NOT include specific verification test plans, but there should be enough information in the Standard to generate these Approach This Standard specifies the interfaces for PCS FGs. Compliance with this Standard is verified through testing these interfaces to verify compliance of data structures and behavior to the extent specified in this Standard As noted in 9, all PCS AE are characterized as having a set of capabilities, and a collection of inputs and outputs, with the outputs being a function of the inputs. The general approach to compliance testing then is to first This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 40 Doc. 5716

47 document the capabilities, and then test the inputs and outputs by (1) generating inputs for the PCS AE to consume and (2) observing corresponding outputs of the engine. It is understood that there are a number of behavior models that an AE shall use to consume inputs and produce outputs, such as active polling by the engine or a request message from an outside source to the AE. The compliance testing method should utilize a mechanism that works with the behavioral model of the AE for subscription to (i.e., consumption of) inputs and publication of (i.e., production of) outputs Note also that all PCS AEs inherit a set of common requirements. Thus, the approach for testing any PCS AE should be to first verify compliance to the common requirements, and then verify compliance to the requirements specific to the particular FG Scope of Compliance Verification Compliance Verification shall address the following: Documentation of FG capabilities Future version of this Standard will also address the following compliance verification: Capability to accept all required inputs Capability to accept properly formatted interface data structures Capability to produce all required outputs; these outputs may be in response to the inputs as specified herein Capability to produce properly formatted output data structures Compliance verification will not address the following: Engine response to improperly formatted inputs Quality of Service (QoS) of data in output structures produced by engine Quality of Performance (QoP) of engine in producing output structures (e.g., in response to receipt of input structures) 10.4 Statement of Compliance (SoC) FG Capabilities Data Sheet All PCS AEs claiming compliance with this Standard are required to be delivered with a statement of compliance sheet on FG capabilities. This sheet specifies for the user which functional capabilities, specified as required or conditional in this Standard, are available with this engine. The format of the SoC sheet is given in Table 2733, which includes a description of the fields of this sheet: Table 33Table 36 PCS AE SoC FG Capabilities Data Sheet Company Company Name Product Product Name Version Software Revision Number, etc. Functional Group(s) Functional Group(s) to Which Compliance is Claimed Functional Group Capabilities - Functional Group #1 # Description Requirement Supported Comments - Functional Group #2 # Description Requirement Supported Comments This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 41 Doc. 5716

48 Company Name of company supplying product Product Name of product being supplied Version Any additional descriptors that supplier applies to product (such as software revision number) that, along with Product Name, uniquely identifies product Functional Group(s) The FGs, as defined in this Standard, to which compliance is being claimed Functional Group Capabilities The FG capabilities as specified in this Standard for the FGs to which compliance is being claimed (as indicated in the Functional Group(s) field). Note that all capabilities specified in this Standard for the FGs, to which compliance is being claimed, must be listed, and are organized by the fields below Functional Group #n The name of the n-th functional group to which compliance is being claimed (e.g., R2R, FD, FC, FP, or SPC) # The index number (copied from the # field for that capability) Description The FG capability description copied verbatim from this Standard (copied from the Description field for that capability), for the PCS AE FG listed Requirement The requirement of the capability as defined in this Standard (copied from the Requirement field for that capability) Supported This field contains the PCS AE provider s claim of support of this capability. The claim could be Yes (Y), No (N), Conditional (C), or Optional (O). Note that if the capability is listed as a requirement then it must be supported Comment This field contains any additional information that the PCS AE provider may wish to provide. Note that if the Supported field is listed as Conditional or Optional, the conditionality or optionality conditions must be delineated in this field PCS AE Compliance Verification Procedure The following procedure should be applied to all PCS AE: Compliance Functional Group Capabilities Data Sheet Verification Test: Is a properly formatted SoC data sheet supplied with product? Pass Criteria: A properly formatted SoC data sheet, as specified in 10.3 is provided with the product. The Product + Version fields uniquely identify the product. At least one FG is claimed (i.e., the engine declares to belong to at least one FG as specified in this Standard). All FG capabilities for each FG claimed in the Functional Group field are listed as defined in 9, and the requirement field matches that provided for each capability in 9. For each capability listed as required, it must also be supported (i.e., if Requirement = Y, then Supported = Y ). For each capability listed as conditional, the conditions, defined in 9, must be met. For each capability listed as optional (i.e., not required), a declaration of whether the requirement is supported must be made (i.e., the Supported field for this requirement must be filled in) Condition of Compliance A PCS AE can be considered to be compliant with this Standard if and only if it passes all of the compliance tests for the AE in This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 42 Doc. 5716

49 RELATED INFORMATION 1 PCS EVENT NOTIFICATION AND DATA COLLECTION USING INTERFACE A NOTICE: This Related Information is not an official part of E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on November 21, R1-1 Overview R1-1.1 PCS Deployment R It is expected in the future that PCS based applications may collect events and data from equipment that have implemented Interface A, also referenced as equipment data acquisition (EDA). In order to meet this requirement a mapping between PCS messages that specify PCS job flow and equipment data collection with Interface A will be needed. This Related Information section presents a Use Case which demonstrates an approach that will accomplish this requirement as well as sample PCS message formats. R1-2 Implementation Approach Example R1-2.1 FD AE/EDA Connectivity Example R The block diagram presented below (Figure R1-1) illustrates one example of an implementation approach that provides connectivity between a FD AE and equipment with an EDA Port in support of event and data collection. Client Application (outside world) FD AE EDA Connector Protocol #2 Connector EDA Port Equipment EDA Port Equipment Port Data Source Figure R1-1 Example Architecture Block Diagram (other implementation architectures are allowed) R1-2.2 Client Application R The Client Application initiates FD AE action by requesting the start of a PCS job. The FD AE will provide events and data back to the Client Application based on the data source specified (global parameter sent with PCSStartJob request). The FD AE will continue to execute the job until a request is received to end the PCS job. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 43 Doc. 5716

50 R1-2.3 FD AE R The FD AE is responsible for providing PCS FD capabilities by executing PCS FD jobs. It receives requests from the Client Application and then sends out messages to collect data from specified equipment, or other fab applications as appropriate or necessary to execute the specified job. R Messages received from the Client Application ideally are E133 compliant. If not then an application programming interface (API) converter will be necessary. The API converter will map client messages received to the appropriate E133 message format and map E133 FD AE response messages to the correct client format. R When processing a PCS job the FD AE will send messages to the EDA Connector which is responsible for the actual connectivity with the appropriate EDA equipment. As requested event and data is received from the equipment the EDA Connector will return the information to the FD AE. R1-2.4 EDA Connector R The EDA Connector will provide the connectivity between the equipment and FD AE. The EDA Connector can support multiple connections to equipment with an EDA Port and will manage the E134 messages sent to the equipment for enabling data collection. It may be part of the FD AE or implemented as a separate module. R The EDA Connector will use the data source specified in the start PCS job message to determine which data collection plans are to be activated and on which equipment. The data source may specify a pre-defined data collection plan or provide the information necessary to dynamically create, define and activate. R Data will continue to be received and forwarded to the FD AE until a request is received to deactivate a data collection plan. This request will be send from the FD AE upon receipt from the Client Application a message to end the PCS job. R1-2.5 Protocol Connector R While not part of EDA, the Protocol Connector illustrated in Figure R1-2 was included to show that the FD AE is not limited to one type of connection for data. R1-3 Message Flow R1-3.1 High Level View of PCS/EDA Interaction Example R Figure R1-2 below shows a high level message scenario for the implementation of FD AE with EDA enabled equipment. The message sequence is executed when the Client Application receives a trigger to start a PCS job for FD. R The Client Application will send to the FD AE a start request which in turn will cause the FD AE to enable data collection on the appropriate equipment. The FD AE will return data to the client application by linking the EDA event to a PCS message. For this example the return of EDA data results in a PCS Event and (after data analysis by the FD AE) a FD Fault message being sent to the Client. R It needs to be noted that at this time the two messages in italics are not in the E133 Standard but are planned for in a subsequent E133 ballot. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 44 Doc. 5716

51 FD Job Triggered Client Application PCSStartJobRequest PCSStartJobResponse PCSEvent FDFault FD AE with EDA EDA Data PCSEndJobRequest PCSEndJobResponse Figure R1-2 High Level Message Flow R1-3.2 PCS/EDA Message Scenario Example R Figure R1-3 is a sample message scenario which shows the message flow between the Client Application, FD AE with EDA Connector, and Equipment. Client Application FD AE with EDA Equipment EstablishSessionRequest PCSStartJobRequest PCSStartJobResponse PCSEvent FDFault PCSEndJobRequest PCSEndJobResponse EstablishSessionResponse MetadataRequest MetadataResponse DefinePlanRequest DefinePlanResponse ActivateRequest ActivateResponse NewDataNotification (DataReport) NewDataNotification (DataReport) DeactivateRequest DeactivateResponse Figure R1-3 PCS/EDA Message Scenario Example This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 45 Doc. 5716

52 R1-3.3 Session, Metadata Request/Response R The first four messages in Figure R1-3 show the establishment of a session with the EDA Port on the equipment and the request for Metadata. Although these are shown prior to the PCSStartJob request they may occur after that request and is dependent on the application. R1-3.4 PCSStartJob Request/Response R The PCSStartJob request is the trigger used by the FD AE to begin collecting data and returning it to the Client Application. In this example this data source in the message will be used by the FD AE to define and activate a data collection plan (DCP). Once the FD AE completes initial processing it notifies the Client Application as to the status of the request by sending back PCSStartJob response. R1-3.5 DCP Define, Activate Request/Response R The messages DefinePlan request and Activate request define the DCP to the equipment and tell the EDA Port to activate the plan. At that point any data reported by the equipment associated with a DCP will be returned to the FD AE. There can be multiple DCPs defined and the actual plans activated are dependent on the data source specified in the PCSStartJob request. Note: Although these messages are shown after the PCSStartJob request is issued they could be executed prior to this if the DCP was pre-defined. This is application dependent. R1-3.6 PCS Event/FDD Fault R The example message flow above shows data from the equipment (NewData notification) being tied to PCSEvent and FDDFault, where the FDDFault message would generally result from FD AE analysis of the data and determination that a fault notification should occur. The decision of data mapping to PCS message will be determined in this case by the FD AE. It needs to be noted that at this time the two messages in italics are not in the E133 Standard but are planned for in a subsequent E133 ballot. R1-4 Message Examples R1-4.1 PCSStartJob request Message R The following XML listing shows one method of sending the PCSStartJob request with an embedded data collection plan. In that the Standard does not define a format for DataSource it allows the PCS DCP definition (in italics) to be mapped closely to the format specified by E134 simplifying the mapping from PCS to EDA message formats. It is recommended by the PCS Task Force that DataSource be put in the global bin. In this PCS DCP there are three requests, two event requests and one trace request, the number of requests is dependent on the application. <AnalysisEngineDataSet xmlns:xsi=" xsi:nonamespaceschemalocation="c:\semidocs\taskforcestandards\apc\pcs.xsd"> <PCSJobID> pcsjob1 </PCSJobID> <PCSAETarget> <AEType>FDD</AEType> <AEInstance>0</AEInstance> <Instructions> <Instruction>PCSJobStart request</instruction> </Instructions> </PCSAETarget> <Globals> <Context> <DataSource> <PCSDataCollectionPlanType name="fdc_dcp_all_ok" description="fault Detection DCP One Standard Oper." > <Event request equipmentid="implantermodel" sourceid="implanter>ionimplanter>endstation" eventid="endofwafer" > <Parameter request This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 46 Doc. 5716

53 equipmentid="implantermodel" sourceid="implanter>ionimplanter>endstation>faradaycup" parametername="beamcurrent"/> <Parameter request equipmentid="implantermodel" sourceid="implanter>ionimplanter>endstation>faradaycup" parametername="bias"/> </Event request> <Event request equipmentid="implantermodel" sourceid="implanter" eventid="fdc_fault_on_endofwafer" > <Parameter request equipmentid="implantermodel" sourceid="implanter" parametername="fdc_data"/> <Parameter request equipmentid="implantermodel" sourceid="implanter" parametername="fdc_result"/> </Event request> <Trace request id="2" intervalinseconds="3" collectioncount="6" groupsize="2" > <Parameter request equipmentid="implantermodel" sourceid="implanter>ionimplanter>endstation>faradaycup" parametername="filamentcurrent" /> </Trace request> </PCSDataCollectionPlanType> </DataSource> <Context> </Globals> </AnalysisEngineDataSet> R1-4.2 PCSEvent Message R The following XML listing shows how data received from the equipment s EDA Port would be formatted and returned to the Client Application. In this example we show how a response to the Trace request may be represented. As the data is coming directly from the equipment it is the recommendation of the PCS Task Force that this information be put into the ModuleData Bin. In that the Standard does not specify a specific format for data returned the reporting of information closely maps to the EDA message representation (in italics). Note this message is not in the E133 Standard but is planned for inclusion in a subsequent E133 ballot. <AnalysisEngineDataSet xmlns:xsi=" xsi:nonamespaceschemalocation="c:\semidocs\taskforcestandards\apc\pcs.xsd"> <PCSJobID> pcsjob1 </PCSJobID> <PCSAETarget> <AEType>FDD</AEType> <AEInstance>0</AEInstance> <Instructions> <Instruction>PCSEvent</Instruction> </Instructions> </PCSAETarget> <ModuleData> <Context> <DCR reporttime=" t14:23: :00" equipmentid="implantermodel" This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 47 Doc. 5716

54 planname="fdc_dcp_all_ok"> <TraceReport traceid="2" /> </DCR> </Context> <Data reporttime=" t14:23: :00"> <TR collectiontime=" t14:22: :00"> <PV> <F8>1.1</F8> </PV> </TR> <TR collectiontime=" t14:23: :00"> <PV> <F8>1.1</F8> </PV> </TR> </Data> </ModuleData> </AnalysisEngineDataSet> R1-4.3 FDDFault Message R The following XML listing shows how data received from an EDA Port would be formatted and returned to the Client Application. In this example we show how a response to the Event request may be represented. For this example we have assumed that calculations have been done on the data received at the equipment level so this data is mapped to the Calculated Output Bin. In that the Standard does not specify a specific format for data returned the reporting of information closely maps to the EDA message representation (in italics). Note at this message is not in the E133 Standard but is planned for in a subsequent E133 ballot. <AnalysisEngineDataSet xmlns:xsi=" xsi:nonamespaceschemalocation="c:\semidocs\taskforcestandards\apc\pcs.xsd"> <PCSJobID> pcsjob1 </PCSJobID> <PCSAETarget> <AEType>FDD</AEType> <AEInstance>0</AEInstance> <Instructions> <Instruction>FDDFault</Instruction> </Instructions> </PCSAETarget> <CalculatedOutputs> <Context> <DCR reporttime=" t14:23: :00" equipmentid="implantermodel" planname="fdc_dcp_all_ok"> <EventReport sourceid="implanter" eventid="fdc_fault_on_endofwafer" /> </DCR> </Context> <Data> <eventtime=" t14:23: :00"> <PV> <F8> </F8> </PV> <PV> <F8> </F8> </PV> </Data> </CalculatedOutputs> </AnalysisEngineDataSet> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 48 Doc. 5716

55 RELATED INFORMATION 2 PCS W2W CONTROL NOTICE: This Related Information is not an official part of E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on September 4, R2-1 Overview R2-1.1 PCS W2W Control Deployment R E133 provides documentation for R2R control communication. W2W control (as defined in E133) is an important type of R2R control. This Related Information section illustrates how the PCS standard communication capabilities could be leveraged to coordinate inside equipment and outside equipment PCS control capabilities to support W2W control. R Coordination of inside equipment and outside equipment capabilities for R2R control is an important application that should be discussed. For example most equipment today supports GEM/SECS interface capabilities ( E30) and/or the emerging XML interface standards (e.g., E134). Coordination of inside equipment and outside equipment capabilities via communication scenarios should be described that could be implemented utilizing these protocols. This Related Information section illustrates how the PCS standard communication capabilities would be utilized in these scenarios. Note that the specific way in which these capabilities are implemented utilizing a specific equipment communication protocol (e.g., GEM/SECS) is outside the scope of this Related Information specification at this time. R2-2 Implementation Approach Example R2-2.1 High Level View R Figure R2-1 is a high level view of the control environment illustrating an equipment with an embedded W2W control capability and a configuration client. The configuration client could be a host computer. Equipment with W2W Control Configuration Client (Host) Figure R2-1 High Level View of W2W Control Environment R A typical W2W control scenario would involve the following steps: Discovery Determine what capabilities the W2W controller has. Enable Turn on or off available select capabilities as needed; the available capabilities are determined in the Discovery step. Control Invoke the W2W controller AE to provide control. Report Retrieve from the W2W controller AE or have the AE publish information related to the control process. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 49 Doc. 5716

56 R These steps would involve PCS communications between the equipment and the configuration client. These communications would be via PCS services. R2-2.2 Communication Scenarios R Introduction R The following communication scenarios identify the PCS services used to support steps associated with providing W2W control. R In the associated figures, parameters associated with a particular service that are required or otherwise pertinent to the description of the communication scenario are indicated inside the parenthesis following that service. The notation of inside a parenthesis following a service is used to indicate (additional) parameters, some of which may be necessary as specified in the E133 Standard. R Discovery Figure R2-2 illustrates the communication scenario to support the Discovery step. The PCSCapabilitiesDiscovery service is used and the Capabilities parameter is used in the response by the AE to indicate which capabilities (from the R2R control capabilities table) are supported, and which of these supported capabilities are currently enabled. Equipment Processing W2W Controller Configuration Client PCSCapabilitiesDiscoveryRequest( ) PCSCapabilitiesDiscoveryResponse(Capabilities, ) Equipment Figure R2-2 Discovery Communication Scenario R Enable Figure R2-3 illustrates the communication scenario to support the Enable step. The PCSCapabilitiesEnable service is used. The Capabilities parameter is used in the request to indicate which capabilities are to be enabled or disabled. The Capabilities parameter in the response indicated which Capabilities are enabled or disabled (as a result of the execution of this service). Note, of course that only capabilities that are supported (as determined through the Discovery service) should be requested to be enabled or disabled. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 50 Doc. 5716

57 Equipment Processing Equipment W2W Controller PCSEnableRequest(Capabilities, ) PCSEnableResponse(Capabilities, ) Configuration Client Figure R2-3 Enable Communication Scenario R Control Figure R2-4 illustrates the communication scenario to support the W2W Control step. The PCSAnalyze service is utilized by the entity requiring W2W control services (such as the equipment) to retrieve control advices from the W2W control AE; as with all R2R control PCS capabilities these control advices are communicated via the ControlAdvice parameter. The R2R control model is updated utilizing the PCSUpdateModel service. Note that the PCSUpdateModel service can be executed by the entity that is requiring the control services, or by an outside agent, such as a host. The determination of which agent is managing this service is implementation dependent. For example it could be dependent on which agent is collecting the pre- and post-metrology data associated with the process. Note that the PCSAnalyze and PCSUpdateModel services could be utilized multiple times to provide control across a number of wafers. In order to maintain synchronization between client, AE and entity requiring the W2W control services, the W2W control capabilities enabled via the Enable service would continue to be enabled until the configuration is changed via the execution of another Enable service request or an event that results in behavior outside the scope of the PCS standard (such as a power cycle or software reset). Equipment Processing W2W Controller Configuration Client PCSAnalyzeRequest( ) PCSAnalyzeResponse (ControlAdvice, ) PCSUpdateModelRequest( ) PCSUpdateModelRequest( ) PCSUpdateModelResponse( ) PCSUpdatemodelResponse( ) Equipment OR Figure R2-4 Control Communication Scenario R Notification Figures R2-5 and R2-6 illustrate the communication scenarios to support the Notification step. The PCSInformationLog service is utilized along with the R2R information parameter to communicate This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 51 Doc. 5716

58 information about a particular W2W control PCS Job, such as calculated Control Advice generated, Control Advice used, and process targets. The PCSJobID parameter indicates to which PCS job the information is associated. The PCSInformationLog service can be utilized as a Notification service (Figure R2-5), where the W2W control AE may provide notification at the end of every run (the behavior associated with when the W2W control AE provides this notification is beyond the scope of this Standard). The PCSInformationLog service can also be utilized as a Request service (Figure R2-6), where the requesting agent asks for W2W control information associated with a particular PCSJobID, and the W2W control AE provides that information in the response via the PCSInformationLog parameter. Equipment Processing W2W Controller R2RInformationLogNotification(R2RInformation, PCSJobID, ) Configuration Client Equipment Figure R2-5 Report Communication Scenario via Notification Service Equipment Processing W2W Controller Configuration Client R2RInformationLogRequest(PCSJobID, ) R2RInformationLogResponse(R2RInformation, PCSJobID, ) Equipment Figure R2-6 Report Communication Scenario via Request/Response Service This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 52 Doc. 5716

59 RELATED INFORMATION 3 PROPOSED PARAMETER DEFINITIONS FOR THE SPC AE TYPE MESSAGES NOTICE: This Related Information is not an official part of E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on May 13, R3-1 R3-1.1 With reference to of the Standard, the following Tables (SPC1 through SPC6) describe the proposed data type valuesdatacollections for the SPC input messages: Table R3-1, SPC1 summarizes the proposed data type valuesdatacollections supported by the PCSAnalyze Message defined in of the Standard. The DataItemsDataItemTypes DataChannel, Key and Aux are suggestions for implementers to provide a way to enable the SPC engine to target the sample to the right Channel, Chart and/or Storage and to have a way for grouping the samples. There should be sufficient Context DataItemDataItemType(s) to enable the engine to target the sample. Table R3-2, SPC2 summarizes the elements for the ParamDef DataItemDataItemTypes defined in Table R3-1, SPC1 and Table R3-3, SPC3. Table R3-3, SPC3 summarizes the proposed data type valuesdatacollections supported by the PCSStartJob Message defined in of the Standard. The PCSStartJob instruction will use all DataItemsDataItemTypes from Table R3-1, SPC1 besides the ParamDef DataItem.DataItemTypes. In addition to those the DataItemsDataItemTypes from Table R3-3, SPC3 below will be used. Table R3-4, SPC4 summarizes the data type valuesdatacollections supported by the PCSAddMoreData Message defined in of the Standard. Table R3-5, SPC5 summarizes the data type valuesdatacollections supported by the PCSEndJob Message defined in of the Standard. Table R3-6, SPC6 summarizes the data type valuesdatacollections supported by the PCSUpdateModel Message defined in of the Standard. R3-1.2 With reference to of the Standard, the following Tables (SPC7 SPC9) describe the proposed data type valuesdatacollections for the SPC output messages: Table R3-7, SPC7 summarizes the proposed data type valuesdatacollections supported by the PCSAnalyze and PCSEndJob Messages. Table R3-8, SPC8 summarizes the OOC indicators for out of control actions used by the OOC_nnn DataItemDataItemType defined in table SPC7. The corresponding Western Electric Company Rules (WECO) are mentioned where appropriate. Table R3-9, SPC9 summarizes additional StatusElement Codes supported by the PCSAnalyze and PCSEndJob Messages. R3-2 Definitions for the Date and Time Format R3-2.1 All DataItemsDataItemTypes which refer to a time format shall use the format of the attribute DateTime as defined in E148 in section Clock Object Attributes. R3-2.2 The E148 Standard specifies that the format is according to the ISO 8601:2004 used in the following way: where: YYYY is the four-digit year, YYY-MM-DDThh:mm:ss.sTZD, This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 53 Doc. 5716

60 MM is the two digit month (01 = January through 12 = December), DD is the two digit day of month (01 through 31), T is a special separator character used between date and time, hh are the two digits of hour (00 through 23), mm are the two digits of minute (00 through 59), ss are the two digits of second (00 through 59), is the separator which is followed by a one or more digits representing a fraction of a second, s is one or more digits representing a decimal fraction of a second, TZD is the time zone designator (+hh:mm or -hh:mm) Example: T19:20: :00 This is: year 2005, July 19 th, 7PM, 20 minutes, 34 seconds, 3 quarter of a second, minus five hours from Coordinated Universal Time (UTC), which is Eastern Standard Time. Table R3-1 SPC1 Example Data Type Values SupportedDataCollections supported by PCSAnalyze Input (Request) Message to an SPC AE BinCategoryCollection Type DataItem Name DataItem Value Description Role #1 Reqd Form Globals StartDate a UTC time The timestamp of the beginning of the measurement time sample period. This timestamp does not have to reflect the current date. It is allowed to be in the past. Globals FinishDate a UTC time The timestamp of the end of the measurement time sample period. This timestamp does not have to reflect the actual date. It is allowed to be in the past. AnalysisParameters DataChannel Example: Product_SPC, Process_SPC, Facility_SPC The unique identification of the data channel to group and store samples for a given SPC application. A channel can also be referred as an instance of a model being utilized for a specific analysis. Within this channel (which corresponds to a name space) the key values are unique and have a meaning. C N DateTime according to E148 format. C N DateTime according to E148 format. C N A string identifier which is known and administered in the SPC AE. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 54 Doc. 5716

61 BinCategoryCollection Type DataItem Name DataItem Value Description Role #1 Reqd Form AnalysisParameters Key[] Example: Equipment_ID= XYZ3, Recipe_ID = Etch05, Lot_ID = BA4711 AnalysisParameters Aux[] Example: Pos.X = 204, Pos.Y = 25 A given DataChannel has a collection of Key[] identifiers under which a sample is stored in the SPC AE. The key names reflect known identifiers from the application domain. Aux[] are auxiliary identifiers, which the SPC AE stores together with the sample data, but they are not used for associations and groupings. These could contain detailed information; e.g., the location on the wafer. AnalysisParameters Comment External comment attached to the sample and displayed in the charts. AnalysisParameters DistributionType Normal, Poisson etc. AnalysisParameters DisplayRule 0 never display charts 1 display affected charts always Distribution type to base limits. This is used to override the display rules for charts. C N Array of name/value pairs of sample key identifiers. C N Array of name/value pairs of auxiliary identifiers. C N String. C N String. D N Enumeration. 2 display affected charts only in the case that a violation was detected AnalysisParameters RejectFromEval If true, this sample is not taken into SPC evaluations, like a repeated measurement, or a false measurement. AnalysisParameters ParamDef An array of all parameters with their statistical values for this sample. D N Boolean. D Y An array of structured elements from table SPC2. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 55 Doc. 5716

62 Table R3-2 SPC2 Examples of Structured Elements for ParamDef DataItem Name Element Name #3 Element Value Examples Thickness, FT-Oxid Description Role #1 Reqd Form Parameter name. D Y String. Index 1, 2, Parameter index. D #2 Integer. Unit MeanUCL MeanCenter MeanLCL StdevUCL StdevCenter StdevLCL RangeUCL RangeCenter RangeLCL nm, in Parameter unit. D #2 String. Externally provided upper control limit for sample mean value. Externally provided center line (expectation value) of sample mean value. Externally provided lower control limit for sample mean value. Externally provided upper control limit for sample standard deviation. Externally provided center line (expectation value) for sample standard deviation. Externally provided lower control limit for sample standard deviation. Externally provided upper control limit of sample range. Externally provided center line (expectation value) of sample range. Externally provided lower control limit of sample range. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. D #2 Floating point real. SpecUpper Externally provided upper specification limit. D #2 Floating point real. SpecTarget Externally provided target value. D #2 Floating point real. SpecLower Externally provided lower specification limit. D #2 Floating point real. UpperSpecAvail LowerSpecAvail UpperAccAvail LowerAccAvail Upper specification limit exists for this parameter (if false one sided distribution). Lower specification limit exists for this parameter (if false one sided distribution). Upper acceptance limit exists for this parameter. Lower acceptance limit exists for this parameter. D #2 Boolean. D #2 Boolean. D #2 Boolean. D #2 Boolean. SampleSize 1.. n Sample size for this parameter. D #2 Integer. Stdev Standard deviation for this parameter. D #2 Floating point real. Mean Mean value for this parameter. D #2 Floating point real. Minimum Minimum value for this parameter. D #2 Floating point real. Maximum Maximum value for this parameter. D #2 Floating point real. Median Median value for this parameter. D #2 Floating point real. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections #2 Elements from this table can be required or not required in various combinations dependent on the actual SPC application. At least one element containing a statistical value must be present (e.g., Mean ). #3 The Element Name list provided here can be extended as necessary to support specific implementations. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 56 Doc. 5716

63 Table R3-3 SPC3 Examples of Additional Data Type Values Supportedadditional DataCollections supported by PCSStartJob Input (Request) Message for an SPC AE BinCategoryCollectio n Type DataItem Name DataItem Value Description Role #1 Reqd Form AnalysisParameters ParamDef An array of all parameter names and indexes. D Y An array of: the structured elements Name and Index from Table R2-2, SPC2. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections Table R3-4 SPC4 Example Data Type Values SupportedDataCollections supported by PCSAddMoreData Input Message for an SPC AE Collection TypeBinCategory DataItem Name DataItem Value Description Role #1 Reqd Form Globals RawDate a UTC time The timestamp of the raw value measurement. This timestamp does not have to reflect the actual date. It is allowed to be in the past. AnalysisParameters StoreFlag Boolean If true, raw values will be stored, otherwise only used for calculation. AnalysisParameters RawDataIndex 1.. n After the PCSStartJob message has occurred, multiple PCSAddMoreData messages for the given PCSJobID may occur. The value is the index (1.. n) of each successive message. Any PCSAddMoreData message out of the scope of a PCSStartJob and PCSEndJob is not allowed (will be omitted if sent). AnalysisParameters Comment External comment attached to the sample and displayed in the charts. AnalysisParameters FlagExternaly Boolean If true, this sample is not taken into SPC evaluations. AnalysisParameters RawValue_nnn Raw values for the associated parameters. nnn is replaced with the index number (001, 002, 003, ) of the corresponding parameter index from the previous PCSStartJob message. C N DateTime according to E148 format. C N Boolean. C Y Integer. C N String. C N Boolean. D Y Floating point real values. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 57 Doc. 5716

64 Table R3-5 SPC5 Example Data Type Values SupportedDataCollections supported by PCSEndJob Input (Request) Message to an SPC AE Collection TypeBinCategory DataItem Name DataItem Value Description Role #1 Reqd Form Globals FinishDate a UTC time The timestamp of the end of the sample period. This timestamp does not have to reflect the actual date. It is allowed to be in the past. AnalysisParameters DisplayRule 0 never display charts 1 display affected charts always 2 display affected charts only in the case that a violation was detected This is used to override the display rules for charts. C N DateTime according to E148 format. D N Integer. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections Table R3-6 SPC6 Example Data Type Values SupportedDataCollections supported by SPCUpdateModel Input (Request) Message to an SPC AE Collection TypeBinCategory DataItem Name DataItem Value Description Role #1 Reqd Form AnalysisParameters DataChannel A string identifier which is known and administered in the SPC AE. ProcessData Key Example: XYZ3, Etch05, BA4711 AnalysisParameters ParamDef Example: +0.7, 1.3 Same as in SPC1. C Y String. Same as in SPC1. C Y Array of name/value pairs of sample key identifiers. A minimum of 20 array elements should be supported. An array of all parameter names and new centering values D Y Array of the structured elements Name and Median from Table R2-2, SPC2. #1 Where, in the Role column D indicates data Data element and C indicates context. Context element to be used in DataCollections This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 58 Doc. 5716

65 Table R3-7 SPC7 Example Data Type Values SupportedDataCollections supported by PCSAnalyze and PCSEndJob Output (Response) Messages for an SPC AE which Indicates Success Collection TypeBinCategory Calculated Outputs OOC_nnn DataItem Name DataItem Value Description Role #1 Reqd Form {1, raw above upper spec, thickness } An array of out of control reasons which have occurred for this sample: each OOC_nnn (where nnn is from 001 to the highest OOC). These OOC_nnn codes may be composed of several western electric rule violations and additional violations. D Y A structure with three elements: OOC indicator (integer) from SPC8 below description (string) from Table SPC8 below ParamDef. Name (string): the name of the parameter of the OOC reason. #1 Where, in the Role column D indicates data Data element and C indicates contextcontext element to be used in DataCollections. Table R3-8 SPC8 An Example Mappingexample mapping of OOC Indicator Codes Used as Fields in Structure for DataItem ValuesDataCollections in Table R3-7, SPC7 OOC #2 Description WECO Reqd 0 Not out of control. Y 1 Raw value above upper given specification limit from input process. N 2 Raw value below lower given specification limit from input process. N 3 Mean value above upper control limit. N 4 Mean value below lower control limit. N 5 Standard deviation above upper control limit. N 6 Standard deviation below lower control limit. N 7 Range above upper control limit. N 8 Range below lower control limit. N 9 Significantly rising trend over the last n mean values. N 10 Significantly falling trend over the last n mean values. N 11 High run: last n mean values above center line. N 12 Low run: last n mean values below center line. N 13 N of M samples in zone A (upper). 2 out of the last 3 points above +2 sigma and below +3 sigma. 14 N of M samples in zone A (lower). 2 out of the last 3 points below 2 sigma and above 3 sigma. 15 N of M samples in zone A or B (upper). 4 out of the last 5 points above +1 sigma and below +3 sigma. 16 N of M samples in zone A or B (lower). 4 out of the last 5 points below 1 sigma and above 3 sigma. 17 N samples in zone C (upper and lower). 8 Consecutive Points on one Side of Control Line, below 1 Sigma Limit. 18 N samples rising in a row. Trend Rule: 6 in a row trending up. N N N N N N This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 59 Doc. 5716

66 OOC #2 Description WECO Reqd 19 N samples falling in a row. Trend Rule: 6 in a row trending down. 20 EWMA of mean values above upper control limit. N 21 EWMA of mean values below lower control limit. N 22 MA of mean values above upper control limit. N 23 MA of mean values below lower control limit. N 24 Moving standard deviation above upper control limits. N 25 Moving standard deviation below lower control limit. N #1 For an explanation of the Western Electric Company Rules (WECO) see, for example, the NIST/SEMATECH e-handbook of Statistical Methods; 7/18/2006. #2 This table can be extended as necessary to support additional control rules including manufacturer specific rules. N Table R3-9 SPC9 An Example of Additional StatusElement Codes Supported by PCSAnalyze and PCSEndJob Output (Response) Messages from an SPC AE Name Code Description Reqd SUCCESS #1 0 No error in that case some OOC_nnn DataItems from SPC7 may be included in the message. SAMPLE_OUT_OF_DATE NO_SPC_CHANNEL_FOUND NO_INTERNAL_SPECIFICATION_FOUND MULTIPLE_SPECIFICATIONS_FOUND PARAMETER_OUT_OF_ACCEPTANCE 32 Sample was not added to the time series of the corresponding channel, since the sample was older than the latest sample in the channel. There can be provisions, which still allow adding samples which are out of date. Such behavior can be enabled/disabled per user administration on the given SPC AE. 33 Sample could not be added to a channel inside SPC AE no SPC channel found. For further information on SPC channels, see table SPC1. 34 Sample could not be added to a channel inside SPC AE no internal specification found. 35 Sample could not be added to a channel inside SPC AE more than one specification found. 36 Parameter nnn out of acceptance sample was not accepted by SPC AE one of the raw values exceeded the acceptance (plausibility) limits nnn contained in Attribute Extension. #1 Identified as required in the generic PCS AE specification. No additional specification is provided here. Y N N N N N This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 60 Doc. 5716

67 ... RELATED INFORMATION 4 EXAMPLES FOR SPC APPLICATIONS AND AN EXAMPLE FOR XML IMPLEMENTATION NOTICE: This Related Information is not an official part of E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on May 13, R4-1 SPC Use Case Scenarios R4-1.1 Actors FICS The factory information and control system, represents any system in the factory automation environment that needs to make use of the SPC system. This could include manufacturing execution system (MES) equipment control software, PCS framework, or a combination of these items. SPC AE The statistical process control analysis engine. R4-1.2 Pre-Conditions For R3-1.3 The SPC AE is initialized and ready to receive PCS AnalysisEngineDataSet messages. For R3-1.4 The FICS system in question has established communication (if necessary) with the SPC AE. R4-1.3 SPC Use Case 1 Asynchronous, StartJob Message Contains No Data FICS SPC AE PCSStartJob(AEType, PCSJobID, StartDate, FinishDate, DataChannel, Key[], ParamDef[]) PCSStartJob(PCSJobID, Status) PCSAddMoreData(AEType, PCSJobID, RawDate, RawDataIndex, RawValue[]) PCSAddMoreData(AEType, PCSJobID, RawDate, RawDataIndex, RawValue[]) PCSAddMoreData(AEType, PCSJobID, RawDate, RawDataIndex, RawValue[]) PCSEndJob(AEType, PCSJobID, FinishDate) PCSEndJob(AEType, PCSJobID, Status, OOC[]) This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 61 Doc. 5716

68 R4-1.4 SPC Use Case 2 Synchronous, Request Contains Pre-Calculated Data FICS PCSAnalyze(AEType, PCSJobID, StartDate, FinishDate, DataChannel, Key[], ParamDef[]) PCSAnalyze(AEType, PCSJobID, Status, OOC[]) SPC AE R4-1.5 SPC Use Case 3 SPC Data Centering FICS SPC AE PCSUpdateModel(AEType, PCSJobID, DataChannel, Key[], ParamDef[]) PCSUpdateModel(AEType, PCSJobID, Status, OOC[]) R4-2 Example for SPC Applications R4-2.1 Amongst the many SPC uses cases, some generic ones are found very often. In this context, these use cases are referred to as SPC applications (see Table R4-1). Example SPC application keys for the selected SPC applications are given in Table R4-2. Any given PCS engine for SPC may implement any kind of SPC application and those given in Table R4-2 are just example cases. Table R4-1 Example SPC Applications Identification of the data channel (refer to Table R3-2, SPC2) SPC Application Description of related SPC application Product_SPC Product SPC Statistical control of product related metrics. This can be used for inline control, functional test or electrical test. Process_SPC Process SPC Statistical control of process related metrics to ensure process capabilities. This can be used for regular tool checks based for example on reference figures, simulated process results, test (non-product) wafers, or checks for defect density. Equipment_SPC Equipment SPC Statistical control of equipment related metrics not necessarily related directly to products produced with the equipment. Facility_SPC Facility SPC Statistical control of environmental or facility related metrics. This may include across-fab and nonfab areas. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 62 Doc. 5716

69 Table R4-2 Some Example SPC Application Keys SPC Application KeyValue Comment (see also International Standards Compilation of Terms) Product SPC Recipe_Sequence The name of the selected sequence of chamber level recipes. Recipe_ID ID of chamber level processing recipe. Lot_ID Product_ID Carrier_ID For packaging, ID of carrier holding packages. ProcessFlow ProcessStep Process SPC Equipment_ID Processing Tool. EquipmentModule Processing Subtool or Chamber ID. Recipe_ID (Process:The reference process performed on the processing tool). Equipment SPC Equipment_ID Processing Tool. EquipmentModule Processing Subtool or Chamber ID. Recipe_ID The reference process performed on the processing tool. Facility SPC Location Location description of production area. R4-3 Example for XML Implementation R4-3.1 The example below shows a prototypic XML implementation of the use case PCSAnalyze. <?xml version="1.0" encoding="utfutf-8"?> <AnalysesEngineDataSet> <PCSAnalyzeIn xmlns:xsi=" xmlns:xsd=" <AnalysisEngineDataSet> <PCSJobID> xmlns="urn:semi-org:xsd.e133.v1115.pcsae">12abcdef abcdef123456</pcsjobid> < <PCSAETargets xmlns="urn:semi-org:xsd.e133.v1115.pcsae"> <AEType>SPC</AEType> <AEAlgorithm>3OutOf5</AEAlgorithm> <AEInstance>1</AEInstance> <AEOrder>0</AEOrder> <Instructions> <Instruction>PCSAnalyze</Instruction> <Order>0</Order> <Status> <Source>Status source</source> <Code>1</Code> <Description>Status description</description> </Status> </Instructions> </PCSAETargets> <DataCollections xmlns="urn:semi-org:xsd.e133.v1115.pcsae"> <BinCategory>Globals</BinCategory> <Context> < <Name>StartDate></Name> <StartDate xmlns=""> t19:20: :00</startdate> < </Context> <Context> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 63 Doc. 5716

70 <Name>FinishDate></Name> <FinishDate xmlns=""> t19:21: :00</finishdate> < </Context> <Context> <Name>DataChannel></Name> <DataChannel xmlns="">product_spc</datachannel> < </Context> <Context> <Name>Key</Name> <List xmlns=""> <Key> <Name>Equipment_ID</Name> <Equipment_ID>XYZ3</Equipment_ID> </Key> <Key> <Name>Recipe_ID</Name> <Recipe_ID>Etch05</Recipe_ID> </Key> <Key> <Name>Lot_ID</Name> <Lot_ID>BA4711</Lot_ID > </Key> < </List> </Context> <Context> <Name>Aux</Name> <List xmlns=""> <Aux> <Name>Pos.X</Name> <Pos.X>204</Pos.X> </Aux> < </List> </Aux> <Aux> <Name>Pos.Y</Name> <Pos.Y>25</Pos.Y> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 64 Doc. 5716

71 </Context> <Context> <Name>Comment></Name> <Comment xmlns="">this is a demo</comment> < </Context> <Context> <Name>DistributionType></Name> <DistributionType xmlns="">normal</distributiontype> </Context> </Globals> <AETarget> <AEType>SPC</AEType> <AEInstance>1</AEInstance> <Instructions> <Instruction>PCSAnalyze</Instruction> </Instructions> </AETarget> < </DataCollections> <DataCollections xmlns="urn:semi-org:xsd.e133.v1115.pcsae"> <BinCategory>AnalysisParameters</BinCategory> <Data> < <Name>DisplayRule></Name> <DisplayRule xmlns="">2</displayrule> < </Data> <Data> <Name>RejectFromEval></Name> <RejectFromEval xmlns="">false</rejectfromeval> < </Data> <Data> <Name>ParamDef</Name> <List xmlns=""> <ParamDef> <Name>Name</Name> <Name>Thickness</Name> < </ParamDef> <ParamDef> <Name>Index>1</</Name> <Index>1</Index> </ParamDef> <ParamDef> <Name>Unit</Name> <Unit>nm</Unit> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 65 Doc. 5716

72 </ParamDef> <ParamDef> <Name>MeanUCL</Name> <MeanUCL>600</MeanUCL> </ParamDef> <ParamDef> <Name>MeanCenter</Name> <MeanCenter>500</MeanCenter> </ParamDef> <ParamDef> <Name>MeanLCL</Name> <MeanLCL>400</MeanLCL> </ParamDef> <ParamDef> <Name>StdevUCL</Name> <StdevUCL>12</StdevUCL> </ParamDef> <ParamDef> <Name>StdevCenter</Name> <StdevCenter>8</StdevCenter> </ParamDef> <ParamDef> <Name>StdevLCL</Name> <StdevLCL>2</StdevLCL> </ParamDef> <ParamDef> <Name>RangeUCL</Name> <RangeUCL>20</RangeUCL> </ParamDef> <ParamDef> <Name>RangeCenter</Name> <RangeCenter>17</RangeCenter> </ParamDef> <ParamDef> <Name>RangeLCL</Name> <RangeLCL>15</RangeLCL> </ParamDef> <ParamDef> <Name>SpecUpper</Name> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 66 Doc. 5716

73 <SpecUpper>550</SpecUpper> </ParamDef> <ParamDef> <Name>SpecTarget</Name> <SpecTarget>500</SpecTarget> </ParamDef> <ParamDef> <Name>SpecLower</Name> <SpecLower>450</SpecLower> </ParamDef> <ParamDef> <Name>UpperSpecAvail</Name> <UpperSpecAvail>true</UpperSpecAvail> </ParamDef> <ParamDef> <Name>LowerSpecAvail</Name> <LowerSpecAvail>true</LowerSpecAvail> </ParamDef> <ParamDef> <Name>UpperAccAvail</Name> <UpperAccAvail>true</UpperAccAvail> </ParamDef> <ParamDef> <Name>LowerAccAvail</Name> <LowerAccAvail>true</LowerAccAvail> </ParamDef> <ParamDef> <Name>SampleSize</Name> <SampleSize>5</SampleSize> </ParamDef> <ParamDef> <Name>Stdev</Name> <Stdev>8</Stdev> </ParamDef> <ParamDef> <Name>Mean</Name> <Mean>503</Mean> </ParamDef> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 67 Doc. 5716

74 <ParamDef> <Name>Minimum</Name> <Minimum>467</Minimum> </ParamDef> <ParamDef> <Name>Maximum</Name> <Maximum>523</Maximum> </ParamDef> <ParamDef> <Name>Median</Name> <Median>501</Median> </ParamDef> < </List> </Data> <Data> <Name>ParamDef</Name> <List xmlns=""> <ParamDef> <Name>Name</Name> <Name>FT-Oxid</Name> </ParamDef> <ParamDef> <Name>Index</Name> <Index>2</Index> </ParamDef> <ParamDef> <Name>Unit</Name> <Unit>um</Unit> </ParamDef> <ParamDef> <Name>MeanUCL</Name> <MeanUCL>2.5</MeanUCL> </ParamDef> <ParamDef> <Name>MeanCenter</Name> <MeanCenter>2</MeanCenter> </ParamDef> <ParamDef> <Name>MeanLCL</Name> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 68 Doc. 5716

75 <MeanLCL>0.5</MeanLCL> </ParamDef> <ParamDef> <Name>StdevUCL</Name> <StdevUCL>10</StdevUCL> </ParamDef> <ParamDef> <Name>StdevCenter</Name> <StdevCenter>6</StdevCenter> </ParamDef> <ParamDef> <Name>StdevLCL</Name> <StdevLCL>2</StdevLCL> </ParamDef> <ParamDef> <Name>RangeUCL</Name> <RangeUCL>10</RangeUCL> </ParamDef> <ParamDef> <Name>RangeCenter</Name> <RangeCenter>8</RangeCenter> </ParamDef> <ParamDef> <Name>RangeLCL</Name> <RangeLCL>5</RangeLCL> </ParamDef> <ParamDef> <Name>SpecUpper</Name> <SpecUpper>2.2</SpecUpper> <SpecTarget>1</ </ParamDef> <ParamDef> <Name>SpecTarget</Name> <SpecTarget>1</SpecTarget> </ParamDef> <ParamDef> <Name>SpecLower</Name> <SpecLower>0.75</SpecLower> </ParamDef> <ParamDef> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 69 Doc. 5716

76 <Name>UpperSpecAvail</Name> <UpperSpecAvail>true</UpperSpecAvail> </ParamDef> <ParamDef> <Name>LowerSpecAvail</Name> <LowerSpecAvail>true</LowerSpecAvail> </ParamDef> <ParamDef> <Name>UpperAccAvail</Name> <UpperAccAvail>true</UpperAccAvail> </ParamDef> <ParamDef> <Name>LowerAccAvail</Name> <LowerAccAvail>true</LowerAccAvail> </ParamDef> <ParamDef> <Name>SampleSize</Name> <SampleSize>10</SampleSize> </ParamDef> <ParamDef> <Name>Stdev</Name> <Stdev>6.78</Stdev> </ParamDef> <ParamDef> <Name>Mean</Name> <Mean>2.05</Mean> </ParamDef> <ParamDef> <Name>Minimum</Name> <Minimum>1.78</Minimum> </ParamDef> <ParamDef> <Name>Maximum</Name> <Maximum>2.19</Maximum> </ParamDef> <ParamDef> <Name>Median</Name> <Median>2.3</Median> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 70 Doc. 5716

77 </ParamDef> </List> </Data> </ </DataCollections> AnalysisParameters> </AnalysisEngineDataSet> </PCSAnalyzeIn> This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 71 Doc. 5716

78 RELATED INFORMATION 5 PCS EVENT NOTIFICATION AND DATA COLLECTION TO PROVIDE A VIRTUAL METROLOGY CAPABILITY NOTICE: This Related Information is not an official part of E133 and was derived from the work of the global Information & Control Technical Committee. This Related Information was approved for publication by full letter ballot procedures on December 24, R5-1 Overview R5-1.1 PCS Deployment R Virtual metrology (VM) is defined as the technology of prediction of post process metrology variables (either measurable or nonmeasurable) using process and wafer state information that could include upstream metrology and/or sensor data. 5 R PCS based applications can be used to help realize VM systems. An example of how a VM system fits alongside other common PCS and nonpcs applications in a semiconductor fab is shown in Figure R5-1. As the VM system is a software system, interaction with the VM system should be via interface B capabilities (such as those defined in E133). R VM systems utilize process and wafer state information as input to the prediction capability. This information could come from a number of sources including data collected directly from the equipment as the processing is occurring (referred to here as trace data ), trace data stored in a database, or trace data processed by a capability such as PCS FD or SPC. VM systems commonly consume FD output from a process as a primary input source, though this input source is often augmented with other sources such as those mentioned above. R An example of the detail of a E133 compliant PCS system that could be used to realize a VM solution is shown in Figure R5-2. In this example the VM systems consume FD output as an input and thus require interaction with an FD AE. As noted above the VM system may consume inputs from other sources (e.g., dashed line in Figure R5-2); the PCS standard would only directly address interaction with PCS AEs. R2R control AEs can utilize VM output to provide improved capabilities. Thus a E133 compliant PCS system that will be used to help realize a VM capability should necessarily include both FD and R2R control AEs. R A high level view of typical integration implementations is shown in Figures R5-3 through R5-6; these figures will be explained in more detail later in this Related Information section. Standardized communications are shown to support (1) equipment/process data collection, (2) communication between PCS AE s, and (3) communication from a PCS AE to non-pcs entities. R Equipment/Process Data Collection Data collection of this type can utilize a number of Standards, most notably GEM/SECS ( E30) and EDA ( E132/ E134). An example of how GEM/SECS standardized communications can be used to support the data collection can be found in and Related Information Section A.4 of E30. An example of how EDA standardized communications can be used to support the data collection can be found in Related Information 1 of this Standard ( E133). R Communication Between PCS AEs This communication can utilize this PCS ( E133) Standard. This Standard defines the mechanism for PCS AEs to produce and consume messages in order to provide their AE capabilities. R Communication Between PCS AEs and Non-PCS Components This communication can utilize this PCS ( E133) Standard. This Standard defines the mechanism for PCS AEs to produce and consume messages in order to provide their AE capabilities. 5 For additional information on virtual metrology see: Aftab Khan, James Moyne and Dawn Tilbury Fab-wide Control Utilizing Virtual Metrology. (invited) IEEE Trans. on Semiconductor Manufacturing-Special Issue on Advanced Process Control (November 2007): pp This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 72 Doc. 5716

79 Figure R5-1 Example of a VM System as a Component of a Fab-Wide Software Architecture That Contain E133 Compliant PCS Components and NonPCS Components Figure R5-2 Example of a E133 Compliant PCS System That Could be Used to Realize a VM Solution (other implementation architectures are allowed; for example the VM system could consume data such as trace data directly from the data access layer ) R5-1.2 Virtual Metrology Implementation Example VM with Feedback to R2R Control System R The block diagram in Figure R5-3 can represent a typical process that utilizes both FD and R2R control AE capabilities. An information flow diagram describing how the solution could be realized is provided in Figure R5-4. For every wafer n being processed, FD data is collected. An FD AE provides FD data analysis output [v(n)] via E133 standard messaging. Separately metrology information, when available, y(k), is provided to the R2R control AE via E133 standard messaging. The R2R controller utilizes this actual metrology information to provide model and subsequent recipe updates u(n) via E133 standard messaging, usually at a frequency dictated by the frequency of metrology data feedback (e.g., lot to lot). This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 73 Doc. 5716

80 Figure R5-3 High Level View of Typical Process Utilizing Both FD and R2R Control AE Capabilities (other implementation architectures are allowed) Figure R5-4 Example of Information Flow for Typical Process Utilizing Both FD and R2R Control AE Capabilities (other implementation architectures are possible) R The block diagram presented in Figure R5-5 can represent an example of a VM solution to the system of Figures R5-3 and R5-4 that provides feedback to a R2R control system to enable enhanced R2R control capabilities such as W2W control. An information flow diagram describing how the solution could be realized is provided in Figure R5-6. For every wafer n being processed, FD data is collected. An FD AE provides FD data analysis output This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 74 Doc. 5716

81 (v(n)) via E133 standard messaging. The VM capability utilizes this information and provides a metrology prediction ŷ(n). This prediction is provided to the R2R controller for each wafer via E133 standard messaging thus providing the R2R control AE with W2W control capabilities. Actually metrology information, when available, y(k), is provided via E133 standard messaging to both the VM module and the R2R control AE for updating of the VM prediction model (diagonal line) and to provide more precise feedback information to the R2R controller for model updating. The R2R controller utilizes both the VM prediction and (as available) actual metrology information to provide W2W control model and subsequent recipe updates u(n) via E133 standard messaging. Figure R5-5 High Level View of Typical VM Integration Architecture Where the VM Solution is Collecting Data from the Equipment FD AE (other implementation architectures are allowed) Figure R5-6 Example of Information Flow for VM Associated with the Architecture of Figure R5-5 This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 75 Doc. 5716

82 Where the VM System is Providing Feedback to a R2R Control System (other implementation architectures are possible) R A high level depiction of information flow associated with VM implementation example of Figures R5-5 and R5-6 is provided in ladder diagram form in Figure R5-7. The entities involved in the information flow or the posts in the diagram are the equipment a FD AE, a VM system, a R2R control AE and a station controller. Trace data is provided from the equipment to the FD AE via either GEM/SECS ( E30, e.g., see Related Information section A.4) or EDA (e.g., E132, E134) communications during a process run or other period of time on the equipment. FD analysis is performed and FD outputs are sent to the VM system via E133 compliant messages (note that if the VM system is an integral part of the FD system as depicted in the example of Figure R5-5 then specification of the communications mechanism between the FD and VM components is beyond the scope of this Standard). The VM system uses this information to predict VM values. These values along with appropriate context information such as prediction quality are sent to the R2R control AE via E133 compliant messages. The R2R control AE uses this information to update R2R control models. At a later time, e.g., when the next wafer is ready for processing, the station controller requests a recipe advice from the R2R controller AE via E133 compliant messaging and communicates any parameter changes to the equipment via GEM/SECS ( E30, e.g., see Related Information section A.8) compliant messaging. Figure R5-7 Ladder Diagram Depiction of the Information of the VM Example of Figure R5-4 (other information flow scenarios are possible as described in R ) This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 76 Doc. 5716

83 R R2R control and FD AE s as well as the VM system can act as servers or clients depending on what task they are executing and how they are implemented. In the example implementation of R the FD and R2R control AE s as well as the VM system are depicted as operating independently to provide a VM solution with feedback for R2R control. Alternatively these components could all act as servers with information flow orchestrated by a master controller controlling all PCS AEs as well as the VM system. This master controller, for example, could be the strategy engine depicted in Figure R5-2. This master controller approach would also be E133 compliant as long as all messaging directed at achieving PCS capabilities from the PCS system are E133 compliant. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 77 Doc. 5716

84 E PROVISIONAL SPECIFICATION FOR XML MESSAGING FOR PROCESS CONTROL SYSTEM (PCS) This standard was technically approved by the global Information & Control Committee. This edition was approved for publication by the global Audits and Reviews Subcommittee on September 5, It was available at in October 2007 and on CD-ROM in November Originally published March Table of Contents 1 Purpose XML Implementation Mapping Scope Specification Scope Limitations Referenced Standards and Documents Standards OMG Standards W3C Standards Terminology Acronyms and Abbreviations Definitions Conventions Documenting XML Schema With Diagrams XML Schema Sample Implementation Overview DataCollection Point-to-point and Daisy Chain Communication Extending the XSD Generic AnalysisEngineDataSet Structure PCS Core Elements PCSJobIDType PCSAETargetType DataType StatusType StatusElementType AnalysisParametersType GlobalsType CalculatedOutputType LogMessagesType ModuleDataType ProcessDataType SubstrateDataType Request vs. Response AnalysisEngineDataSet Structure APPENDIX 1 PCS Aggregate XSD This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 78 Doc. 5716

85 1 Purpose 1.1 XML Implementation Mapping The purpose of this specification is to provide an implementation mapping of the E133 specification for an Automated Process Control System Interface. This specification does not provide a transport protocol for communication of XML messages between client and server (Analysis Engines). 2 Scope 2.1 Specification Scope This specification utilizes XML Schema definitions per W3C recommendations This specification provides XML Schema mapping of E133 PCS messages. NOTICE: This standard does not purport to address safety issues, if any, associated with its use. It is the responsibility of the users of this standard to establish appropriate safety and health practices and determine the applicability of regulatory or other limitations prior to use. 3 Limitations 3.1 This document represents an XML aggregation model for PCS messaging. Additional specification will be necessary to represent concepts in E133 that are not covered by the current model. 3.2 This is a provisional specification. In order to have the provisional status removed, the following items must be completed. E133 must have its provisional status removed. This specification must provide XML Schema mapping for the specific R2R, SPC, FD, FC, FP functional groups. 4 Referenced Standards and Documents NOTE 1: Definitions or descriptions of the following terms used in this specification may be found in the Compilation of Abbreviations and Acronyms, available on the web site, Standards E133 Provisional Specification for Automated Process Control Systems Interface 4.2 OMG Standards Unified Modeling Language (UML) Specification, Version 1.4, OMG Specification ; technology/documents/modeling_spec_catalog.htm 4.3 W3C Standards Extensible Markup Language (XML) 1.0 (Second Edition) W3C, 6 October 2000; REC-xml / Namespaces in XML W3C, 14 January 1999; XML Schema Part 0: Primer W3C, 2 May 2001; XML Schema Part 2: Datatypes W3C, 2 May 2001; XML Schema Part 0: Primer W3C, 2 May 2001; XML Path Language (Xpath) W3C, 16 November 1999; NOTICE: Unless otherwise indicated, all documents cited shall be the latest published versions. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 79 Doc. 5716

86 5 Terminology NOTE 2: Terminology is defined as acronyms, abbreviations and term definitions. 5.1 Abbreviations and Acronyms The following acronyms and abbreviations are unique to this standard UML Unified Modeling Language W3C World Wide Web Consortium XSD XML Schema Definition See also E133 for additional acronyms 5.2 Definitions No additional term definitions are unique to this standard. 6 Conventions 6.1 Documenting XML Schema with Diagrams This document provides graphical representations of the included XML Schema data type and element definitions. Although no standard graphical notation for XML Schema could be found, various XML tools have their own notation. This document will use the notation provided by XMLSpy from Altova Corporation Figure 1 shows a sample XML Schema diagram that will be used to provide a basis for explanation of the schema graphical notation used in the rest of the document. Figure 1 XML Schema Example Diagram In the diagram, rectangular boxes represent XML element definitions. Ownership or containment is read from right to left in the diagrams. In the sample diagram, ParentType contains Child1, Child2, Child 3, and Child 4. In turn, This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 80 Doc. 5716

87 Child2 contains Child2a, Child2b, and Child2c. The additional symbols (8-sided boxes) represent sequences or choices. See Table 1 for an explanation of these symbols. Table 1 Altova XMLSPY Schema Diagram Symbols Denotes a required ordered sequence of the right hand elements with a cardinality of one for each element. (sequence) Denotes an optional ordered sequence of the right hand elements with a cardinality of one for each element. (sequence) Denotes a required, but unordered, sequence of the right hand elements with a cardinality of one for each element. (all) Denotes a required choice of the right hand elements. Exactly one or two of the right hand elements must be present. (choice) Name Denotes an element. Name Denotes an element that contains parsed character data A graphic using a solid line is a required element; using a dashed line represents an optional element. Numbers or ranges in the lower right hand corner represent cardinality. The default cardinality is one To simplify a diagram or help focus on a particular aspect, detail may be hidden. The 8-sided symbols have a small square on the right end. If a minus sign - is in the box, then all detail is shown. If the box contains a plus sign +, then all detail to the right of that symbol is hidden. The example has no hidden detail The yellow (or gray if printed in monochrome) boxes indicate the use of other defined types. So, Child4 is of type Child4Type. Child4Type defines Child4a and Child4b. This detail may be hidden in the diagram. Object oriented inheritance is typically represented in XML as type extension. In Figure 1, ParentType extends Child1and2Type by adding a sequence that includes Child3 and Child Reading Figure 1 would yield the following additional information: 1. Child1and2Type is an ordered sequence of two items: Child2 and Child1. 2. Child1 contains an optional ordered sequence of Child1a, one or more Child1b, and (optionally) Child1c. 3. Child2 contains a choice of one or two of the following: Child2a, Child2b, and Child2c. 4. Child3 contains an unordered sequence of Child3a and Child3b. 6.2 XML Schema Sample The sample XML Schema for the example shown in Figure 1, is presented below. This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 81 Doc. 5716

88 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="parenttype"> <xs:complextype> <xs:complexcontent> <xs:extension base="child1and2type"> <xs:sequence> <xs:element name="child3"> <xs:complextype> <xs:all> <xs:element name="child3a"/> <xs:element name="child3b"/> </xs:all> </xs:complextype> </xs:element> <xs:element name="child4" type="child4type"/> </xs:sequence> </xs:extension> </xs:complexcontent> </xs:complextype> </xs:element> <xs:complextype name="child1and2type"> <xs:sequence> <xs:element name="child2"> <xs:complextype> <xs:choice maxoccurs="2"> <xs:element name="child2a"/> <xs:element name="child2b"/> <xs:element name="child2c"/> </xs:choice> </xs:complextype> </xs:element> <xs:element name="child1"> <xs:complextype> <xs:sequence> <xs:element name="child1a"/> <xs:element name="child1b" maxoccurs="unbounded"/> <xs:element name="child1c" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> <xs:complextype name="child4type"> <xs:sequence> <xs:element name="child4a" type="xs:string"/> <xs:element name="child4b" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:schema> Figure 2 XML for Sample This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 82 Doc. 5716

89 7 Implementation Overview 7.1 DataCollection 7.1 The E133 specification suggests that an Element DataCollection exists with an attribute of BinCategory. To allow for XML validating parsers to work with the XSD and instance XML, the DataCollection element is not used. Instead, the name of the XSD overview The XSD is documented in the E133-1-V0717-PCSAE-Schema.xsd file. This file is the authoritative definition of E This document elaborates on the purpose and use of the structures defined in the E133-1-V0717-PCSAE- Schema.xsd file BinCategory is used as the element name. For example, we use: <Globals> <item1>123</item1> <item2>abc</item2> </Globals> Instead of: <DataCollection BinCategory= Globals > <item1>123</item1> <item2>abc</item2> </DataCollection> This allows the following to be enforced: Order using xs:sequence to ensure Globals is before ModuleData, etc. Children can be validated for structure and content. 7.2 Point-to-point and Daisy Chain Communication Point-to-point communication represents one client communicating to one server. In extending the XSD in this document, a closed form XSD can be defined for request and response XML instances Daisy chain communication is where one client communicates to one server, and that server communicates to an additional server, and so on and so forth. It is left to the field implementation to coordinate the XSDs that are passed from clients and servers and how data is passed through from upstream servers back to the client.the PCSAETargetType.AEOrder and the PCSAEInstructionType.Order fields are provided to coordinate the daisy chaining order between separate PCSAE services or within a single PCSAE service instance. 7.3 Extending the XSD This document does not provide a complete XSD form for use in a specific application. Instead, Data, Context and Extension elements are used as placeholders for additional structure to be implemented in the field For example, if SomeDataType within this schema has the following definition: Figure 3 Generic XML Schema Diagram for SomeDataType This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 83 Doc. 5716

90 7.3.3 The actual implementation of SomeDataType would add elements under Context and/or Data specific to that application such as: Figure 4 Application Specific XML Schema Diagram for SomeDataType SomeDataType now requires that <Context> and <Data> elements are present. It also requires specific child elements for <Context> and <Data> with specific data types in order. All instances of the Context, Data and Extension elements within this specification shall be modified in a similar manner Figure 5 Application Specific XML Schema for SomeDataType This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 84 Doc. 5716

91 8 Generic AnalysisEngineDataSet Structure 8.1 The following requirements define a generic AnalysisEngineDataSet. This XML Schema definition (XSD) can be used for validatation of any XML message for compliance to this specification. This XSD does not impose further restrictions required by functional group or requests and responses. AnalysisEngineDataSetType PCSJobID DataCollections 1..* PCSAETargets 1..* PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Instructions 1..* DataCollectionType Status 1..1 BinCategory Context 0..* DataItemType At least one of Context or data 0..* Data StatusElementType Source Code Description Extension 0..* PCSAEInstructionType Instruction Order Status * Extension Name Value DataItemType Name Value StatusElementType Code Source Description DataItemType Name Value Extension 0..* DataItemType Name Value Figure The AnalysisEngineDataSet has the following ordered child elements: This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 85 Doc. 5716

92 Element Name Type Min Occurs Max Occurs PCSJobID PCSJobIDType 0 1 PCSAETarget PCSAETargetType 0 Unbounded Status StatusType 0 1 Globals GlobalsType 0 1 AnalysisParametersDataC ollections AnalysisParametersTypeDataCol lectiontype 0 1 CalculatedOutputs CalculatedOutputType 0 1 LogMessages LogMessagesType 0 1 ModuleData ModuleDataType 0 1 ProcessData ProcessDataType 0 1 SubstrateData SubstrateDataType PCS Core Elements NOTE 3: The following defines the PCS core elements. The core elements may be extended by future versions of this document. 9.1 PCSJobIDType The PCSJobIDType is used to define the schema requirements for the PCSJobID element. The following is the definition: Type Restriction Base Enumerations xs:simpletype xs:string Not Applicable This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 86 Doc. 5716

93 9.2 PCSAETargetType PCSAETargetType PCSAETarget for PCS messages AnalysisEngineDataSetType PCSJobID DataCollections 1..* PCSAETargets 1..* PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Instructions 1..* DataCollectionType Status 1..1 BinCategory Context 0..* DataItemType At least one of Context or data 0..* Data StatusElementType Source Code Description Extension 0..* PCSAEInstructionType Instruction Order Status * Extension Name Value DataItemType Name Value StatusElementType Code Source Description Extension 0..* DataItemType Name Value DataItemType Name Value Figure The PCSAETargetType is used to define the schema requirements for ana PCSAETarget not associated with a functional group in the instance XML. Note that PCSAEType is an optional child element in the PCSAETarget element. Also, the. The Extension element is to be used to add additional information as child elements under this element. Element Name Type Model Min Occurs Max Occurs Enumerations PCSAETypeA EType xs:stringaetypeselect or NA 01 1 PCS, R2R, FDD, FCC, FPP, SPC, etc. AEAlgorithm xsd:string NA 1 1 NA AEInstance xsxsd:int NA 01 1 NA InstructionsAE Order xs:complexxsd:int xs:sequencena 1 1 NA Status StatusElementType NA 1 1 NA This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 87 Doc. 5716

94 Instruction xs:stringpcsaeinstruc tiontype NA 1 Unbounded NA Extension xs:complex xs:sequence 0 1 NA 9.3 DataType AnalysisEngineDataSetType PCSJobID DataCollections 1..* PCSAETargets 1..* PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Instructions 1..* DataCollectionType BinCategory Context 0..* DataItemType At least one of Context or data 0..* Data StatusElementType Source Code Description Status 1..1 Extension 0..* PCSAEInstructionType Instruction Order Status * Extension Name Value DataItemType Name Value StatusElementType Code Source Description Extension 0..* DataItemType Name Value DataItemType Name Value Figure The DataType is used to define a generic Data element containing the results from an analysis engine. This type is used for Context and Data elements. AdditionalThe structure of DataType allows for extension of the Value node to support additional child elements can be added for field implementation of specific applications. Element Name Type Model Min Occurs Max Occurs DataItem DataItemType Not Applicable StatusType This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 88 Doc. 5716

95 AnalysisEngineDataSetType PCSJobID DataCollections 1..* DataCollectionType BinCategory Context 0..* DataItemType Name Value At least one of Context or data 0..* Data PCSAETargets 1..* StatusElementType Source Code Description PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Status 1..1 Extension 0..* DataItemType Name Value Instructions 1..* PCSAEInstructionType Instruction Order Status 1..1 StatusElementType Code Source Description Extension 0..* 0..* Extension DataItemType Name Value DataItemType Name Value Figure The StatusType defines the Status attribute. Note that the StatusType is implemented as a XML element instead of an XML attribute. The StatusType is a xs:complextype with a xs:sequence model. The StatusType has the following ordered child elements: Element Name Type Model Min Occurs Max Occurs StatusElement StatusElementType NA 1 unbounded 9.5 StatusElementType This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 89 Doc. 5716

96 AnalysisEngineDataSetType PCSJobID DataCollections 1..* DataCollectionType BinCategory Context 0..* DataItemType Name Value At least one of Context or data 0..* Data PCSAETargets 1..* StatusElementType Source Code Description PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Status 1..1 Extension 0..* DataItemType Name Value Instructions 1..* PCSAEInstructionType Instruction Order Status 1..1 StatusElementType Code Source Description Extension 0..* 0..* Extension DataItemType Name Value DataItemType Name Value Figure The StatusElementType defines the StatusElement. Note that the StatusElement is implemented as a XML element instead of an XML attribute. The StatusElement is a xs:complextype with a xs:sequence model. The StatusElement has the following ordered child elements: Element Name Type Model Min Occurs Max Occurs Source xs:string NA 01 1 Code xs:int NA 1 1 Description xs:string NA 01 1 Extension DataItemTypexs:comple xtype xs:sequencena The Extension element is used by field implementations to add additional child elements. 9.6 AnalysisParametersType This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 90 Doc. 5716

97 AnalysisEngineDataSetType PCSJobID DataCollections 1..* DataCollectionType BinCategory Context 0..* DataItemType Name Value At least one of Context or data 0..* Data PCSAETargets 1..* StatusElementType Source Code Description PCSAETargetType AEType AEAlgorithm AEInstance AEOrder Status 1..1 Extension 0..* DataItemType Name Value Instructions 1..* PCSAEInstructionType Instruction Order Status 1..1 StatusElementType Code Source Description Extension 0..* 0..* Extension DataItemType Name Value DataItemType Name Value Figure The AnalysisParametersType definesdatacollectionsdefines the generic AnalysisParameters BinCategory. The AnalysisParametersType isdatacollectionsis a xs:complextype with a xs:sequence model and a cardinality minimum of 1 and maximum of 23 child elements. The AnalysisParametersType hasdatacollectionshas the following ordered child elements: Element Name Type Model Min Occurs Max Occurs BinCategoryConte xt BinCategoryTypeDataIt emtype NA 01 1 Data DataItemType NA GlobalsType Figure The GlobalsType defines the generic Globals BinCategory. The GlobalsType is a xs:complextype with a xs:sequence model and a cardinality minimum of 1 and maximum of 1 child elements. The GlobalsType has the following child element: Element Name Type Model Min Occurs Max Occurs Context DataItemType NA 1 1 This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 91 Doc. 5716

98 9.8 CalculatedOutputType Figure The CalculatedOutputType defines the generic CalculatedOutput BinCategory. The CalculatedOutputType is a xs:complextype with a xs:sequence model and a cardinality minimum of 1 and maximum of 2 child elements. For R2R control advise, the ControlAdvise element shall be used to return data. This element shall contain child elements that are to be field configured to meet the needs of the specific application. The CalculatedOutputType has the following ordered child elements: Element Name Type Model Min Occurs Max Occurs Context DataItemType NA 0 1 Data DataItemType NA 0 1 ControlAdvise DataItemType NA 0 1 This is a Draft Document of the 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 International Standards committee (document development) activity. All other reproduction and/or distribution without the prior written consent of is prohibited. Page 92 Doc. 5716