SEMI International Standards
Standards New Activity Report Form (SNARF)
Date Prepared: 03/30/2021Revised (if Applicable):

Document Number: 6802
SNARF for: Line Item Revision to SEMI E5-0220: SPECIFICATION FOR SEMI EQUIPMENT COMMUNICATIONS STANDARD 2 MESSAGE CONTENT (SECS-II)

Originating Global Technical Committee: Information & Control
Originating TC Chapter: North America
Task Force (TF) in which work is to be carried out: Advanced Backend Factory Integration
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.)
SEMI E142 was recently updated to allow for DeviceData information, which can result in more data to be transferred. This could lead to the map data to transfer to become too large to be stored in the SECS-II data item used for MapData in SEMI E142.2. A new Standard development activity is underway to define a new subordinate standard to support using Stream 21 Item Transfer SECS-II messages to transfer the map data.

SEMI E5 (which defines Stream 21 Item Transfer messages) needs to be updated to address gaps discovered in the functionality. These changes are independent of any SEMI Standard that uses Stream 21 functionality to transfer information. The gaps include:
• When sending item data with multiple S21F17 messages, the receiver can specify the sender to send the message again. The configuration to specify how many times the Equipment should try to resend the ItemPart before aborting the Stream 21 messages should be consistent between implementers.
• Stream 21 supports two different mechanism to transfer item data – a single Stream 21 with multiple ITEMPART dataitems, or multiple Stream 21 messages with a single ITEMPART data item. There should be a consistent way to report what mechanism an implementation supports for a given ITEMTYPE. (An implementation may choose to support different mechanism based on the ITEMTYPE being transferred, and there may ITEMTYPE values specified by different SEMI Standards)

Note – these items are being proposed in SEMI E5 so that we do not have different instances for every SEMI Standard that uses Stream 21, plus custom ones if the implementation uses Stream 21 to transfer other data types.


b. Estimate effect on industry.
2: Major effect on an industry sector - identify the relevant sector
Sector or Company Information: Anyone who implements uses Stream 21 SECS-II messages to transfer data

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:
The following items will be considered for Line Item Revisions to SEMI E5:

When using S21F17/F18 to send multiple Stream 21 messages to transfer data, the receiver can specify ITEMACK=32 (Retry) to have the sender re-send the ItemPart. Consider defining an Equipment Constant in SEMI E5 to specify how many times the sender should try to resend the ItemPart before aborting the Stream 21 messages. This setting would be applicable to equipment only, and not the host. Having an equipment constant defined in SEMI E5 will ensure consistency between different implementations.

The sender should be able to determine what Stream 21 transfer mechanisms the equipment supports for a given ITEMTYPE. (Do not want to use a transfer mechanism that the equipment does not support and get error messages). Consider defining a new Status Variable that reports what ITEMTYPE are supported by the implementation, and what Stream 21 transfer mechanisms are supported for it. Potentially a List of {ITEMTYPE, ItemTransferPreference} list elements, where the following ItemTransferPreference values are supported:

Synchronous = 1 – item data is transferred in a single Stream 21 message
Asynchronous = 2 – item data is transferred in multiple Stream 21 messages
Both = 3 – implementer’s choice (based on what they feel is the best Stream 21 transfer mechanism to use based on the item data to transfer and other conditions).

For simplicity, the SV would tell the Host what type of Stream 21 messages the Equipment could support for both sending and receiving, and the presumption is that the Host side can match. If the Host side is limited (for example, can only support Synchronous), the Equipment side should be configured to match (even though it might be capable of supporting both Synchronous and Asynchronous).

Investigate if the S21F17 description needs to be updated that each message transferring the item should have ItemPart dataitem set to the same data format. (So you can’t have the first S21F17 message with an ASCII ItemPart dataitem, the second S21F17 message with a Binary ItemPart dataitem, etc.)

Any other changes to address features, defects or issues with the Style Guide raised by Task Force members during the development and review of the proposed changes related to Stream
21 Item Transfer messages. Significant changes in scope still require a SNARF revision in
compliance with SEMI Regulations.

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: 03/01/2021b. 1st Draft by: 04/01/2021
c. (Optional) Informational Ballot by: d. Letter Ballot by: 05/01/2021
e. TC Chapter Approval By:11/01/2021

_____________________________________________________________________________
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.)
Information & Control – GEM300 Task Force

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):
None

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 GCS05/18/2021
Recorded in TC Minutes

__________________________________________________________________________

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