Background
As one of the North American DDA Task Force co-leaders, I am often asked when EDA Freeze 3 will be ready to implement. The SEMI DDA Task Force has been working on developing an EDA Freeze 3 standard for several years. This is an updated version of the data collection standard for manufacturing equipment. Unfortunately, due to many factors, this work has been slow to develop. For more information on a “freeze version” see SEMI standard E178 where official freeze versions are defined.
Status
To date the following ballots have been completed:
|
Standard (Ballot) |
Ballot Status |
| E138 (6336) | Published - 03/15/2019 |
| E120 (6434) | Published – 05/30/2019 |
| E145 (6436) | Published – 05/31/2019 |
| E178 (6300) | Published – 01/10/2020 |
| E179 (6803) | Published – 03/11/2022 |
| E132 (6719A) | Published – 04/29/2022 |
| E132.2 (6346F) | Published – 04/29/2022 |
| E125 (6718A) | Published – 04/22/2022 |
| E134 (6720A) | Final publication approval. Possibly 09/2022 but certainly by 10/2022. |
| E134.2 (6347A) | Final publication approval. Possibly 09/2022 but certainly by 10/2022. |
| E179 (6837) | Approved - In Publication Queue |
| E125.2 (6345A) | Final publication approval. Possibly 09/2022 but certainly by 10/2022. |
| E125 (6891) | Final publication approval. Possibly 09/2022 but certainly by 10/2022. |
| E179 (6892) | Approved - In Publication Queue |
| E120.2 (6908) | Final publication approval. Possibly 09/2022 but certainly by 10/2022. |
In the last summer 2022 meetings, three DDA task force ballots failed adjudication, 6927 (E125, E125.2), 6928 (E132, E132.2) and 6929 (E134, E134.2) due to procedural errors which violated SEMI regulations. This is primarily due to a long backlog of publications on previously approved specifications. Since then SEMI has been working very hard to catch up standard publication.
Test Session #1
The most important activity for the DDA task force was “vender test session #1” held on Thursday, July 14. An open invitation was made to all task force members to participate in an E132 test session. Anyone could submit a client and/or equipment server implemented with the current E132 and E179 specifications. Four companies came together and ran tests against each other’s software. Each participant will provide the task force with a list of issues in E132 and E179. This was a great opportunity to try the gRPC technology together and get a sense of what issues still need to be resolved before EDA Freeze 3 is complete.
Current Ballots
There are two ballots currently open for voting. Adjudication on the voting will occur during North America SEMI Fall meetings the second week of November at SEMI headquarters (attendees can also attend remotely).
Ballot 6947
Ballot 6997 is an update to SEMI E179, a foundation standard for EDA freeze 3 defining how gRPC is applied to the standards and other important definitions. This ballot has three line items.
1. Fix a defect in the definition of Arrays discovered by the Cimetrix Software Engineering team.
2. Clarification of the usage of the “one of” keyword
3. Address changes related to conformance to the SEMI style manual.
Ballot 6946
This ballot includes 5 line items, including work from a few contributors.
1. Clarify some definitions and concepts.
2. A complete rework of ACL passwords and security scenarios.
3. Rework EstablishSession and ChangeSessionEndpoint functionality.
4. Fix some issues discovered during the vender test session #1.
5. Clean up some spelling errors and the usage of .proto files.
The rework of ACL passwords and security was submitted by Cimetrix. In current EDA freeze 1 and freeze 2, there are no passwords where authentication only occurs when SSL is used. Passwords were introduced to E132 in a previous ballot, passed voting and were published. The intention is provide some security despite not using SSL. However, a security review of the current password implementation revealed some issues with the authentication. The ballot proposes the introduction of a challenge token which allows an EDA client to prove knowledge of the correct password, as outlined in this scenario:
|
Client Session |
Direction |
Equipment Server |
|
Client Session is assumed to know the equipmentId, clientId and plaintext ACL password. The equipmentId can be obtained using the InterfaceDiscovery interface. |
|
|
|
GetEquipmentInformationRequest |
→ |
|
|
|
|
Generate a challengeToken value associated with the equipmentId and clientId. |
|
|
← |
GetEquipmentInformationResponse |
|
Client Session uses aclEntrySalt and plaintext ACL password to generate the passwordHash. |
|
|
|
Client Session uses the challengeToken and passwordHash to generate a client challengePasswordHash
|
|
Equipment Server uses the challengeToken and passwordHash to generate its version of challengePasswordHash
|
|
EstablishSessionRequest (equipmentId, clientId, challengePasswordHash)
|
→ |
Client Session provided challengePasswordHash equals Equipment Server’s version challengePasswordHash Generate the sessionId. |
|
|
← |
EstablishSessionResponse |
At no point is an EDA client required to include the password or hashed password when establishing a session. To keep passwords secure, administrative EDA clients should use SSL when adding ACL entries. This increase in security is expected to allow for the adoption of EDA standards in a wider spectrum of applications.
Known Future Ballots
- An update to E164.
- Another update to E132, E125, and E134. A proposal was made to redefine the terms “client” and “consumer”. This week, the task force decided to go forward with this proposal.
- The adoption of gRPC allows EDA clients to receive NewData messages with a bi-directional (full duplex) connection. In EDA freeze 1 and 2, SOAP message over HTTP are only one-directional. This new bi-directional use case muddied the meaning of “client” and “consumer”. The proposal will clarify how a “client” is the entity that initiates communication with the “equipment server”. When configured to do so, an “equipment server” can initiate communication with a “consumer”. So there may or may not be a consumer present.
- EDA Freeze 3 also introduces three classifications of messages from the equipment server, heartbeat, operational, and notification messages. The heartbeat and operational are sent either to the client (in bi-directional mode), to the consumer or are disabled entirely. Notification messages can be sent to client and/or consumer.
- The task force plans to organize another test session open to anyone interested, where E132, E120, E125 and E134 can all be tested together. This had been planned for early 2023, but dates have not been proposed and these plans may slip. This test is expected to validate whether the published standards are ready. The task force leaders expect that some issues might be revealed and further changes to E125 and E134 may be required. If so, EDA freeze 3 might not be ready until spring 2024.
- An update to E178 Guide for EDA Freeze Version. This is the final step to officially declare the freeze 3 version.
To summarize, while the EDA Freeze 3 is not getting completed as quickly as most would like, the work is progressing. There aren’t any major hurdles at this time, but it lots of time and effort to complete the work that has already been planned.
