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 !

What is GEM Control State?

The GEM Control State is one of the fundamental E30 GEM requirements. It defines the level of cooperation between the host and equipment and specifies how the operator may interact at the different levels of host control.

In a semiconductor factory, the host or operator may be in control of equipment processing. Having both sides in control of the equipment at the same time poses problems. When one side is in control of the equipment, the other side should be limited in the operations it can perform. For example, if an operator pauses processing, the host should not be allowed to send commands to resume processing or to start a new job. The GEM Control State is provided to prevent these types of issues from occurring.

Figure 1: SEMI E30 GEM Control State Model

How does the Control State work?

The Control State provides three basic levels of control. Each level describes which operations may be performed by the host and equipment sides.

Remote

• The host may control the equipment to the fullest extent possible.
• The equipment may impose limits on the local operator’s ability to control the equipment, but this is not a requirement of the standard. The host must be capable of handling unexpected commands invoked by the operator at the equipment.
• GEM Remote Commands are used by the host to invoke commands on the equipment.

Local

• The operator may control the equipment to the full extent possible.
• The host has full access to information. The host can collect data using other GEM features such as collection events, traces, and status data collection.
• Limits are placed on how the host can affect equipment operations:
  • Remote commands that initiate processing (e.g. START) or cause physical movement are prohibited. During processing, remote commands that affect processing (STOP, ABORT, PAUSE, RESUME) are also prohibited.
  • Other remote commands that do not initiate processing, cause physical movement, or affect processing may be allowed.
  • During processing, the host is prohibited from modifying any equipment constants that affect that process.
  • Equipment constants that do not affect the currently running process may be changed.
  • All equipment constants are changeable when not processing.

Offline

• The operator has complete control of the equipment.
• The host has no control over equipment operations and very limited information gathering capabilities.
• The only messages that the equipment will accept from the host are:
  • Messages used to establish GEM communication (S1F13/F14).
  • Requests to activate Online Control State (S1F17), but only if the currently active state is Host Offline (transition #11 on the Control State Model).
  • S1F2 “Are You There Response” while the attempting to go Online.
• The only primary messages that the equipment may send to the host are:
  • Messages used to establish communications (S1F13).
  • S9Fx messages, but only in response to the messages to which the equipment will normally respond to while Offline (i.e., S1F13 and S1F17).
  • S1F1 “Are You There Request” is sent to the host when the “Attempt ON-LINE” sub-state is entered. This message is used to get permission from the host to transition into an Online state (transition #5).
• No messages are spooled while Offline.

The Control State Model was designed in a way to give the equipment operator more control over the state machine than the host.  This protects the operator from unexpected state changes initiated from the host.

• The equipment operator can choose which Online sub-state is active through the operator interface. The host side cannot choose which Online sub-state is active.
• The equipment side can put the Control State Model into an Equipment Offline state (transition #6). When in this state, the host cannot request to go Online.
• The host side can put the Control State into a Host Offline state (transition #10), but the equipment side could reject this request. When in the Host Offline state, the equipment side can always attempt to go Online by first transitioning into the Equipment Offline state (transition #12) followed by an attempt to go Online (transition #3).

Operator Interface Requirements

The equipment must provide a way of displaying the current Control State to let the operator know who is in control of the equipment.

The equipment must provide a momentary switch to initiate the transition to the Equipment Offline state, and another switch to attempt to go Online from the Equipment Offline state. This may be a hardware switch on the front panel, but is often implemented in software using button controls.

The equipment must provide a discrete two-position switch which the operator may use to indicate the desired Online sub-state (Local or Remote). This may be a hardware switch on the front panel, but is often implemented in software using button controls. If implemented in software, the setting must be saved in non-volatile storage.

Conditional State Transitions

In the Control State Model, transitions #1, #2, #4, and #7 are conditional state transitions. The equipment application must provide a way of configuring which state to transition into. Equipment constants may be used for these configuration settings.

Conditional transitions #1 and #2 determine the initial state of the Control State Model during startup. The configuration that controls these transitions can be set for one of the following states:

• Online
• Equipment Offline
• Attempt Online
• Host Offline

Conditional transition #4 is used to determine which state to transition into after an equipment attempt to go Online fails. The configuration can be set to one of the following states:

• Equipment Offline
• Host Offline

Conditional transition #7 is used to determine which Online sub-state (Local or Remote) should be active when the Control State becomes Online. The configuration can be set to one of the following Online sub-states:

• Local
• Remote

Which Messages are used for Control State?

Click here to read the other articles in our SECS/GEM Features and Benefits series. 

To download a white paper with an introduction to SECS/GEM, Click below: