SECS and the Single Semiconductor
"The nice thing about standards is that there's so many of them to choose from." -Andrew Tannenbaum, in Computer Networks
For the last few years, we’ve grown accustomed to the fruits of Moore’s law, which states that available computing power doubles every 24 months or so. Although experts (including Gordon Moore himself) believe this can’t continue indefinitely, the progress we've seen in the last four decades been just short of miraculous. In the mid-twentieth century, IBM's chairman believed there would never be more than a half dozen computers in the world. Now millions of us own a computer (sometimes several), each of which has computing power exceeding the combined capacity of NASA when the first man was sent to the moon.
If anyone can be given credit for this incredible advance, it is the engineers who design and manufacture the semiconductor chips that are the heart of all modern computers. Semiconductor manufacturing has always been a difficult and exacting business, but it becomes more so with each advance in technology. As the speed and memory capacity of components increases, the size of their constituent parts must decrease. The circuits on a modern semiconductor chip are visible only with the aid of a powerful microscope. To offset the increasing cost of designing them, companies duplicate them by the millions, manufacturing them at the lowest possible cost.
In manufacturing, there is always a trade off between cost and quality. For this reason, in 1980, a group of semiconductor companies banded together to form a consortium called SEMI, the Semiconductor Equipment and Materials International. One of SEMI’s main goals was to produce standards by which the manufacturing of semiconductors could be made more reliable and efficient. To achieve this, it was necessary to coordinate the efforts of the hundreds of companies involved in this industry. These companies deal with the many stages in the manufacturing process, producing the machines, chemicals, and software used in each step.
SEMI has created numerous standards, which pertain to the manufacturing process: the physical dimensions of silicon wafers, the safe handling of chemicals, and the cleanliness of the manufacturing environment, just to name a few. To software developers like me, the most pertinent standard is called SECS: the Semiconductor Equipment Communications Standard. Outside of the suggestive acronym, SECS is serious business—it aims to ensure that different processing machines made by different manufacturers can communicate easily throughout the fab environment. Good communication is essential for achieving the goals of semiconductor companies: efficiency, worker safety, and the continuing improvement of the manufacturing process.
SECS provides a standard interface for diverse types of semiconductor processing equipment. It defines two kinds of entities: the “equipment”, the machine that does the actual work, and the “host”, a computer that monitors one or more pieces of “equipment”, gathering production statistics, advising managers of potential manufacturing or safety problems, and (optionally) controlling the equipment remotely. SECS provides the communication link between these entities. SECS is actually composed of two sub-standards (SECS-I and SECS-II) and is usually grouped together with the closely related standards HSMS and GEM. In terms of the Open Systems Interconnection (OSI) network model, SECS-I corresponds roughly to “three and a half” of the seven network layers. It specifies the hardware interface; the basic format of messages and the handshaking used between the entities to ensure that data is transferred reliably. SECS-II defines the middle communication layers, such as the network, transport, and session layers. HSMS, or High-Speed SECS Messages Services, is an alternative to SECS-I that runs on Ethernet, rather than the traditional serial link. GEM, which stands for General Equipment Model is a related but higher-level standard.
The SECS-I standard specifies the hardware interface (the physical link layer, in OSI terms) as RS-232, better known as serial. The maximum speed is 19200 baud, which in the past has been more than sufficient for the slow-moving world of factory automation. The protocol’s handshaking is primarily software-based, and uses ASCII control characters. Packet sizes are small (240 bytes maximum), although there is a method for chaining multiple packets together if necessary. Like any good communications protocol, SECS-I includes methods for validating data (a checksum), handshaking (the acknowledge character) and for re-transmitting packets in case of error. These portions cover layers two (data link) and four (transport) and part of five (the session layer.) Layer three, the network layer, is not implemented, because network management is left to the host.
The SECS-II standard specifies the types of messages to be exchanged between the host and the equipment, and their general formatting. It also defines data types (numeric, text, arrays, etc) and provides for most of the activities required in the semiconductor manufacturing process. Messages are classified into of numbered functional groups called "streams." Eighteen streams have been defined (zero through seventeen), but only a few of these are commonly used.
For example, stream 1 messages are classified as “equipment status” messages, and are used mostly for initiating, terminating, and controlling the connections between the equipment and the host computer. Stream 5 messages include alarm messages from the equipment (anything from routine problem notifications to life-threatening emergencies) and all messages for managing the alarm process. Stream 9 messages are generalized errors.
Individual message types within each stream are called functions; these definitions are also numbered. Odd numbered functions are used when one machine initiates communications with another; they can be commands, requests or status reports. Even numbered functions can only occur as responses to an odd-numbered function (although not all odd-numbered functions have responses.) A specific message type is defined by both its stream and function numbers, and is usually abbreviated SxFy, where x and y are numbers. Most message types are initiated by the host computer, which controls and monitors one or more pieces of equipment, the machines that do the actual manufacturing, processing and testing. A few message types (such as alarm reports) are initiated by the equipment; and a few others can originate from either type of entity.
Functionally, the various SECS-II messages are often described in terms of scenarios. A scenario is a series of messages that normally occur in a particular order. Many of these indicate transitions of the equipment from one state to another. The following diagram indicates a sample scenario:
HSMS was created as a response to the availability of faster and more convenient communications interfaces. It serves the same function as SECS-I, except that the slow RS-232 interface is replaced by TCP/IP running over Ethernet. One difference is that there is no 240-character size limitation of the message size. Another is that communications parameters such as word size and baud rate do not need to be specified.
One of the problems that occurred with SECS-II was that the specification was too flexible. There was no recommended or required set of core functionality, which made it difficult to determine if a piece of "SECS standard" equipment would be compatible with any particular application. It was also pretty open-ended for customization. Many manufacturers would define dozens of custom SECS messages where standard message types would have been more appropriate.
For this reason, SEMI created a new specification called GEM, which is an abbreviation for “General Equipment Model.” GEM narrows the SECS specification by restricting the SECS-II message set. It also defines required functionality (such as the ability to establish and end communications) and optional functional areas (such as reporting of events by the equipment.) These functional sets correspond to families of messages in SECS-II format. The standard also requires the equipment manufacturer to document which functional subsets are supported. The GEM standard has a few functions that are mandatory. The host must be able to initiate (and terminate) a communication session with the equipment. The equipment must be able to send unsolicited notifications (events) to the host. Both host and equipment must support a few simple error messages. The equipment must have an ID string, which can be queried by the host. GEM also requires that there be broad, general models for the functional states of the equipment.
GEM has many other functional areas which are officially optional, but a useful configuration must have at least some of them. The following is a partial list:
* Alarm management – An alarm is another message type that is originated by the equipment. Officially, it is defined as an abnormal, undesirable, or hazardous condition on the equipment. Alarms can vary in severity from minor (endangering the material being processed) to major (endangering human life.)
* Trace data collection – Trace messages, like events and alarms, are originated by the equipment. Their primary purpose is debugging or impromptu data collection. Trace messages are similar to events in that they can return information about the instantaneous state of the equipment. Unlike events, which are triggered by a predefined condition or occurrence in the equipment, a trace must be requested by the host. The host must specify how many trace messages to be returned, and the time interval between them.
* Terminal services – This provides a simple messaging facility for human communication between the host and the equipment (assuming the host and equipment are in physically separate locations.)
* Remote control – This feature allows equipment commands to be initiated by the host instead of manually from the equipment’s control panel. For safety’s sake, the equipment can be put in a “local” mode, which blocks remote commands, so that, for example, a test can’t be initiated when someone is servicing the machine.
* Process programs — Often it’s desirable to modify the way in which the equipment processes its material. This may be part of an attempt to optimize throughput, or perhaps different types of material require different processing. The “process program” is a kind of recipe that tells the equipment how to proceed. In GEM, process program support allows programs to be uploaded, downloaded, and selected dynamically from the host.
Defining messages isn't very useful if the there's no standard way to convey information about the semiconductor equipment. There needs to be a way to save and access data. SECS defines several types of data:
*Equipment constants – Abbreviated EC, these store configuration data of the equipment. For example, for how much time should a wafer be subjected to a particular process? Note that these aren't constants in the software developer's sense, because these values can be changed by the host. They do tend to be changed less frequently than other data types.
* Status variables – Abbreviated SV, these are the places that the equipment stores status information about itself. The host can read these variables but normally cannot change them. Examples of these would be process statistics such as wafer count, or environment variables such as ambient temperature.
* Data (or discrete variables) – These are similar to status variables, with the difference being that they are time dependent, and may not be meaningful at all times. For example, the machine might have data on the pass/fail status of a device under test, which would not be relevant after the device is unloaded.
* Each of these data types can appear in several of the forms typically expected by programmers, such as integer, string, binary, floating point, and array.
Those of you who are familiar with process control know the importance of the finite state machine (FSM.) This is a description of a machine's behavior that can be modeled in software. It has states, which contain information about the current configuration of the system. Transitions define changes between states, and describe what external and/or internal conditions can enable specific changes. An FSM also have actions, which describe activities that are to be performed at a particular time.
Some of the required minimum state machine implementations include:
* Communications – determines how equipment establishes communications with the host
* Control -- whether equipment is on-line with the host, and whether control is local or remote (by the host)
* Process – general state of the equipment operation; for example, idle, executing or paused.
The following is an example of a typical GEM state diagram:
There are a number of tools which are designed to make things easier for the SECS/GEM developer. These usually implement lower-level communications protocols, and common messages and their responses, and handle data variables. Most also have simulation and test utilities. Some makers of SECS development tools are listed below:
* Asyst (formerly GW Associates) – Produces the popular development libraries SDR and GWGEM – www.asyst.com * Cimetrix – Software Solutions for Factory Connectivity and Advanced Motion Control - www.cimetrix.com * SDI-USA – SDI uses CIMETRIX, Inc. software in its automation projects – www.sdiusa.com * WonderWare -- Wonderware connects older SECS/GEM process tools with APC applications by combining Cimetrix (R) CIMPortal product with its Interface A solution. – www.wonderware.com
The SECS and GEM standards are complex but powerful. They require semiconductor equipment (and the host systems that talk to them) to provide a minimal subset of functionality. At the same time, they are lax enough to allow significant customization (a fact which helps keep SECS/GEM development engineers is business.) The standards are widespread and increasing in popularity. It also provides a good niche market for the software consultant.
References: http://en.wikipedia.org/wiki/Moore's_law I think there is a world market for maybe five computers. - IBM Chairman Thomas Watson, 1943 http://www.ussg.iu.edu/usail/network/nfs/network_layers.html http://www.cimetrix.com/gemintro.cfm en.wikipedia.org/wiki/State_machine
