Industry News, Trends and Technology, and Standards Updates

Joe Cravotta, Client Support Engineer

Recent Posts

SECS/GEM series: Documentation

Posted by Joe Cravotta, Client Support Engineer on Mar 6, 2018 11:27:00 AM

Case_studies.jpgAs the first article in this Features and Benefits of SECS/GEM series points out, the SECS/GEM standards define a standardized interface that may be used on any equipment. A GEM interface exposes an equipment's capabilities through status variables, data variables, collection events, alarms, data formats, error codes, SECS-II messages, and other optional GEM capabilities. The GEM standard requires each equipment to come with documentation; ensuring a factory has the information it needs to use an equipment’s GEM interface. This documentation is commonly referred to as the GEM manual.

The GEM manual may be distributed in many ways. Currently, most GEM manuals are provided digitally in a Word, Excel, or PDF  document. The vast amount of information in a GEM manual is used to make purchasing decisions, develop host software, and test equipment. For a full GEM interface, the GEM manual must include the following topics: State Models, Scenarios, Data Collection, Alarm management, Remote Control, Equipment Constants, Process Recipe Management, Material Movement, Terminal Services, Error Messages, Clock, Spooling, Control, Supported SECS-II messages, GEM Compliance statement, and Data Item Formats. To keep this post a reasonable length, we will only cover a few of the required topics.

GEM Compliance Statement

The compliance statement is one of the first topics to be reviewed. It is a quick and easy way to understand the features of an equipment’s interface. The manufacturer is required to mark which GEM capabilities are implemented on the equipment, and if they are implemented in a way that is compliant with the GEM standard.


State Models

State Models is a fundamental GEM capability, and is therefore implemented on every equipment. This capability defines the Communication, Control, and spooling behavior of the equipment. A processing state model must be provided. However, it is not possible to define a processing state machine that can be used on every equipment. The processing behaviors that should be the same for all equipment are specified by the standard. Each state model must be documented with a state model diagram, a transition table, and a text description of every state. The consistent and detailed information about each state model enables a factory to start writing a host application as soon as they have the GEM manual.


Alarms, Collection Events, Equipment Constants, Data Variables, and Status Variables 

Alarms, Collection Events, and Variables are large components in gathering data from an equipment. It should not be a surprise that these are required to be in the GEM manual. Each alarm on the equipment should have its ID, name, description, and associated Set/Clear events in the GEM manual. The documentation for each collection event should include the ID, name, description, and a list of associated variables. The documentation for all variables will include an ID, name, description, and the data type. Information about a variables default value or value range should also be provided when appropriate. Although not required, it is common to display all this information in five tables that are easy to find. There would be a single table for each of the following: alarms, collection events, equipment constants, data variables, and status variables. See the examples below.



Collection Events


Status Variables


Remote Control

Once a factory can gather data from an equipment they start looking at how to control the equipment. Remote Control is the GEM capability that allows a host application to request an equipment to perform an action. Each remote command should be in the manual with its name, description, and details about each command parameter that may be sent with the command. The details of a command parameter should include the name, the format, and a description. An example is shown below.



GEM manuals rarely come in a format that is easy to parse in software. This often results in duplicating code and making small changes in order to communicate with other equipment. SEMI E172 SECS Equipment Data Dictionary (SEDD) and E173 SECS Message Notation (SMN) are two standards that can drastically increase the flexibility and reusability of a host application. SEDD is an xml file that is easily distributed and parsed in software. SEDD can be considered a modernized GEM manual because it contains much of the same information that is found in a GEM manual. For example, a SEDD file contains details about every variable, collection event, alarm, and supported SECS-II message. A SEDD file uses SMN to represent the data items, variables, and SECS-II messages. SMN is also XML and is the first standard to define a notation for representing data items and SECS-II messages. This means a single application can read a SEDD file, have a short configuration process, and then immediately start using the GEM interface of an equipment. These features allow a single application to be used with multiple equipment instead of creating slightly different variants for each equipment.

Wrap up

The GEM manual is a crucial piece of documentation that is required by the GEM standard to be provided with every equipment. The GEM Manual should be the first place to look for an answer when there is a question about an equipment’s GEM interface. SEMI continues to improve the content and flexibility of a GEM manual by updating existing standards and creating new standards.

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

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

SECS/GEM White Paper

Topics: SECS/GEM, Smart Manufacturing/Industry 4.0, SECS/GEM Features & Benefits Series

Introducing Cimetrix HostConnect

Posted by Joe Cravotta, Client Support Engineer on Jan 26, 2017 11:45:00 AM

Cimetrix is proud to release its first new product to assist in GEM host application development, and I’m excited about how this is going to change the development of new host applications. Prior to the release, I was given access to HostConnect, a native .NET software development kit, and used it to create a couple of applications that connect to GEM equipment.

In developing those applications, I quickly became familiar with the layered architecture of HostConnect. HostConnect has four layers; each layer name and relevant classes is shown in the image below.


As with most layered objects, each additional layer adds to the previous layer. Now that I’m familiar with these layers, starting with the first layer, these are the aspects that stand out to me:

  • SECS Messaging: This is equivalent to our SECSConnect product. A solid understanding of the SEMI E5 (SECS-II) and E30 (GEM) standards is necessary to interact with this layer. The user application must be able to construct, parse, and handle asynchronous SECS-II messages.

  • SECS Transactions: This layer adds classes (generically called SxFy classes) to abstract the construction and parsing of many SECS-II messages. It also has the ability to synchronously send and receive SECS-II messages. Automatic message replies may be configured, but none are setup by default.

  • GEM Capabilities: This layer specializes the SECS Transaction layer for use in GEM host applications by setting up common automatic message replies and providing the EquipmentCapability classes (more detail about these classes below).

  • Connection and Discovery: This is the layer I’m most excited about because it is configuration based. The discover feature quickly characterizes an equipment’s GEM interface for HostConnect to use.

After working with HostConnect, I’m reminded of the task that got me acquainted with the SEMI E5 and E30 standards. I was asked to create a GEM host sample application from scratch. A large majority of my time was spent learning specific SECS-II messages and understanding the capabilities defined by GEM. After a few months, the sample application included trace report, collection report, and unformatted recipe management. If HostConnect was available, I’m willing to say I would have been able to complete this task in only a couple of weeks.

Remember the EquipmentCapability classes I mentioned? These classes encapsulate common GEM capabilities, and is one reason I believe I would have been able to complete the sample application in a much shorter time. For example, the EventReports class greatly simplifies report management. Simply register for the EventReportReceived event to receive incoming report data. The report data is parsed and provided in an easy to use parameters object. You don’t need to parse the SECS-II messages, and you don’t even need to know which SECS-II messages are used.

Another reason HostConnect would simplify my sample application, and the most exciting feature to me, is the configuration ability at the fourth layer. HostConnect stores default behavior options and an equipment’s GEM interface within a single configuration file. The discover feature can characterize an equipment’s GEM interface and create the configuration file for you. With a single file per equipment, it would be simple for my sample application to communicate with several different equipment without any code modifications. This flexibility makes HostConnect ideal for developing an application that needs to communicate with multiple different equipment, such as a testing application.

Seeing how much HostConnect does out of the box, but also allowing customization by accessing lower layers, I can say that I wish I had HostConnect when I built my sample host application.

Topics: Doing Business with Cimetrix, Smart Manufacturing/Industry 4.0, Cimetrix Products