Industry News, Trends and Technology, and Standards Updates

As part of the CIMControlFramework (CCF) product for creating equipment control applications, Cimetrix developed a logging package. Our logging package has two parts – collecting the log messages and analysis of the messages.

The logging package allows you to assign a source and a type for each log message. The source specifies where the log message originated. The type is a category that can be used to route the log 

messages to specific output locations called log sinks. We have found the most useful log sink to be a text-based log file. The logging package can be configured for the types of messages to log. It can also be configured for how long to keep log files and how many to keep. This helps keep hard drives from getting too full.

As 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.

Alarms

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.

SMN and SEDD

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:

Yufeng Huang of Cimetrix talks about our China Office Opening. Read now in Chinese or English.

美国矽美科股份有限公司上海代表处成立于2017年8月，地址位于称为中国硅谷的上海张江高科技园区。公司总部（矽美科股份有限公司）创建于1987年，地址位于美国犹他州盐湖城。矽美科公司是一家为半导体行业、SMT行业、PCB行业、光伏行业、LED行业及相关行业的设备制造商和生产工厂提供产品和服务的软件公司。

矽美科公司有着非常良好的客户评价，公司不仅将自己视为客户的重要供应商，更加将自己视为客户值得信赖的合作伙伴。我们坚信有能力为客户提供全球最先进的基于SEMI标准的软件解决方案。

矽美科上海代表处为中国、台湾等亚太地区客户提供售前产品咨询，客户培训，售后技术支持服务。我很荣幸在今年8月份加入到矽美科上海代表处，在过去的几个月内我们不断收到老客户给予的好评和新客户的合作意向。感谢新老客户对公司的支持，我们将一如既往的为客户提供最优质的、高效的服务，希望我们的产品和服务能让您满足，并为您带来巨大的帮助。

Following several SECS/GEM series blog posts, including Collection Events, Data Polling and Alarms, we now get into the features and merit of the GEM feature called Recipe Management. We will cover the definition of recipes, what recipe management means and why you need this feature!

What are recipes?

Recipes are sets of instructions describing how the equipment should process its material.  The Recipe content is defined by the equipment supplier.

What is recipe management?

Recipe management allows the factory host to transfer recipes to and from the equipment.   It also requires the equipment to notify the factory host when recipes are changed on the equipment.

Why do you need this feature?

Almost all semiconductor factories require this feature to ensure recipe integrity and to support traceability.   The host will upload approved recipes from the equipment and save them for later use to ensure that the recipe does not change.   For traceability, the recipe is usually saved with the process data.

How does recipe management work?

Recipes are passed between the host and equipment via SECS messages.   There are several sets of SECS messages to enable this.  E30 GEM specifies formatted, unformatted, and large recipe message sets.  The large recipe message set will not be discussed here. 

The equipment is also required to notify the host whenever recipes are changed by an operator at the equipment.  A PPChange collection event is generated with two data variables PPChangeName containing the PPID of the recipe that changed and PPChangeStatus containing the type of change (created, deleted, edited).

Once a recipe has been transferred to the equipment, the equipment should verify the content.  If the recipe is invalid, then a PPVerificationFailed collection event should be generated with a  PPError data variable containing the validation failure information to notify the host of the problem.  The recipe should not be used if it fails verification.

Identification

Each recipe is identified by an ASCII name called a process program ID or PPID.  The factory host and the equipment GEM interface use the name in recipe operations.

Persistence

Recipes are persisted in a GEM interface. If the host disconnects and reconnects, or if the equipment is restarted, the GEM interface will remember the recipes.   In addition, most factory hosts will save recipes on the factory side.

Which messages are used?

Here is a summary of each of the primary messages related to collection events. Note that the “S” identifies the “stream” and “F” identifies the “function”. Together, a stream and function number uniquely identify a message.

All Recipes

Unformatted Recipes

Formatted Recipes

Frequently Asked Questions about Recipe Management

How large a recipe can be transferred?

For unformatted recipe messages, the recipe is either a single ASCII string or a binary array value.  A single array value is limited to 16.777215 MB.

Formatted recipe messages, the recipe is split up into a list of items. A single array value is limited to 16.777215 MB.  Total message size is limited to 4.294967295 GB.

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:

Previous posts have talked about functionality that allows data to be collected through the GEM interface so the factory applications described in the most recent post can analyze this data. With this posting, we return to a discussion of specific features and capabilities of the SEMI E30 GEM (Generic Equipment Model) standard, specifically the management of error conditions on the equipment.

In a perfect world everything goes according to plan, but in reality, things always go wrong. The secret to success is being able to know when something goes wrong, and then responding appropriately.

Just like a home alarm system, semiconductor fabs want to know when something bad has happened. They want to prevent the material being processed from being scrapped. Alarm management enables the equipment to notify the host when something goes wrong, and provide information about what has gone wrong. The GEM standard defines Alarm Management as the capability to provide host notification and management of alarm conditions occurring on the equipment. 

In GEM, an alarm is any abnormal situation on the equipment that may endanger people, equipment, or material being processed. For example, if a technician opens an access panel to replace a component, the equipment should send an alarm notifying the host that it is not safe to operate the equipment in its current condition. Another example might be if an equipment requires a high temperature for processing but a sensor detects a low temperature condition, it should trigger an alarm, since running the process under those conditions could damage the material being processed. It is also the responsibility of the equipment manufacturer to inhibit unsafe activities on the equipment when an alarm condition is present. The equipment manufacturer knows best what specific alarms are required on the equipment to ensure safety for people, equipment and material.

Often it is useful to have more information about the conditions in the equipment at the time an alarm condition occurs. Communicating that additional information to the host is valuable, but cannot be done through the normal Alarm Report Send/Acknowledge messages. To provide a way to get this additional information, GEM requires that two collection events be defined for each possible alarm condition on the equipment – one event for when the alarm is set, and another for when the alarm is cleared. These collection events allow the GEM event data collection mechanisms to be used to send the additional related information to the host when an alarm changes state.

In addition to providing the time of an alarm state change, Alarm Management on the equipment must allow the Host to request a list of all alarm IDs and associated alarm text. The host must also be able to enable/disable individual alarms on the equipment, and query the equipment for the list of alarms that are currently enabled for reporting.

The state diagram for an Alarm is not very exciting, but it fills a vital need. The picture below illustrates the Alarm State diagram:

GEM alarms only have 2 states: each alarm is either SET or CLEAR. It’s simple but effective.

Alarm Management isn’t rocket science, but through effective use of Alarm Management, fabs can carefully monitor the health of their process equipment and minimize negative impacts to their production yield. 

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:

In the introduction to this series posted December 19, 2017, we listed some of the manufacturing stakeholders whose work objectives are directly addressed by the applications we’ll highlight in subsequent postings. Before getting into the specific capabilities and benefits of these applications, however, it seemed appropriate and timely to share a little bit about the process that the leading EDA practitioners use to ensure the equipment they are purchasing will support these applications. “Appropriate” because you may need to review and update your own purchasing specifications to clearly convey your requirements in the areas that are not directly covered by the standards (like model content, performance, and stability); “timely” because we at Cimetrix have recently conducted a number of customer workshops and seminars in which this process was effectively used and refined.

What do the factories DO with all that data?

Unlike the other postings in this series which deal with specific features and capabilities of the SEMI E30 GEM (Generic Equipment Model) standard, this blog identifies a number of the factory applications that depend on collecting data from the equipment.

Moreover, since we often hear the question “How do the factories actually use the different types of equipment information we’re expected to provide?” this posting will summarize the specific data required to support a number of these applications. This list is by no means exhaustive, but should give you an idea of the range of factory stakeholders whose objectives are supported by GEM data collection.The figure below illustrates the relationship between the Key Performance Indicators (KPIs), the factory stakeholders responsible for optimizing them, the applications used to achieve this, and data required by these applications.

The most effective way to share this kind of information is in tabular form. Within a group of related applications (e.g., scheduling, preventive maintenance), the applications are listed in generally increasing order of complexity, which is also the likely order of implementation by the factory applications development staff.

To the extent that some of the application data described in the table above can be standardized across equipment types, there is an opportunity to create generic factory applications that would only require a mapping from the supplier-specific GEM IDs (collection event IDs, status/data variables, equipment constants, etc.) to their generic counterparts. But this is a topic for another posting on the concepts of “plug-and-play” in a GEM context.

We hope this explanation helps you appreciate how valuable equipment information is for the factories that consume it, and therefore how important it is to provide a rich set of events, variables, and other detailed information in the GEM interfaces you design in the future. 

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:

GEM is an industry standard, which defines standard methods to communicate between process equipment and factory host software for monitoring and controlling purposes. By connecting GEM equipment, factories can immediately experience operational benefits. Factory hosts can collect data in multiple ways. A previous blog post discussed collecting data by using collection event reports where data is pushed to the host based state transitions performed by the equipment. In addition to event reports, the factory host often has a need to poll the equipment for current data values. Data values can be directly requested by the host, or can be sampled on a periodic basis in a trace report. This is called Data Polling and is the topic for today's discussion.

Types of Data

There are three types of data in a GEM interface:

• Data Variable (DV) – data items that can be gathered when an equipment event occurs. This data is only guaranteed to be valid in the context of the event. For example, the GEM interface may provide an event called PPChanged (triggered when a recipe changes). The interface may also provide a data variable called changed recipe. The value of this DV is only valid in the context of the PPChanged event. Polling the value at a different time may have invalid or unexpected data.
• Status Variable (SV) – data items that contain information about the equipment. This data is guaranteed to be valid at any time. For example, the equipment may have a temperature sensor in a process module. The GEM interface may provide a ModuleTemperature status variable. The host can request the value of this SV at any time and expect the value to be accurate.
• Equipment Constant (EC) – data items that contain equipment settings. Equipment Constants determine how equipment will behave. For example, a GEM interface may have an equipment constant called MaxSimultaneousTraces which specifies the maximum number of traces that can be requested simultaneously from the host. The value of equipment constants is always guaranteed to be valid and up to date.

Data Properties

Each of the three data types listed above have similar properties that help define the data. The equipment supplier is responsible for providing these properties in a GEM manual so that the factory host will be able to interact with the data. Some of the important data properties are:

• ID – a numeric ID that must be unique in the GEM interface. These IDs can be grouped by data type and are referred to as SVIDs (Status Variable IDs), DVIDs (Data Variable IDs) and ECIDs (Collection Event IDs).
• Name – a human-readable name for the data item
• Format – the data type of the item. 
  • Data formats can be simple (numeric, ASCII, Boolean) or complex (arrays, lists, structures). For example, numeric types can be I1, I2, I4, I8 (signed integer types of different byte length), U1, U2, U4, U8 (unsigned integer types) and F4 or F8 (floating point types). 
  • List and array types contain multiple values in the data item. For example, image data would be formatted as a byte array. 
  • Structure types contain a specific type of data. For example, a variable may represent a slot map which contains carrier information as well as a list of slots and their wafer placement status.
    
• Value – the actual value of the data item. Data values are in an accurate, efficient, self-describing binary format so that the host will know how to interpret the data. The data format allows for collection of more data more efficiently.

Collection Events (CE) and Alarms also have IDs and names. These items are discussed in other blog posts, but it is important to know about some of the properties for this post because these properties can be queried as well.

Data Polling

As mentioned, the factory host will often get data on a regular basis through trace reports and event reports that it defines. GEM also provides a method for the factory host to poll data based on its needs.

Status Variables

The host can query the value of status variables at any time by sending an S1F3 message containing a list of SVIDs for which to obtain the value. If the list has a length of one, only the value of the single SV will be returned. If the list has a length of zero, the values of all SVs defined in the interface will be returned. The values are returned in a list in an S1F4 message from the equipment.

The host can also request a list of SV names from the equipment by sending an S1F11 message to the equipment. The list rules mentioned above apply to this message as well. The return message will contain an entry for each SV that displays its SVID, Name and Unit.

Equipment Constants

Similar to the way SVs work, the host can also query the values of equipment constants defined in the GEM interface by sending an S2F13 message. The values will be returned from the equipment using an S2F14 message.

Also similar to SVs, the names of ECs can be queried using an S2F29 message.

Data Variables

Since data variables are only valid in the context of a collection event, there is not a method for polling values of data variables. The value of a Data Variable can only be reported in a collection event report.

Other

In addition to the methods for polling data discussed above, the following items can also be obtained from a GEM host by polling the equipment:

• Collection Events (CE) – The host can query what Collection Events are available on the GEM interface along with what DVs are associated with each CE. These are requested using the S1F23 message.
• Alarms – The host can query what Alarms are available on the system by sending an S5F5 message listing the ALIDs of the desired alarms. The return message lists the alarm code and alarm text associated with the ALID. Two status variables are required to be present in every GEM interface. AlarmsEnabled contains a list of IDs of all enabled alarms on the equipment. AlarmsSet contains the list of ID for alarms on the equipment that are currently in the Set state. Since these values are status variables, they can be queried at any time.
• MDLN and SOFTREV – The response to an S1F1 (Are you there?) message will contain the equipment model type (MDLN) and software revision (SOFTREV) for the equipment.
• DateTime – The date and time for the equipment can be requested using an S2F17 message. The host can synchronize the equipment’s time using the S2F31 message. GEM requires the equipment to maintain a Clock SV containing the current time. Allowing the host to query and synchronize time provides the capability to order nearly simultaneous events on the system.

Trace Data Collection

Trace data collection provides a method of sampling data on a periodic basis. The time-based approach to data collection is useful in tracking trends or repeated applications within a time window, or monitoring of continuous data.

When creating a trace definition, the host provides the following:

• Sample period – the time between samples. The resolution is in centiseconds, so it is possible to gather data very quickly using a trace. It is common for equipment so support as fast as a 10 Hz trace interval.
• Group size – number of samples included in a trace report
• SVIDs – List of status data to be included in the trace
• Total samples – number of samples to be taken over the life of the trace
• Trace request id – identifier of the trace request (GEM only allows trace IDs of type integer)

The host defines a trace request by using the S2F23 message. Trace reports are sent from the equipment to the host using the S6F1 message.

Trace Sample

Let’s suppose that a piece of equipment is processing a wafer and the processing takes 5 minutes. It is important to keep the chuck temperature within a certain acceptable range and to make sure that the chamber pressure stays below a specified level. It is sufficient to monitor the values at 15 second intervals, but we can create groups of data to only receive reports once a minute. The host could send an S2F23 message with the following trace configuration:

Trace ID: 100 (ID must be an integer)
Sample Period: 00001500 (take a sample every 15 seconds)
Total Samples: 75 (Samples every 15 seconds for 5 minutes)
Group Size: 4
SVID List:
   300 (ID of the status variable that contains information about chuck temperature)
   301 (ID of the status variable that contains information about chamber pressure)

After one minute, the first trace report will be delivered using an S6F1 message from the equipment. The message will contain the following information:

100 (Trace ID)
4 (last sample number)
2018-01-22T14:20:34.8 (date format depending on TimeFormat equipment constant)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for first sample)
    0.0112 (pressure for first sample)
   219.97 (chuck temperature for second sample)
   0.0122 (pressure for second sample)
   219.97 (chuck temperature for third sample)
   0.0120 (pressure for third sample)
   219.96 (chuck temperature for fourth sample)
   0.0119 (pressure for fourth sample)

After another minute the trace report may look like the following:

100 (Trace ID)
8 (last sample number)
2018-01-22T14:21:34.8 (date time shows one minute later than the first trace)
Status Value List: (Length is 8: 2 SVs with a group size of 4)
   219.96 (chuck temperature for fifth sample)
   0.0112 (pressure for fifth sample)
   219.97
   0.0122
   220.01
   0.0120
   220.00
   0.0119

Three more reports will be received at one-minute intervals. The host can check returned values in the report and react accordingly if values are out of the expected range.

Conclusion

The host could poll status data using S1F3 if it wanted to check a value at a given point in time. It can set up a trace if it wants to continuously collect data over a given period of time.

Using the data sampling methods outlined in this blog will allow host applications to poll the data they need when they need it. GEM provides flexibility in requesting data from the equipment either by allowing the host to query values at a given point in time or to be sampled on a periodic basis using a trace.

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:

Wow – what a great year for Cimetrix and exciting time for our industry!

The president and CEO of Applied Materials recently said, “This is the most exciting time in the history of the electronics industry.” The race is on for faster/better/cheaper devices, cloud computing, autonomous vehicles, Big Data, artificial intelligence, the “Internet of Things” and more. This means the world needs not only a lot more computer chips, but also innovations in chip design, packaging and electronics assembly. The fast moving (and giant) electronics companies driving these trends are also pushing to get far more data from the factory floor to support their “Smart Manufacturing” and “Industry 4.0” initiatives.

2017 was a record setting year for Cimetrix. Revenues increased 34% year-over-year. The Company continued to operate profitably on a quarterly basis with operating income over 10% for the year. We invested heavily in R&D to pursue new technologies and products for long-term growth while strengthening our balance sheet with solid increases in cash and stockholders’ equity.

Going Forward

Cimetrix is uniquely positioned as the world leader in developing and using standards that connect manufacturing equipment to factory software systems. We are second to none in knowledge of “equipment connectivity” standards. We chair the relevant global standards committees, and are well known throughout the industry as experts in this vital domain. In addition, our products are used worldwide in hundreds of thousands of equipment connections. We recently expanded the Cimetrix team with some great new employees located around the world to better serve our growing international customer base, which now includes over 30 factories in Taiwan and China.

Based on what we see, the industries we serve will continue to expand their usage of equipment connectivity standards such as the Generic Equipment Model (GEM) to integrate more equipment into their factory systems, while the more advanced semiconductor manufacturers will accelerate their adoption of the latest Equipment Data Acquisition (EDA) connectivity standards.

While we are very bullish on the longer-term trends for our industry and Cimetrix, it is always a little difficult to forecast short-term results. For 2018, industry analysts are currently predicting a single-digit percentage increase in semiconductor capital equipment spending. While you might think we would be satisfied with another year like we had in 2017, we expect to perform better than the overall industry in 2018 for a number of reasons. First, the “design wins” we worked so hard to earn in prior years should lead to market share gains that result in higher percentages of equipment using Cimetrix software products. Second, we believe the adoption rate will accelerate for the newer EDA equipment connectivity standards, where Cimetrix products are the most proven and widely used in the industry. Lastly, we believe our reputation for providing the highest levels of technical support to customers worldwide, especially in the Japanese, Korean, Taiwanese and Chinese markets, will enable us to continue winning new customers.

From all of us at Cimetrix, we thank our customers and shareholders for the faith and confidence they have placed in our products and our team. We will continue to strive for excellence in satisfying our worldwide base of customers and delighting them with innovative new products. 

To start off our SECS/GEM series, let's begin with an explanation of one of the GEM standard’s key features called Collection Events. We'll start with an explanation as to how they work, then move to why they are so effective for collecting data from manufacturing equipment. 

What are collection events? 

The two words in the name “collection event” are descriptive. 

As denoted by the word “event” a collection event is a notification. Its purpose is to notify the host when something of interest happens at the equipment. The “host” is the factory client software that connects to the equipment’s GEM interface. For example, collection events can report when material arrived, a consumable is running low, a hardware problem occurred, a camera inspected the material, the material is ready to be removed, a chamber reached the target vacuum pressure, processing completion, etc. The equipment can use the collection event feature to report when anything of interest happens. Whoever makes the GEM interface determines exactly what collection events are available to the host; therefore the set of available collection events is different from equipment type to equipment type.

As denoted by the word “collection”, collection events are also capable of publishing data along with the collection event message. It is a very efficient form of data collection, asynchronously providing information as it becomes available. For example, a collection event that reports when material arrives might also report the arriving material’s barcode and location. There are three types of data in a GEM interface; information about the collection event (called data variables), status information (called status variables) and equipment settings (called equipment constants). Whoever makes the GEM interface determines exactly what information will be available for each collection event. So the set of available information for collection events is different from equipment type to equipment type. And the available data is only sent if the host sets up the reports. 

So in summary, a collection event can not only tell the host when something happens but it can also provide more detailed information about what happened and about the status of the equipment. 

A little analogy

As an analogy, think of the factory as a boss and the equipment they purchase as employees. There are many different styles of managing, just like there are different types of factories and styles for running a factory. You don’t want to be forced to run your factory just like someone else’s factory. You want to run it your way.

Additionally, each employee is unique and needs unique level of attention. And each employee is doing unique things. Generally speaking, all managers want to know basic information about employees and what their employees are doing. They want to know when the employee starts a project and when they finish a project. Some employees are very productive even with minimal oversight and reporting. Some employees need extensive oversight and reporting. GEM allow the factory to deal with each equipment uniquely. Specifically, GEM collection events give the equipment a way to report on what it is doing. 

The host has to set up the rules for the reporting and adapt the rules appropriately. For example, sometimes a manager does not care when the employee goes to the bathroom. For certain employees, the manager might want to know. In a GEM interface, the host can choose which notifications occur and which do not. 

Sometimes a manager just needs to be told when the employee does things like when employee arrives, departs, goes on break, and come off break.  Sometimes a manager needs more details, like what project did you finish, how long did it take, the key results of the project. Similarly, GEM allows the host to track not when things happen, but to also provide details about the activity. GEM reports meet this need very effectively. 

Why do you need this feature? 

The short answer is that collection events allow you to track what the equipment is doing in real time. If a factory wants to any degree of Smart Manufacturing or just wants to improve productivity, then one of the first things needed is the ability to track what the equipment is doing. Collection events provide this. You can track equipment utilization, material movement, processing milestones, count cycles of activity for predictive maintenance, consumable usage, and anything else related to the published collection events. The applications for such information are endless.

Sometimes collection events are also used to implement scenarios where the equipment needs information from the host before proceeding or permission to proceed. A collection event tells the host when the equipment is ready for the host instructions or permission.

How does the collection event notification work?

An equipment’s GEM interface can publish many different collection events. The host will not typically want to be notified of all of them at once and it does not have to. Collection events use a publish/subscribe design pattern in two ways.

Basic Publish/Subscribe Notification

The host subscribes to specific collection events to receive notification when they occur. The subscription allows a host to enable or disable the reporting of each collection event available in the GEM interface. The equipment publishes the collection events as they happen.

Event Report Publish/Subscribe Data Collection

By default, a collection event message will not include any data. A subscription also allows the host to decide what data to include in each enabled collection event’s message. The host defines reports and links the reports to collection events; thereby subscribing to the data. Each collection event can have a different report. Reports can also be shared across multiple collection events. A report can include any data variables associated with the collection event, any status variables and any equipment constants. The equipment publishes the collection event with the requested data.

Identification

Each collection event published by the equipment has a unique ID number for identification. The host software uses the ID number when enabling or disabling a collection event. The equipment uses the ID number when the collection event message is sent. Each available data variable, status variable and equipment constant also has a unique ID number. When the host defines a report, it assigned the report a unique ID number.

Broker

The broker to handle all collection event publication/subscription is built into the equipment’s GEM interface. It is part of the equipment system. Communication between the host (a client) and GEM interface is standardized using SECS/GEM communication. Communication between the GEM interface and the rest of the equipment hardware and software (the source of the equipment collection events and data) can be any appropriate technology and does not matter as long as the GEM interface functions properly and performs sufficiently well.

This means that messages are only sent from the equipment to the host when the host has subscribed. Having the broker as part of the equipment and GEM interface makes the GEM interface very efficient and use much less bandwidth than protocols that use an external broker where all messages and data have to be sent to a broker all the time.

Persistence

The collection event subscriptions are persisted in a GEM interface. So if the host disconnects and reconnects, or if the equipment is restarted, the GEM interface will remember the setup of all subscriptions.

Which messages are used?

Here is a summary of each of the primary messages related to collection events. Note that the “S” identifies the “stream” and “F” identifies the “function”. Together, a stream and function number uniquely identify a message. 

Frequently Asked Questions about Collection Events

How much bandwidth do collection events require?

This depends on several factors. 

1. The number of collection events that are enabled by the host. 
2. The size of the data reports linked to the collection events. 
3. The frequency at which the enabled collection events are triggered by the equipment. This depends on the meaning of the collection event. 

How fast can collection events be triggered?

The GEM standard does not limit collection event frequency and uses standard communication hardware. In other words, by improving the hardware you can allow for faster collection events.

GEM allows for two protocols: SECS-I and HSMS. SECS-I is based on RS-232 serial communication and therefore little used today. Such implementations are not able to trigger collection events very quickly.

HSMS is based on network communication. Because serial communication is slow, by far most GEM implementations use HSMS. GEM uses TCP/IP very efficiently. The possible frequency of collection events depends on the speed of the network hardware, equipment computer performance, and host computer performance. Like most protocols, it usually takes more computer resources to consume messages than it does to produce them.

The speed at which collection events can be generated also depends on the data reports linked to the collection events. For example, if a data report is large, like 10 MB, this will impact performance.

Why aren’t I receiving the collection event messages? 

There are a few reasons why a host might not receive collection event messages. 

1. Host and equipment must have established GEM communication using a successful S1F13/S1F14 exchange.
2. GEM control state must be on-line. It cannot be in a host-offline or equipment-offline state. 
3. GEM spooling must be inactive. To disable spooling while it is active will not make spooling go inactive. If the spooled messages are not wanted, then purge spooling using message S6F23. If the spooled messages are wanted, then request them iteratively using S6F23 until the spooling state becomes inactive.
4. The collection event must be enabled. Use S1F3 to check the “EventsEnabled” status variable to confirm that the collection event is enabled. Use message S2F37 to enable the collection event. 
5. The collection event activity needs to occur. For example, a collection event reporting when material arrives will never occur if material does not actually arrive. If the activity happens and the above conditions are satisfied, then the equipment’s GEM interface has a defect. 

What if an equipment’s GEM interface does not publish the collection event I need?

Ask the equipment supplier to add the desired collection event. It is difficult for an equipment supplier to accurately predict all collection events that the factories will want. The equipment supplier will need to upgrade their GEM interface software at the factory.

How large of data reports can be when linked to a collection event?

GEM allows a single data variable value or status variable value to be an array or structure of any data type including a floating point, string or integer. A single array is limited to 16.777215 MB. Total message size is limited to 4.294967295 GB.

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