半导体通讯协议SECSII/HSMS/GEM详细介绍和使用-2023/07/04

半导体通讯协议SECSII/HSMS/GEM详细介绍和使用-2023/07/04

凡事讲究一个为什么，为什么要按照这个协议去开发软件。因为在高度自动化的半导体制造厂，行业的设备大多来自不同的供给商，缺乏统一的通讯规范。没有标准的通讯协议，并且如果设备供应商不向半导体生产商开放通讯协议及接口软件，半导体生产商就必须自己建立软件之间的连接，增加额外的成本。而且工厂大多数会有一个集中控制中心，如果各个设备采用不同的通讯协议，集控中心很难实现智能工厂自动化这个目标。

SECS协议基本概念扫盲

SECS（全称：半导体设备通讯标准）协议协议是由国际半导体设备与材料产业协会（简称：SEMI）发布的。
SECS是一个协议族，主要包含4类：
1.SECS I (E4)
2.SECS II (E5)
3.GEM (E30)
4.HSMS (E37)

通讯方式

首先确定使用SECS协议的客户端和服务端之间使用什么通讯方式。如下图。

从图片里面可以看出来通讯方式有两种：
第一种就是串口通讯：对应的就是SESC I协议。串口通讯，一般都是通过设置串口号，波特率，数据位，停止位，校验位等来实现。比较直观简单，也比较落伍（毕竟机台哪有这么多的串口可供使用，而且通讯距离短，还需要考虑布线的问题）
第二种就是TCP/IP通讯：通过设置ip地址和端口号实现，这时主流的连接方式。做得Demo也是以这个通讯方式实现的。对应HSMS协议。

HSMS（全称 HIGH-SPEED SECS MESSAGE SERVICES）

HSMS通讯流程

HSMS通信的设备端通常为客户端（Equipment）（也可称为Active 在通信中主动连接对方的），工厂会部署服务端（Host）（也可称为Passive 被动等待对方连接）。
编写软件，不管是客户端软件还是服务端软件，因为都需要进行指令的收发，所以区别不是很大。通讯流程如下图：通俗易懂
判断两端是否连接，是通过TCP/IP通讯决定的。（即配置好IP地址和端口号之后，两端就可以直接通信）。
连接之后，服务端与不同客户端之间的通讯是HSMS协议决定的（即两端通过HSMS规定的不同的信息格式，接受和发送信息，实现服务端统一处理）。举个例子，就比如说客户端要和服务端建立连接，客户端1，客户端2…不管多少客户端，都应该发送同一个格式的信息，服务端这边才可以知道是连接这个请求。不能客户端1采用一种格式，客户端2采用另一种格式。
如下图：客户端Not Connection与Connection状态，这个是通过TCP/IP协议进行监听的，而Not Selected与Selected状态，是通过HSMS协议对客户端Connection状态的进一步划分。客户端Not Selected 不表示断开连接。

HSMS协议

HSMS一般信息格式

个人喜欢称服务端和客户端之间的一次通信信息，叫指令。这个就是指令的一般通用格式，前4个字节是表示这个指令的长度(注意：这个长度不包含自己的4个字节)即：Length = Header.Length + Message Text.Length。并且低位在后，高位在前。

重点的Header部分（一共十个字节）

序号	标识	含义
00-01	Device ID	设备的ID标记设备的唯一标识，低位在后，高位在前。
02	Header Byte 2	解释起来很复杂，对于控制信息和数据信息含义不同
03	Header Byte 3	解释起来很复杂，对于控制信息和数据信息含义不同
04	Ptype	消息的编码格式（SECS-II 编码格式 取值为0 ，所以该位就是0）
05	SType	消息的类型（==0表示为数据信息，!=0表示控制信息）
06-09	System Byte	标记这次指令的ID，通常用于超时判断（响应时依据发送者指令的最后4字节作为回复，发送时生成不重复的4个字节）

数据信息 Header Byte 2=（W+Stream），Header Byte 3=（Function）

Stream和Function

SECS使用Stream 和Function来区分不同的功能,即用SxFy表示所有的功能。
通常Fy中y是奇数则是发送消息,y是偶数表示响应消息 。
这其中S1F1、S1F2等都是具有特定含义的。
例如S1Fy的指令都表示与机台状态相关。
S9Fy的指令都表示与系统错误相关。
SxFy的发送接收，服务端或客户端并非每一个都可以使用，有的只有客户端可以发送，有的只有服务端可以发送，也有一些两者都可以发送。对于两者都可以发送的，如果发送方是S1F15，则回复方是S1F16。即，接收的一方收到SxFy后，则必须以SxF（y+1）来回复。

W

一个字节B，有8位b。如果这个指令需要回复，则8位里面，最高位是1。如果这个指令不需要回复则8位里面最高位是0。如上图，S1F1和S1F2同样都属于S1大类，但是Header Byte 2字节却不相同。需要回复的S1F1<Header Byte 2:10000001>转成十六进制就是81。十进制就是129。本文中所有指令交互默认都是16进制显示的。

控制信息 Header Byte 2 Header Byte 3

要介绍控制信息的Header Byte 2 和Header Byte 3，先介绍Stype字节。

SType（==0表示为数据信息，!=0表示控制信息（只列举了几个常见的，不全））

序号	标识	含义
0	Data Message	这是一个交换数据的报文
1	select.req	请求建立连接
2	select.rsp	同意建立连接响应
3	Deselect.req	请求断开连接
4	Deselect.rsp	同意断开连接响应
5	Linktest.req	心跳检查连接是否正常
6	Linktes.rsp	心跳检查连接响应

Header Byte 2 Header Byte 3

如下图

SelectStatus

如下图

DeselectStatus

如下图

此外还有一些控制信息，比较复杂，Demo中并没有使用到。

例子分析

控制信息

如下图关键是区分SType的值，作为回复方的要注意Header Byte 3这一位，作为发送方则Header Byte 3=0，

数据信息

如下图

最后你能完全看懂这张图，HSMS协议指令这一块基本就没问题了

HSMS 的 Message Text （SECS-II 编码格式）

正常来说到这步骤的时候，客户端和服务端之间指令交互已经没问题了。例如：客户端请求建立连接，服务端同意建立连接。如果这一步还没有做到的话，下面暂时不需要看，继续看上面的文章。心急吃不了热豆腐。
如果指令交互已经可以了，接下来就要解析数据信息（即头信息中SType字节==0）的数据部分。现实场景中，就是假如服务端要求获得客户端的某一个设备的温度（这个是由SxFy决定的），客户端返回给你温度100。这个100就会出现在数据信息的数据部分。只有一个值，很容易解析，那如果有100个值，解析和发送就需要按照特定的格式。也就是 SECS-II 编码格式，所以不管控制指令还是数据指令，头信息中PType字节一定取值为0。

SECS-II

SECS-II 主要是用于规范通信过程中的数据结构、数据项、变量项、对象字典、信息细节等。
还记得第一张图里面，服务端与客户端之间有两种通讯方式吗，走串口通讯，虽然使用的SECS-I协议，但是传输数据的格式，也是SECS-II。

SECS-II 的 构成

如图片所示，重点是类型字节（自己起的名称，字节长度一定是1）和长度字节组（这个长度由类型字节的最后2位决定）。一个字节有8位，类型字节的前6位代表Message Text的数据类型，是字节、bool、还是list等，类型字节的最后两位表示长度字节组的长度（因为只有两个字节，所以一共只有0,1,2,3这4种取值情况）。01即图片下方的1表示长度字节组的长度为1，长度字节组的长度为1则最多可以表示2的8次方（即如果需要传输的数据量是布尔类型的100个值，小于255，类型字节的前六位设置成001001，表示数据类型是布尔类型，最后两位设置成01就可以，长度字节组的长度也为1,100用字节表示则为00110010）。而如果超过255,1个字节就不够表示了，所以类型字节的最后2位，就依据情况而设置，（超过7.99M怎么办，我也不知道）。

SECS-II 支持的数据类型

SECS-II 的例子

例如需要发送一个字符串是ABC，
则类型字节就是前六位01000，因为ABC数量为3,1个字节就可以表示，所以最后2位为01，即长度字节组的长度为1。
长度字节组就是00000011表示3，
而ABC去查对应的ASCII码，也就是01000001（十进制就是65）,01000010（66），01000011。
所以最终需要发送的数据用字节表示就是
01000001
00000011
01000001
01000010
01000011

GEM

GEM也叫（SEMI E30）， 定义了一组最低要求、附加(可选)功能、用例和部分SECS-II消息的用户场景。通俗易懂的来说，就是你不可能把HSMS里面所有的SxFy都写在一个程序里面,GEM就是规定了必要的控制信息，基础的功能。会上面的HSMS 和SECS-II通用标准，GEM就没什么难度了。

总结

小时候看迪迦，里面一段话特别印象深刻，“努力活完短暂的一生，将成果留给后代继承，人类就是如此反复，真的很了不起！”为往圣继绝学，为万世开太平。