|Introduction to SECS/GEM - Beginner's Guide|
|SEMI E30 GEM standard|
|SEMI E5 SECS-II Message|
|SEMI E37 HSMS|
|How We Can Help You|
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.
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. To understand the SECS/GEM standards you will need to purchase the following 3 basic standards from SEMI:
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||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.|
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:
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.
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:
SECS/GEM a couple of avenues for Host to collect data or information from the equipment:
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:
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.
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
|Fn Identifier||Fn Name/Description||Message Block||Message Direction||Need Reply|
|Sn,Fm||Name of Function (XXX)||
"blank" (no reply required)
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.
As HSMS protocol is derived from TCP/IP, the following settings are required for both Host (client) and Equipment (Server):
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|
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 and Equipment software. Check out our product section today!