The GEM standard is often incorrectly perceived as a single-connection protocol for manufacturing equipment. A single connection means that only one software product can use the GEM interface at one time. Many manufacturing equipment that support the GEM standard only have the ability for one connection. However, this limitation is set only in ignorance, by tradition, and to satisfy the common manufacturing system architecture. 

The truth is that the GEM standard simply does not discuss additional connections--meaning that additional connections are neither required nor prohibited. Not only is it possible for an equipment to support multiple concurrent GEM interfaces, this is becoming more and more common. If each supported GEM connection is point to point and complies with the GEM standard, this is certainly allowed. However, each connection should be completely independent of other GEM connections and still comply with the GEM requirements. Implementing multiple connections raises several questions. 

What does it mean for each GEM connection to be independent?

It means that each GEM host operates completely independently, as if the other GEM host connections were not present. Here is a more specific list of attributes that define “completely independent”:

• The Communication state model is independent. Each can establish and disconnect independently from the other host packages.
• The Control state model is independent. Each can be set up as local or remote as needed. 
• Collection event report dynamic configuration is completely independent. Each host defines a unique set of reports and subscribes to a unique set of collection events. Even so, if two GEM host connections create identical reports and link them to the same collection event, then both should receive identical data. 
• Each host subscribes to a unique set of alarms. 
• Each host can query status information independently of any another.
• Each host can choose to enable or disable Spooling and configure it as desired.
• Each host can set up its own trace data collection.
• Each host only receives messages based on its subscriptions.
• Each host only sees reply messages to its primary messages.

Are you talking about HSMS-GS? 

No. HSMS-GS means implementing SEMI Standard E37.2, High Speed Message Service – General Session, an inactive SEMI standard. This standard, which never gained much industry traction, opens a single port through which any number of clients can connect. In contrast, I am talking about supporting multiple implementations of E37.1, High Speed Message Service – Single Session (HSMS-SS) where each connection uses a unique port number. Nearly all GEM interfaces today use the HSMS-SS protocol. 

What are the advantages of having multiple GEM connections in a single GEM interface? 

This opens the door for many useful applications. Here are three example configurations, and of course, all of them could be accomplished at the same time. 

1. A factory can set up multiple host software packages at the same time to connect to the same equipment’s GEM interface, without any knowledge of or interference with each other. With only a single connection, a factory wanting to do the same thing has to implement some sort of GEM host broker to funnel the different GEM host package communications into a single GEM connection… a technically challenging feat. 
2. If an equipment supplier wants to create an application designed specifically for its equipment running in a factory, they can use one of the GEM connections. They don’t have to replicate functionality into a custom interface. 
3. If one equipment needs to monitor, control, or pass data directly to or from another equipment, this can be done using one of the GEM connections without interference to the factory GEM connection. This is relatively simple to set up. Sometimes this is called horizontal communication. Such communication can also be channeled through a host using the traditional vertical communication use case for a GEM interface. 

What about safety?

Typically, I would expect factories to set up one and only one connection in the GEM interface to be in the online-remote state and allowed to send remote commands. But this is not an absolute requirement. It is not difficult to imagine applications where execution of remote commands is distributed among multiple applications. For example, an equipment supplier might use one GEM connection to manage periodic recalibration of the equipment based the actual measured performance. 

What are the technical complications? 

There are a few. 

• Because each connection uses a separate port number, the GEM interface can only support a finite number of connections when using HSMS-SS. 
• Because multiple connections are not addressed explicitly in the standard, there are not requirements for handling them. For example, GEM requires that operator commands and operator recipe management activity be reported to the host. However, when another connection sends a remote command or downloads a new recipe, there is no requirement to report this. Our CIMConnect product does, but there are no formal requirements to do so. 
• GEM requires the communication status to be displayed in the GUI, but what about multiple connections? It is not clear what needs to be displayed for multiple hosts. Typically I’ve just displayed the first GEM connection status, but it might be useful to show each connection status and give the operator a chance to control all GEM connections. 
• Some collection events (and hence data variables), status variables and equipment constants are targeting the behavior of that single connection. This means that in order to implement multiple connections correctly, these connection-specific features must be unique for that connection. For example, consider status variables EventsEnabled and ControlState. The values reported for these two status variables are unique to that connection. This adds some complexity to implementing the GEM interface with multiple connections. Of course, our CIMConnect product implements and handles this already. 

Does each GEM connection have to be identical? 

No, but generally speaking it should be the same. The same set of collection events/data variables, alarms, status variables, and equipment constants should be reported to all connections. However, there are use cases where it might be useful to have some unique collection events and data on one connection. For example, if an equipment supplier uses one GEM connection as a pipeline for a factory host package dedicated to their equipment, they might want to publish some unique data that is for its eyes only. As mentioned above, if two GEM host connection create an identical report, and link it to the same collection event, then both should receive identical data. On the other hand, trace data reports with the same status variables may not need to report identical data, because the values might be sampled independently and at different time intervals. 

How many GEM connections should an equipment support in its GEM interface?

I recommend supporting five connections. Most GEM implementations are just using one connection today, so this opens the door for up to four more connections. This enables an equipment to handle most situations without the need to be reconfigured later at the factory. In CIMConnect, the overhead for having five connections is quite minimal, and virtually nothing if they are not used. 

What should the communication settings be? 

You should definitely set up the equipment as passive. This puts all of the configuration on the host side. The device ID can be the same for all connections, where 0, 1, or 32767 is best. 

How do I turn on multiple GEM connections in CIMConnect?

Since our CIMConnect product inherently supports multiple GEM connections, Cimetrix customers really only have to configure the setup file. Our CIMConnect GEM product was originally designed with multiple GEM connections in mind; therefore it is native and intuitive, with virtually no extra programming required unless you count the additional work in the operator interface. In the setup file, just create the five [CONNECTIONX] sections initially, and then set up a connection-specific VARIABLES and EVENTS section for each of the five connections. 

Alternative Approaches?

One alternative approach is to look at the SEMI Equipment Data Acquisition (EDA) standards. An EDA interface is inherently only for data collection and has multiple client access built into the standard as a fundamental requirement. The semiconductor front end device manufacturers have successful embraced this technology in addition to the GEM standard. The GEM interface is used by the Manufacturing Execution System for command and control of the equipment, while the EDA interface is used for every other application. 

Final Thoughts

My recommendation is that everyone, especially Cimetrix CIMConnect customers, take a look at their GEM interface and make sure that you are doing a good job implementing multiple host connections. CIMConnect makes this extremely easy. And let your customers know that you have this feature so that they can take advantage of it. 

You can learn more about the GEM standard any time on our website.