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

Document Number: 6804
SNARF for: Revision to Add a New Subordinate Standard: SPECIFICATION FOR SECS II PROTOCOL FOR SUBSTRATE MAPPING WITH ITEM TRANSFER to E142-0820: SPECIFICATION FOR SUBSTRATE MAPPING

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.2 – SPECIFICATION FOR SECS II PROTOCOL FOR SUBSTRATE
MAPPING defines how to use SECS-II messages for E142 Services (SEMI E39.1 Object Services for the MapDownload service and SEMI E5 Data Collection Services for the MapUpload service.)

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. SEMI E5 was recently updated to support Stream 21 Item Transfer SECS-II messages, which can be used to transfer data larger than what can be accommodated in a single SECS-II dataitem (roughly 16.7MB). As well, some implementers would find it simpler to use Stream 21 messages to transfer map data (compared to the different techniques of E39 Object Services and E5 Data Collection services mechanism described in SEMI E142.2).

Originally, an alternative method to transfer MapData with Stream 21 messages was going to be made to SEMI E142.2 as part of SNARF #6682. However, it was decided that trying to support the existing SECS-II transfer mechanisms plus Stream 21 messages in the same subordinate standard was too confusing, and a separate subordinate standard should be developed. That way implementations who are happy with the current transfer mechanisms can continue to support SEMI E142.2, and those implementations that want to support Stream 21 messages can support the new subordinate standard.

Since this is the first SEMI Standard to use Stream 21 messages, 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. They will be addressed in a separate Line Item Revision document to SEMI E5, and this new standard will use that proposed functionality.

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 SEMI E142 with a SECS-II interface

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 the new subordinate standard to use SECS-II Item Transfer for Substrate Maps
• Use Stream 21 Item Transfer Services for the MapDownload and MapUpload Service. Implementers can choose to use a single Stream 21 message with multiple ITEMPART data items (S21F5/F6), or multiple Stream 21 messages with a single ITEMPART data item. (multiple S21F17/F18 messages).
• Determine if the Group Map Download Service needs to be supported in the subordinate standard.
• Determine how the ITEMTYPE value will be used in this subordinate standard. One proposal for the map data item data is to start with “SEMI:MAPDATA-”, followed by the substrate type, all upper case. For example
o If the SubstrateType is ‘Wafer’, the ITEMTYPE is specified as ‘SEMI:MAPDATA-WAFER’
o If the SubstrateType is ‘Tray’, the ITEMTYPE is specified as ‘SEMI:MAPDATA-TRAY’
• Investigate specifying ITEMVERSION in the subordinate standard as 16-byte timestamp when item was last modified (this is the default value specified by SEMI E5). This value needs to be associated with the MapData downloaded so it is not lost. (i.e. want to know the MapData downloaded to the equipment matches the version uploaded). If the MapData is stored on the file system, one potential way to handle this is to update the file timestamp to match the timestamp specified in the ITEMVERSION field.
• Consider if a new configuration switch to specify which mechanism (SEMI E142.2 or the new subordinate standard) will be used to transfer maps.
• The subordinate standard will not require implementers to support both Stream 21 Item Transfer mechanisms (Single S21F5/F6 message or multiple S21F17/F18 messages). In the Compliance table for the subordinate standard, implementer reports which Stream 21 Item Transfer mechanisms they support
• The subordinate standard will use new functionality to be proposed by a separate Line Item Revision to SEMI E5.
o Report what Stream 21 Item Transfer mechanism it supports (Single S21F5/F6 message and/or multiple S21F17/F18 messages). This will be used to specify what mechanism the implementation uses to transfer the MapData.
o How many times to try resending an ItemPart message per S2F17/F18 if the receiver gets ITEMACK=32 (Retry). This will be used by implementations for transferring MapData with Stream 21.

b: Expected result of activity
New Subordinate Standard to an existing Standard or to a new Primary Standard to be developed concurrently with this new Subordinate Standard

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


Revision or addition of one or more Subordinate Standards to an existing Primary Standard

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:
took place between (put dates below) before approval by the GCS, or

Member Review Start Date; 4/15/2021
Member Review End Date: 4/29/2021

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