This guide is intended to give an overview tutorial 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.
Although this tutorial attempts to give you a high level understanding of SECS/GEM in the most simplest way possible, however developing a SECS/GEM driver from scratch for your business isn't easy. In fact, 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 simplifies these complexity, automate most the GEM messages, so that you can build a cost effective and time to market SECS/GEM solution.
Checkout our flagship product below to learn more about SECS/GEM and how our products can help in your development, contact our Sales Representative: sales@insphere.com.sg
What is SECS/GEM?
SECS (SEMI Equipment Communication Standards) and GEM (Generic Model For Communications and Control Of Manufacturing Equipment) standard is published and maintained by SEMI.org, an international organization of semiconductor manufacturers, is an organization body that governs the standard for semiconductor manufacturing.
It is the main communication protocol used in automation for (initially) semiconductor/electronics industries, however, today it has been widely adopted in photovoltaic and SMT industries too.
It provides a communication interface between equipments and host systems.
Unlike other communication protocol like PLC, it enable equipments from variety of vendors to communicate using standard and consistent protocol with various type of Host systems.
To understand the SECS/GEM standards you will need to purchase the following 3 basic standards from SEMI:
SEMI E30 GEM Standard - This is the "Brain" that defines the behaviours 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. It also defines the functionalities like Status Data Collections, Trace Data Collection, Alarms Management, Spooling, Remote Command, etc.
SEMI E5 SECS-II - Defines the details of the interpretation of messages (APIs) exchanged between equipment a host. It also defines message inputs/outputs data structure, data item format, acknowledgement codes, etc.
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. This is also the layer where the SECS-II messages are encoded into HSMS message format.
Let's take a closer at the diagram below where it gives a good high level illustration of the command from GEM flows to SECS-II and all the way to HSMS layer.
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.
Communication
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
Control
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).
Processing
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.
Variables
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.
Discrete 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 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.
Documentation
The SECS/GEM standard requires that each equipment supplier 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.
SEMI E5 SECS-II Message
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
Where:
Stream ID = Message stream/category
Function ID = Function identifier of the message. Each stream has multiple functions. Odd Function ID denotes Primary message (request) while even Function ID (SnFm+1) denotes the Secondary/Reply message
Mnemonic = Short forms of the message
S,M = S=Single, M=Multi-block
H,E = H=Host, E=Equipment
Message Directions = Denotes the valid message direction. Some messages only is valid for single direction (e.g.: H->E or H<-E), however certain messages can be for bi-directional (H<->E). E.g.: S1F13 Establish Communication (H<->E)
Reply = Denotes whether or not the message required reply.
Description
A description of the action generated by the function.
Structure
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
Exception
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)
SEMI E37 HSMS
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:
T3 Reply Timeout: Specifies maximum amount of time an entity expecting a reply message will wait for that reply
T5 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: Specifies the time which a control transaction may remain open before it is considered a communications failure.
T7 Not Selected timeout: Specifies 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 Inter-character Timeout: Maximum time between successive bytes of a single HSMS message