1. SECS/GEM简介

SEMI：Semiconductor Equipment and Materials International 国际半导体设备与材料产业协会

SECS：Semiconductor Equipment Communication Standard 半导体设备通讯标准

SECS是由SEMI制定，用来统一各个生产设备之间以及生产设备和控制设备之间的通讯标准。

1.1 软件集成自动化的痛点

不同的设备供应商之间没有标准的通讯协议，导致CIM自动化管理的困难与复杂程度增加，早期设备供应商不向半导体生产商开放通讯协议以及接口软件，这使得半导体生产商不得不建立他们自己的软件“连接”，既耗时又费钱。

1.2 SECS带来的益处

成本方面：缩短设备开发的时间及成本，通过自动化减少人力投入、生产费用减少；

效率方面：实现设备管理的最大化，提升设备装机效率达到快速量产，进而提升产能输出；

控制方面：减少操作人员的失误，还能通过对设备状态的把控来预测和预防错误，通过检测设备状态计划性的分配设备保养和工作时间。

1.3 SECS的分类

SECS/GEM

1.协议层：SEMI E4 (SECS-I) , E37(HSMS); 2.消息及数据层： E5 (SECS-II); 3.行为和场景： E30 (GEM).

GEM300：对设备行为和场景的更高级的要求，提供更高的复杂度和灵活度。

1.E40 (Process Job Management);

2.E94 (Control Job Management);

3.E87 (Carrier Management);

4.E90 (Substrate Tracking);

5.E116 (Equipment Performance Tracking);

6.E157 (Module Processing Tracking).

Interface A/EDA：提供即插即用的设备元数据接口，以及高密度高质量的设备数据。为工厂可以对大数据进行建模分析提供数据源。

1.E120 (Commone Equipment Module);

2.E125 (Equipment Self-Description);

3.E132 (Client Authentication and Authorization);

4.E134 (Data Collection Management);

5.E164 (EDA Common Metadata);

6.E179 (Protocol Buffers Common Components).

其他辅助及特种机台相关标准

1.E172 (SEDD);

2.E173(SMN);

3.E84 (Enhanced PI/O);

4.E109 (Reticle Management)

…..

1.4 SECS/GEM 结构

SECS-I 和 HSMS 处于SECS/GEM模型的底层，属于传输协议标准，描述数据是如何通过物理层在设备与主机之间进行传输的。SECS-I 的物理传输媒介是RS-232，HSMS的物理传输媒介是TCP/IP。 SECS-II属于消息格式标准，定义了在设备与主机之间进行双向会话时所使用的消息格式。 GEM属于设备功能标准，在SECS-II的基础上定义了半导体生产制造过程中的交互行为，即根据特定消息设备所应该采取的对应行为。

2. SECS-I 通信标准

2.1 SECS-I 简介

SECE-I 定义了半导体工艺设备(晶片制造、加工、检测、组装、打包设备)和主机之间交换消息通信的接口，即使用 RS-232 作为传输媒介时点到点的数据通信。

2.2 SECS-I 数据传输

（1）物理传输单位：bit

通信使用的是一个串行发送的 8 bit字符串，以及一个起始位和一个终止位。

（2）逻辑传输单位：block

数据被分块进行传输，一个块包括一个Length Byte、N Data Bytes 和 CheckSum。每个数据块最大为 254 字节，如果一个SECS-II Message大于245字节，则以分块的形式进行传输。

10 byte Header 组成：

– Device ID：Header的第一和第二字节，其第一个比特为 R-bit，其作用是指出消息传输的方向。

– Message ID：Header的第三和第四字节，其第一个比特为 Wait-bit，用于指示消息的发送者是否需要回复。

– Block No.：Header的第五和第六字节，其第一个比特为 End-bit，用于指示这个是否是消息的最后一个块。

– System Bytes：Header的最后四个字节，第七和第八字节表示 source ID，用于表示消息的发送者，第九和第十字节表示 transaction ID，用于唯一标示每个发送的消息。

2.3 Block传输协议

Block传输协议用于建立通信并为数据块的传输提供环境。协议使用单个字节进行握手，标准定义了四个握手编码，用于控制数据流，四个标准编码如下表所示：

T1计时器：表示在接收数据块时每个字符之间的时间间隔。

T2计时器：表示发送了ENQ之后到接收EOT之间的时间。

3. HSMS通信标准

3.1 HSMS简介

HSMS 定义了使用 TCP/IP 作为物理传输媒质时的通信接口。HSMS 又包括了两个子标准，分别是 HSMS-SS (High-Speed SECS Message Service Single Selected Mode)和 HSMS-GS (High-Speed SECS Message Service General Session)。HSMS-SS 对母标准中的操作进行了简化，以便于实际应用。HSMS-GS 定义了使用 HSMS 访问多个子实体的操作。

3.2 HSMS连接状态图

状态说明：

Not Connected 状态：实体开始侦听，但未建立任何 TCP/IP 连接或者之前建立的 TCP/IP 连接已断开；

Connected 状态：已建立一个 TCP/IP 连接，包括 Not Selected 和 Selected两个子状态；

Not Selected 状态：Connected 的子状态，表示没有创建 HSMS 会话或之前的会话已结束；

Selected 状态：Connected 的子状态，表示至少创建了一个 HSMS 会话。

表3-1 HSMS连接转态转换表

3.3 TCP/IP 的使用

HSMS可以使用任何标准 TCP/IP API 进行开发，比如 BSD socket、TLI等。使用标准的 TCP/IP 寻址，默认的端口号为 5000。

HSMS将通信实体分为Passive Mode和 Active Mode。

Passive Mode：处于被动模式的实体侦听线路，接收主动模式的实体的连接请求

Active Mode：处于主动模式的实体发起连接请求

3.3.1 建立TCP/IP连接

被动模式下建立连接的步骤包括：

(1)获得一个连接端点，在指定的端口进行侦听 (2)侦听到远程端点发送的连接请求 (3)接收连接请求，发送确认

主动模式下建立连接的步骤包括：

(1)获得一个连接端点 (2)向指定端口号的远程端点发起连接 (3)等待远程端点接收连接并返回确认

3.4 HSMS消息交换过程

HSMS定义了跨TCP/IP连接的实体之间的所有消息交换过程。一旦连接建立，这两个实体间就建立起HSMS通信。然后，数据消息可以在任何时候以任意一个方向进行交换。消息交换过程分为：

•Select Procedure：在TCP/IP连接上建立HSMS通信 •Data Procedure：连接处于Selected状态，任何一个实体都可以发起HSMS数据消息 •Deselect Procedure：在断开TCP/IP连接之前优雅终止HSMS通信 •Linktest Procedure：用于通信状态的确认 •Separate Procedure：在断开TCP/IP连接之前突然终止实体的HSMS通信 •Reject Procedure：响应在不适当的上下文中收到的其他有效的HSMS消息

3.5 HSMS的消息格式

HSMS消息以单个连续字节流传输，其格式如下图所示：

Message Length：一个 4 字节无符号整型，表示其后 Message Header 加上 Message Text 总的字节数，其最小值为十字节。
Message Header：消息头长度为10字节，格式如下图所示。

其中，

1)Session ID：16位无符号整型，最高位为零，剩下15位作为设备唯一标识。 2)Header Byte 2：在不同 HSMS 消息中用途不同，在控制消息中，取值为 0 或者Status Code，在数据消息中，它表示等待位（W-Bit）和SECS Stream。 3)Header Byte 3：用法和Header Byte 2 相似，不同之处是在数据消息中表示 SECS Function。 4) PType：表示类型(Presentation Type)为8位无符号整数，用于枚举表示层消息类型，即表示消息头和消息文本的编码类型，PType 取值如下表所示：

取值	描述
0	SECS-II编码
1-127	子标准保留
128-255	保留，未使用

5) SType：会话类型(Session Type)为八位无符号整数，取值为 0 时表示 HSMS 数据消息，否则表示 HSMS 控制消息，不同取值如下所示：

取值	消息类型
0	数据消息(Data Message)
1	选择请求（Select.req）
2	选择响应（Select.rsp）
3	取消选择请求（Deselect.req）
4	取消选择响应（Deselect.rsp）
5	连接测试请求（Linktest.req）
6	连接测试响应（Linktest.rsp）
7	拒绝请求（Reject.req）
8	(not used)
9	断开请求（Separate.req）
10	(not used)
11-127	Reserved for subsidiary standards
128-255	Reserved, not used

6) System Bytes：四字节无符号整数，作为事务的唯一标识。

3.6 HSMS的控制消息

Select.req：SType=1，PType=0

Select.rsp：SType=2，PType=0，Header Byte 3 为 Select Status 项

Linktest.req：SType=5，Ptype=0，Session ID=0xFFFF

Linktest.rsp：SType=6，Ptype=0，Session ID=0xFFFF

Separate.req：SType=9，PType=0

3.7 通信计时器

3.7.1 T3计时器

回复超时 T3 ：表示一个实体等待回复消息的最长时间，如果T3 超时则取消这次会话但不断开 TCP/IP 连接，如果这个实体是设备，则向主机发送 SECS-II S9F9 消息。

3.7.2 T5计时器

连接间隔时间 T5 ：表示两个连接请求之间的时间间隔。过于频繁的向一个未准备好连接的实体发起连接请求，会加重 TCP/IP 的负荷。因此，当一个主动模式实体发起的连接操作终止后，该实体必须等待 T5 计时器超时后发起下一次连接请求。

3.7.3 T6计时器

控制会话超时 T6 ：表示一个控制会话所能开启的最长时间，超过该时间就认为这次通信失败。当发送<xx>.req 控制消息时 T6计时器开启，若在 T6 超时之前收到相应的<xx>.rsp 消息则计时器关闭，否则控制消息的发起者将关闭这次会话，并认为出现一个通信故障。

3.7.4 T7计时器

Not Select 状态超时 T7 ：表示当建立了 TCP/IP 连接之后通信处于 Not Select 状态的最长时间，通信必须在该时间内完成 Select 操作，否则将会断开 TCP/IP 连接。

3.7.5 T8计时器

网络字符超时 T8 ：表示成功接收到单个HSMS 消息的字符之间的最大时间间隔。鉴于 TCP/IP 是面向流的通信协议，因此一个 HSMS 通信消息可能被分为若干个 TCP/IP 消息进行传输，若 T8 计时器超时则认为这次传输失败。

4. SECS-II通信标准

4.1 SECE-II简介

SECS-II 标准定义了设备和主机之间发送的消息所表达的含义。所有的消息按照其行为分类，称为Stream，每个Stream又包括具体的消息，称为Function。标准还定义了消息的结构，消息由Item和List构成。SECS-II还规定了事务协议，用于管理消息的交换、分块等。

4.2 Stream and Fuction

Stream和Function按照数字进行编号。所有的Primary Message的Function编号为奇数，其对应的Secondary Message的Function编号为偶数且为其Primary Message的Function编号加1。

Stream编号	功能名称	Stream编号	功能名称
1	设备状态	10	终端服务
2	设备控制与诊断I	11	主机文件服务
3	原料状态	12	晶元定位
4	原料控制	13	数据集传输
5	意外处理	14	对象服务
6	数据采集	15	配方管理
7	加工程序控制	16	加工管理
8	控制程序传输	17	设备控制与诊断II
9	系统错误	18	子系统控制与数据

保留的 Stream和Function编号为：

        Stream 1，Function 0-255
        Stream 1-63，Function 0-63
        Stream 64-127，Function 0

4.3 SECS-II 事务

事务：是信息交换的基础。一个事务由不需要Reply的Primary Message或需要Reply的Primary Message及其Reply Message组成。

4.4 SECS-II 会话

会话：是用于完成特定任务的一系列一个或多个相关事务。会话应包括完成任务所需的所有事务，会话结束时，会话双方应释放相关资源。

SECS-II中定义了7种类型的会话:

1. 一个无需回复的Primary Message是最简单的会话。此消息必须是一个单块的SECS-II消息。

2. 如果响应端有发起端想要的数据，则会使用Primary Message请求这些数据，响应端将这些数据作为Reply Message回复给发起端。这是一个 request / data conversation。

3. 如果发起端将单块消息中的数据发送给响应端，并期望从响应端回复确认。

这是一个 send / acknowledge conversation。

4. 如果发起端有一个要为特定的交互发送的多块消息，则发起端必须在发送数据之前获得响应端的许可。

会话中的第1个事务请求发送权限，响应端授予或拒绝发送权限。如果授予权限，发起端发送数据，响应端进行相应地回复。

这是一个 inquire / grant / send / acknowledge conversation。

5. 一个关于在设备和主机之间传输未格式化的数据集的对话，这个会话在 Stream 13 中有详细描述。

6. 一个关于设备之间原料处理的会话。这个会话在 Stream 4中详细描述。

7. 发起端可以向响应端请求需要一段时间才能获取的信息（例如，操作员的输入）。

会话中的第一个事务请求信息，并且响应端以三种方式之一响应：（1）返回信息，（2）响应端表示不能或不会获得信息，（3）响应端表示将在随后的事务中获得并返回信息。

　对于方式（3），响应端将在信息可用时启动后续事务返回信息。方式（3）是一个 request / acknowledge / send / acknowledge conversation。

4.5 消息的数据结构

所有根据SECS-II标准的消息使用两种数据结构，即 Item (项目) 和 List（列表）。消息数据结构定义了消息的逻辑划分，与消息传输协议的物理划分不同。

消息的数据结构旨在为在设备和主机之间传递的消息提供一个自描述的内部结构。

4.5.1 Item

一个Item是一个具有长度和格式的信息包。由Item Header 和 Item Body 组成。

Item的前2个、前3个或前4个字节称为 Item Header，用以描述Item的长度和格式。Item Header后的字节称为 Item Body，Item Body是Item的实际数据。

下图是ItemHeader的结构图。

Header的第1个字节为Format byte，其后的字节为Length byte。

Format byte的第1位和第2位：

定义Format byte后面有几个字节来表述Item Body的长度。第一个字节是格式字节，其高六位表示这个数据项的格式，低二位表示数据项长度的字节数，取值只能为1、2 和 3，如果为 0 则该数据项格式错误。若为 1 则该数据项最长为255字节；若为 2 则该数据项最长为 64K 字节；若为 3 则该数据项最长为 7.99M 字节。

Format byte的第3位至第8位：定义数据的格式，即ItemBody中的字节数据类型。下表为数据类型定义表：

格式编码		含义
（Bit 765432）		含义
Binary	Octal	数据类型
000000	0	List结构
001000	10	二进制
001001	11	布尔值
010000	20	ASCII
010001	21	JIS-8
010010	22	2字节字符
011000	30	8字节有符号整数
011001	31	1字节有符号整数
011010	32	2字节有符号整数
011100	34	4字节有符号整数
100000	40	8字节浮点数
100100	44	4字节浮点数
101000	50	8字节无符号整数
101001	51	1字节无符号整数
101010	52	2字节无符号整数
101100	54	4字节无符号整数

4.5.2 List

List是一组有序的元素，其中元素可以是Item或List。

List的Header与数据类型为0的Item的Header形式相同。不过List的Header中的长度表示List中元素的个数，Item的Header中的长度表示数据字节的个数。

4.5.3 Localized Character String Items

本地化字符串项是一个用于表示由多字节字符组成的字符串的Item。其Header中的Format Code为22（Octal）。它由string header和string组成。

因为字符有许多不同的编码方案，所以有一个附加的string header来表述字符集。

string header 是一个2字节16位的数字，它在 Item Header 之后，在string之前。

string header 是 Item 的实际数据的一部分，所以它的长度计算包含在Item Header 的 Length byte 中。

下图为string header的编码集对应。

4.5.4 不同Item的数据实例

1. 包含一个二进制数据10101010的Item。

　　00100001　　Item, binary, 1 length byte

　　00000001　　1 byte length

　　10101010　　data byte

2. 包含三个ASCII字符ABC的Item。

　　01000001　　Item ASCII, 1 length byte

　　00000011　　Three bytes long

　　01000001　　ASCII A

　　01000010　　ASCII B

　　01000011　　ASCII C

3. 包含三个2字节有符号整型数字的Item。

　　01101001　　Item, 2-byte integers

　　00000110　　6 bytes total (6/2=3 integers)

　　xxxxxxxx 　　MSByte number x

　　xxxxxxxx 　　LSByte number x

　　yyyyyyyy　　MSByte number y

　　yyyyyyyy　　LSByte number y

　　zzzzzzzz　　MSByte number z

　　zzzzzzzz　　LSByte number z

4. 包含一个4字节浮点数的Item。

　　10010001　　Item, 4-byte floating point　　

00000100　　4 bytes (4/4=1 number)

　　f f f f f f f f

　　f f f f f f f f　　Floating point number

　　f f f f f f f f

5. GEM通信标准

5.1 GEM 简介

GEM (Generic Model for Communications and Control of Manufacturing Equipment)，通用设备模型定义了通过通信链路所能看到的半导体设备的行为。SECS-II 标准定义了在主机和设备之前交换的消息格式以及相关数据项。GEM标准在此基础上定了在何种情况下使用哪些SECS-II消息以及会发生哪些行为。主机电脑在任何时间都可能发起任何GEM消息场景，设备必须按照 GEM标准中的描述做出响应。设备提供商可以提供GEM中没有的额外功能，但是不能与GEM中已定义的行为和功能相冲突。

5.2 状态模型

状态模型的基本单位是状态。一个状态是一组静态的条件。如果满足这些条件，则该状态为当前状态。这些条件可能涉及传感器读数、开关位置、工作时间等。

一个状态的另一部分是对特定刺激的反应的描述(例如，如果接收到消息Sx，Fy，生成回复消息Sx，Fy+1)。刺激可能相当多样，但对于半导体设备，将包括接收到的SECS消息、到期的计时器、设备终端的操作员输入以及传感器读数的变化。

状态模型从主机角度描述设备行为。不同设备的状态模型在有些方面相同（比如通信）但是在其他方面不同（比如加工）。因而需要把一个设备分为并行的几个部分，这些部分既可以单独的建模又可以合并起来，如下图所示：

5.2.1 通信状态模型

通信状态模型定义了设备与主机有无通信连接时的行为。此模型适用于设备和主机之间的逻辑连接，而不是物理连接。

在建立通信链路时发生通信连接事务失败，这是由通信故障，或在回复超时时间限制内未接收S1、F14回复，或S1 F14的接收格式不当或结果未设置为0引起的。

在第一次成功完成任何一个S1、F13/F14事务后，建立一个通信链路。

通信状态模型图和转化表如下：

SECS通信有两种主要状态，即 Disabled 和 Enabled 。系统默认状态必须在设备上可用户配置。一旦实现系统初始化，操作员应能够随时通过设备终端功能或瞬时开关改变通信状态的选择。

DISABLED状态：与主机没有SECS-II通信。如果操作员从 Enabled 切换到 Disabled，所有SECS-II通信必须立即停止。任何排队等待发送的消息都将被丢弃，并且对任何开放的事务和会话的所有进一步行动都将被终止。

Enabled状态：有2个子状态，Not Communicating 和 Communicaing。

Enabled – Not Communicating 状态：在此状态下，不得发送除S1 F13、S1 F14、S9 Fx以外的任何消息。

设备应丢弃除S1、F13或S1、F14以外的任何从主机接收到的任何信息（建立通信确认）。还应定期尝试通过发出S1，F13来与主机建立通信，直到通信成功建立为止。

Not Communicating 状态有两个子状态，Host Initiated Connect 和 Equipment Initiated Connect。

Not Communicating – Equipment-Initiated Connect 状态：这个状态有两个子态，Wait CRA 和 Wait DELAY。

在进入 Not Communicating 状态时，每当 Equipment Initiated Connect 状态首先被激活时，就会发生向 Wait CRA状态的过渡，通信延迟计时器被设置为“过期”，并立即尝试发送S1，F13。

Not Communicating – Equipment-Initiated Connect – Wait CRA 状态：已发送了一个建立通信请求。该设备将等待主机确认该请求。

Not Communicating – Equipment-Initiated Connect – Wait Delay 状态：已发生了连接事务失败。通信延迟计时器已初始化。该设备将等待计时器过期。

Not Communicating – Host Initiated Connect：这个状态描述了在Communicating状态未激活时，设备响应主机启动的S1、F13的行为。

Not Communicating – Host Initiated Connect – Wait CR From Host：设备等待来自主机的S1、F13。如果接收到S1、F13，则该设备尝试发送带有通信结果为0(成功)的S1、F14。

Enabled – Communicating：通信已经建立。设备可以接收来自主机的任何消息，包括S1、F13。

当设备正在进行通信时，必须维护与主机计算机的SECS通信。此状态一直处于活动状态，直到通信被禁用或发生通信故障。

如果设备处于Communicating子状态下从主机接收到S1、F13，则应该用S1、F14回复结果设置为0的消息。

5.2.2 控制状态模型

控制状态模型定义了主机和设备之间的操作等级。它还指定了操作员如何在不同级别的主机控制上进行交互。

通信状态模型解决了主机和设备交换消息的能力，而控制模型则解决了设备对其接收到的消息采取行动的责任。

控制模型为主机提供了三个基本的控制级别：

– 最高级别（Remote），主机可以尽可能地控制设备。
– 中间级别（Local）允许主机完全访问信息，但对对设备的操作有一些限制。
– 最低级别（OFF-Line），设备不允许主机控制且只提供非常有限的信息。

控制状态模型图和转换表如下：

5.2.3 设备处理状态模型

记录设备在执行其预期功能时的行为。该处理状态模型高度依赖于设备的工艺、采用的技术和类型。

状态模型图和转换表如下：

IDLE：设备正在等待指示。

PROCESSING ACTIVE：此状态是存在处理程序执行上下文的所有子态的父状态。

PROCESS：此状态是指处理程序的主动准备和执行的子状态的父状态。

SETUP：在这种状态下，满足了工艺执行所需的所有外部条件，如确保材料存在于设备上，输入/输出端口处于正常状态，温度和压力值等参数在限制范围内等。

如果所有的设置操作都已经完成，将转换到下一个状态。

READY：在这种状态下，设备已准备好要执行处理程序，并正在等待来自操作员或主机的启动命令。

EXECUTING：处理程序执行中。

PAUSE：处理程序暂停。