Standards Doc. Bank

SEMI International Standards
SEMI New Activity Report Form (SNARF)



Activity Number: 5003
SNARF for: Revisions to:
* SEMI E125, Specification for Equipment Self Description (EqSD)
* SEMI E128, Specification for XML Message Structures
* SEMI E132, Specification for Equipment Client Authentication and Authorization
* SEMI E134, Specification for Data Collection Management
For reliable messaging for EDA Standards



Originating Global Technical Committee: Information & Control
Originating Technical Committee Region: North America
Task Force in which work is to be carried out: Diagnostic Data Acquisition Task Force NA


1. Rationale: The current 0710 version of the EDA standards provides live data collection from manufacturing equipment to client software applications using SOAP/XML messages over HTTP. As the EDA standards have been adopted and utilized more broadly, two related problems have been realized.

1. The EDA standards do not provide any features like Spooling in the GEM standard; therefore any time there is a short, temporary network disruption, the live data being collected is permanently lost. When client software is collecting data 24 hours a day, 7 days a week, it is inevitable that some short network disruptions occur. For some EDA client software, this lost data is unacceptable. Since these disruptions typically last only up to about 10 minutes, there is a need to recover the live data for this short period of time. When network disruptions are longer than 10 minutes, the network disruption is not considered temporary and therefore becomes a different issue. There is a strong reluctance to duplicate the GEM Spooling feature which theoretically can preserve data over a long period of time.

2. The HTTP protocol does not guarantee that messages arrive at the client software in the same order that the server (equipment) published the data. In practice, it has been observed that when network traffic is very high, sometimes the live data arrives out of order. In order to analyze the data accurately, client software is required to sort the data based on the data timestamps. Sorting algorithms based on timestamps are CPU intensive. There is a need to either simplify the sorting or guarantee that messages arrive at the client software in the intended order.

Rate the Estimated Effect on the Industry
2: Major effect on an industry sector - identify the relevant sector

Rate the Estimated Technical Difficulty of the Activity
II: Some Difficulty - Disagreements on known requirements exist but developing consensus is possible

2. Scope:
a: Define the areas to be covered or addressed by this activity or document:
These issues are not unique to the EDA standards. The internet industry has already developed and standardized technology that seems to resolve these issues. In February of 2009, the industry approved WS-ReliableMessaging version 1.2 which “allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures”. It also includes a feature to assure that messages are delivered in order. WS-ReliableMessaging has already been widely accepted and adopted by the internet industry.

In 2009, the EDA standards adopted the SOAP 1.2, a prerequisite for using WS-ReliableMessaging. The DDA Task Force will determine whether or not WS-ReliableMessaging is appropriate for use with the EDA standards. If not, then alternative solutions will be investigated and pursued. Adopting WS-ReliableMessaging could require a revision to multiple SEMI standards including E125, E128, E132, and E134.


b: Expected result of activity
Revision to an existing Standard/Guideline

3. Projected Timetable for Completion:
a: General Milestones
a. Activity Start: 07/30/2010b. 1st Draft by: 12/01/2010
c. Preballot by: d. Technical Ballot by: 02/01/2011
e. Committee Approval By:04/01/2011

b: Activity Specific Milestones
a. Proof of Concept b. Acquisition of Resources:
c. Safety Checklist Completed



Safety Considerations:
The resulting document is expected NOT to be a Safety Guideline


Intellectual Property Considerations:
a. In complying with the standard or safety guideline to be developed, the use of patented technology or a copyrighted item(s) is NOT required
b. The body of the standard and any appendices or related information sections will NOT include copyrighted material

Comments, Special Circumstances: None.

Approval: Activity approved by Committee/GCS on July 14, 2010