Purpose of the Protocol Layer
The protocol layer packages data and reliably transfers it between the factory host and the equipment GEM interface.
Protocol Layer Definition
The protocol layer implements the transport technology and data packing algorithms used to send messages across a wire between a factory host and an equipment GEM interface.
The SEMI E5 standard, SEMI Equipment Communications Standard 2 Message Content (SECS-II), defines SECS messages that are used as the data and defines how they are packed into binary buffers for transport.
The SEMI E37 and E37.1 standards, High-Speed SECS Message Services (HSMS), define a protocol for exchanging SECS messages over a TCP/IP connection. This is the most used transport technology in SECS/GEM.
HSMS Protocol Stack
The SEMI E4 standard, SEMI Equipment Communications Standard 1 Message transfer (SECS-I), defines a mechanism for exchanging SECS messages over RS-232. This is normally used for older equipment or for some hardware inside an equipment such as an EFEM controller.
The rest of the document will focus on SECS messages over HSMS.
Protocol Layer Benefits
The protocol layer in GEM maintains the connection and detects a loss of connection so either party may take appropriate action such as activating Spooling.
The protocol layer defines handshaking mechanisms to ensure delivery of messages if desired.
The protocol layer connection is point-to-point between the factory host and equipment. It is a dedicated connection with no broadcast capabilities. This makes it easier to predict network loading.
Data Density
SECS/GEM transmits data with little overhead and high density. This means less network bandwidth usage for a given data set.
For illustrative purposes, let us look at a typical example of an event report and compare SECS/GEM messaging to a somewhat equivalent XML and JSON message.
Take a typical GEM interface that uses unsigned 4-byte integers for IDs and an event report containing 8-byte floating point numbers and 4-byte integers. An example of this message is shown in the table below in a SECS/GEM format per E5 and in equivalent JSON and XML formats.
The binary SECS/GEM message will take 58 bytes over the wire, the JSON around 206 bytes and XML 175. The JSON and XML numbers can change a bit based on key/element names and the above is just one of many possible representations.
A chart showing the data density comparison for the example message is shown below. The Actual Data size is 2 4-byte integers + 2 8-byte floating point numbers + 1 4-byte event id + 1 4-byte report id = 32 bytes of actual data. The overhead is calculated by subtracting the actual data size from the total number of bytes for the message.
For the example message the data density for SECS the data density percentages are shown in the graph below. Data density percentage is calculated by the (actual data) / overhead *100.
Now if we change the example message to have 100 8-byte floating point numbers in it, the Data Density % graph changes to the chart below. Notice the JSON and XML are relatively the same, but the SECS/GEM data density increases to 78%.
SECS/GEM encoding has very little overhead. The overhead for a message is 10 bytes for a header describing the message, plus 1 to 4 bytes for the size of the message body. For any 4-byte integer or floating-point number in a SECS message, 6 bytes will be sent across the wire, 4 bytes for the integer value + 1 for the type + 1 for the length in bytes of the data. Likewise, for any 8-byte integer or floating-point number, 10 bytes will be sent. For a string value, the length will be the number of characters plus 2 to 4 bytes. Any time a List (L in the readable example above) appears in a SECS message, 2 to 4 bytes will be added to the message.
Arrays of numbers are brutally efficient in SECS/GEM. The overhead for an array is 1 byte for the type plus 1 to 4 bytes for the length of the array, plus the data in its native size. For example: an array of 10 4-byte integers would take 42 bytes, that is a data density of 95%!
In the JSON example, a 4-byte integer requires 16 bytes + the number of characters needed to represent the integer, so 17 to 28 bytes. Floating point numbers are the same overhead, but probably requiring more characters to represent the value.
In XML, the overhead is based on the sizes of the XML element names. Using the element names in the example above, for any 4 -byte integer the number of bytes across the wire will be 9 + number of characters needed to represent the integer, so 10 to 21 bytes. Floating point numbers are at the mercy of the string formatting used to represent the values.
In summary, looking at the per-item byte size across the wire, SECS/GEM is very dense. Take the 4-byte integer example where SECS/GEM is 6 bytes across the wire, the JSON example is 17 to 28 and the XML example is 10 to 21 bytes and you see as you scale the number of parameters the overhead really matters. 300mm Semiconductor equipment are expected to transfer 1000 parameters per second per process module to the host. For a 2-module equipment, this results in the following number of bytes just for the data: 12K bytes/ over SECS/GEM, 34K-56K for JSON, and 20K-42K for the XML example. These numbers do not account for size of the rest of the message, just the actual parts related to parameter values. If that data is transferred in lots of messages with few values per message, then the network load is even worse. Fewer, larger messages are always better in all cases.
XML and JSON may also add to the overhead depending on the transmission protocol used. For example, XML is often transmitted over HTTP using SOAP, this adds two additional layers of overhead and more bytes going across the wire for each message.The numbers of bytes shown for SECS/GEM are what is transmitted across the wire on top of TCP/IP.
No Data Translation
Numeric data is transmitted with no translation in SECS/GEM. Numbers are transmitted in their native format. For example: an 8-byte floating point number is transmitted in its 8-byte representation without any conversion, truncation, or rounding.
Any protocol such as JSON or XML must convert those 8-byte floating point numbers into a text representation. This takes computing resources for the encoding and decoding and significantly more bytes across the wire. IEEE754 requires 17 decimal digits to accurately represent an 8-byte floating point number as a string. Adding in characters for sign, decimal point, exponent and exponent sign leads to 21 characters. That is over twice what SECS/GEM sends across the wire.
Circuit Assurance
HSMS defines a circuit assurance mechanism called Link Test. The protocol layer has a timer that is started if there are no active message exchanges. Every time the timer expires, a protocol message is exchanged to ensure the connection is still open.
Security
HSMS defines no security. There is no validation of the connecting party, no credentials or certificate is required to connect. The data is not encrypted by any normal encryption algorithms; however, data is obfuscated through the data packaging process and is not generally human readable.
Security is not normally seen as an issue since factory networks are isolated from the outside world.
Conclusion
The SECS/GEM Protocol Layer using HSMS provides a very efficient means of exchanging accurate data between the factory host and equipment.
Click here to read the other articles in our SECS/GEM Features and Benefits series.
To download a white paper with an introduction to SECS/GEM, Click below:
Figure 1: SEMI E30 GEM Control State Model
I remember as a new Boy Scout, we planned a hiking trip up into a primitive area in the mountains near my home. One of the first things we learned about reading a map was where to find the legend. The map legend contains important information needed to read a map, like indicating which direction is north. Now that we knew where to find the legend, we could orient the map so it made sense as we were planning our hike.
As the 
