SECS Messaging Primer - Cimetrix

SECS Messaging Primer WP

www.cimetrix.com Page 1 of 14

TABLE OF CONTENTS 1 Overview of SECS/GEM Standards ..................................................................................... 3 2 HSMS – High-Speed SECS Message Services ...................................................................... 3 3 SECS Messaging Concepts ................................................................................................. 4 4 HSMS ........................................................................................................ ........................... 5

4.1 IP Address and TCP/IP Port .............................................................................................. ............................. 5 4.2 Modes............................................................................................................................................................... 5

4.2.1 Active Mode IP Address and TCP/IP Port .................................................................................. 5 4.2.2 Passive Mode IP Address and TCP/IP Port ................................................................................ 5

4.3 Device ID .........................................................................................................................................................6 4.4 Link Test .......................................................................................................................................................... 6 4.5 Protocol Timers .............................................................................................................................................. 6

5 SECS-II .............................................................................................................. ................... 7 5.1 Message Pairs ................................................................................................................................................. 7 5.2 Common Streams .......................................................................................................................................... 7

5.2.1 Steam 1 Equipment Status ........................................................................................................... 7 5.2.2 Stream 2 Equipment Control and Diagnostics .......................................................................... 8 5.2.3 Stream 5 Exception Handling ...................................................................................................... 8 5.2.4 Stream 6 Data Collection ............................................................................................................. 8 5.2.5 Stream 7 Process Program Management .................................................................................. 9 5.2.6 Stream 9 System Errors................................................................................................................. 9

5.3 Message Bodies ............................................................................................................................................. 11 6 GEM ................................................................................................................ ................... 12 7 Troubleshooting Common Problems ................................................................................ 13

7.1 Cannot Connect ........................................................................................................................................... 13 7.2 Connection Dropping and Reconnecting ................................................................................................ 13 7.3 Receiving Many S9F9 Messages ................................................................................................................ 13 7.4 Host Receives S9F7 from the Equipment ................................................................................................. 13 7.5 Which of My Network Cards (NICs) Will Be Used? .................................................................................. 13

8 Glossary ........................................................................................................... ................. 14

www.cimetrix.com June 15, 2020

SECS Messaging Primer



- NOTICE -

The information contained in this document is subject to change without notice. Every effort has been made to supply complete and accurate information. However, Cimetrix Inc. makes no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Cimetrix shall not be liable for errors contained herein or direct, indirect, special, incidental, or consequential damages in connection with the furnishing, performance, or use of this document.

- COPYRIGHT -

©2016 Cimetrix Incorporated. All rights reserved. No part of this work may be copied, modified, distributed in any form or by any means, or stored in any database or retrieval system, without the prior written permission of Cimetrix Incorporated, except as permitted by law. Violation of copyright carries civil and criminal penalties.

- TRADEMARKS -

Cimetrix is a registered trademark. CIM300, CIMConnect, CIMFoundation, CIM40, CIM87, CIM90, CIM94, CIM58, CIM116, CIM148, CIM157, SECSConnect, ECCE Plus, TESTConnect, CIMPortal, CIMPortal Plus, EDAConnect, and CIMControlFramework (CCF) are trademarks of Cimetrix Incorporated. All other registered trademarks and trademarks are properties of their respective holders.

Cimetrix® 6979 High Tech Dr Midvale, UT 84047

Phone: 801.256.6500 www.cimetrix.com



1 Overview of SECS/GEM Standards This primer is a companion to the Introduction to the SEMI Standards: SECS/GEM white paper available on the Cimetrix SEMI Standards web page. That white paper provides an overview of the SEMI SECS/GEM standard. This primer is intended for anyone who needs to learn how to connect an instrument or a machine with a GEM (Generic Equipment Model) interface using the SECS-II messaging standard. It also provides the underlying information needed by the manufacturing company’s equipment interface engineers or the QA personnel responsible for testing a new piece of equipment or other instruments. SECS/GEM refers to the SEMI SECS-II (E5) and GEM (E30) standards. Manufacturing equipment worldwide in the semiconductor (front end and back end), surface mount technology, electronics assembly, photovoltaic, and flat panel display industries may provide a GEM interface so that the factory host software can monitor equipment performance and control processes. The Generic Model for Communications and Control of Manufacturing Equipment (GEM) standard is maintained and published by the non-profit organization Semiconductor Equipment and Materials International (SEMI). Generally speaking, the GEM standard defines messages, state machines, and scenarios to enable factory software to monitor and control manufacturing equipment. The GEM standard is formally designated as SEMI standard E30, but frequently simply referred to as the GEM or SECS/GEM standard. The intent of the GEM standard is to establish a common set of equipment behavior and communications capabilities that provide the functionality and flexibility to support the manufacturing automation programs of semiconductor and other electronics device manufacturers. All GEM-compliant manufacturing equipment share a consistent interface and behavior. GEM equipment communicates with a GEM-capable host via TCP/IP using the HSMS standard, SEMI E37. Every machine can be monitored and controlled using a common set of SECS-II messages specified by SECS/GEM. When a machine has a GEM interface, it takes much less time for the factory GEM host software developers to establish communications and begin monitoring the machine's activity. This means that equipment manufacturers can spend more time and money improving the machine's process capability and other differentiating features by providing a common interface to all factories. It likewise means that factories can spend more time and money improving production operations and processes, rather than setting up communication to the machines. In a factory SECS/GEM implementation, there are two parties, the host and equipment. The equipment runs GEM interface software on one of its computers that must implement and comply with the SEMI standards. The manufacturer (factory) runs GEM host software that establishes communication with the equipment's GEM interface. A host may also be called a station controller or line manager. Often the host software is part of the factory's Manufacturing Execution System (MES). A host system can communicate with one or multiple equipment GEM interfaces at the same time. The host communicates directly with each piece of equipment using HSMS. SECS-II messages over HSMS are also sometimes used within a piece of equipment to connect to a specific subsystem, such as an EFEM controller or Metrology Module.

2 HSMS – High-Speed SECS Message Services SEMI E37 High-Speed SECS Message Services (HSMS) is the primary SEMI SECS/GEM transport protocol standard in general use today. HSMS defines a TCP/IP-based Ethernet connection used by GEM for host/equipment communication. It is used for applications where higher speed communication is needed and the facilitated hardware setup is convenient. HSMS provides a means for independent manufacturers to produce implementations which can be connected and interoperate without requiring specific knowledge of one another. This is the transport protocol required in all 300mm fabs.

https://www.cimetrix.com/secsgem-overview

https://www.cimetrix.com/SEMI-Standards

https://www.cimetrix.com/SEMI-Standards

http://www.cimetrix.com/secs-ii

http://www.cimetrix.com/semi-secs-gem-intro

http://www.cimetrix.com/secs-gem-industrial-uses#semiconductor

http://www.cimetrix.com/secs-gem-industrial-uses#surfacemount

http://www.cimetrix.com/secs-gem-industrial-uses#pv

http://www.cimetrix.com/secs-gem-industrial-uses#flatpanel

http://www.cimetrix.com/cimconnect.cfm

http://www.cimetrix.com/hsms

http://www.cimetrix.com/secs-ii

http://www.cimetrix.com/CIMConnect



The HSMS Standard defines message exchange procedures for using the TCP/IP network protocol.

• Establishing a communication link between entities using a TCP/IP connection procedure • Developing and maintaining the protocol conventions necessary for exchanging SECS messages between entities • Sending and receiving data using TCP/IP • Recognizing error conditions • Ending communications formally to confirm both parties no longer need the TCP/IP connection • Breaking the communications link logically without any physical disconnect from the network medium • Testing the communications link for the purpose of connection integrity • Rejecting connection attempts from incompatible subsidiary standards

In addition, the SEMI E37 standard describes special considerations, such as network timeouts, and handling multiple connections, which should be taken into account in a TCP/IP implementation.

3 SECS Messaging Concepts SECS-II messages are formatted sets of data used to convey status and commands between two units of hardware. These units are typically a factory host computer and a piece of manufacturing equipment. However, in some cases the manufacturing equipment may also communicate to one of its subsystems (such as an EFEM) using SECS-II messages. SECS messaging involves sending encoded binary messages across a TCP/IP connection using HSMS. The messages are identified by numbers. SECS communication products usually take care of encoding the buffers for you. Each message sent has a transaction ID (TID). This is used to match a reply message to its primary message. The transaction ID must be unique among all open transactions. Although most HSMS/SECS-II entities support multiple open transactions, some do not. SECS messaging involves sending encoded binary messages across a TCP/IP connection using HSMS. The messages are identified by numbers. SECS communication products usually take care of encoding the buffers for you. Each message sent has a transaction ID (TID). This is used to match a reply message to its primary message. The transaction ID must be unique among all open transactions. Although most HSMS/SECS-II entities support multiple open transactions, some do not.

HSMS/SECS-II



The entity sending the message can signal the receiver that a reply is expected. In this case, the receiver must send a reply message or risk the communication link being reset. If the reply is not received within a certain amount of time, the transaction is closed by the sender and a communication fault is declared. The timeout is usually configurable. To establish communications, several layers must connect. At the lowest level, a TCP/IP connection is established. At the next layer, HSMS protocol messages must be successfully exchanged. And lastly, for GEM-enabled equipment, a successful S1F13/F14 exchange must occur. Non-GEM connections may require other messaging exchanges. Failure at any of these levels results in no communication. The diagram below shows the communications protocol described above and the software that implements the layers. WinSock is provided by Microsoft. SECSConnect and CIMConnect are Cimetrix products. SECSConnect provides HSMS/SECS-II communications and CIMConnect provides GEM messaging.

4 HSMS HSMS defines a protocol for exchanging SECS-II messages over TCP/IP. It defines connection modes, communications timers, protocol messages, and a message header. Most SECS Communication Products abstract the user from the low-level HSMS interchanges and that detail will be left to the SEMI E37 standard. What is discussed here is the information you will need to understand how to configure an HSMS connection.

4.1 IP Address and TCP/IP Port Since HSMS is built on top of TCP/IP, any application using HSMS must support configuration of the IP Address and TCP/IP Port that it should use.

4.2 Modes HSMS defines two connection modes: Passive and Active. Each pair of communicating entities using HSMS will have one Passive entity and one Active entity. The Passive entity opens a TCP/IP port and listens for an Active Entity to talk to it. The Active entity initiates the connection to the Passive entity. The traditional terms of client and server don’t map to HSMS modes. In a factory environment, they apply more directly to the factory host and equipment. The manufacturing equipment would be the server, and the factory host would be the client. Either may be configured to be Active or Passive.



4.2.1 Active Mode IP Address and TCP/IP Port For an Active mode entity, the IP address and TCP/IP port number is what the entity will actively try to connect to.

4.2.2 Passive Mode IP Address and TCP/IP Port For a Passive mode entity, the IP address and TCP/IP port number is what the entity will open and listen on.

4.3 Device ID HSMS defines a device ID which is just an integer number used to further specify a connection beyond the TCP/IP port number. The concept is used to support talking to multiple HSMS entities on the same TCP/IP port, though in practice this is not done. What is important is that the device IDs configured on the active and passive entities match.

4.4 Link Test HSMS defines a message called Linktest that is periodically sent between the two communicating entities to verify the TCP/IP connection is still active. It is only sent if the connection is idle for a configured period of time. SECS communication products usually have a setting for how long a connection should be idle before a Linktest message is sent. It is usually referred to as the Linktest Timer. Again, the Linktest message is used to detect a break in the TCP/IP connection.

4.5 Protocol Timers HSMS also defines several timers that are used to detect communications problems. These times are configurable in most SECS communication products.

Parameter Typical Function Typical value

T3 Maximum time to wait for a reply message 45 seconds

T5 Amount of time to wait between attempts to connect to a passive entity

5 seconds

T6 Maximum time to wait for a reply to an HSMS control message before declaring a communications failure

5 seconds

T7 Maximum time a connection may remain NOT SELECTED before declaring a communications failure

10 seconds

T8 Maximum amount of time allowed between successive bytes of an HSMS message before declaring a communications failure

5 seconds

Linktest HSMS heartbeat message timer 60 seconds



5 SECS-II The SECS-II standard (SEMI E5) defines messages, usually in pairs. These messages are used by the manufacturing equipment to report status to the factory host and for the factory host to control the manufacturing equipment.

5.1 Message Pairs Messages and their replies are defined in E5. These pairs have a Primary and a Secondary (or reply) message. Messages are identified by Stream and Function. Stream is a number that represents a group of related messages, and Function is a message identified that is unique within its Stream. Primary messages always have odd Function numbers, and the corresponding Secondary message Function numbers are always the Primary Function plus 1. For example, S1F13 (Stream 1 Function 13) is used to establish communications and is replied to with S1F14. This exchange of a message pair is referred to as a transaction.

5.2.1 Steam 1 Equipment Status Stream 1 is used to report and change equipment status. Common Functions are:

Function Description

F1 – Are You There Request Basically a ping message

F3 – Selected Equipment Status Request

Request the values for a set of Status Variables

F13 – Establish Communications Request

Used to initialize communications

F15 – Request Offline Used by the host to release control of the equipment

F17 – Request Online Used by the host to request control of the equipment



5.2.2 Stream 2 Equipment Control and Diagnostics Stream 2 is used to send commands to the equipment and define data collection. Common Functions are:


F15 – New Equipment Constant Send

Used by the host to change the value of a configuration parameter on the equipment

F21 – Remote Command Send

F41 – Host Command Send

Used by the host to send a command to the equipment

F23 – Trace Initialize Send Used by the host to define periodic data collection on the equipment

F33 – Define Report

F35 – Link Event Report

F37 – Enable Event

Used by the host to set up event-based data collection

5.2.3 Stream 5 Exception Handling Stream 5 is used to manage and report alarms. Common Functions are:


F1 – Alarm Report Send Used by the equipment to report a change in an alarm’s state

F3 – Enable/Disable Alarm Send Used by the host to enable or disable F1 sending for each alarm

5.2.4 Stream 6 Data Collection Stream 6 is used to manage data collection and report data. Common Functions are:


F1 – Trace Data Send Used by the equipment to report data collected periodically

F11 – Event Report Send Used by the equipment to report the occurrence of an event with requested data



5.2.5 Stream 7 Process Program Management Stream 7 is used to manage recipes on the equipment. Common Functions are:


F1 – Process Program Load Inquire

Used to request permission to transfer a recipe. Usually used before F3

F3 – Process Program Send Used to send a recipe

F5 – Process Program Request Used to request a recipe

F17 – Delete Process Program Send

Used by the host to delete a recipe on the equipment

F19 – Current EPPD Request Used by the host to request a list of the recipes available on the equipment

5.2.6 Stream 9 System Errors Stream 9 is used by the equipment to reply with common error messages. Common Functions are:


F1 – Unrecognized Device ID The HSMS header contained a device ID other than what was specified in the HSMS configuration. This is usually handled by the communications product.

F3 – Unrecognized Stream The equipment does not recognize the stream type in the message.

F5 – Unrecognized Function The equipment does not recognize the function in the message, but does recognize the stream.

F7 – Illegal Data Used by the equipment to inform the factory that the host message body was unrecognizable.

F9 – Transaction Timer Timeout The equipment did not receive a reply to its Primary message and has aborted the transaction.

S9 Error messages are used by an entity to signal an error that cannot be expressed in the normal Secondary message. For example, if one entity sends an S100F1 message and the receiver does not understand Stream 100, then it would reply with an S9F3 to complete the transaction.



Another common S9 message is S9F7. This signifies that the message is poorly formatted or an element in the message is the wrong type. For example, say an S1F13 message is supposed to be a message containing a list of two strings. If an entity were to send an S1F13 with an empty message body, the receiver could send an S9F7 in response as the message is incorrect.

An S9F7 may also be sent if a Secondary (reply) message is received and it is invalid.



5.3 Message Bodies SECS-II message bodies contain the information to be conveyed. SECS-II defines a format for each of the messages in terms of SECS types. Message bodies are usually a single item of a SECS type or a list of items. SECS communication products provide a method for building and parsing message bodies. The valid SECS types are defined in the table below.

SECS Value Type SECS Value Code (octal)

Description

I1 31 1-byte integer




U1 51 1-byte unsigned




F4 44 4-byte float

F8 40 8-byte float

Boolean 11 1-byte Boolean

Binary 10 1-byte binary

ASCII 20 ASCII string

JIS-8 21 JIS-8 string (not always supported, rarely used)

WChar 22 2-byte character string

List 00 A list of SECS values



For example, an S1F13 message contains a list of two strings described in the E5 standard as:

MDLN and SOFTREV are specified as format ASCII (20) in E5.

For example:

There are many message fields in E5 that are defined as allowing more than one format. For example, CEID used to specify a collection event ID is allowed to be 20, 3(), 5() in E5. This means E5 allows it to be ASCII, any signed integer or any unsigned integer. Note that this doesn’t mean that the entity you are connecting to will accept all those formats. Typically, only one format will be used, and you will have to consult documentation or the provider of the entity you are connecting to in order to determine the correct format to use. If you use the wrong format, you will most likely receive an S9F7 error message.

6 GEM The GEM E30 standard is a layer above SECS-II. It defines equipment behavior based on SECS-II messages. GEM will not be discussed here outside the context of establishing communications with GEM-enabled equipment. GEM specifies a connection scenario of exchanging S1F13 and S1F14 with the factory host. Until there is a successful S1F13/F14 exchange, communications is not considered established at the GEM level. Both the host and the equipment may send S1F13 to establish communications, and, indeed, both are expected to reply with S1F14. With GEM-enabled equipment, not much will happen until after a successful S1F13/F14 exchange. The diagram below shows a simultaneous attempt to establish communications by a GEM Host and Equipment pair.



7 Troubleshooting Common Problems

This section will provide some useful techniques for diagnosing common problems with HSMS/SECS-II messaging.

7.1 Cannot Connect The first item to check is if a firewall is running and if it is configured to allow the application using HSMS to open TCP/IP ports. Next you can run ‘netstat–a’ on a command line to see if the passive TCP/IP port has been opened. If the port number the application is configured to use does not show up in the list, the application is being prevented from opening the port. Double check the firewall. If the port is listed, look at the status. If the status is “Listening” then the application has opened the port, but a connection has not been made. If the status says “Established,” a connection has been made at the TCP/IP level. If the Active entity is unable to open the target port and is receiving socket error 10061, then double check the IP address and port number. Remember that localhost or 127.0.0.1 IP addresses do not leave the PC.

7.2 Connection Dropping and Reconnecting If the connection keeps dropping and reconnecting at the HSMS level, double check your device IDs. If the ports are open, and the application can log the HSMS protocol activity, check for errors about invalid device ID received followed by the closing of the port.

7.3 Receiving Many S9F9 Messages If there are a lot of S9F9 messages being exchanged, then you may need to increase your T3 timer value in the configuration of the HSMS connection of the application with the connection(s) sending S9F9. It is timing out before it receives an expected reply message. Another possibility is that the target is not sending reply messages.

7.4 Host Receives S9F7 from the Equipment If an S9F7 message is received, that means the Primary message had an invalid message format. Either the message was the wrong format, or an element within it may have been the wrong type, or both. To find the Primary message at fault, either match the transaction ID of the S9F7 to the Primary or decode the message body of the S9F7. It contains the HSMS header of the Primary message including Stream, Function, and transaction ID.

7.5 Which of My Network Cards (NICs) Will Be Used? In a system with multiple NIC cards you can normally select which one will be used for HSMS by specifying the IP address assigned to the NIC you wish to use in the application configuration.



8 Glossary

Term Definition

SECS-II SEMI Equipment Communications Standard 2 Message Content (SEMI E5 standard). Message content definitions for SECS-II messages.

GEM Generic Equipment Model

HSMS High–Speed SECS Message Services (SEMI E37 standard). Basically a protocol definition for SECS-II messages over TCP/IP communications

SECS communication product

A library providing the capability of sending and receiving SECS-II messages over an HSMS connection

Transaction ID or TID An integer identifying a SECS-II message exchange. The number must be unique amongst all open transactions

Status Variable A GEM term referring to a variable whose value is always valid

Data Variable A GEM term referring to a variable whose value is only valid in the context of a collection event

Equipment Constant A GEM term referring to a variable whose value is used to configure equipment behavior

Event/Collection Event A GEM term referring to an item used to signal the occurrence of something important on the equipment such as a valve closing or the process module finishing processing a substrate

Alarm A GEM term referring to an item that has a Set and Clear state. Alarms are used to signal the occurrence of something on the equipment that poses a danger to humans, substrates, or the equipment itself

Recipes Recipes are used to convey processing instructions to the equipment. They usually include a sequence of processing steps, including sets of parameters that tell the process module how to process the substrate

W-bit A bit in the HSMS header of a Primary message that signifies the sender is expecting a reply message. If the W-bit is not set (=0) then the receiver should not send a reply

Documents

SECS Messaging Primer - Cimetrix