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.
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:
Two Levels of Subscription
An equipment’s GEM interface serves as a message broker and much more. It is not just a simple on/off message subscription service. The end user host has substantial control to dictate the content of each message coming from the equipment. The same GEM interface might send fewer and smaller messages at one end user site and send many and larger messages at another, based on the data collection setup by each’s end user’s host. Compare the following features to a typical message broker subscription model, where a client can only subscribe to receive or not receive specific messages but has no control over the message content or frequency.
Collection event reports allow the end user to enable and disable collection event message notifications, a typical client subscription model. As a second level of subscription, the end user also can choose the data reported in those messages.
Trace reports allow the end user to choose the trace report message frequency. As a second level of subscription, the end user also chooses the data reported in those messages.
Alarm reports allow the end user to enable and disable alarm message notifications. As a second level of subscription, the end user also independently chooses the collection event report configuration for the collection events associated with the alarms.
Adaptability
Any manufacturing equipment, simple or complex, can have a GEM interface. The GEM interface complexity reflects the equipment’s complexity. For example, one GEM interface might have 15 unique collection events yet another might have 20,000. One equipment might have 10 status variables while another has over 5,000.
Additionally, the technology within a GEM interface is mature enough that it is possible to implement a GEM interface on equipment platform, be that Windows, Linux, a PLC or any other operating system. A surprising number of equipment are still using older software development technology including Visual Basic 6.0 and Visual C++ 6.0, but these can still implement GEM. And yes, even an equipment implemented completely on a PLC could have a minimalistic GEM interface within the PLC using serial communication or TCP/IP. The GEM standard allows implementation to choose to implement capabilities or not based on what is appropriate.
Extensibility
It is easy to add additional collection events, alarms and variables to an existing GEM interface without affecting backward compatibility. And once new items are in the GEM interface, the end user host can use the data or not as desired.
It is also to combine requirements from different sources and put them together in one GEM interface. To explain further, requirements for a GEM interface will come from different end users, the GEM standard itself, the equipment supplier and from additional standards. It is relatively into to combine the requirements from all of these sources into one GEM interface. And the combined data collection features can be combined together inherently is trace reports and collection event reports.
Top-Down Connectivity
In many situations it can be useful to give one equipment access to data from another equipment. One possible solution for this is direct equipment-to-equipment communication. However, when using GEM while direct equipment-to-equipment connectivity is not prohibited, it is not normally used. Instead, GEM uses a top-down approach to connectivity. This means that the end user host collects information from one equipment using its GEM interface, and then the end user host passes that information to the downstream equipment. While this might seem less efficient because it is indirect, this top-down approach can be easier to integrate on the factory floor. Reasons include:
1. The scenarios can be equipment agnostic. Validating equipment-to-equipment communication can be difficult. And you can’t easily swap one equipment from one supplier with equipment from other. Each equipment only has be tested with one host entity.
2. This is easier for the equipment supplier to support. The equipment supplier only must support the GEM interface, not an additional equipment-to-equipment protocol.
3. This gives mores control to the end user. The end can log precisely what is occurring with each equipment, and can even manipulate the information if necessary. And independent connection between equipment is an additional complication when diagnosing issues.
Exciting Changes to the GEM Standard
In a couple weeks ballot 6572C, a proposal to modify the SEMI E30 GEM standard, will be adjudicated during the Fall North American Information & Control Committee. The meeting will be held on November 9, 2022 at SEMI headquarters in Milpitas, CA. This ballot proposes the biggest changes to the GEM standard in many years. Since this is the fourth round of balloting these changes, it seems highly likely that the changes will be approved, especially since the voting in the last round indicated strong support for the changes. Following is a summary of the proposed changes
Process Program Management
Several changes are proposed related to the handling of equipment recipes, a.k.a. process programs. The biggest change is a proposal to officially adopt the Stream 21 SECS-II messages previously approved in the SEMI E5 (SECS-II) standard, which is the library for all standard message definitions. Stream 21 messages will allow equipment to transfer unformatted process programs to and from the equipment even when they are greater than 16.7 MB. This is a long overdue enhancement to the GEM standard, which current defines alternative ways to support large process programs which are complicated enough that few if any have ever implemented it.
Additionally, the process program management section has been completely reorganized to isolate each implementation alternative, so make it easier to identify the set of scenarios. For example, here is a new table summarizing the messages for each scenario:
Table 7 SECS-II Message Summary For Each Process Program Management Option
Each process program implementation alternative removed from the main body of the GEM standard has been relocated into an appendix.
The hope is that recipe management will be easier to understand, easier to implement, and able to handle the increasing size of process programs will less effort.
Additional New Messages
Ballot 6572C also proposes the addition of new message S2F51 through F64. These messages were also previously approved in the SEMI E5 (SECS-II) standard and are now proposed to be added to the GEM standard. These message add additional transparency to a GEM interface. Here is a quick summary of the new messages:
| Message |
Description |
| S2F51 |
A request to the equipment to return the list of all report identifiers. |
|
S2F53
|
A request to return one or more report definitions |
| S2F55 |
A request to the equipment to return the list of linked reports identifiers for one or more collection events. |
| S2F57 |
A request to the equipment to return the list of all collection event identifiers that are enabled for reporting. |
| S2F59 |
A request to the equipment to return the list of streams and functions that are to be spooled whenever spooling is active. |
| S2F61 |
A request to the equipment to return the list of all trace identifiers. |
| S2F63 |
A request to the equipment to return the list of one or more trace definitions. |
These new messages not only make a GEM interfaces setup and configuration more transparent, but they also will allow for improved GEM interface testing. For example, it will be possible to test a GEM interface following steps like these:
1. Define a report using message S2F33
2. Check the report existence using new message S2F51
3. Check the report definition using new message S2F53
4. Link the report to a collection event using message S2F35
5. Check the report linking using new message S2F55
6. Enable the collection event using message S2F37
7. Check for the collection event enable status using new message S2F57
8. Disconnect from the equipment and restart the equipment
9. Check the report existence using new message S2F51
10. Check the report definition using new message S2F53
11. Check the report linking using new message S2F55
12. Check for the collection event enable status using new message S2F57
Today it is common for a host when it reconnects to a GEM interface to redefine the data collection, to ensure that the data collection was not changed while it was not connected where another host application might have modified the data collection setup. Instead of redefining the data collection, a host can verify whether the data collection is still the same.
Equipment Identification
Today an equipment is identified through a GEM interface using the equipment’s software revision and model number. Two equipment of the same model number and running the software revision cannot be easily distinguished.
A few new identification features were added.
| E30EquipmentSupplier |
This is a new proposal to identify the equipment supplier. |
| EqpSerialNum |
The equipment’s serial number. This has been part of the E5 SECS-II standard for many years, but was not required by the GEM standard. |
| EqpName |
A name assignable by the operator or host. This has been part of the E5 SECS-II standard for many years, but was not required by the GEM standard |
Improved equipment identification should assist Advanced Process Control applications.
Documentation Access
One of the common difficulties using a GEM interface is getting access to the correct documentation for an equipment, and the right version of that documentation. This ballot proposes providing two ways to obtain GEM documentation through a GEM interface.
1. Download the traditional GEM documentation, which might be a PDF or CSV file.
2. Download the SEDD file, an XML file describing the GEM interface. SEDD stands for SECS Equipment Data Dictionary.
In both cases, the documentation is downloaded using Stream 21 messages, the same new message available for process program transfer.
Miscellaneous Changes
There are a handful of other changes also proposed. SEMI somewhat recently adopted requirements for restricted bias terminology and guidelines for other biased terminology. Although no restricted bias terms were in the GEM standard, some biased terms are present. The ballot address bias terms that can be addressed following SEMI guidelines.
The GEM compliance statement has also been updated to reflect changes to GEM. The new compliance statement looks like this:
PDF Solutions and Cimetrix by PDF Solutions are exhibiting at SEMICON West 2023 in less than a week and we hope to see you there!
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”.
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.
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.
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.
Both visualization examples were created with the same visualization library.
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.
