SEMI International Standards
Standards New Activity Report Form (SNARF)
Date Prepared: 11/04/2019Revised (if Applicable):

Document Number: 6597
SNARF for: Line Item Revision to SEMI E173-0415E: Specification for XML SECS-II Message Notation (SMN)

Originating Global Technical Committee: Information & Control
Originating TC Chapter: North America
Task Force (TF) in which work is to be carried out: GEM 300 Task Force
Note: If a new task force is needed, also submit a task force organization form (TFOF)

___________________________________________________________________________
1. Rationale:
a. Describe the need or problem addressed by this activity.
(Indicate the customer, what benefits they will receive, and if possible, quantify the impact on the return on investment [ROI] if the Document is implemented.)
1. SMN defines what information is logged for SECS messages. However, the examples listed in the Related Information (R1-2 - SECS-II Message Notation Logging Example) seem to contradict the requirements, and doesn’t include examples for all the possible protocol types (HSMS Data messages, HSMS Control messages, SECS-I). As well, including all the information listed for logging can be a time consuming operation result in large log files, impacting equipment performance. It would be nice to define a minimal set of attributes that can be logged and still be compliant to the standard.
2. Requirement E173.00-RQ-00005-00 (first one) specifies the HSMSMessage should be before the SECSMessage entry. It is not clear if it should appear immediately before the SECSMessage entry for the same SECS message, or if it could be spaced widely apart. As well, when sending any SECS message, is it better to log the SECS Message, and then the protocol data? (if so, then the HSMSMessage should be after the SECSMessage entry).

3. It is not clear what information specified with SMN logging maps to information defined by the transport protocols (HSMS, SECS-I). For example, what information in SEMI E37 HSMS does the replyBit correspond to?

There are errors in the Specification that make it hard to understand. For example, there are two E173.00-RQ-00005-00 requirements defined.



b. Estimate effect on industry.
2: Major effect on an industry sector - identify the relevant sector
Sector or Company Information: Anyone implementing or using SMN with GEM

c. Estimate technical difficulty of the activity.
II: Some Difficulty - Disagreements on known requirements exist but developing consensus is possible

___________________________________________________________________________
2. Scope:
a: Describe the technical areas to be covered or addressed by this Document development activity. For Subordinate Standards, list common concepts or criteria that the Subordinate Standard inherits from the Primary Standard, as well as differences from the Primary Standard:
This proposal suggests updating SEMI E173 as follows:
1) Consider defining a minimal logging mode so implementations can be mindful of equipment performance issues and still be compliant with this standard. Review attributes that are required when logging and ensure the specification identifies them consistently. For example, E173.00-RQ-00006-00 does not include the name and mnemonic attributes to be logged, yet Table 5 shows they should be logged.

2) Consider examples listed in Related Information R1-2 - SECS-II Message Notation Logging Example and ensure they are consistent with the standard. Look at adding other examples (for example, related to HSMS Control Messages and SECS-I Messages).

3) Consider Requirement E173.00-RQ-00005-00 (first one) and if it should be clarified that the HSMSMessage entry is immediately before the SECSMessage, or if this requirement should exist at all given the difference in sending and receiving messages.

4) Consider if all information specified for logging is clearly mapped to sources from SEMI E4, E5 and E37 For example,
· What information does the replyBit correspond to in HSMS (SEMI E37) and SECS-I (SEMI E4)?
· Clarify in the Standard that the txid maps to System Bytes
· Is there any information currently in the protocol that is not being logged that should be? (For example SessionID/DeviceID in the HSMS and SECS-I)

5) Fix errors in the specification. For example,
· There are two Requirements E173.00-RQ-00005-00 defined
· In sections 7.3.2.3 and 7.3.2.4, Element SECSIIMessage is referenced, but this does not exist in the specification (SECSIIMessage is referenced in the title of the Complementary file E173-0315-SECSIIMessageNotation-Schema.xsd – this should be SECSMessage instead)


The ballot will also include any minor editorial changes or technical errors identified during the ballot creation.

b: Expected result of activity
Line-item revision to an existing Standard or Safety Guideline

For a new Subordinate Standard, identify the Primary Standard here:


Modification of an existing part of Standard(s) or Safety Guideline(s) including Appendices, Complementary Files, and Supplementary Materials

For Standards, identify the Standard Subtype below:
Specification

Miscellaneous (describe below):

___________________________________________________________________________
3. Projected Timetable for Completion:

a: General Milestones
a. Activity Start: 11/06/2019b. 1st Draft by: 02/02/2020
c. (Optional) Informational Ballot by: d. Letter Ballot by: 02/02/2020
e. TC Chapter Approval By:07/20/2020

_____________________________________________________________________________
4. Liaisons with other Global Technical Committees/TC Chapters/Subcommittees/TFs:
a. List SEMI global technical committees, TC Chapters, subcommittees, or task forces in your or other Regions/Locales that should be kept informed regarding the progress of this activity. (Refer to SEMI Standards organization charts and global technical committee charters and scopes as needed.)


b. List any planned Type I Liaisons with external nonprofit organizations (e.g., SDO) that should receive Draft Documents from Standards staff for feedback during this activity and be notified when the Letter Ballot is issued (refer to Procedure Manual § 7):


c. Intercommittee Ballots:
will not be issued

Identify the recipient global technical committee(s):

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

NOTE FOR "to be a Safety Guideline": When all safety-related information is removed from the Document, the Document is NOT technically sound and complete - Refer to Section 15.1 of the Regulations for special procedures to be followed.

NOTE FOR "NOT to be a Safety Guideline": When all safety-related information is removed from the Document, the Document is still technically sound and complete.

___________________________________________________________________________
6. Intellectual Property Considerations:
Note: Both a: and b: below should be checked for Revision of existing Standard(s) and Safety Guideline(s).

a. For a new Standard or Safety Guideline and for any part to be modified or added in a Revision of published Standards and Safety Guidelines:
the use of patented technology is NOT required.

If "patented technology is intended to be included in the proposed Standard(s) or Safety Guideline(s) " is selected above, then also check one:


b. For Revision, Reapproval, Reinstatement, or Withdrawal of existing Standard(s) and Safety Guideline(s):
there is no known material patented technology necessary to use or implement the Standard(s) and Safety Guideline(s)

c. The body of the Document and any Appendices, Complementary Files, Related Information sections, or Various Materials that may or may not be a part of the Document by reference:
the incorporation of Copyrighted Item will NOT be required



NOTE FOR ‘the use of patented technology or the incorporation of Copyrighted Item(s) is NOT required’: If in the course of developing the Document, it is determined that the use of patented technology or Copyrighted Item(s) is necessary for the Document, the provisions of Regulations § 16 must be followed.

NOTE FOR ’will incorporate Copyrighted Item’: A copyright release letter must be obtained from the copyright owner prior to publication.

___________________________________________________________________________
7. Comments, Special Circumstances:
None.

__________________________________________________________________________
8. TC Member Review:
is not required for this SNARF.

Member Review Start Date; None.
Member Review End Date: None.

NOTE FOR ‘TC Member Review’ is required by the Regulations for a period of at least two weeks
before approval of a new, or a major revision of an existing, Standard or Safety Guideline. (Refer to Regulations ¶ 8.2.1)
__________________________________________________________________________

9. SNARF Approval Dates:
TC Chapter or GCS11/06/2019
Recorded in TC Minutes11/06/2019

__________________________________________________________________________

10. SNARF Extension Dates:
TC Chapter Extension Granted on
Extension Expires on