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:

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.

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: