Industry News, Trends and Technology, and Standards Updates

If you’ve ever wondered how to implement the SEMI E30 GEM (Generic Equipment Model) communications standard in a PLC-based equipment control system, read on – this posting is for you!

What problem does the GEM OPC Connector Application solve?

The Cimetrix CIMConnect product provides a software library that equipment suppliers in a wide range of manufacturing industries use to integrate the GEM standard into their equipment control systems and associated applications. These applications are typically written in C#, VB.NET, or C++, which must run on a Microsoft Windows operating system.

This solution works great for equipment controllers that run on Windows, but what about equipment that does not use a Windows-based control system? In particular, some equipment controllers are PLC based and therefore cannot use the CIMConnect libraries directly. What then? The GEM OPC Connector application very effectively addresses this specific situation.

GEM OPC Connector Application Description

The screenshot below shows the GEM State Settings and current status of a GEM interface implemented by the GEM OPC Connector application. 

The GEM OPC Connector is provided as a CIMConnect sample application. Several of our customers have used it to implement a GEM interface for their PLC-based equipment applications. Since it runs on the same computer as CIMConnect, it requires a Windows operating system, but thankfully, most equipment types that have PLC-based controllers also have a Windows computer somewhere in the overall control system. For example, the HMIs (Human-Machine Interfaces) on much of this equipment run on Windows computers and use OPC UA (or OPC Classic) to share data between the HMI and PLC controllers. In this configuration, CIMConnect and the GEM OPC Connector application can be installed on the HMI Windows computer and connect to the same OPC UA server that the HMI uses (see the block diagram below). Of course, if the equipment controller does not already have a Windows computer, one would have to be added to the controller to use this solution.

How Does it Work?

The GEM OPC Connector application is both a CIMConnect application and an OPC client. GEM features are supported by CIMConnect and variables defined in the OPC server can be used to invoke method calls in CIMConnect or to receive notifications from CIMConnect. OPC variables can be used to:

1. Update status variables (SVIDs) and equipment constants (ECIDs)
2. Trigger collection events (CEIDs)
3. Set or Clear alarms.
4. Receive notification of remote commands from the host.
5. Invoke custom methods. For example, there are pre-defined methods to:
   1. Set the Offline/Online switch,
   2. Set the Local/Remote switch,
   3. Enable/Disable GEM communication with the host,
   4. Change the GEM communication settings.

As OPC UA tags  are updated by the PLCs or the HMI, the GEM OPC Connector monitors these tag value changes and calls the appropriate methods in CIMConnect depending on the function of each OPC UA tag.

Data updates and control signals can go in the opposite direction as well. For example, when the host sends a remote command to the equipment, the GEM OPC Connector handles the remote command by updating the OPC UA tags associated with that remote command’s parameters and setting a Boolean OPC UA tag value to “True” to notify the PLC-based control application that a remote command has been invoked by the host.

An XML configuration file defines the various types of links between OPC UA tags and GEM artifacts. Each link describes a specific function and provides the additional information needed to perform that function. The following sections give examples for several common link types.

Variable Links

Variable links are used to keep GEM variables and OPC UA variables in sync.  The links look like this in the XML file:

This example links the GEM EstablishCommTimeout equipment constant (VID = 4000) to an OPC UA tag = “Channel1.Device1.Standard ECs.EstablishCommTimeout”. Since equipment constants can be updated by the operator or by the host, the Direction attribute is “Both”.

Alarm Links

Alarm links are used to Set and Clear GEM alarms. Alarm links look like this in the XML file:

This example links a GEM alarm (ALID = 20045) to a Boolean OPC UA tag = “Channel1.Device1.Alarms.PMTempTooHigh”.  The PLC software sets this value when an alarm state changes. The GEM OPC Connector monitors this tag for any value changes, and calls the SetAlarm() or ClearAlarm() methods in CIMConnect to update the associated alarm state accordingly.

Event Links

Event links are used to trigger GEM collection events. Event links look like this in the XML file:

This example links a GEM collection event (CEID = 5000) to a Boolean OPC UA tag = “Channel1.Device1.Events.LoadLockDoorOpened”. The GEM OPC Connector monitors this tag for any value changes, and when the value changes from 0 to 1, it calls a method in CIMConnect to trigger the associated event.

Remote Command Links

Remote command links are used to notify the PLC equipment application of a remote command initiated by the host. Remote command links look like this in the XML file:

This example links the GEM “PP-SELECT” remote command to the Boolean OPC UA Tag = “Channel1.Device1.RemoteCommands.PP-SELECT”. Parameter values are optional. In this case there is a single parameter linked to OPC UA tag = “Channel1.Device1.RemoteCommands.PP-SELECT_PPID”. When the host sends the PP-SELECT remote command using S2F41 “Host Command Send”, the GEM OPC Connector handles the message as follows: if the value of the Processing State is such that the equipment can accept this remote command, the parameter value will be updated first, and then the PP-SELECT value will be set to ”True” to notify the PLC application that the remote command was invoked.

Method Links

Method links are used to invoke custom methods in the GEM OPC Connector itself. Several pre-defined methods are available, and custom methods can be added, but the latter requires source code changes to the GEM OPC Connector application. Method links look like this in the XML file:

This example links the method named “PPChange” to the Boolean OPC UA tag = “Channel1.Device1.Methods.PPChange”. Methods may have parameters, and in this case, there are two parameters linked to OPC UA tags: one for the Process Program name that has changed, and another to describe the type of change that was made (Create, Edit, or Delete). To invoke this method, the PLC should first update the parameter values and then change the PPChange OPC UA tag value from 0 to 1 to notify the GEM OPC Connector that the method has been invoked. The GEM OPC Connector then looks for the method by name and executes the code.  In this example, it would update the GEM data variables PPChangeName and PPChangeStatus and trigger the PPChange collection event.

Conclusion

This quick overview of the GEM OPC Connector application is intended to pique your interest in this capability and prompt you to contact us to find out how much more there is to be learned. If you think the GEM OPC Connector might be right for you, reach out to us by clicking the button below for a demo !

Background

At SEMI in North America, the Information & Control Committee meets three times per year; spring summer and fall. This year the spring meetings were held on April 3-5. The meetings include task forces with leaders from Cimetrix on the GEM 300, ABFI (Advanced Backend Factory Integration), GUI, DDA, CDS task forces as well as the committee meeting on the final day. This is a summary of what happened in the task forces I am highly involved in including GEM 300, ABFI and DDA. 

GEM 300 Task Force

After very busy previous GEM 300 task force meetings over the last couple of years, this is the first time in a long time that the GEM 300 task force did not have a major ballot up for voting. A major update to the GEM standard (SEMI E30), ballot 6572C, is awaiting publication at SEMI but was previously approved. In our task force meeting this week, we primarily discussed a new ballot proposed by a couple of active task force members regarding SEMI E172, SPECIFICATION FOR SECS EQUIPMENT DATA DICTIONARY (SEDD). The proposed new ballot would enhance the E172 SEDD file to add: 

1. alarm names
2. a new “well known” element to all collection events, data variables, status variables, equipment constants and alarms.
3. enhanced comments in the schema file
4. possibly a few schema changes regarding the handling of empty lists

The major new feature is the “well known” element. When an equipment supplier creates a GEM interface on the equipment and related GEM 300 standards, the implemented SEMI standards define required collection events, data variables, status variables, equipment constants and alarms which much be available. However, the actual name for each required item published in the GEM interface is not specified in the standard and is not a strict requirement. As a result, implementations of GEM and GEM 300 standards use different names for the same required item. For example, the GEM standard requires collection event “Control State REMOTE” to notify when the operator changes the equipment to remote control. One implementation might call this collection event “ControlStateRemote” while other implementations might call this collection event “Control State REMOTE” or “CntrlStateREMOTE”. All of these names are valid and GEM Compliant. The “well known” element in the E172 SEDD file would allow items in the GEM interface to be assigned a tag mapping it to a required item in a SEMI standard. Each SEMI standard in turn will need to be updated to define “well known” names to use in the E172 SEDD File. This new feature will allow GEM host software to have increased plug-and-play intelligence when connecting to a GEM interface to identify standard features. EDA (Equipment Data Acquisition) interfaces solved this problem in the SEMI E164 standard. The proposed “well known” names to be used in a GEM interface are expected to use the same names currently found in SEMI E164. Then SEMI E164 can be updated to reference the same “well known” names. This will be a lot of work to standardize, but will be a valuable feature. The upcoming GEM revision already defines how an SEDD file can be transmitted through the GEM interface using Stream 21 messages. 

Additionally, the task force discussed SEMI E87 and the new carrier ready to unload prediction. Prior to these discussions on April 3, I had thought that the state model was stabilized enough to implement. However, the work for ballot 6835 has been redefined to include additional work to modify the state model yet again. With this redefined scope, a new ballot number will be issued by SEMI. The task force is investigating changing the state model to predict transition to a final carrier accessing state (carrier complete or carrier stopped) instead of predicting transition to the carrier ready-to-unload state. The assumption is that the time between carrier completion and ready-to-unload states is fixed, and that it might be more useful for internal buffer equipment to predict carrier completion instead than ready-to-unload. Additionally, a few of the states are proposed to be changed. 

Both activities are expected to happen quickly and be submitted for SEMI voting cycle 5 in 2023. 

ABFI (Advanced Backend Factory Integration) Task Force

A new specification (ballot 6924, Specification for Equipment Management of Consumable and Durables) and subordinate standard (ballot 6925, Specification for SECS-II Protocol for Equipment Management of Consumable and Durables) were submitted for voter feedback since the committee last met in the fall. During the Spring meetings, the voter feedback was adjudicated. The ABFI Task Force and the I&C (Information & Control) Committee agreed to fail ballots 6924 and 6925. There were a few technical mistakes in the ballots that need to be reworked. Most of the feedback identified editorial mistakes or improvements in the ballot. Only a few minor technical issues need to be ironed out. I will be reworking both ballots, seeking task force member feedback and submitting them to the upcoming SEMI Cycle 5 voting. The voting feedback from the last cycle makes me optimistic that the ballots will soon pass and become new standards. 

The task force also spent time discussing and debating SEMI E142 substrate maps and how they might be used in specific traceability situations. 

DDA (Diagnostics Data Acquisition) Task Force

The DDA task force and Information & Control committee pass several ballots proposed by the DDA task force including:

• Ballot 7001 – Revision to SEMI E125-1022 Specification for Equipment Self Description (EqSD) and SEMI E125.2-1022 Specification for Protocol Buffers for Equipment Self Description (EqSD)
• Ballot 7002 – Revision to SEMI E132-0922 Specification for Equipment Client Authentication and Authorization and SEM E132.2-0422e Specification for Protocol Buffers for Equipment Client Authentication and Authorization (ECA)
• Ballot 7003 - Revision to SEMI E134-1022 Specification for Data Collection Management and SEMI E134.2-1022 Specification for Protocol Buffers of Data Collection Management
• Ballot 7017 - Line Item Revision To SEMI E120.2-0922: Specification For Protocol Buffers For Common Equipment Model (CEM)

All of these ballots are part of the effort to develop a “freeze 3” version of the EDA (Equipment Data Acquisition) standards, where the underling protocol will use gRPC and Protocol Buffer technology instead of the current SOAP and HTTP seen in EDA freeze versions 1 and 2. 

Ballot 7002 includes multiple editorial changes and technical changes. The technical changes will result in a Ratification ballot for SEMI Cycle 4 voting. If the Ratification ballot passes, then ballot 7002 will pass. But if it fails then ballot 7002 will also fail and have to be reworked. 

While handling the considerable work adjudicating all of the ballot negatives and comments, the task force considered some new cases. For example, the task force discussed the role of the Security Admin, and whether it should be used only for EDA interface management as designed today or whether it should also provide additional EDA diagnostics capabilities. 

For the first time in a very long time, no DDA ballots are proposed for the next voting cycle (other than the Ratification ballot). The task force co-leaders are hoping to let SEMI publication catch up and to plan another event where companies can test EDA against other implementations. The previous tests were limited to E132. Since then some major changes have been made to E132. The new tests would include testing E132, E125 and E134 together to ensure that the standards define compatible and useful EDA implementations. After these tests, it is expected that one more round of changes might be needed for E132, E125 and E134 to correct defects or missing features identified by members participating in this testing. 

Information & Control Committee

For the first time in a very long time, the committee meeting was unable to complete all planned business. To comply with SEMI regulations, the meeting was required to end on time with unfinished business. The unfinished business will be handled by the Information & Control GCS chairs. This group includes the co-chairs from the SEMI Information & Control Committees in North America, Japan, South Korea, Taiwan and China. 

Background

The North America Information & Control Committee (I&CC or NA I&CC) is comprised of several task forces including GEM 300, Diagnostic Data Acquisition (DDA), Advanced Backend Factory Integration (ABFI), Fab & Equipment Computer and Device Security (CDS), and Graphical User Interfaces (GUI). These task forces and the committee all met during the week of SEMICON West, July 11-13, 202. Not long ago, SEMI regulations were modified to allow TC Chapter (Committee) voting in virtual meetings; therefore, the standards activities continue to move forward. In-person task force participation was much higher than the last meetings, but remote participation also remains strong. This blog is a summary of the activities in each task force.

GEM 300 Task Force

Here is a summary of worldwide activities related to the GEM 300 task force as of the start of the GEM 300 task force meeting.

Three ballots were adjudicated during the GEM 300 task force meeting. The term “adjudication” means we review the voting and recommend handling of all negative votes and comments received to ultimately accept the ballot for publication or reject the ballot for rework. The recommendations by the task force are then finalized at the committee meeting. Usually, the task force recommendation is accepted by the committee, as was the case in all three ballots.

6916 E5

This ballot proposes to modify the E5 SECS-II standard and included the following minor changes:

• Allow data variable OperatorCommand to be type ASCII.
• Correct various typographical errors
• Remove the dependency between variables MDLN (equipment model number) and EqpSerialNum (equipment serial number).

This ballot passed after the only negative was withdrawn by the voter.

6572B E30

This ballot proposes to modify the GEM (E30) standard. It is a revision ballot, meaning the entire E30 standard is subject to review. This is the third time the ballot has been submitted. It is a major update to the GEM standard and includes the following changes:

• Process Program Management changes
  • The terms “recipe” and “process program” are currently used nearly interchangeably. The proposal is to use the term “process program” exclusively.
  • References to E42, large formatted and large process programs are moved out of the main standard and into the appendix.
  • Stream 21 messages are introduced for process program management, including both the single and multiple message techniques. This provides a simplified way for GEM interfaces to upload and download large process programs.
  • The entire process program management section is vastly reorganized to help implementers understand the available alternatives and the scenarios for each available alternative. New tables were introduced to compare and summarize implementation alternatives.
  • Collection event ‘Process Program Error’ is specifically listed as required, rather than just as an implied requirement.
• A series of new SECS-II messages are introduced including S2F51-S2F64. These are new capabilities to make a GEM interface more transparent.
• S5F7/F8 is added to the alarm management capability for similar reasons.
• Two new GEM documentation features are added and made available through the GEM interface using Stream 21 messages including PDF documentation and SEDD (see SEMI E172) documentation. This should make it easier to distribute GEM documentation and ensure that the right documentation is referenced.
• Two new equipment identification features are added, one to identify the equipment supplier and one to uniquely identify each individual equipment. This should make it easier to identify and track specific equipment on the factory floor.
• Some changes related to terminology are included. SEMI regulations recently were updated with a list of restricted bias terminology which are not allowed in any SEMI standards and a list of terms to avoid when possible.

This ballot failed due to a disagreement regarding a proposed change to the GEM control state model collection on transition 10 related to the host off-line state. The task force remains evenly divided on this issue; therefore, this change will be withdrawn from the next revision of this ballot.

I am optimistic that the 6572C revision of this ballot will pass voting with little controversy. This ballot has already been distributed to the task force for final review. Little controversy remains unless some voter raises a new issue.

6859 E116

Originally ballot 6859 intended to add significant new features to the E116 standard. However, the aggressive changes have been abandoned. Instead, this ballot is focused on making one change to E116. Currently the E116 specification implements collection events in a manner inconsistent with E30, E40, E87, E90, E94, E109, and E157. This E116 ballot failed. After further discussion in the task force, consensus on the proposed changes seems possible in the next voting cycle. The updated ballot 6859A has already been submitted for review by the task force.

DDA Task Force

The DDA task force has been and continues to update the Equipment Data Acquisition (EDA a.k.a. Interface A) standards with the goal to approve an EDA Freeze 3 set of standards based on gRPC technology. To date the following ballots have been completed:

During these 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. Discussions were held in several meetings in an attempt to find ways to help SEMI get caught up on publications. The delay in publication is partly due to the several large ballots that were backlogged when COVID activity prevented the committee from completing adjudication in remote or hybrid meetings.

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.

DDA Freeze 3 Plans

The DDA Task force plans an update to E125, E132, and E134 including changes from the recently failed ballots as well as topics raised in the test session. Due to the expanded scope, new ballot numbers will be issued. Additionally plans to update E164 are also moving forward. The biggest challenge for E164 will be converting the XML files into JSON files. Either JSON5 or JSONC will likely be used since comments are mandatory in the E164 complementary files which show how to create GEM 300 capable EDA equipment models.

ABFI Task Force

The Advanced Backend Factory Integration task force is actively working on two ballots.
One ballot is a minor update to the E142, the substrate mapping specification which facilitates traceability and other application where substrate, tray, feeder, and other information can be shared between a factory and equipment. The minor update will add additional substrate types so E142 substrate maps can be used in more applications.

Additionally, the task force is working on ballots 6924 and 6925. The 6924 specifications will define the management of Consumable and Durables on manufacturing equipment. Features include allowing the host to accept or reject newly mounted consumables and durables. Additionally, the equipment will be able to report on consumable and durable usage. While technically both can already be done, the specification establishes a standard way for the features to be implemented. The 6925 ballot maps 6924 for usage in a GEM interface. The plan is to submit the ballot for the next voting cycle.

GUI Task Force

The GUI task force continues to work on a major revision of the E95 specification for Human Interfaces for Semiconductor Equipment. In addition to updating the specification with changes in software development, this revision will establish requirements for the usage of human interfaces on equipment using devices with small screens. The task force seems to be gaining consensus of many topics and getting ready to submit the ballot for voting.

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged here.

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. Here are the community names for the task forces covered in this blog:

• GEM 300 Task Force - North America
• Diagnostic Data Acquisition Task Force - North America
• Fab & Equipment Computer and Device Security (CDS) Task Force – North America
• Advanced Backend Factory Integration (ABFI) Task Force – North America
• Graphical User Interfaces (GUI) Task Force - North America

In the late 1980s and early 1990’s the Semiconductor Equipment Communication Standard (SECS) was starting to gain traction. Back then it was based on RS232 serial communication defined by the SEMI E4 SECS-I Standard. Later, SECS-I was replaced by the SEMI E37 HSMS standard. The content of the messages was defined by the SEMI E5 SECS-II standard. At the time, that was all that was defined. It was a bit like the Wild West with each equipment vendor implementing SECS-II messages as they saw fit.

While it was cool to be able to connect to process or metrology equipment and collect data, specify the process, and monitor alarms, it was a big task to develop factory systems that interface to the equipment because each SECS-II interface was unique. One of the first tasks required when developing an interface was to perform an equipment characterization to understand and document the details of the SECS messages used by each equipment. The characterization report became the guide for developing the factory side interface to that particular piece of equipment.

Semiconductor factories were buying hundreds of pieces of equipment for their factories, and though there were usually multiple pieces of the same equipment, there were still many unique equipment interfaces in each factory. The factories had to develop unique interfaces for all the equipment they wanted to automate. This issue was a bit like the tail wagging the dog.

To change things so that each equipment interface wasn’t completely unique, semiconductor factories worked with SEMI to better define how the communication between factory control systems and equipment should work in the factory. In 1992 SEMI published the first version of the E30 standard – Specification for the Generic Equipment Model for Communications and Control of Manufacturing Equipment (GEM). This standard provided a stable base for both factories and equipment manufacturers to work from in developing equipment interfaces. Message usage and contents were consistent, state models were defined, and interface capabilities were well-documented.

Since that time, other equipment communication standards have been developed and approved for use in semiconductor manufacturing. The GEM300 standards for factory automation (E39, E40, E87, E90, E94, E116, E148, and E157) have made it possible to enable fully automated manufacturing. The EDA standards (E120, E125, E132, E134, and E164) make it possible to implement consistent, well-defined data collection.

Even though the SEMI standards are quite well-defined, they are only as good as the implementation on the equipment. Compliance testing is essential for both equipment manufacturers and factories to ensure the interfaces are compliant to the standards and function as defined. In the early days of GEM, compliance testing was an essential piece of factory acceptance of the equipment. Initially, there wasn’t a lot of experience with developing or using the equipment interfaces. This meant that we needed some way to test compliance to ensure the interfaces worked as expected. Even though GEM and GEM300 are now quite established, compliance testing is still important to ensure the communication interfaces will support the functionality needed in the factories.

Compliance testing for the EDA standards hasn't been as well-defined as it has been for GEM and GEM300. In 2011 the International SEMATECH Manufacturing Initiative (ISMI) published the ISMI Equipment Data Acquisition (EDA) Evaluation Method document which provided step-by-step instructions for testing and evaluating an EDA interface. Using that document, Cimetrix developed EDATester which automates the instructions defined in the Evaluation Method document. This automation allows testing that would normally take several days to be done in a few hours, or less.

Having standard, well-defined communication interfaces for semiconductor manufacturing equipment is important to automated manufacturing and data collection. The ability to test developed interfaces and assure that they are compliant with the SEMI standards is essential to successfully introducing the equipment into a semiconductor factory.

Cimetrix compliance test tools automate the testing process making the acceptance process smooth.

For the first time since the Fall of 2019, the SEMI North America Information & Control Committee (I&CC) was finally able to meet and conduct business online. Throughout all of 2020, the I&CC was not able to meet because SEMI regulations did not at that time allow voting in online meetings. Instead, only the task forces have been meeting. As a result, any passing ballots, unless super clean, had to wait for adjudication in the North America I&CC.

This year, prior to the I&CC meeting on April 1 and 2, all of the associated task forces also met as usual, including the GEM 300, Diagnostic Data Acquisition (DDA), and Advanced Backend Factory Integration (ABFI) task forces. Moreover, the I&CC was able to conduct all the unresolved business that had accumulated over the last year. During the committee meeting, the I&CC successfully used the SEMI Virtual Meeting (SVM) software which runs in an internet browser, allows each committee member to log in, and allows for official voting to take place during the meeting. The North America I&CC will meet again during the summer.

GEM 300 Task Force

In the GEM 300 task force, the primary activity was to officially redefine its charter and scope to match what it has already been doing for the last 20 years. Each SEMI task force defines a “Task Force Organization Force” document (aka TFOF) to establish its charter and scope. Somehow, the GEM 300 task force charter and scope were severely out of date.

In addition to this update, some changes to the E5 standard finally passed voting, pending some final approval. The E5 changes include several new messages and establish definitions for commonly used data collection terminology. The new messages complement the existing set of messages by allowing the host to query information about the current data collection setup. Currently, it is common for a host program to reset and redefine all data collection after first connecting to an equipment because there has been no way to query this information. With these new messages, the host will be able to query the setup and confirm that no data collection has changed while disconnected. Finally, it will be easier to test GEM interfaces with these new messages.

The task force already approved tasks to consider some major work to the GEM standard. The task force is also considering changes to the E116 standard, but there is some resistance to these changes. Here is a summary table of the GEM-related standards activity from across the globe.

DDA Task Force

In the Diagnostic Data Acquisition (DDA) task force (responsible for the EDA standards, aka Interface A), freeze 3 development is moving forward. All of the ballots still failed as expected. The number of remaining technical issues nevertheless has dwindled to just a handful. E132, E125, and especially E164 need the most work.

Following is a summary of the previously completed work.

And here is a summary of the work in progress.

All of the failed ballots will be reworked and resubmitted for voting. For many of these ballots, it will be the sixth time to go through the SEMI ballot procedure. Consensus is very nearly achieved, and the defects in the ballots have been identified and corrected. Additionally, there are plans to modify SEMI E179, the standard that defines how gRPC will be utilized. While testing EDA freeze 3, Cimetrix has identified two simple ways to modify the E179 protocol buffer files in order to reduce overhead. These and a few other changes will be proposed in a new ballot.

One of the last changes to the freeze 3 standards will be the introduction of passwords. In the current freeze 1 and freeze 2 versions, there are no passwords. Any client that knows a valid, unused Access Control List entry (ACL, the equivalent of a user name) can connect; therefore, there really isn’t any authentication unless using the SSL protocol with certificates. Passwords will enhance EDA security and facilitate EDA interface setup by allowing client applications to use the same ACL entry while defining a unique password to block other clients from using the same entry. The final E132 ballot will finalize the password feature.

The task force leaders are asking the voting members to raise any final issues before these ballots are submitted to SEMI to the next voting cycle so that we can approve these standards, give implementers a chance to experiment with EDA freeze 3, raise any serious issues that impede the implementation, and then propose the final changes which incorporate that feedback. Until a version of these standards is formally approved, it will be difficult to get concrete and widespread feedback on the new technology, which is a necessary precursor to its adoption and use.

ABFI Task Force

The Advanced Factory Integration task force passed more changes in E142 without controversy. The task force plans to create E142.4, another GEM implementation of E142, designed for larger wafer maps to allow for increased traceability possibilities. Additionally, the task force continues to make plans to develop an adoption matrix as a new standard to describe when GEM and GEM 300 standards should be adopted in backend equipment based on equipment features.

Background and Audience

Over the past several years, I have written numerous blog postings heralding the benefits of the SEMI Equipment Data Acquisition (EDA, also known as Interface A) standards, promoting their adoption by 300mm wafer fabs around the world, explaining how to develop robust purchase specs to ensure the interfaces delivered by the equipment suppliers meet the fab customers’ expectations, describing how the various components of the standards work together and the importance of the embedded equipment model, and finally explaining how to run compliance and performance tests on an EDA interface to validate its fitness for production use. The target audience for most of these postings has been the factory users, for they are the ones who increasingly depend on detailed equipment and process data to profitably run their enterprises.

By contrast, this posting is aimed at the equipment suppliers who are looking to increase the value of their product families by augmenting their hardware offerings with software capabilities that only they are uniquely qualified to provide.

This is not a new idea. Several major equipment suppliers have offered so-called “Equipment Engineering Systems (EES)” products as companions for their equipment over the years, providing applications like Fault Detection and Classification (FDC), production monitoring, maintenance management, local repositories for diagnostics and field support, and other capabilities that leveraged deep domain knowledge of the equipment. However, these systems necessarily relied on private interfaces to the equipment for their data, such as an additional network connection, direct access to the file system, or other mechanisms. And from the fab’s perspective, these constituted yet another piece of infrastructure to maintain.

Now there’s EDA: a key enabler for value-added equipment applications

Since the SEMI EDA standards are inherently multi-client, a single EDA interface can support not only the factory information and control systems that depend on equipment data, it can also provide whatever information a supplier-specific application may need as long this data is represented in the equipment metadata model. Since that model is designed by the equipment suppliers as a fundamental component of the EDA interface, they can choose to put as much information in these model as they want, possibly well beyond that required by the fab customers’ purchase specifications. In fact, these models could be used to implement the diagnostic logging capability that suppliers usually build into their equipment for their own use, but without requiring custom software to read and interpret that information. See the figure below for an example of such a configuration.

The EDA standards also include a provision for “built-in DCPs” (DCP = Data Collection Plan) which can be shipped with the equipment and protected from accidental deletion at the factory site. These DCPs could be crafted by the equipment supplier to directly feed whatever value-added applications the supplier chose to develop, whether these resided on a computer local to the equipment in the fab, on portable computers used by field service engineers to diagnose problems, or on remote cloud-based systems allowed to connect via secure EDA-defined URLs. This flexibility opens up a wide range of application types, from those that embed equipment-specific algorithms to generic Machine Learning frameworks… the possibilities are endless.

What all these approaches have in common is a standard EDA client capability that can establish a session with the equipment, activate Data Collection Plans, and receive the ensuing Data Reports. The EDAConnecter within the Cimetrix Sapience platform provides all these features and more in a lightweight set of .NET libraries which can be deployed wherever they are needed to consume EDA data.

Conclusion

More and more semiconductor factories are requiring EDA interfaces with their new equipment purchases with highly prescribed equipment models and demanding performance criteria. From the equipment supplier’s perspective, these requirements have been viewed as a source of additional cost, with all the benefits accruing to the factory customers. But it doesn’t have to be that way…

Why not take advantage of this interface to offer additional value using a standards-based approach? This just might be an idea whose time has finally come. If you agree, give us a call – we can help you make it happen!

Background

The SEMI North America Advanced Backend Factory Integration (ABFI) task force is part of the North America Information and Control Committee (I&CC or NA I&CC). Normally this task force meets every July in San Francisco as part of SEMICON West. However, this year the technical committee meetings are spread out over several weeks and do not coincide directly with the exhibition. Additionally, the I&CC did not meet at all because SEMI regulations do not currently allow TC Chapter (Committee) voting in virtual meetings. That will hopefully change later this year, but for now delays SEMI standards development.

Regardless of these challenges, the ABFI task force did meet on Monday July 13, 2020 and continues to develop SEMI standards. I am co-leader of the NA ABFI task force along with Dave Huntley of PDF Solutions. This blog is a summary of the current task force activities.

Wafer Maps

Ballot 6648 to update to the SEMI E142 (Specification for Substrate Mapping) specification has passed initial voting and is recommended to be accepted and published. This ballot significantly enhances the amount of traceability data that may be embedded within wafer maps.

Additional Wafer Map Activity

Because wafer maps will potentially be much larger with additional traceability data, they could be too large for the messages currently defined in the E142.2 standard. A new activity has been started to modify wafer map usage further and to allow Stream 21 messages to be used for wafer map transfer. The stream 21 message in the SECS-II standard can be used to transfer very large items through a GEM interface.

SEMI Standard Usage Matrix for Backend

The ABFI task force is also defining a matrix that specifies which standards beyond GEM (E30), SECS-II (E5), HSMS (E37) and Substrate Mapping (E142) should be used for backend automation, and under what conditions they should be used. This includes consideration of the full suite of GEM 300 standards and other standards that all GEM interfaces should consider, such as SEDD (E172) and SMN (E173).

Getting Involved

For those interested in participating, it is easy to join SEMI standards activities. Anyone can register at www.semi.org/standardsmembership.

All SEMI task force ballot activities are logged at http://downloads.semi.org/web/wstdsbal.nsf/TFOFandSNARFsbyCommittee?OpenView&Start=1&Count=1000&ExpandView

After joining the standards activities, anyone can get involved. The task forces post everything on the connected @ SEMI website https://connect.semi.org/home. The North America ABFI task force does not have a community.

To learn more about the standards, or to speak with a standards expert, click on the button below: