Industry News, Trends and Technology, and Standards Updates

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:

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:

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:

After the Taiwan Printed Circuit Board Association (TPCA) chose the Generic Model for Communication and Control of Manufacturing Equipment (GEM) standard for equipment connectivity, they asked Cimetrix to present at a TCPA technical conference explaining some of the most important features and benefits of GEM.  After Brian Rubow (Cimetrix Director of Client Training and Support) presented they asked him to write a summarizing article which was published by TPCA during the October 2017 TPCA show. Today, we are re-publishing the article as we launch an extensive features/benefits blog series coming up in 2018. 

SECS/GEM refers to a set of SEMI standards that govern the communication between manufacturing equipment and factory host computer systems. The Message layer standard, SEMI E5 SECS-II, defines a generic message structure and a library consisting of many standardized messages. The Protocol layer standard, SEMI E37 High-Speed Message Service (HSMS), defines a binary structure to transfer SECS-II messages using TCP/IP. SEMI E30 GEM, defines a minimum set of requirements, additional (optional) capabilities, use cases and user scenarios for a subset of SECS-II messages. 

SECS/GEM is implemented on an equipment, and is used by the factory to implement command and control functions. Since it is an industry standard, any SECS/GEM-compliant host software can communicate with any SECS/GEM-compliant equipment. When fully implemented on the equipment, the standards enable factory software to completely control and monitor the equipment by means of its SECS/GEM interface. These standards provide numerous benefits to both equipment manufacturers and factories. Several of these benefits are highlighted in this article.

SECS/GEM Reduces Equipment Integration Costs

Factories are typically owned and operated by multinational enterprises which purchase equipment from a variety of equipment manufacturers. Even though the control software is different on every equipment, the factory is required to integrate the equipment to operate in harmony. While it is possible to independently integrate each equipment with custom software, this is not cost or time effective. 

The situation is similar for equipment manufacturers, who sell their products to diverse factories across the globe. Data collection and application software at every factory are different. The equipment manufacturer is required to help the factory integrate the purchased equipment. While it is possible to develop a custom integration solution for each factory, this is again not cost effective. Every time a factory asks for custom integration features, these costs get passed on to the factory itself.

Custom software, whether developed by the equipment manufacturer or the factory, is expensive to create and maintain, and tends to be of lower quality than desired. By contrast, the SECS/GEM standards define how to create a standardized interface on any manufacturing equipment. Equipment manufacturers benefit by developing one interface for all of their customers. Factories benefit by reusing the same integration software for all of their purchased equipment. Reuse of this software and technology both by the factory and equipment manufacturer raises the software quality, reduces costs and allows for more functionality. The equipment manufacturer and factory alike can invest not only in the minimum features required, they can also implement advanced functionality that is otherwise unaffordable. If they only have to support SECS/GEM, then equipment manufacturers can publish more data and support more advanced control. In turn, factories can then use the additional data to improve product quality and productivity. 

SECS/GEM Is Applicable to All Manufacturing Equipment 

Because SECS/GEM is divided into Fundamental Requirements and Additional Capabilities, it can be implemented on any manufacturing equipment, regardless of size and complexity. Additional Capabilities are optional because they are not always needed. For example, some equipment do not have recipes and therefore do not need to implement the Recipe Management Additional Capability. 

SECS/GEM also scales well with the magnitude of an equipment’s data. For example, a very simple equipment or device might publish 10 different collection events, whereas a complex equipment might publish 5000 different collection events; yet both can use the same SECS/GEM technology. 

Innumerable Applications Can Be Supported Using a SECS/GEM Interface

Everything that happens on an equipment can be tracked. Any remote control features and system configuration can be supported. The more data that is published by an equipment, the more software applications a factory can implement. A SECS/GEM interface makes it possible to implement applications for statistical process control, troubleshooting, predictive maintenance, feedforward/feedback process control, equipment utilization, material tracking, recipe validation and many more. Such applications often reduce the need for an operator interface on the equipment, thereby reducing the number of operators in the factory. Recipe management allows factories to minimize scrap. For example, use the SECS/GEM interface to store golden recipes in a central location and also to ensure that the correct recipe is used on the material. 

SECS/GEM Uses Network Bandwidth Very Efficiently

There are several features that make SECS/GEM naturally efficient. First of all, every SECS/GEM interface acts as a message broker. Because the broker runs on the equipment, unsubscribed data is not published on the network. For host software to receive alarm, collection event, or trace data messages, it must first subscribe. Since subscriptions for each alarm, collection event, and trace data are managed separately, the equipment can implement a single SECS/GEM interface that publishes all alarms, collection events and trace data requested by all factory applications without wasting network bandwidth with unnecessary data. Moreover, when the host subscribes for trace data, it specifies the data collection rate, making SECS/GEM much more efficient and useful than protocols that publish data at a hard-coded rate. 

Additionally, all SECS/GEM messages are always transmitted in an efficient binary format. This uses much less bandwidth than protocols that transmit in ASCII format. Despite using a binary format, SECS/GEM messages are also easily converted to and from a standardized XML notation. 

SECS/GEM Enjoys Enormous Industry Support 

SECS/GEM has been the backbone of factory/equipment communication and control systems for years in the semiconductor industry. This means that all semiconductor manufacturing today completely relies on SECS/GEM communication. 300mm semiconductor factories have been running with full automation based on SECS/GEM communication since the late 90s—large companies like TSMC, Samsung, Micron, Intel, Toshiba and many others utilize SECS/GEM 24/7 in every factory. Other industries like Flat Panel Display, High-Brightness LED and Photovoltaic have also officially adopted SECS/GEM because they recognized how SECS/GEM features can be applied to any manufacturing equipment to support mission-critical applications.

SECS/GEM Is Self-Describing

Although the standard requires GEM documentation to be provided with the equipment, SECS/GEM supports multiple approaches for host software to automatically adapt to an equipment’s SECS/GEM interface. There are messages for the host software to ask for the list of available alarms, status variables, equipment constants, and, for newer implementations, a list of available collection events and data variables. These messages make SECS/GEM plug-and-play. Additionally, the equipment manufacturer can provide a standardized XML file that provides a full description of the SECS/GEM interface and its features. 

Summary

These are just some of the many benefits of using SECS/GEM technology, both for factories and equipment manufacturers. SECS/GEM is proven technology that is available today.