协议层的用途

协议层封装数据，并在工厂主机和设备GEM接口之间可靠地传输数据。

协议层定义

协议层实现了通过工厂主机和设备GEM接口之间的连线发送消息所用到的传输技术和数据打包算法。

SEMI E5标准，半导体设备通信标准II 消息内容(SECSII), 定义了用作数据的SECS消息，以及如何将它们打包到二进制缓冲区中进行传输。

SEMI E37和E37.1标准高速SECS消息服务(HSMS)定义了一种协议，用于在TCP/IP连接上交换SECS消息。这是SECS/GEM中使用最多的传输技术。

HSMS协议栈

SEMI E4标准，即半导体设备通信协议标准I 消息传输 (SECS- I)，定义了在RS-232上交换SECS消息的机制。这通常用于较旧的设备或设备内部的某些硬件，例如EFEM控制器。

本文的其余部分将重点讨论通过HSMS传递的SECS消息。

协议层的好处

GEM中的协议层维护连接并检测连接丢失，因此任何一方都可以采取适当的操作，比如激活假脱机。协议层定义握手机制，以确保在需要时传递消息。协议层连接是工厂主机和设备之间的点对点连接。它是一个没有广播功能的专用连接。这使得预测网络负载变得更加容易。

数据密度

SECS/GEM传输数据开销小、密度高。这意味着给定数据集的网络带宽使用更少。

为了便于说明，我们来看一个典型的事件报告示例，并将SECS/GEM消息传递与某种程度上等价的XML和JSON消息进行比较。以一个典型的GEM接口为例，该接口为id使用无符号的4字节整数，以及一个包含8字节浮点数和4字节整数的事件报告。下表以SECS/GEM E5格式以及等效的JSON和XML格式显示了此消息的一个示例。

二进制SECS/GEM消息将通过网络占用58个字节，JSON大约占用206个字节，XML 175占用175个字节。JSON和XML数字可以根据键/元素名称进行一些更改，上面的只是许多可能的表示之一。

下图显示了示例消息的数据密度比较。实际数据大小为2个4字节整数+ 2个8字节浮点数+ 1个4字节事件id + 1个4字节报告id = 32字节的实际数据。开销是通过从消息的总字节数中减去实际数据大小来计算的。

对于示例消息SECS的数据密度，数据密度百分比如下图所示。数据密度百分比由(实际数据)/开销*100计算。

现在，如果我们将示例消息更改为包含100个8字节浮点数，则数据密度百分比图将改变为如下图。注意JSON和XML相对相同，但是SECS/GEM数据密度增加到78%。数据密度百分比由(实际数据)/开销*100计算。

SECS/GEM编码的开销非常小。消息的开销是描述消息的头部的10个字节，加上消息体大小的1到4个字节。对于SECS消息中的任何4字节整数或浮点数，都将通过网络发送6个字节，4个字节表示整数值+ 1个字节表示类型+ 1个字节表示数据的长度(以字节为单位)。同样，对于任何8字节的整数或浮点数，都将发送10字节。对于字符串值，长度将是字符数加上2到4字节。在SECS消息中出现列表(上面可读示例中的L)时，将向消息添加2到4个字节。

在SECS/GEM数据中，数字数组尤为高效。数组的开销是类型为1字节，数组长度为1到4字节，加上数据的本身大小。例如:一个由10个4字节整数组成的数组将占用42字节，即数据密度为95%!

在JSON示例中，一个4字节的整数需要16个字节加上表示该整数所需的字符数，因此需要17到28个字节。浮点数的开销相同，但可能需要更多字符来表示值。

在XML中，开销基于XML元素名称的大小。使用上面示例中的元素名，对于任何4字节整数，跨连接的字节数将是9 +表示该整数所需的字符数，所以是10到21字节。浮点数取决于用来表示值的字符串格式。

总而言之，通过查看每项数据所需字节大小，SECS/GEM非常密集。以4字节整数为例，其中SECS/GEM是6个字节，JSON示例是17到28个字节，XML示例是10到21个字节，随着参数数量的增加，您会发现开销确实很重要。300mm半导体设备预计每秒每个工艺模块向主机传输1000个参数。对于2个模块的设备，这将导致仅用于数据的字节数如下: SECS/GEM 12K字节, JSON 34K-56K, 如实例的XML 需要20K-42K。这些数字不考虑消息其余部分的大小，只考虑与参数值相关的实际部分。如果数据在大量消息中传输，而每个消息的值很少，那么网络负载就更糟了。在所有情况下，更少、更大的消息总是更好。

根据使用的传输协议，XML和JSON也可能增加开销。例如，XML通常使用SOAP通过HTTP传输，这就为每个消息增加了额外的两层开销和更多的字节。SECS/GEM所显示的字节数是实际通过TCP/IP上的网络传输的。

无数据翻译

在SECS/GEM中传输数值数据时不需要转换。数字以其原始格式传输。例如:8字节浮点数以其8字节表示形式传输，没有经过任何转换、截断或舍入。

任何协议，如JSON或XML，都必须将这些8字节浮点数转换为文本表示形式。这需要计算用于编码和解码的资源，并且需要更多的字节。IEEE754要求17位十进制数字将8字节浮点数精确地表示为字符串。将符号、小数点、指数和指数符号的字符相加，得到21个字符。这是SECS/GEM通过网络发送的两倍多。

环路保证

HSMS定义了一种称为Link Test的环路保证机制。如果没有活动的消息交换，协议层将启动一个计时器。每次计时器过期时，都会交换一条协议消息以确保连接仍然是打开的。

安全

HSMS没有定义安全性。没有连接方的验证，连接不需要凭证或证书。数据未使用任何普通加密算法加密; 然而，数据在数据打包过程中是模糊的，通常是人类无法读懂的。由于工厂网络与外部世界隔离，安全通常不会被视为一个问题。

结论

使用HSMS的SECS/GEM协议层提供了在工厂主机和设备之间交换准确数据的非常有效的方法。

SECS/GEM series: Protocol Layer

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 (SECSII), 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 ProtocolStack

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 24-byte integers + 2 8-byte floating point numbers + 1 4-byte event id + 1 4 bytereport 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 DataTranslation

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.

CircuitAssurance

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.

Topics: SECS/GEM, Smart Manufacturing/Industry 4.0, SECS/GEM Features & Benefits Series

Posted by Bill Grey: Distinguished Software Engineer on Aug 2, 201810:43:00 AM