Introduction to SECS/GEM

SECS/GEM identifies the type of communication interface commonly used in the semiconductor, electronic, and photovoltaic industries which has been standardized by the non-profit trade association SEMI.  You can obtain copies of the SEMI standards through their website at http://www.SEMI.org.  Since there are a number of standards relating to equipment automation and software, our advice is to obtain a CDROM subscription to all of the standards instead of obtaining them individually.  This introduction is intended to convey an understanding of the basic capabilities and scope of SECS/GEM without the low level detail of the underlying protocols and data formats.

SECS is an acronym for Semiconductor Equipment Communication Standard. GEM refers to the SEMI standard E30 which describes a generic model for equipment behavior and communication using a subset of the message types defined in the SEMI standard E5. Deployment of SECS/GEM interfaces will generally use TCP/IP networking as specified by SEMI Standards E37 and E37.1 but RS-232 serial connections can also be used as described by standard E4. The latter is more common for older equipment. The SEMI standards have shorthand names as well as their official identifiers, thus E4, E5, and E37 are also referred to as SECS-I, SECS-II, and HSMS respectively.

Platform Independence

SECS/GEM describes two way communication through a network or serial cable connection that is independent of any operating system or programming language. Usually the host side of a connection is executing on a computer system provided by the factory, and the equipment side of a connection is running on a controller computer provided by the equipment manufacturer.  These computer systems and their installed software are completely independent - they may be using different operating systems and it is the usual case that the SECS/GEM software on each system has been written by different parties.  This is the value of standards and true interoperability - the factory is not restricted to using a proprietary operating system or buying a proprietary interface package provided by the equipment vendor.

Connections

SECS describes the communication between a host computer and the equipment using a single connection.  HSMS refers to a network connection that uses TCP/IP.  SECS-I refers to a connection that uses RS-232 serial ports.  In the original concept and still the most common scenario, the equipment provides a single SECS interface for exclusive use by a single host.  The message types defined by SECS are partially asymmetric - some message types are defined only for host use, others are defined only for equipment, but many are defined for the same use by either side.  Since SECS can be an effective means of integrating sub-equipment in a fabrication cell, there are also scenarios where an equipment connects to sub-equipment in the role of a host, and offers an integrated equipment interface to a factory host.  Network connected equipment using HSMS usually provides independent SECS connections for independent modules such as furnace tubes.  However, there is provision in the SECS standards for sharing a connection by modulating the device identification value in each message.  The practice of connection sharing is not recommended for new deployments and is typically found only with older RS-232 systems.  Once a connection is established, messages are exchanged in both directions between host and equipment.  It is typical that a connection is maintained for long periods of time and only interrupted if the equipment or host is rebooted.  The usual SECS connection has fairly light usage of network bandwidth compared to a busy web server. It is feasible to run dozens of SECS interface connections on a typical desktop computer.

Niche Applications

An equipment provider can deploy multiple SECS interfaces if he allows for coordinating machine control, for example by indicating to the extra host connections that the machine is under local control.  It is also possible to deploy a SECS/GEM host interface to a tool which offers multiple connections to other host applications - a specialized multiplexer.  The latter can be done without help or customization by the equipment provider.  A special case of this configuration is to have a host and equipment connection pair working as a filter application between the real host and equipment interfaces making changes to the message data passing through such as reformatting selected data items in order to accommodate limitations of the host or the equipment software.  SECS communication can be eavesdropped and monitored by an independent application.  For RS-232 connections this requires a cable tap which is easily made or purchased.  Network connections can be monitored with the help of programs such as tcpdump which capture TCP/IP communication.  These specialized applications are not in the mainstream of SECS usage.

SECS-II Protocol

The E5 standard describes the core message types of SECS as well as the format of exchanged data.  SECS uses a compact, self-describing binary representation of data items.  A message consists of header data and optional message data items.  In the header data, there is an integer code named the Stream and another integer code named the Function.  Together, the Stream and Function indicate the type or meaning of the message.  SECS message types are categorized by Stream, for example Stream 1 deals with equipment status and Stream 6 deals with data collection and monitoring of equipment events.

A message may be sent with or without expecting a reply message.  A convention exists for the Function values used in message conversations.  A message that is initiated independently or asynchronously for sending has an odd Function value and is called a Primary message.  A message that is sent as a reply to a received message is termed a Secondary message, and the Function value is an even number that is one more than the Function value received in the Primary message.

There is a unique 4 byte integer in the message header set by the sender that is used to correlate a Secondary reply message with the Primary message being replied to.  This makes it possible to send multiple messages of any Stream and Function without waiting for each reply before sending the next message, and still be able to correlate reply messages that are received asynchronously, or received out of order.  Modern SECS software is expected to be able to handle receiving multiple messages of any type in succession even though each message may require a separate reply that has not been sent by the receiver.  Also, the reply messages may be sent in a different order than received.  This capability is referred to as supporting concurrent open transactions.  Older RS-232 software may have limits on the support of concurrent open transactions, in which case the sender may need to wait for a reply before sending another Primary message that requires a reply.

SECS-II Message Types

The E5 standard is a long document that defines many more message types and data items than any interface implements.  Also, there are complexities of different formats being possible for a given message type, and different data type representations of data items.  Other SEMI standards describe additional SECS-II message types for specialized purposes.  The GEM standard E30 was created to provide guidance for the deployment of a subset of E5 with emphasis on a core set of message types and less variation in message and data item formats.  The GEM standard also describes scenarios and state models to standardize the integration of SECS messaging with equipment actions, control, and behavior.  The newly emerging Draft Standard #4557 for the Photovoltaic Industry is playing a role similar to GEM, by providing important guidance for leaving behind obsolete features of SECS such as RS-232 support, and steering a path away from complex message types that are not needed in the PV industry.

The message types defined in the standards cover a broad range of functions, with most of the message types being defined for a specific use, but a few are more general.  In particular, message types that provide for sending command invocations to the equipment with optional arguments are defined in the standards as Remote Commands.  In the other direction, the equipment can post data collection events for any particular reason with arbitrary data items and values available in event reports.  These fairly generic mechanisms can be useful in a variety of ways with the underlying message types already specified by the standards.  SECS also provides for a range of Stream and Function values that are available for custom use for situations when it is not desired to use the predefined message types.

The SECS/GEM Conceptual Model

One of the benefits of a standard interface is that dissimilar equipment is integrated into the factory in the same general way, with the same conceptual model.  Here is the conceptual view of the equipment as it seen by the exchange of SECS messages.

Variables

SECS identifies three categories of variable data items. The values of these data items are passed in specific message types such as data collection event reports.

Status Variables are read-only values communicated to the host such as sensor readings or the clock value.  Status Variables can also include data that describes the equipment such as a list of the data collection events which are currently enabled for reporting.

Data Value Variables are similar to Status Variables in being read-only data items whose values can be communicated to the host.  The distinction is that a Data Value Variable does not always have a valid value.  For example, there is a Data Value Variable named AlarmID by the standards.  This variable holds the identifier of the most recent alarm condition, but an alarm condition may not have occurred.  Here is a fine point on the transience of Data Value Variables.  Suppose you have two distinct alarm conditions sensed at nearly the same time and both have been configured by the host for event reports.  The alarm handling and event report logic needs to be carefully designed to communicate the proper value of the AlarmID variable in each alarm's report.  A second point is that the host should not request additional context information for any transient event in a follow-up message since a newer condition may have replaced the earlier context.  The host should take full advantage of the SECS/GEM features that support dynamic event report definitions and obtain all of the desired context data values for an event in a single event report message.

The third category of variable items are termed Equipment Constant Values.  This term is a misnomer, since these values are not constant - these are values that the host is able to change within limits specified by the equipment.  Equipment Constant Values are specified to be only single values and not lists of values or arrays of values.  This difference is intended to foster simple and correct usage because of their role in equipment control.

The SECS standards provide different message types that are not equivalent for the host to work with these variable types.  The deployed Status Variables and Equipment Constant Values can be discovered and their values queried, but there is no standard message for discovering Data Value Variables.  Hume provided equipment software implements a Status Variable to make this information available.

Event Reporting

Event report messages enable the equipment to inform the host of the passage of an event such as the completion of processing or a change in status.  Older equipment typically provided a predefined event report containing a fixed set of variable values.  The modern approach is for the equipment to support dynamic event report which allows the host to configure which variable data items are included in the set communicated with an event report.  The event report mechanism is general and powerful.  For example, it can be used to communicate the validation result for a process program as an asynchronous event after the process program has been downloaded.  The most commonly reported events indicate process state changes and control state changes as described in detail in the GEM standard.

Alarm Reporting

An alarm differs from an event in that it signifies an undesirable condition with both a set and clear state.  For example, a process tool that relies on compressed air input might communicate an alarm condition if the input air pressure fell below the needed amount.  If the air pressure was restored, the alarm clear condition message would be sent.  GEM requires that alarm set and alarm clear transitions are also reported as data collection events.  This is a desirable feature because it lets the host use the same dynamic event reporting mechanism and software logic to capture alarm conditions and context data.

Control State Model

GEM specifies a control state model that makes sense for integrating operator actions in a safe way with automation.  The host cannot assume remote control of the equipment unless it is permitted at the equipment.  The concept of the SECS interface being off-line or on-line also provides for common scenarios such as performing maintenance or process qualification activity with the usual host communication being bypassed.

Process Programs

Simpler equipment that supports remote control of processing may use a set of Equipment Constant Values to define processing setpoints.  More sophisticated equipment can use Process Programs or Recipes.  The terms are often used interchangeably in the industry but they do have distinct meaning in the SECS standards.  A Process Program is an equipment specific data set that has an identifier and that specifies the processing of material.  There are message types defined in Stream 7 for discovering the Process Programs residing on the equipment, transferring Process Programs to the host (uploading) or to the equipment (downloading), or deleting a Process Program at the equipment.  A Process Program is usually manipulated as a binary sequence without the host understanding its equipment specific format.  However, there are messages defined for Formatted Process Programs where the Process Program data format is specified by the standard. T he term Recipe is used for the more complex data sets manipulated using Stream 15 messages and described in standard E42, or for the complex data sets manipulated using Stream 19 messages and described in standard E139.  These types of Recipes are intended to meet the needs of more complex equipment that may feature tunable processing parameters or that may have multiple process chambers with independently controlled processing.  In addition these standards provide for attribute information such as a description and author value so that the usage of a Recipe can be more easily determined then when only the identifier is known.

Remote Commands

The SECS/GEM interface on equipment may enable the host to control equipment actions such as processing by sending Remote Commands.  Conceptually a Remote Command is similar to a programming procedure invocation - there is an action indicated and the ability to pass data items as argument values for the indicated action.  An example might be to begin executing a specified process program.  As a general statement, an automated factory wants to be able to perform any action provided on the tool user interface by using the SECS/GEM interface, and Remote Commands have the needed flexibility to enable this.  Time and effort spent by the equipment provider to support Remote Commands is greatly appreciated by the factory users.

Spooling

Spooling is the ability for the equipment to save an ordered sequence of messages that would have been communicated to the host during a period when host communication is interrupted.  At first glance it seems like this is a valuable feature, however, that is not the case, at least for factories that we are familiar with.  A highly automated factory that is utilizing the SECS/GEM interfaces to the extent that they want to continuously capture event and alarm information has also taken the steps to deploy host software that is rarely if ever down.  We have actually had support calls where users have forgotten how to start their SECS software after months of uninterrupted running.  Hand in hand with this level of automation is that the tools are not operated unless the host interface is functioning so that mistake-free process setup can be verified.  So there are no periods of time when spooling is used.  Spooling has created problems with many host side users because its original specification did not provide for compatibility with older host software that is not aware of spooling.  In a nutshell, the SECS interface may appear not to work correctly if the host does not send an initialization command to purge or unload the spool.  Newer versions of the standards have introduced an Equipment Constant Value which allows the host to persistently disable spooling and avoid this problem.

Trace Reporting

Trace reporting is a feature that provides for periodic reporting of selected variable values.  Often there is a higher expectation of the value of this feature than is warranted since it can support an impressive demonstration.  A SECS interface cannot be relied on for real-time, deterministic performance, so the ability to use this feature for precise endpoint detection or similar real-time control is lacking.  The limitations of Trace Reporting are in part due to the proliferation of computers, controllers, intelligent instrumentation, and software processes within the equipment system.  The mental picture of one controlling program running on a single computer with immediate, synchronized access to all relevant information is simplistic and wrong.  Precision in the time of data collection between various sensor readings and synchronization of the data collection with process initiation needs to be planned for and designed into the control system from the beginning to support accurate, precise reporting.  In general, sensor data reported through SECS Trace Reports cannot be expected to have the quality and value of that obtained with add-on instrumentation.  Is this summary is too pessimistic?  If you are finding real value in SECS Trace Reporting, particularly in a production setting, we would like to hear from you.

Terminal Services

SECS also includes message types to support the display and acknowledgment of short text messages.  This is another feature that is commonly supported for demonstrations and example programs but sees less use in production.  A factory that has invested in automation and is actively using SECS interfaces is doing their best to move away from production scenarios that rely on displayed messages and operator acknowledgment.  Also in the usual factory setting there are many different types of production tools, and the menu navigation to view and acknowledge terminal messages is likely to be dissimilar and create training problems even if everyone uses the same language.  So if operator interaction is needed, it is almost always conducted using operator station software deployed by the factory and not each equipment vendor.

Diagnostic and Support Features

There is sufficient complexity with SECS and automation applications in general that support issues in the field are not uncommon.  Sometimes the issue is only one of understanding but there can be problems with non-standard or buggy implementations particularly with older equipment or when a mature toolset has not been used.  Therefore it is not enough for SECS/GEM interface software to function correctly - there must also be features to capture for diagnostic purposes the communication interaction in varying levels of detail.  The Hume software products have exemplary features for diagnostics.  Data exchanged on the SECS interface can be automatically captured in log files organized by date and saved in compressed archive files.  This allows for review or investigation long after the fact. For interactive use, field personnel can display in real-time the SECS message data being exchanged, with full control over the level of detail and data interpretation shown.  Displayed data can easily be saved to files for later review.  Diagnostic features can also be accessed remotely through the local area network.  Using diagnostic features remotely is a more common scenario for host side users who may access the factory systems from their offices.  Typically the factory is heavily firewalled and remote access to the equipment by the vendor is prevented even though VPN and similar network security products could provide secure access.

Software Integration Architecture

An equipment vendor plans for SECS/GEM integration by designing his control system software so that the actual tool control is logically separated from the user interface.  This gives the flexibility needed to share control of the equipment with an automation interface.  As tools grow in sophistication, the need for inter-process communication grows and products such as the Hume Datahub with its data table management, message system, and subscription features can provide a needed integration framework.

On the host side, a factory architecture for supervisory control and monitoring will usually define a "driver" level for equipment integration.  The driver level software encapsulates equipment variation so that a uniform command interface is provided to upper level software.  Alarm and event report messages that originate from the equipment can be mapped or filtered before passing them on to general monitoring software.  Data from event reports can be collected by the driver, combined with context information, and sent to a persistent database for later analysis and reporting.  The Hume host libraries provide a high-level start for drivers with their built-in features for handling event reports and assigning virtual names for events and variables.  Also, the inclusion of the Hume DMH message queue system can be a key feature.  You cannot shutdown and restart the entire factory to deploy a new or updated driver, and if a driver is not on-line, the failure needs to be handled gracefully.  For these reasons and others, a message queue interface is preferred for integrating drivers into a distributed factory system.

Summary

SECS/GEM is a widely deployed communication interface that relies on robust TCP/IP networking in its modern form.  The protocol has been of extreme value in the Semiconductor and Electronic industries by enabling extensive automation which prevents costly mistakes and relieves humans of tedious, repetitive, and error prone work.  The success stories of SECS/GEM are:

• automated systems are able to establish or verify proper equipment setup before processing,
• measurement tools are able to transfer important data without operator transcription
• handling systems are able to coordinate moving and transferring material automatically
• event and alarm reports provide for monitoring and optimizing equipment use
• mature SECS/GEM software that is robust and capable of 7x24 stable operation is available for almost any platform.

The original protocols were developed by hands-on implementors and they reflect an engineering mindset of directness and efficiency.  As the scope of the SECS/GEM standards has expanded, the standards show the inputs of many companies and many points of view.  Thus, they lack the coherence of something developed by a single team for a narrow set of requirements.  Said another way, you can expect to see inconsistencies and imperfections when the world of SECS/GEM is considered in its entirety.  However, this is a small price to pay for the large value received.

  About Us                   Contact Us                 News and Views             Integrators                Documentation                Support 

Serving the semiconductor manufacturing industry since 1992                          Copyright Hume Integration Software 2021