Semiconductor Equipment and Materials International

3081 Zanker Road

San Jose, CA 95134-2127

Phone:408.943.6900 Fax: 408.943.7943

hb khghgh1000A4729

Background Statement for SEMI Draft Document 4729

REVISIONS TO:

SEMI E125-0308 SPECIFICATION FOR EQUIPMENT SELF DESCRIPTION,

SEMI E125.1-0308 SPECIFICATION FOR SOAP BINDING FOR EQUIPMENT SELF DESCRIPTION,

SEMI E134-0308 SPECIFICATION FOR DATA COLLECTION MANAGEMENT,

SEMI E134.1-0308 SPECIFICATION FOR SOAP BINDING OF DATA COLLECTION MANAGEMENT, AND

SEMI E138-0309 XML SEMICONDUCTOR COMMON COMPONENTS

Note: This background statement is not part of the balloted item. It is provided solely to assist the recipient in reaching an informed decision based on the rationale of the activity that preceded the creation of this document.

Note: Recipients of this document are invited to submit, with their comments, notification of any relevant patented technology or copyrighted items of which they are aware and to provide supporting documentation. In this context, “patented technology” is defined as technology for which a patent has issued or has been applied for. In the latter case, only publicly available information on the contents of the patent application is to be provided.

Purpose

To propose additions, modifications and/or deletions to the following standards:

  • SEMI E125-0308, Specification for Equipment Self Description
  • SEMI E125.1-0308,Specification for SOAP Binding for Equipment Self Description
  • SEMI E134-0308,Specification for Data Collection Management
  • SEMI E134.1-0308,Specification for Soap Binding of Data Collection Management
  • SEMI E138-0309,XML Semiconductor Common Components

Line item specific background statements are found within each line item definition below.

Impact

The proposals in this document represent a change to the following documents that may have an impact on current implementations.

  • SEMI E125
  • SEMI E125.1
  • SEMI E134
  • SEMI E134.1
  • SEMI E138

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

Page 1Doc. 4729 SEMI

Semiconductor Equipment and Materials International

3081 Zanker Road

San Jose, CA 95134-2127

Phone:408.943.6900 Fax: 408.943.7943

hb khghgh1000A4729

Proposals

This section contains the lines item(s) for this ballot. The following is a summary list of line item(s) contained in this document.

  • Line item #1 – E125, E125.1, E134, E134.1, E138 Updates to the Data Collection Interface.

The results of this ballot will be discussed at the next North America I&C committee meeting on April 2, 2009 in conjunction with the NA Standards Spring 2009 meetings in Milpitas, CA.

SEMI Draft Document 4729

REVISIONS TO:

SEMI E125-0308 SPECIFICATION FOR EQUIPMENT SELF DESCRIPTION,

SEMI E125.1-0308 SPECIFICATION FOR SOAP BINDING FOR EQUIPMENT SELF DESCRIPTION,

SEMI E134-0308 SPECIFICATION FOR DATA COLLECTION MANAGEMENT,

SEMI E134.1-0308 SPECIFICATION FOR SOAP BINDING OF DATA COLLECTION MANAGEMENT, AND

SEMI E138-0309 XML SEMICONDUCTOR COMMON COMPONENTS

1 Line Item #1 – E125, E125.1, E134, E134.1, E138 Updates to the Data Collection Interface

1.1 Background

What is the problem being solved?

 The data collection interface represented by E125, E134, and their associated standards has been commercially implemented according to the standards versions available at the end of 2005. Work has been going on to complete updates to the initially implemented suit from 2005 to correct issues found, to streamline operational efficiency, and to reduce implementation cost. A number of ballots have been approved in the interim. This ballot proposal represents what is expected to be the last step of that process: the proposed update of E125 and E134.

As part of this process, the E138 Common Components specification was updated in 2008. Subsequently, an error was found that requires correction before this standard can be used as part of the updated data collection interface proposed here. Due to the dependencies on E138, in order to make that correction and do the updates to the E125 and E134 specifications in the same ballot cycle, they must be balloted together as a single line item. The advantage of this approach is that the voter can more easily see the combined improvements, rather than analyze separate line item proposals to understand how they will combine to modify the data collection standards. To ensure that the proposed changes are technically sound, the updated data collection interface has been prototyped and evaluated.

This proposal is a combined modification of the three standards and their sub-specifications (with XML/WSDL files).

What is the history of this issue and ballot?

 The movement to an updated set of data collection interface standards has been in progress for some time. Changes have been made to all the specifications as experience has shown us particular issues.

The issues/changes addressed by this proposal are presented for the first time.

Who will this effect? How? Why?

 This proposal affects all implementers of the data collection interface at the time that the industry determines to move implementations from the 2005 release of the standards to the current release. These changes touch many parts of the specification, but have been crafted to minimize the impact on current implementations wherever possible. However, these changes are not backward compatible. The “freeze” of the data collection standards was created to eliminate the need to constantly changes implementations from one ballot cycle to the next. The effect of this freeze is to accumulate the changes for implementation all at once, for the next freeze.

Is this a change to an existing solution, or, is it a new activity?

 This is a change to an existing set of standards.

Revision Control

This revision control records activity within the task force as well as formal submit and resubmit dates and results per SEMI. Entries have been made by the task force.

Date / Version / Name / Edits
09-Jan-2009 / 0.1 / Lance Rist / First version of the combined ballot proposal
02-Feb-2009 / 0.2 / Lance Rist / Full version of document for Task Force Review.
05-Feb-2009 / 1.0 / Lance Rist / Final version approved by DDA TF for ballot.

1.1.1 Proposal Structure

To make review by the voter as easy as possible, the changes proposed are presented “in situ”. A complete copy of each of the current specifications affected by this proposal is included with this proposal with proposed changes shown in a “redline” format. Blue underlined text represents proposed additions: example addition. Blue text with double strikeouts represents proposed deletions: example deletion.

Where diagrams have been altered, only the new diagram is included in the text. An editor’s note (in blue) is included below the caption of each changed figure noting the change(s) to the figure. For example “[Editor’s note: Figure 32 was replaced – added DCPDefined & DCPDeleted to DCPConsumer]”.

Original section, figure, and table numbers are maintained wherever possible. This helps the voter to compare the proposal document with the current standard file. When a new section is added (for example), the following section numbers are not changed. However, an editor’s note is included to indicate renumbering should be done by the SEMI editorial staff if the ballot is approved.

The intent of the proposal is that the changes to the data collection interface be as clear as possible. However, the proposed changes are represented only by the redline changes shown in the “specification change proposal” documents listed below and in the XML schema and WSDL files as they differ from the current standards versions of those files.

1.1.1.1 The following files are provided:

  • 4729 Ballot Proposal (this document) – This document outlines the purpose of the ballot proposal, describes the files that make up the ballot structure, and gives technical descriptions of the more significant technical changes that are proposed in this ballot.
  • Specification Change Proposals – These documents contain the proposed changes to the included SEMI specifications. At the beginning of each specification is a table listing the issues addressed by the proposed changes and referencing the section numbers affected by the solutions to those issues.
  • 4729 E125-0308 Change Proposal.pdf
  • 4729 E125-1-0308 Change Proposal.pdf
  • 4729 E134-0308 Change Proposal.pdf
  • 4729 E134-1-0308 Change Proposal.pdf
  • 4729 E138-0309 Change Proposal.pdf
  • Proposed New XML Schema and WSDL Files – The schema and WSDL files are the final ones to be included with the new specifications (if approved). These are provided together in a single zip file.
  • 4729 DDA TF Proposed Schema and WSDL Files.zip (contents covered in proposal below)

  • Overview of Schema and WSDL Changes – The schema and WSDL files listed above cannot include redline markings to highlight the changes and still be functional. The file listed below is included as an extension of this background section to show the changes made to the schema and WSDL files in redline format.
  • 4729 Schema-WSDL Change Overview.pdf

1.1.2 Explanation of Selected Proposed Changes

The changes proposed by this ballot are generally explained in tables included in the documents where the changes are shown (additions and deletions). These tables list the issues addressed, give brief descriptions, and reference the places in the document where changes are made to address the issues.

Most of the changes in this proposal are adequately explained in the tables mentioned above. However, a few of the changes need additional explanation to be clear to the voters. These explanations are presented in this section.

The explanations in this section and the issues tables should be considered an extension of the background for the ballot proposal.

1.1.2.1 Transient Parameters

In the current implementations of the data collection interface standards, there are some inconsistencies in the utility of parameters designated as “isTransient=True”.

There are two specific situations that result in end user complaints and inconsistencies between equipment data collection interface implementations that need to be eliminated:

  • Some equipment reject a DefinePlanRequest if it includes a TraceRequest with any transient parameter. Others allow it.
  • Some equipment reject a DefinePlanRequest if it includes an EventRequest with a transient parameter that is not in the event’s EventData. Others allow it.

The root of the problem is that a two-state “isTransient” attribute does not adequately cover the cases of when a parameter is valid. It can be more productively described using three designations:

  • A parameter that is valid only in conjunction with a particular event or set of events is said to be “Transient”. These parameters cannot be used for trace reporting or ad hoc request and only for the selected events where they are valid.
  • A parameter that is available for collection at all times (non-transient) and also contains a valid value at all times is said to be “Unrestricted”. These can be trusted to give useful values at all times for any form of data collection.
  • The third group is also available for collection at all times (non-transient), but is valid only under certain conditions. Such parameters are said to be “Restricted”. A restricted parameter might be related to a feature that may be deactivated by an equipment setting, or a measurement that is only valid when the process chamber is active. Rather than the momentary validity of Transient parameter, these tend to be valid for periods of time (often bracketed by events). These parameters can be depended upon to give valid values under the correct conditions and are often very useful for trace reporting during their valid periods.

This proposal changes the isTransient parameter from a Boolean to an enumeration and specifies how the three types of parameters can be used in line with the descriptions above.

1.1.2.2 DCPDefined and DCPDeleted Added to DCPConsumer Interface

A privileged client, such as one with all privileges, can use DataCollectionManager operation GetDefinedPlanIds to discover all data collection plans created by other clients as well as those created by itself. In order to implement a data collection system administration client or to share data collection plans between clients, it is important for the client to know when other clients are defining new data collection plans and deleting existing ones. However, when other clients define new data collection plans or delete existing data collection plans, the current standard does not provide any notification to other clients. To keep track of other client activity, a privileged client must be continuously polling the equipment using GetDefinedPlanIds. This creates unnecessary traffic on the network. This line item proposes new DCPDefined and DCPDeleted messages to the DCPConsumer interface in SEMI E134 to enable clients to receive asynchronous notification when new data collection plans are defined and deleted.

Additionally, the GetDefinedPlanIds operation currently provides only the planId, timeDefined, and definedBy attributes but does not provide the description. The planId itself typically does not provide enough descriptive information for clients to understand the purpose of a data collection plan. In order to get the description of the data collection plans, a client must use GetPlanDefinition and query the entire definition which includes the description. Once the client has queried the entire definition of the data collection plan, then the usefulness of the description is limited. If the data collection plan is very large this creates unnecessary traffic on the network. In order to maximize the usefulness of the newly proposed DCPDefined operation and to increase the usefulness of operation GetDefinedPlanIds the data collection plan “description” and “name” attributes are proposed to be added to the class DCPDefined.

1.1.2.3 Multi-client Trace Resolution

When the Data Collection Plan state model was originally designed, it was specified that one instance of the state model would exist for each data collection plan, no matter how many clients activate the DCP. The purpose for that was to allow the implementer to be more efficient in cases where multiple clients activate the DCP. Each event report, trace report, etc. need be created only once and sent to all clients who had activated the DCP.

This approach works well for event reports, but it has been the source of problems for trace data collection. Under the current definition, if a new client activates a DCP that is already active, then it joins the trace in progress. This means it might collect only a fraction of the data points specified in the DCP. In fact, for a non-cyclical trace that had already completed for the original client, the new client may never receive any trace reports at all (in fact, no notification of any kind). The members of the DDA TF find this to be unacceptable.

After discussing a number of options for updating the DCP state model, the DDA TF decided that the best solution is the simplest. This proposal changes the state model definition to require a separate instance of the state model for each client that activates the DCP. This change results is a great simplification of the state model and the transition definitions.

Consideration has been given for the implementers who still wish to achieve the original optimizations. It is still possible to create and send the same event report and exception messages to all clients of a DCP. In addition, a statement has been included that allows the equipment to delay the first sample of additional DCP clients for up to one interval so that the sampling can be merged for all clients.

1.1.2.4 Addition of Index for TraceResults

When a data collection client activates a Data Collection Plan including a TraceRequest, the client receives one CollectedData (the “TR” element in the schema) entry for each trace sample. The CollectedData are sent within the TraceReport data which in turn is encapsulated within the NewData operation on the DCPConsumer interface. One TraceReport can have one or more CollectedData. The TraceRequest includes a collectionCount attribute which determines the number of TraceResults samples that should be sent by the equipment.

]It is useful for the data collection client to know whether or not it has received all of the requested samples and whether or not samples were skipped or lost for whatever reason. The TraceResults element has a timestamp which can be used to estimate whether or not samples have been missed. However, in practice this proves to be only an estimate.

This proposal adds an index attribute to each CollectedData that will begin at one for the first trace result and increments for those that follow. Provision has been made to reset the index to one each time the trace is deactivated and then reactivated or when an integer overflow occurs.

When this was previously submitted in Cycle 4 2008, rejecting voters pointed out that 1) the initial starting value of the index had not been specified and 2) there was no accounting for integer rollover. This has been corrected by 1) specifying the first value to be 1 and 2) requiring integer rollover to reset the value to 1.

1.1.2.5 Exception Modification

The current exception definition includes “setData” and “clearData” parameters to be reported any time the exception report is sent. These parameters were intended to provide key context information to help explain the cause of the exception.

Unfortunately, in practice, implementers of the data collection interface almost never define setData or clearData. One reason for this is the way these parameters are defined. A typical equipment has thousands of exceptions defined in the metadata. The setData and clearData define separate new parameters for each exception. This results in many new parameters in the metadata, with much duplication.

This proposal replaces the setData and clearData with a new “exceptionData” construct. Rather than defining all new parameters, exceptionData contains a list of Parameter references. It can reference any parameter defined in the metadata. This change can reduce the total number of parameters defined for an equipment by thousands.