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.

The purpose of SECS/GEM is to send messages with data, instructions, recipes, commands, events, and alarms to and from process tools and fab or factory hosts which collect data and monitor the fab production and processes. So there are a few basic messages and data types which are widely used in SECS/GEM applications.

From a fab Host point of view, data is gold. The only way a Host is going to be able to monitor the processing of lots and wafers in the fab is to collect data from the tools. The fab host is also responsible to send the tools instructions, commands, and recipes to run for the specific lots.

Data in SECS/GEM messages are specific types as defined in the SEMI standard, such as Strings (type 20), Floats (type 44, 45, etc.), unsigned integers (type 51, 52, 54, etc.) and signed integers (31, 34, etc.), as well as boolean (type 10) and bytes (type 11).

IDs in SECS/GEM are the base unit data container and are one of the specific types described above. IDs in SECS/GEM come in several types used for different purposes: VIDs (Value IDs), which are SVIDs (Status Variables), ECIDs (Equipment Constants), and DVIDs (Data Variables). Also there are ALIDs (Alarms), CEIDs (Collection Events), and RPTIDs (Reports).

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.

From a TransSECS point of view, SECS/GEM messages are containers for data but some also require action when received. TransSECS allows you to connect data to the items in a message, and also respond to these messages either automatically (for most GEM messages) or, if needed, run a script (see examples of message handling). The items in a message can be either a source or sink for the data values. In other words, message data items are updated from data sources for an outgoing message, or for an incoming message the data can be captured and stored or processed. One of the most important message groups for TransSECS host applications are the event report messages from the tool. Since events signal an important process stage for the tool, the associated event messages contain not only the signal that the event has occurred, but also important associated data.

Messages usually expect a reply, which can be a simple acknowledgement or a complex response with requested information, from the recipient to complete the handshaking between the tool and host. If the recipient does not understand the message (the message is not defined, for example), the reply might be a generic S9Fx message. TransSECS will automatically handle responses to unknown messages.