1. SECS/GEM简介

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

SECSSemiconductor 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 ByteN Data Bytes CheckSum。每个数据块最大为 254 字节,如果一个SECS-II Message大于245字节,则以分块的形式进行传输。

        10 byte Header 组成

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

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

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

- System BytesHeader的最后四个字节,第七和第八字节表示 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 socketTLI等。使用标准的 TCP/IP 寻址,默认的端口号为 5000

        HSMS将通信实体分为Passive ModeActive 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 取值如下表所示:
取值描述
0SECS-II编码
1-127子标准保留
128-255保留,未使用

5) SType:会话类型(Session Type)为八位无符号整数,取值为 时表示 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.reqSType=1PType=0

Select.rspSType=2PType=0Header Byte 3 Select Status

Linktest.reqSType=5Ptype=0Session ID=0xFFFF

Linktest.rspSType=6Ptype=0Session ID=0xFFFF

Separate.reqSType=9PType=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。标准还定义了消息的结构,消息由ItemList构成。SECS-II还规定了事务协议,用于管理消息的交换、分块等。

4.2 Stream and Fuction

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

Stream编号

功能名称

Stream编号

功能名称

1

设备状态

10

终端服务

2

设备控制与诊断I

11

主机文件服务

3

原料状态

12

晶元定位

4

原料控制

13

数据集传输

5

意外处理

14

对象服务

6

数据采集

15

配方管理

7

加工程序控制

16

加工管理

8

控制程序传输

17

设备控制与诊断II

9

系统错误

18

子系统控制与数据

        保留的 StreamFunction编号为:

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

4.3 SECS-II 事务

        事务:是信息交换的基础。一个事务由不需要ReplyPrimary Message或需要ReplyPrimary 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的长度。第一个字节是格式字节,其高六位表示这个数据项的格式,低二位表示数据项长度的字节数,取值只能为12 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  

  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:处理程序暂停。 

5.3 设备功能和场景

        功能是由半导体制造设备所执行的操作。这些操作是通过使用SECS-II通信接口的消息发起的。场景是一组为了实现特定功能的SECS-II消息。

下列是GEM所定义的场景:

5.3.1 建立通信

        建立通信提供了一系列在系统初始化或通信节点丢失通讯之后正式建立通信的方法,以及通知远程通信节点通信发生了中断。

5.3.2 数据收集

        数据收集使主机可以通过事件报告、跟踪数据报告、阈值监视和查询所选状态或其他变量数据来监视设备活动。

5.3.3 事件数据报告

        事件报告为用户提供了一种动态和灵活的方法,定制化地满足主机对数据表示和呈现的个性需求。基于事件的数据收集方法可以主动向设备活动的主机提供通知,并且在监测设备状态和同设备保持同步。

5.3.4 变量数据收集

        该功能允许主机查询设备数据变量,用于初始化和同步。

5.3.5 跟踪数据收集

        跟踪数据收集提供了一种定期采样数据的方法。这种基于时间的数据收集方法便于跟踪和分析数据的趋势,便于在某个时间段内重复应用程序,便于监测连续数据。

5.3.6 阈值监视

        阈值监视功能为主机提供了一种监控设备状况的灵活、高效的异步方法。它不需要主机不断轮询设备。该功能允许主机根据需要实现阈值范围的更改。该功能适用于生产操作、诊断/测试和统计过程控制。

5.3.7 状态数据收集

        状态数据收集功能使主机可以向设备查询选定的状态信息,便于和设备状态保持同步。

5.3.8 在线确认

        设备在线和通信时的时候接受到来自主机的S1、F1,并用S1、F2作出响应。

5.3.9 报警管理

        报警管理功能使主机可以管理设备上发生的报警状态,获得报警通知。主机可以打开或关闭某个报警,要求设备上传警报信息等。

5.3.10 远程控制

        远程控制功能使主机按不同级别对设备请求执行操作。设备向主机提供的操作包括:开始工艺、选择工艺配方、停止工艺、暂停工艺、恢复工艺和取消工艺。

5.3.11 设备常量

        该功能为主机提供了一种读取和更改设备上所选设备常量值的方法。

5.3.12 工艺程序管理

        工艺程序和配方必须通过设备和主机系统之间的交互来进行管理。工艺程序管理提供了一种方法来传送或接收工艺程序,并在主机和设备之间共享这些工艺程序或配方的管理。

        工艺程序允许工程师设置和修改设备的工艺和和工艺参数,以达到不同的结果。不同的产品可能需要不同的工艺程序,而通常相同的工艺程序将用于所有大量给定的产品。

        工程师必须能够创建,修改,并从设备存储中删除程序。

        为了主机确认设备上有适当的工艺程序,必须有一种从设备到主机及从主机到设备的传送工艺程序的方法。主机还可能需要从设备的存储器中删除程序,以便为下载新程序腾出空间。

        此外,当工艺程序的内容或状态发生变化时,必须随时通知主机。

5.3.13 原料运输

        原料运输功能包括原料在设备、缓冲区和载具之间的物理传输。该功能可以通知主机原料是否已从设备的某个端口接收或传输。

5.3.14 设备终端服务

        设备终端服务允许主机能够在设备的显示器上显示信息,操作员能够在设备工作站与主机交换信息。

5.3.15 错误消息

        错误消息向主机提供由设备检测到的特定消息或通信故障的原因的信息。

5.3.16 时钟

        时钟功能使主机能够管理与设备相关的与时间相关的活动和事件。

        时钟的主要目的是为收集事件和警报报告提供时间戳。时间戳的使用利于分清事件或警报的发生顺序,并使主机能够调度设备行为。该功能使主机能把设备的内部时钟设定为某个特定值,同时设备也可以向主机询问当前日期和时间。

5.3.17 数据缓存

        数据缓存功能使设备可以在发生通信错误时存储消息并在通信修复之后继续向主机发送这些消息。数据缓存的目的在于当发生通信错误时保存消息以免信息丢失。

5.3.18 控制

        控制功能用于配置并操作控制状态图,使用户或主机可以修改设备的控制相关行为。

Logo

瓜分20万奖金 获得内推名额 丰厚实物奖励 易参与易上手

更多推荐