SECS/GEM Lessons and Concepts

More on this topic will be added from time to time, but the information below should be useful to everyone wondering what SECS/GEM is, what it is used for, and basic concepts. Also you will read about how TransSECS makes SECS/GEM so much easier for both process tool interfaces and fab or factory Host application.

SEMI first published the standards for semiconductor tool and host communication in the 1970s as SEMI E5. Most tools with SECS interfaces at this period of time used SECS-I (defined by SEMI E4), serial port communication, between the tool and the host. As time went on, in the 1980's E37 was added to allow tools and hosts to communicate using HSMS (SECS-II) over Ethernet. TransSECS supports communication using either SECS-I (SECSI) or HSMS (SECSII). The GEM (Generic Equipment Model) standard E30 was added about the time of HSMS. This enhanced the basic E5 with better messaging between the process tool and host and defines basic requirements for a tool model (such as required messages and required data which can be provided to the host at any time it is requested). Nowadays most new process tools support SECS/GEM using HSMS. ErgoTech has been providing software to easily integrate data from databases, devices and PLCs into SECS/GEM interfaces since the 1990s and satisfies all the basic requirements of GEM for a tool.

When you read the SECS/GEM manual it's a confusing set of messages defined by streams and functions so you'll see references to S1F3, S2F35, S6F11, etc.

These messages do represent the underlying protocol, but can be, for the most part, transparent to a SECS/GEM implementation.

At its core, SECS/GEM is about ID/Value pairs. In the GEM standard, the ID is numeric. If you're building a host application, the manual will list these IDs. If you're building a tool interface, you get to assign suitable values. When building a host you can also use the "Tool Characterization" function of TransSECS to pull all the IDs live from the tool, saving hours of reading manuals and typing and ensuring the information is accurate.

The primary IDs are VIDs - value IDs. These just represent values that can be read from the tool (and sometimes written).

Two other fundamental IDs are ALIDs - Alarm IDs. These are pretty self explanatory - a high value indicates and alarm state, when the alarm is reset (low) to clear the alarm.

CEIDs are “Collection Event Ids” . A collection event, or simply an event, is something of interest that happens in the tool. Examples, might be lot loaded, process started, process ended, etc. Tool vendors are free to create as many events as they wish to allow the host to follow operation of the tool. At a minimum there should be sufficient events to allow the host to track product through the tool, usually events like load, start, end unload.

Host application can enable and disable events and alarms essentially choosing which they want to “listen” for. From the equipment vendor standpoint this generally means that it's better to add more alarms and events and allow the host to choose only those of interest rather than have too few and limit the hosts ability to track the tool and collect data.

The host can associate “reports” with events - this is the RPTID. A report is a collection of VIDs. Each time the tool triggers an event the reports, and so the values associated with the event are sent to the host as part of the event message.

A “report” is a fundamental part of data collection. The challenge is that reports contain only values, not the original IDs so the host has to map from the original configuration to the values to understand the significance of each value.

When you configure reports in TransSECS and link them to CEIDs, TransSECS will do this work for you. Of course, you can do much more with the data. TransSECS can perform automatic mapping of reports to SQL. Using the names of the variables TranSECS will dynamically control the schema of the database and store the contents of the report each time it is received from the tool. You can go from nothing to full data collection with a few keystrokes and in a matter of hours.

There are subsets of VIDs. SVIDs, which are values that are written by the equipment and read by the host. Similar to SVIDs are DVIDs.

There is often a lot of confusion understanding the difference between SVIDs and DVIDs, when they should be used, their association with event reports, and other details. Generally, you can think of the difference like this:

SVIDs are “Status Variables” and the value is updated by the tool periodically and the host can request the latest value in several ways, including the simple S1F3, a trace message S6F1, or in an event report. The SVID could have been updated days ago, seconds ago, or some other time ago, it depends on when the tool last updated the value. Usually these values will be updated periodically, such as a process temperature read every second or so.

DVIDs are designed to be used by event reports, and are often described as “associated” with an event. The data value sent in the associated event message is guaranteed to be “fresh”, updated at the time of the event trigger. If an S1F3 sometime later requests this DVID value (known as a DVVAL), it will probably contain the same values as it did for the last event, not necessarily updated since that time.

Data collection - from zero to data in a database can be accomplished directly by TransSECS with a few key presses. You can even use our pre-configured system with a web-interface for data collection.

Tool control, the ability to start and stop the tool take a little more effort, but not too much. Tool control, sending “Remote Commands” is also based around ID/Value pairs. The S2F41 and S2F49 messages contain lists of CPName/CPVal pairs.

Creating and using these messages in TransSECS is fairly simple, but it does depend on where you're getting the data. TransSECS supports getting data from everything from MES systems, databases, OPC (servers and clients) to small controller and PLCs small controller and PLCs.