Wednesday, 16 January 2019

Introduction to SECS/GEM - Beginner's Guide

Article Index
Introduction to SECS/GEM - Beginner's Guide
SEMI E30 GEM standard
How We Can Help You
All Pages

This guide is intended to give an overview and basic introduction of SECS/GEM and its usage in the semiconductor industry to the beginner. And It is NOT INTENDED to substitute or serve as complete reference of the standards. For a complete reference of the standards, please refer to SEMI.

If you would like to learn more about SECS/GEM and how our products can help in your development, please contact our Sales Representative: This e-mail address is being protected from spambots. You need JavaScript enabled to view it

Introduction to SECS/GEM Standard

SECS (SEMI Equipment Communication Standards) and GEM (Generic Model For Communications and Control Of Manufacturing Equipment) standard is published and maintained by, an international organization of semiconductor manufacturers, is an organization body that governs the standard for semiconductor manufacturing. To understand the SECS/GEM standards you will need to purchase the following 3 basic standards from SEMI:

  • SEMI E30 GEM Standard - Defines the behaviors of equipment (Business Rules), state machine and some rules like which SECS-II messages should be used, in what situations, and what the resulting activity should be.
  • SEMI E5 SECS-II - Defines the details of the interpretation of messages (APIs) exchanged between equipment a host.
  • SEMI E37 HSMS - High Speed SECS Message Services. This is a transport layer based on TCP/IP protocol and a successor of the previous SEMI E4 SECS-I standard that is based on serial communication.

SECS/GEM interface is developed in the 80s but the concept to the modern technology is very similar. As an illustration, let's consider Web Service technology. An enterprise application server uses Web Service to interface with other services or hosts via HTTP or TCP/IP. And let's compare each layer to the SECS/GEM:

Comparison Web Service vs SECS/GEM
Comparison Modern Technology - Web service SEMI - SECS/GEM
Behaviors, Business Rules "Enterprise Application Server" defines all the business rules and behaviors of the application. In SECS/GEM, SEMI E30 GEM standard defines the generic equipment behaviors, state machines, rules that govern what the Host can or can't do.
Message Protocol Web services uses SOAP message which details the messages structure exchanged between Client/Server. In SECS/GEM, SEMI E5 SECS-II uses SML (SEMI Markup Language) to define the message details and structure to be exchanged between Equipment/Host.
Transport Protocol Web services SOAP messages can be transported via HTTP or TCP/IP protocol. In SECS/GEM, SECS-II messages can be transported with SEMI E37 HSMS over TCP/IP protocol.

SEMI E30 GEM Standard

The GEM standard defines a common set of equipment behavior and communications capabilities that provide the functionality and flexibility to support the manufacturing automation programs of semiconductor device manufacturers. Equipment suppliers may provide additional SECS-II functionality not included in GEM as long as the additional functionality does not conflict with any of the behavior or capabilities defined in GEM. Such additions may include SECS-II messages, collection events, alarms, remote command codes, processing states, variable data items (data values, status values or equipment constants), or other functionality that is unique to a class (etchers, steppers, etc.) or specific instance of equipment.


The COMMUNICATION state model defines the behavior of the equipment in relation to the existence or absence of a communication link with the host. It also defines how communication is established or re-established with S1F13/S1F14 when communication is broken


The CONTROL state model defines the level of cooperation between the host and equipment. The CONTROL model provides the host with three basic levels of host control which determine the host's ability to control the equipment:

  • OFFLINE (Lowest Level): Operation of the equipment is performed manually by the operator at the operator console. Equipment will respond with an SxF0 to any primary message from the host other than S1F13 or S1F17.
  • ONLINE/LOCAL (Middle Level): In this state, the host is only allowed to perform "read-only" operation like data collection. The host shall be prohibited from modifying any equipment constants that affect processes, remote commands that cause physical movement or which initiate processing.
  • ONLINE/REMOTE (Highest Level): In this state, the host may operate the equipment to the full extent available through the communications interface ("read-write" operations).


The PROCESSING state model is highly dependent on the equipment process, technology, and style. However, there are expected to be common aspects to these models.

Remote Command

Host can send command to instruct the equipment to perform an automatic operation. E.g.: START, STOP, PAUSE, etc. This is similar to the manual operation performed by operator on the console.


The GEM standard defines three types of variable which are accessible by the Host:

  • Status Variable: This is a "readonly" global variable defined in the equipment. Whenever there is a processing the equipment will update the respective status variable to reflect the latest data. E.g.: incremental of some counter, current/previous state, etc.
  • Equipment Constant: This is a "read-write" global variable defined in the equipment. Host can set or modify the equipment constant variable which may affect the setting that in turn change the way equipment's behaviors.
  • Data Variable: This is a "local" variable which only exists in collection event.

Data Collection

SECS/GEM a couple of avenues for Host to collect data or information from the equipment:

  • A set of status variable values can be requested at anytime using S1F3 command.
  • A set of equipment constant values can be requested at anytime using S2F13
  • Host can define report containing status variable, equipment constants and data variable then attaching it to a collection event. When equipment raise the event (using S6F11 command), the report containing those variable's values will be sent together.
  • Host can define traces which will do sampling of status variable data at a periodic basis.
  • Another way is leverage on alarm notification to collect more data with collection event. By standard, whenever an occurrence or clearance of an alarm, an event (collection event) must be sent to Host.

Alarm Notification

This feature allows the Equipment to notify Host for every occurrence or clearance of an alarm/error on the equipment. Alarm refers to those occurrence that are abnormal, undesirable and endanger people, equipment or physical material being processed.

Below are some of the characteristics of Alarm Management defined by GEM:

  • Each alarm has two associated state model. ALARM SET (occurrence) and ALARM CLEAR (clearance)
  • Each AlarmSet and AlarmClear has an associated Collection Event. This is to address the host's potential need for more extensive and flexible data reporting.
  • Host can requests which Alarms to be enabled/disabled and Equipment will only notify the Host for the enabled Alarms.


The SECS/GEM standard requires that each equipment provide a GEM Interface Reference Manual. It must include GEM Compliance statement, Complete SECS-II message documentation, State Model, list of status variables, equipment constants, data variables, alarms, collection events, etc that are defined/supported by the equipment.

And Many More...

Please refer to the complete standard for other features like: Spooling, Process Program, Terminal Services and Limit Monitoring.


As described in the article's introduction section, this standard provides the APIs for interfacing between Host and Equipment. In this standard, each message is represented in Function and grouped in Stream (category).

Like Webservice, each SECS-II message consist of Header (which typically contains the method/function name, transaction type=request/reply) and Body (which specify the parameter's name and type). In some functions, the Body may be empty.

Below describes the convention of the SECS-II Message Structure

Message Header

Fn Identifier Fn Name/Description Message Block Message Direction Need Reply
Sn,Fm Name of Function (XXX)





reply (required)

"blank" (no reply required)


  • Sn = Stream n
  • Fm = Function m. Odd function number denotes Primary message (request) while even function number (SnFm+1) denotes the Secondary/Reply message
  • (XXX) = Short mnemonic
  • S,M = S=Single, M=Multi-block
  • H,E = H=Host, E=Equipment


A description of the action generated by the function.


The function's message body. Detailed structure showing lists and defined items. Lists are denoted by a capital L followed by the length seprated by a comma. The individual elements in the list are numbered on seprate lines.

Nested lists are indented to emphasize the structure. The detailed form of the items is given in the define section at the beginning of the transaction. The symbols "<" and ">" are used to item header. A detailed description of each data item as well as a list of the allowable data formats can be found in the Data Item Dictionary


Special cases in the structure that have a different meaning. 
Sn,Fm+1 Name of function (same structure as above (secondary) except never with reply)


HSMS is the transport layer built on top of the TCP/IP protocol and it is intended as an alternative to SEMI E4 (SECS I) for applications where higher speed communication is needed or when a simple point to point topology is insufficient.

TCP/IP Settings

As HSMS protocol is derived from TCP/IP, the following settings are required for both Host (client) and Equipment (Server):

  • ConnectionMode: ACTIVE/PASSIVE Mode. ACTIVE Mode is normally on the Host side while PASSIVEMode (Listening) is on the Equipment side. However there is no restriction to use it vice versa.
  • Local IP Address and PortNumber: Required for any entity operating in PASSIVE mode. Determines the address on which the local entity will listen for incoming connection request. Typically Equipment is operating in this mode.
  • Remote IP Address and PortNumber: Required for any entity operating in ACTIVE mode. Determines the address of the remote entity to which the local entity will attempt to connect. Typically Host is operating in this mode.

HSMS Timeout Settings

Implementations of HSMS must provide for installation time setting of the following parameters.  The range and resolution of all parameters must be at least as shown in the table.

Parameter Name Range Typical Settings SEMI - SECS/GEM
T3 Reply Timeout 1-120 secs 45 secs Reply timeout.  Specifies maximum amount of time an entity expecting a reply message will wait for that reply
T5 Connection Separation Timeout 1-240 secs 10 secs Connection Separation Timeout.  Specifies the amount of time which must elapse between successive attempts to connect to a given remote entity
T6 Control Transaction Timeout 1-240 secs 5 secs Control Transaction Timeout.  Specifies the time which a control transaction may remain open before it is considered a communications failure.
T7 Not Selected timeout 1-240 secs 10 secs Time which a TCP/IP connection can remain in NOT SELECTED state (i.e., no HSMS activity) before it isconsidered a communications failure
T8 Network Intercharacter Timeout 1-120 secs 5 secs Maximum time between successive bytes of a single HSMS message

How We Can Help You

As demonstrated in this tutorial, building the SECS/GEM driver for your business isn't simple. It's easy to spend more than you need, but there are also opportunities to save money and improve operational efficiency that you don't want to miss. It's hard to learn everything you need to know and still perform your daily job.

INSPHERE TECHNOLOGY products can simplify these complexity, build a cost effective and time to market solution for your Host SECS/GEM driver and Equipment SECS/GEM driver. Check out our product section today!