Industry News, Trends and Technology, and Standards Updates

In the semiconductor industry, the fabrication process is a complex process and involves multiple steps to achieve the desired result. Each process step uses different types of equipment. Semiconductor industry equipment uses a specific type of communication protocol called SECS/GEM (SEMI equipment communication standard and Generic equipment model).

High-level architecture of a fabrication factory

• MES: Manufacturing Execution System is the central part of the production process. It connects with multiple equipment and monitors the progress of material in individual equipment and the entire factory at the same time. It integrates the ERP system (Enterprise Resource Planning) and individual machines.
• MES DB: It is a MES database system that will store the MES related information including recipe information.
• FDC: Fault Detection and Classification is used to continuously monitor the sensor data coming from the equipment and analyze and detect fault to prevent it from reoccurrence.
• APC: Advanced Process Control uses R2R (Run to Run) method that adjust the process parameters based on the incoming and outgoing data from an equipment for a material in combination with process model.
• Host: This is an application that connects with the equipment via SECS/GEM. This application instructs the equipment to process the materials and retrieve the related information.
• Equipment: This is a tool that performs and process the incoming materials based on the instruction given by the host.
• DB: This is an equipment database that can store the material processing information as a raw data form. (Example Metrology tool data).

Some of the SECS/GEM standards we will highlight are E4, E37, E5 and E30.

Communication Layer

There are two different types of GEM communication models.

• SEMI E4 standard which is SECS-I a serial communication model that uses RS-232.
• SEMI E37 standard which is HSMS communication model that uses TCP/IP. (There is a subset of E37 standard is called E37.1 HSMS-SS).

Message Structure Layer

The Message Structure Layer is also called the SEMI E5 standard. A typical SECS/GEM message contains a header and a body. The Header contains Stream and Function, and a Body contains a list of one or more data items. Each data items may contain another list of data items. Refer the below example.

GEM Layer

Messages can be categorized into two types, the primary message and secondary message.

Primary messages are usually the request message that will be initiated by one party (Host/equipment). The secondary message will be the response that will be acknowledged by the other party (host/equipment).

Some common GEM messages include:

• Collection Events – these messages are raised when the equipment processes the substrates using S6F11.
• Alarms – these messages are raised when any problem occurs at the equipment using S5F1.
• Remote Commands – these messages are sent by the host to command the equipment using S2F41.
• Recipe Management – these messages manage the recipes and can sent by either party. Example: S7F3 is the recipe download command.

A typical process flow between a host and the GEM based equipment is explained below.

Conclusion

This blog post has summarized how the factory host communicates with equipment using SECS/GEM protocol. At the Cimetrix Connectivity Group of PDF Solutions, we have products for the factory hosts that can easily be integrated with any existing systems with minimal configuration settings. To learn more about our products for the factory host click on the below button.

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. 

Earlier this quarter (October 2022) the SEMI Smart Manufacturing Council conducted one of its regular meetings with factory stakeholders to determine what sort of SEMI-sponsored activities could accelerate this important industry initiative. One focus area of the discussion was getting more and better data out of the sub-fab, since the performance and integration of these components is becoming more important for many of the leading manufacturers. The related, familiar topic of achieving better visibility into equipment and process behavior was also raised.

In that context, as it often does, the role of industry standards came up as a key enabling technology. The following question was posed: “Are the current standards sufficient to support the broad range of smart manufacturing use cases that factories envision, or does more need to be done? Specifically, since the Information and Control Committee is working on the Freeze 3 version of the EDA (Equipment Data Acquisition, also known as Interface A) suite of standards, are there problems that need to be addressed to improve the adoption of usage of these standards?”

This question triggered a lively (but non-convergent!) conversation among the participants in the meeting, many of whom have years (no, decades) of experience working in the standards community. Before long, it became clear that the group had no clear answer to these questions, and that more information from the actual user community was needed. Someone suggested that the Council pose the questions to a broader audience in survey form, and this proposal was enthusiastically accepted. Several of us volunteered to generate a draft survey for SEMI’s review and refinement, which got the activity off to a running start.

Given this opportunity to connect directly with the ultimate beneficiaries of SEMI Standards, there was a temptation to broaden the survey’s scope to cover other topics of interest in the smart manufacturing domain. Cognizant of the fact that the longer surveys have a lower chance of being returned with useful data, however, the group largely resisted this temptation, including the most important questions in an easy-to-answer format, leaving room for optional additional information in the responses for those so inclined.  

The final survey was issued by SEMI around October 21,2022 with a requested response date of November 15 (which has been extended to gather more feedback). Rather than repeat the entire content here, I include the following excerpts from the introduction and the table of contents:

The purpose of this questionnaire is to assess the status of the industry’s experience with and impressions of the SEMI EDA (Equipment Data Acquisition) standards suite to guide current and future initiatives that improve its capabilities, communicate implementation best practices, and foster broader adoption to realize the vision of SEMI’s Smart Manufacturing Community.

Respondents to this questionnaire should include companies that have already deployed the EDA standards in volume production as well as those that have yet to do so. Respondents in the latter category can simply skip the questions about current usage/issues.

The target audience was originally thought to be stakeholders in 300mm wafer fabs, but with the growing interest in enhanced data collection and automation for backend (packaging, assembly, and test) factories AND growth in the 200mm wafer fab segment (including new models of 200mm manufacturing equipment), it has been broadened to include these domains as well.  

Most questions are posed in multiple choice format, but additional detail is always welcome in the Comments fields where appropriate.

SEMI will compile the responses and share the result with the industry while preserving the anonymity of individual responses.

1. Manufacturing Stakeholders
2. Manufacturing KPIs (Operational Performance)
3. Manufacturing Application Support
4. Automation Requirements and Equipment Acceptance
5. Current (or intended) Usage
6. Issues and Expectations
7. Other Data Collection Needs

Appendix – Stakeholders and Acronyms

 

 

Moreover, at this writing, the link to the on-line survey is still active here: 
à SEMI Equipment Data Acquisition / Interface A Standards Survey – Questionnaire on Usage, Requirements, Expectations, and Issues.

Finally, if you are interested in the details of the survey, and especially if you would like to provide your inputs directly to SEMI, you should contact Mark da Silva, Chair, SEMI Smart Manufacturing, Global Executive Committee, at mdasilva@semi.org.

And as always, to discuss your company’s specific Smart Manufacturing journey and to understand how we at Cimetrix by PDF Solutions can help, click on the contact button below. We look forward to hearing from you!

Background

Chris Maloney of Intel and I are the North American GEM 300 Task Force co-leaders. We lead the task force activity related to all SEMI standards related to GEM technology. This includes a long list of SEMI standards.

APCSM Conference

I recently participated in the APCSM (Advanced Process Control Smart Manufacturing) conference in Austin, Texas by teaching about the GEM standard. In the material I presented, I included what I called the “core philosophies of GEM”. These are the features in GEM that justify the increased adoption and usage of GEM technology. These core philosophies include:

What’s new with CIMControlFramework^TM (CCF)?

CCF is a software development kit (SDK) that enables users to design and implement a high-quality equipment control solution using provided components for supervisory control, material handling, operator interface, platform and process control, and automation requirements. CCF is built on the reliable Cimetrix connectivity products which provide GEM/GEM300/EDA interface functionality.

We released CCF 6.0 in March of 2021. Since that time, we have released four additional versions of CCF. In CCF 6.1 we added a continuous flow sample. We created a blog post for that sample that can be read here. We thought it would be fun to create another blog to keep readers up to date on some of the additional cool things that have been added to CCF in these subsequent releases.

GUI Changes

Many of the visible changes to CCF have been made in the operator interface.

New WPF OI for vacuum sample

The trend for most of our CCF customers has been to implement their equipment control application GUI using Windows Presentation Foundation (WPF). In previous releases, CCF had fully functional WPF GUIs for the Atmospheric and Continuous Flow samples. CCF now has a full WPF operator interface for the Vacuum Sample. The picture below shows the default main screen for the WPF GUI for the Vacuum Sample.

New visualization library

In addition to full operator interfaces created with WPF, a visualization library has been added to CCF. In previous versions, visualizations were achieved using bitmaps that were updated when states changed. While the results were adequate, they did not scale very well, and it was difficult to customize the visualizations. The new visualization library uses vector graphics to draw the visualizations. This makes the lines and images in the visualizations crisp and clear regardless of the scale. It also allows for easy customization so that CCF application developers can create a visualization to exactly match their equipment. The Developer Guide and training labs have instructions for using the new visualization library.

The picture of the full GUI main screen above shows the default visualization for the vacuum sample. The following image is a visualization from the continuous flow sample.

Both visualization examples were created with the same visualization library.

Additional GUI changes

In addition to the GUI changes listed above, Cimetrix has made more changes to the GUI and added new screens for both WinForms and WPF. These screens include:

• GEM300 E39 objects screen
• GEM Traces screen
• GEM Reports screen
• EFEM Robot service screen
• Aligner Service screen

Simulation Changes

Cimetrix has always been a proponent of using simulators as much as possible during equipment control application development and testing. (See blog post on simulation here.) Simulation in CCF has always been easy to use, but now it is even easier and has more functionality. Simulators should be interchangeable with hardware so that regardless of whether you are running against simulation or real hardware, the application makes the same calls and receives the same feedback. In the latest versions of CCF, Cimetrix has:

• Added simulation for Kawasaki D60 robot
• Added simulation for TDK TAS300 LP
• Made simulation more extensible
• Added simulation templates

Efficiency Changes

A change that is not very flashy but is probably one of the most important changes made to CCF is that the efficiency has been greatly improved. While CCF has never been a resource hog, there were some instances where it was using more CPU and memory than was needed. This was the case especially when GUI screens were being updated with large amounts of data.

In these instances, a data structure dealing with material locations and another dealing with process and control job data were being sent from the supervisory layer to the GUI more frequently than was needed. By being more intelligent about sending these data structures, we have greatly reduced the CPU usage.

Another change that has reduced CPU usage and data traffic is that the user can now set up trace reports to the GUI that are only sent when data changes rather than on a 10 Hz timer.

Additionally, CCF now has a performance monitor class that allows users to monitor performance counters like CPU, Disk usage, and memory usage.

CCF provides history objects for storing certain data to a database. This history includes:

• Wafer history
• Equipment Performance Tracking (EPT)
• Alarms

As a final efficiency enhancement, these objects now share a base class and are more efficient in writing to the database.

Interlocks

Software interlocks are designed to prevent executing an unsafe command. Using multiple levels to do safety checks provides redundancy and reduces the chance an unsafe command could be executed.

These interlocks are generally based on states and are equipment-dependent. Software interlocks are not a replacement for hardware interlocks. Software interlocks are like a safety net—they are not normally needed, but when they are, there is a much lower risk of damage.
CCF has previously had interlock functionality available. However, in the latest release, the interlock functionality has been consolidated, centralized, and simplified. Using a single interlock class gathers all the interlock code into one location instead of scattering interlock code through all the Components.

Interlocks have been added to each of the CCF samples to show how they work and how they could be implemented in your application.

Conclusion

These are just some of the cool and useful features that have been added to CCF in the last two years since the release of CCF 6.0. To learn more about these features or the other new features that have been added, please schedule a time to talk with a Cimetrix representative.

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.

This blog is the conclusion to the blog: Identifying Custom Test Cases in the SEMI E30 GEM Standard found here.

Unhappy Path Testing

Though this post will focus on the so-called “happy path” (i.e., no errors), it is also important to test unhappy paths.

Conditions that might show up in the “unhappy path” testing include:

1. Card reader loses internet connection.
2. Card reader loses power
3. Vending machine loses communication with Card reader

Happy Path Test Case

The happy path is the program flow that is followed given the user (or in this case, the equipment) only enters valid data. I

n this simple test, we ignore the Error/Alarm cases (Transitions T2 and T4).

Transition Test Steps for Happy Path

1. Initializing T1 =>
2. Wait_Payment T3 =>
3. Wait_Selection T5 =>
4. Dispense_Item T7=>
5. while (User wants more items && has sufficient funds)
   {
   Dispense_Item T6
   Wait_Selection T5
   }
6. Transaction Complete T8

EquipmentTest plugin setup

Prerequisites:

1. EquipmentTest 1.0.3 or later installed.
2. Visual Studio 2019 or later (Targeting .NET Framework)
3. .NET 4.8 SDK
4. A unit of GEM-enabled equipment (or equivalent) to test against
5. Follow the instructions in the EquipmentTest Developer Guide Section titled: “Creating a plug-in using Visual Studio”,

Test Flow

Sometimes I find it beneficial to assert the data as it occurs. For the sake of brevity, this test will gather all the data, and then verify it at the end of the test.

Documentation

Documentation is one if the items the user will see in the EquipmentTest User Interface. Each Test Step must be documented in the plug-in so the user understands what the test is doing.

User Parameters

In GEM, each Collection Event, Variable, and Alarm will have an ID. These IDs are needed for host-side testing. Most modern equipment allows us to get these IDs through characterization messaging. For this example, we will allow the user of our test (plug-in) to enter the values manually.

Custom Test Overview

The HSMS settings are retrieved from the set the user entered in the EquipmentTest user interface.

In Step 1, the Event Report for the Processing State Transitions and associated variables are created.

In Step 2, the test waits for an Auto Reset Event “timeOutWait”. If the result times out, the test fails. If the test receives Transition 8, the test continues.

Steps 1-2

Create Reports

The CreateReports API call sends an S2F33 message to create the report number specified by the user parameter ProcessState Report. The report will contain the status variables ProcessState and PreviousProcessState. Both have a value type of Ascii in this example.

Test Steps 3-4

Step 3 inspects the data to make sure all the state transitions occurred in the expected order.

The first 4 states should always be T1, T3, T5, and T7 respectively. However, the next states will vary depending on how the user responds. This requires the test to dynamically assert the data.

In test step 4, we extract the variable values, and then use the same approach as step 3 to ensure the previous and current process states were reported correct.

Conclusion

Though developing this test took a basic understanding of GEM and C#, running the test requires the user to understand neither. This means anyone with access to the equipment and an EquipmentTest run-time license can run successfully run this test.

Cimetrix EquipmentTest allows the developer to harness the extensibility of the .NET Framework. Furthermore, the well-written and proven GEM libraries flatten a significant portion of the learning curve associated with writing GEM tests.

For more information on Cimetrix EquipmentTest, to request a demo, or to speak with an expert, please click the button below.

Testing the interface capabilities of GEM-enabled equipment not only during development but also while in production has measurable benefits. There are portions of the GEM standard that are not explicitly specified, allowing implementations to vary from equipment to equipment. As a result, equipment manufacturers should write equipment-specific tests that will continue to provide value throughout the equipment’s service life.

Processing State Model

One GEM item that will almost always vary is the equipment’s processing state model. I will use the Cimetrix GEM test utility EquipmentTest to show an example of creating a custom test for an equipment’s processing state. You can request an evaluation of EquipmentTest on our website.

The E30 standard provides an example Processing State Diagram and Transition table.

Process State Requirements

Though implementations can vary without violating the standard, the processing state section includes the following requirements which must be followed for the interface to be compliant:

SEMI E030-00-0520

Explanation:

The examples for the Processing States (INIT, IDLE, SETUP, etc.) are not absolutely required in a GEM implementation. However, the equipment manufacturer must identify the equipment’s states and document them similarly to the examples.

SEMI E030-00-0520

Explanation:

• There must be a collection event for each state transition in the processing state model.
• The following status variables must be provided:
  
  • ProcessState
  • PreviousProcessState
• Whenever any state transition occurs, the ProcessState and PreviousProcessState status variable values must be updated

Pseudo example Vending Machine

Though it is unlikely a GEM interface would ever be implemented on a vending machine, it is a universally known system, often used as a state machine teaching example in academia. Therefore, we will likewise use our imaginary GEM-compliant Vending Machine as an example.

Assumptions to Maintain Simplicity

• The vending machine uses contact-less payment that authorizes $5.00 at the beginning of the transaction.
• The vending machine has no knowledge of the items it contains except their location and prices.
• All items are always in stock.

Make a Diagram

When your GEM documentation is final, the Process State diagram should be in Harel notation. For the purposes of brainstorming, I have used a simple UML diagram.

When building a diagram, first identify all the possible GEM states, transition/collection events, variables, alarms, and errors.

Transition Table

Note the above diagram has each state transition marked in red e.g. T1.

Each state transition must be documented in the Transition Table. The Transition Table will be crucial for developing an effective test.

Part 2 - The Conclusion will be published next week. In the meantime, if you have questions, would like to request a demo, or would like to speak with one of our experts, please click the button below.