本文将讲述 SEMI 规范以及 SECS/GEM 协议的实现原理，消息包的构造实现，各种特殊消息类型（如 HSMS 状态控制、心跳包等）。笔者将尽可能展示一些细节，由于时间仓促，加之编者水平有限，文中错误在所难免，请读者谅解，欢迎批评斧正。

关于 SECS 协议，这里直接引用一下 SEMI 协会官网（www.semi.org）上的介绍

SECS/GEM is a language between an Equipment (a machine producing stuff like CPUs for computers, cell phones, solar panels, flat panels displays) and a Factory Host System, who wants to control lots of equipments and get data out of them. As every language it has its rules, defined by a group of people called SEMI which stands for Semiconductor Equipment and Materials International.

SECS 协议目前被主要用于半导体领域的设备自动化中，在 Fab 中通常由服务端 Factory Host System 负责接收 Tool（机台）的消息，网上统称此模块为 EAP 软件，它能向机台下发指令，监听相关作业信息，以完成机台对 Wafer（晶圆）一系列的加工过程。

目前行业内统一遵守一套自动化的流程规范，这套规范被统称为 SEMI 规范，它是国际半导体产业协会，主要为半导体制程设备提供一套实用的准则，适用于所有用于芯片制造、量测、组装和测试的设备，后续文中提到的 E87、E90、E94、E40 等编号均为 SEMI 规范的一部分。

不过本指南主要力求以最简单的方式展现自动化设备通信的工作原理，且 SEMI 对众多规范文档拥有版权，禁止二次配布，故不会对协议规范有过于深入的解读，如有需要，请移至 SEMI 官网查看。

对于 GEM 能力而言，SEMI 协会官网已经给出了大体框架，通常实现 GEM 能力的双端都拥有收、发事件，异常报警，设置机台常量的能力，跑货的大体流程可以分为物料载入，加工信息发送、核对，开始加工，加工过程中，加工结束，物料载离等步骤，具体可以参考下图。

有限状态机（自动机）FSM

在工业控制领域，状态机是一个极其重要的概念，它决定了设备能否按照计划流程加工，以及及时的停止加工，防止物料受损，一个好的状态机在异常处理上有着良好的 Handle 能力，需要通过一个状态模型来尽可能涵盖可能发生的情况。

一个抽象的状态机模型可以拆分为若干个状态节点，而每完成一个节点，下一个节点的动作才会被触发，我们称每一个这样的节点，为一步（Step），因此状态机可以用有向图（Directed graph）来表示，在实际实现状态机的数据结构中，也常视作图来编写整个流程。

通常状态机可以分为两种不同的类型，Moore 状态机和 Mealy 状态机，前者不考虑输入的内容而只根据目前状态决策，而后者不仅会考量当前状态，也同时会考虑当前的输入数据，最后综合做出决策。

由于工艺制程的复杂性，半导体领域通常使用的是 Mealy 状态机。需要注意的是，几乎所有的状态机有自己完整的生命周期（Life Cycle）钩子，通常在被初始化（Initialization）、状态转移（State Transition）、事件触发（Event Trigger）、动作（Action）、销毁的时候，会触发相应的钩子函数，以实现更加强壮的功能，我相信很多学习前端 Vue 的朋友应该都会比较熟悉，可以把它简单的理解为一个 DOM 从创建、渲染到销毁的过程。

状态机通常会被具象为某个机械实物、某个信号连接或为某个作业对象的工作流程模型，以 Factory Host System 端来举例，对于每一个批次的物料在到达某一个设备后，根据到达~加工~离开的作业流程，都需要编写相应的状态流程来支撑，在此先抛砖引玉，为能理解此概念，后面在详细展开。

HSMS 协议

HSMS 全称为 High Speed SECS Message Service，是一种高速的 SECS 消息传输协议，而自身只负责连接的控制，用于现代半导体设备高效的信息传输，承载整个通讯连接的底层基础消息，也有人称之为 SECS II，是 SECS I（E4）的替代品。

HSMS 协议拥有 4个状态，分别为 Not Connected, Connected, Not Selected, Selected。之所以出现这四种状态，是因为 HSMS 是一种基于 TCP/IP 协议上的高层协议，当套字节（Raw Socket）建立连接后，还需要保证两端能互相确认对方能支持 HSMS 协议，故会有 Select 状态，只有 Selected 的 HSMS 连接才被视为有效可用的连接。

对于 TCP Stream 而言，发送和接收的均为二进制数据包，它的整体长度大小随着消息长度大小而灵活决定的，但是 HSMS 的握手过程中，没有交换数据包需求，它为固定的 14 Bytes 消息。

上面是 SECS II / HSMS 大致的结构图，第1~4位主要表示了后面的整体消息长度，第5~6位为 SessionID 位，第7~8位为 Ptype 位，第9~10位为 Stype 位也就是 HSMS 协议控制位，第11~14位为 System Bytes 位，而如果存在数据，第15位开始后面的均为数据位。

建立握手的 HSMS 协议一共有 14 个字节，这里之所以除去头部用于表示消息长度的4位，因不存在数据，剩下的消息长度为 10 个字节，因此最后的结果为 0x00 0x00 0x00 0x0A 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00。

由于这里我们还没有牵涉到数据交互，因此 Session、Ptype 部分我们可以全部置零，但是 Stype 为控制 HSMS 状态的重要 Byte，当我们需要请求 Select 时候，将此位置为 0x01，代表 Select Request，所有的 sType 可以参考下面的列表。

sTypeDataMessage = 0
sTypeSelectReq   = 1
sTypeSelectRsp   = 2
sTypeDeselectReq = 3
sTypeDeselectRsp = 4
sTypeLinktestReq = 5
sTypeLinktestRsp = 6
sTypeRejectReq   = 7
sTypeSeparateReq = 9

System Bytes

你是否考虑过，如果有一天，你连续向对端同时发送了两个 HSMS 消息包，其中第一个数据包由于路由的关系导致被延迟了，而第二个数据包先到达了，于是对端先回复了第二个请求，随后才回复了第一个请求，那么对于收到回复的你而言，可能会产生错乱，因为按照我们先前所介绍的内容，我们完全无法确认这一个消息包究竟是回复我之前发送的哪一条消息的，我们只能根据收到的时间线来推断回复，这显然是不可行的。

System Bytes 就是为了解决这个问题而来，SEMI 协议规范，当对方向你发送消息时，它会携带一个 System Bytes ID，这是此请求近阶段唯一的身份证明，而你回复时，也需要以这个 System Bytes ID 回复，这样对端哪怕收到的消息时间线是完全乱序的，也能根据它的 ID 号正确的找到对应的请求数据包。

一般来说，每次发送一个新的请求，就会给 System Bytes +1，System Bytes 是会重复使用的，当 System Bytes 的四位达到 0xFF 0xFF 0xFF 0xFF，会置零重新开始，这也是为什么说是近阶段的消息身份证明，在以按年为计的长远角度来看，某个 System Bytes 会被重复利用，而再次出现。

心跳包

当一个 TCP 连接长时间建立但是没有任何数据传输的时候，网间路由为了能降低负载，可能会掐断这条 TCP 连接，因此定期发送心跳包保活是非常有必要的，与 WebSocket 发送 Ping/Pong 来维持连接不同，HSMS 协议设计上使用 LinkTest 来保活，同时也可以确认这条链路对端是否还在正常工作。

与 SelectReq 相同，只需要修改 Stype 位为对应的数字即可，这里不再多做赘述。

在这一篇文章中，我们只是简单的介绍了一下整个概念，方便读者理解一些术语以及基础架构，后续文章，我们将深入来探讨 SECS/GEM 协议的一些细节上面的内容，包括具体的实现。