User:Ismith/SECS-II

SECS II refers to part 2 of the SEMI Equipment Communications Standard, a standard that defines a protocol used for communications between semiconductor manufacturing tools and the software systems that control them.

In a semiconductor manufacturing environment the processes employed are so complex and the cost of errors potentially so high that automation of the tools is necessary to eliminate as far as possible opportunities for error. In order to be able to reliably and efficiently automate a diverse range of tools from many different manufacturers it was necessary to establish a common communication framework. This was possible because the set of commands used to drive a tool is relatively well defined and can be presicsely specified while retaining sufficient flexibility to allow for any variations in needs.

SECS-II is the name given to this prococol, the II referring to part 2 of the protocol used for communications between any compliant semiconductor manufacturing tool and its controler or automation interface. It defines the format of the messages to be exchanged, as well as the replies, so that tools or software programs that use the standard are able to talk reliably to one another. One of the SEMI® Standards, it greatly simplifies the job of both the tool vendors and the automation software providers who can then build on this protocol.

The SECS-II Protocol

The SECS-II protocol is defined in terms of streams and functions. A stream is a broad area of functionality, with functions for individual transactions defined within each stream.

Section 2

The SEMI Equipment Communications Standard Part 2 (SECS-II), or SEMI E5, defines the message structure between equipment and host. Most of the SEMI E5 standard is a large library of possible messages – a few of which have redundant functionality with different message structures. Most equipment support only a restricted subset of these messages. Some equipment define custom SECS-II messages that are not part of the SEMI E5 standard.

Only a subset of the possible messages is actually required by the GEM standard. Some SECS-II message transactions may be initiated by only the host. Other SECS-II message transactions may be initiated only by an equipment. A few message transactions may be initiated by either the host or equipment. In order for a SECS-II message to be valid, it must be used by the correct party and have the correct message format (the SECS-II message structure defined by E5). The host and equipment can agree to support custom messages to implement custom features whose format is not defined in SEMI E5, but this is highly discouraged when standard message are sufficient.

The SECS-II messages are organized into categories called streams that are identified by an integer between 0 and 255. Each stream category contains specific messages, or functions, also identified by an integer between 0 and 255. A primary message is an odd-numbered function. A secondary message is the corresponding even numbered function. A request for information and the corresponding data transmission is an example of such an activity. In most transmissions when either the host or equipment sends a primary message, the response is the corresponding secondary message.

Unless the reply bit is clear, a primary message should always be responded to with the complementary secondary message. For most SECS-II messages, a secondary reply message is required. For example, if the host sends an S1,F1 (stream 1, function 1) message to request 'Are you there?', then equipment will send a reply S1,F2 message to indicate 'I am here'. Each SECS-II message exchange has a unique transaction ID number. The standards allow message interleaving where there is more than one open, concurrent transaction.

The SECS-II standard also defines list of allowed data types including ASCII, binary, boolean, 4 and 8 byte floating points, signed and unsigned integers of byte length 1, 2, 4, or 8 and a List; a container for other data elements including other lists.

SECS-II messages are sent as structured binary data. It is a very efficient means to package information across a network without wasting bandwidth. When using the SECS-I standard, RS-232 serial communication, the message size is limited to 7995148 bytes (about 8 MB). When using the HSMS standard, TCP/IP network communication, the maximum message size is limited to 4294967295 bytes (about 4.3 GB). The structure of each standard SECS-II message is defined by the SEMI E5 SECS-II standard. A message can be a simple data element, such as a binary response or an ASCII string. A message can also be a complex list structure with multiple levels of lists in the hierarchy. The SECS-II standard limits a single element within a SECS-II message to 16777215 bytes (about 16.5 MB).

External links

• Latest version of SECS-II standard
• More info on the SECS-II standard