SECS and GEM
SECS
Around 1980 there was a big push in the semiconductor manufacturing industry to develop automation. An industry consortium (Sematech) was formed and began work on a wide variety of standards proposals. Among them was SECS (Semiconductor Equipment Communications Standard).
Though it's now getting a bit long in the tooth, the SECS standard was a remarkable accomplishment. The designers had the foresight to recognize that message content should be separate from transport mechanism, and so defined SECS-I (the RS-232 transport) and SECS-II (the message content). Since that time an alternate transport mechanism, TCP/IP based, called HSMS has been defined and has been the most common transport implementation for the past 8 years or so.
SECS is a point-to-point protocol, with one end being termed the
equipment and the other end the
host , for reasons that should be obvious.
SECS messages are hierarchical - lists within lists, basically. Each message has an identifier pair called a
stream and
function - both are integers. Each
stream represents a category of message - for example, alarms are stream 5, event reporting is stream 6, terminal messages are stream 10. Each
function represents a unique message specification within a stream. Odd-numbered messages are called
primary messages ; even-numbered messages are called
secondary messages .
A SECS
transaction consists of a primary message sent by one side of the communication link and the secondary
reply message sent by the other side of the communication link. The reply message function number is always 1 greater than the primary message function number. For example, an event report message sent by the equipment is stream 6 function 11 (normally written as S6F11), and the reply message is stream 6 function 12 (written S6F12). Not all primary messages require a reply, and in some cases the decision whether a particular message requires a reply is configurable at runtime.
Messages are represented in a binary structure. The message itself has a 10-byte header that
- identifies the stream and function
- has a bit saying whether a reply is expected
- has a few other fields needed for transaction control
Each
item within a message has a short header that specifies
- its type
- its number of 'length bytes'
- its length
For compactness and versatility there can be 1, 2, or 3 length bytes, so each item can be up to 2^24 bytes in size. The data types are:
- List
- Signed or unsigned integer of size 1, 2, 4, or 8 bytes
- boolean
- binary (byte)
- Floating point 4 or 8 bytes
- Ascii or JIS-8
An item can consist of an array of any of these types (except List).
Lists can be nested to any level. Each list is defined as either fixed-size or variable-size. At runtime there is no such distinction - a list is whatever size it is. But in the SECS-II message definition provision was made for variable-length lists. For example, an event report can contain any number of individual reports and each report can contain any number of variable values - all configurable by the host.
GEM
The SECS standard defined
many messages. Initially I think streams 1-12 were defined, and there are about 10-40 messages defined per stream. The SECS standard provided very little guidance about how the messages should be used. Each equipment vendor would choose the set of messages that it would provide, so host-side programming was a very case-by-case business. This was not a Good Thing. The GEM (Generic Equipment Model) standard was created to address this problem.
GEM specifies a smallish subset of the SECS-II messages. It says how those messages should be used, and defines a set of
scenarios with associated
transactions . It also defines a set of standard state machines (represented as
StateCharts of course!) which must be implemented by the equipment. Finally, it provides a compliance chart. The standard consists of a required core and a set of optional GEM features. To be termed
GEM compliant an equipment must implement the GEM core features in a compliant way. To be termed
fuly GEM capable an equipment must implement all of the optional GEM features in a compliant way.
--
DaleBrayden - 07 Jul 2002
Books RSS
