前期调研与开发阶段技术详解：打破PLC工程师对SECS/GEM的认知误区

1. 需求调研阶段

2. PLC端修改与开发

3. 结语

一、需求调研阶段：模板文档的价值与使用指南

很多客户甚至部分同行，对“需求调研”的理解停留在“打个电话问问”的层面。事实上，一份结构化的《PLC转SECS/GEM需求调研表》，是整个项目成败的第一道防线。

1.1 为什么必须有文档模板？

在半导体工厂里，每台设备都有自己的“语言”。SECS/GEM协议就像一个“翻译官”，但翻译官需要一本字典——这就是需求文档的作用。没有这本字典，我们无法确定：

• 设备要让Host读取哪些状态变量（SVID）
• 设备要上报哪些采集事件（CEID）
• 哪些情况需要触发报警（ALID）
• 设备要响应哪些远程命令（RCMD）
• 设备要支持哪些终端消息（Terminal Services）
• 哪些变量需要极限监控（Limits Monitoring）

90%的认知误区在于：客户认为厂商提供一份SECS/GEM文件就够了，找个人看一下，等设备到了再测试。但这远远不够。

1.2 模板文档的核心构成（附讲解）

我们使用的《PLC转SECS/GEM需求调研表》包含以下核心章节：

第一部分：设备基础信息

不同PLC平台的集成路径差异极大。三菱使用MC Protocol，西门子使用S7 TCP/IP或OPC-UA。选错了通讯驱动，后面全是坑。

第二部分：状态变量清单（SVID / VID）

SVID（状态变量） 是Host可以从设备读取的实时数据。

数据类型必须严格匹配SEMI E5标准。如果变量定义为2字节整数（I2），却传输4字节整数（I4），Host会直接拒绝该消息。

第三部分：采集事件清单（CEID）

CEID（采集事件） 是设备主动通知Host“发生了某件事”的机制。

第四部分：报警清单（ALID）

第五部分：远程命令清单（RCMD）

第六部分：Terminal Services

第七部分：Limits Monitoring

第八部分：Process Program

1.3 模板使用的核心原则

很多客户说“我们的设备支持SECS/GEM”，但实际进厂一看——协议根本没有安装授权，有些连网口都没有。我们的模板要求客户提供厂商的SECS/GEM手册、测试日志（SML格式）和完整的点位Excel清单。

80%以上的测试问题，来自SECS/GEM事件没有发生、参数值不对、远程命令被拒绝。如果需求调研阶段没有把细节写清楚，联调阶段就是在“猜”。

二、PLC端修改与开发：为什么PLC程序必须改动？

2.1 工程现实下的核心矛盾

PLC工程师的认知：设备已经在稳定运行了，PLC程序是成熟的，为什么要动它？

SECS/GEM集成的需求：要满足半导体工厂CIM系统的接入要求，必须实现毫秒级事件响应、实时报警上报、远程命令控制、终端消息显示、极限监控等功能。

真实的现场往往是：

• 十年前的老设备，梯形图经过多位工程师修改，地址分配随性而为
• D100是温度（SVID），D101是定时器，D102是报警位（ALID），D103是其他数据
• 上千个点位分散在不同数据块中，毫无连续性可言

2.2 物理层的第一道坎：串口 vs 网口

在讨论地址之前，首先要面对物理现实——PLC的通讯接口决定了性能上限。

SECS协议在任何物理层上都可以运行，但性能和完整性是否达标，取决于物理层的承载能力。

串口连接（RS-232 / RS-485）

网口连接（Ethernet）

性能对比

说明：SECS协议本身在串口上也能跑，但半导体产线对事件响应延迟要求通常在100ms以内，串口Bulk Read的200ms延迟会导致瞬态报警漏报、状态变化丢失等问题。网口配合地址规整，才能保证性能和完整性同时达标。

2.3 业务属性的核心约束：为什么同类要连续

Bulk Read命令可以读取任意连续地址，无论这些地址是否分散——只要它们在物理地址上是连续的。

但问题的关键在于：如果同一段连续地址里混入了不同业务属性的点位（ALARM、CEID、SVID、RCMD等混杂），Gateway即使一次性读回来，也无法高效处理——因为每个点位的数据类型、含义和处理逻辑都不同。

错误认知：地址连续就行

有些PLC工程师认为：“把所有SECS点位挪到D1000-D2000，连续了，就完事了。”

错。

如果D1000-D1050是SVID、D1051-D1080是ALID、D1081-D1100是CEID，虽然物理上是连续的，但Gateway在每次读取后需要：

1. 逐个解析每个地址属于哪个类别

2. 分别放入不同的处理队列

3. 分别应用不同的业务逻辑

这就失去了Bulk Read的意义——原本可以一次读、一次处理，变成了“一次读回来，还要拆包分类”。

正确做法：按业务属性分别连续

将所有SVID排列在D1000-D1199，所有RCMD排列在D1200-D1249，所有ALID排列在M500-M599，所有CEID排列在M600-M699。

这样做的好处：

• Gateway可以分批次Bulk Read：一次读取D1000-D1199（全部是SVID），直接存入SVID缓存；另一次读取M500-M599（全部是ALID），直接更新报警状态
• 无需拆包分类，读回来的数据直接可用
• 代码逻辑清晰，维护成本低

对比示例

错误做法：混在一起

D1000: SVID_101（温度）
D1001: ALID_1（超温报警位）
D1002: SVID_102（压力）
D1003: CEID_1001（加工完成触发位）
D1004: RCMD_START（远程启动命令区）

Gateway读回D1000-D1004后，需要逐个判断这个地址是SVID还是ALID还是CEID还是RCMD。Bulk Read带来的效率优势被拆包处理抵消了。

正确做法：按类别分别连续

非布尔型区域（D区）：
D1000-D1199: SVID（全部）
D1200-D1249: RCMD接收区（全部）
D1300-D1399: 配方参数区（全部）

布尔型区域（M区）：
M500-M599: ALID触发位（全部）
M600-M699: CEID触发位（全部）
M700-M799: 状态标志位（全部）

Gateway执行4次Bulk Read即可覆盖全部点位，每次读回来的数据直接对应一个业务类别，无需拆包分类。

核心规则

Bulk Read的前提是地址连续，但真正重要的是“同类别连续”。 即使地址在物理上是连续的，如果SVID、ALID、CEID、RCMD混杂在一起，Gateway依然无法高效处理。只有确保同一业务属性的点位各自连续排列，才能最大化Bulk Read的价值。

2.4 完整的工程验证逻辑

验证方案1：不修改PLC，纯逐点轮询

验证方案2：只做物理连续，但不按类别分类

如果只是把所有SECS点位搬到一个连续区间，但不区分SVID/ALID/CEID/RCMD：

验证方案3：按类别分类连续分配（正确方案）

验证方案4：串口场景 + 变化位映射区

如果PLC只有串口，Bulk Read帧大小受协议限制。此时需在PLC中增加一个独立的变化通知区，Gateway只轮询这一小区块。

2.5 Terminal Services 与 Limits Monitoring

Terminal Services：Host通过S10F3下发消息，Gateway写入PLC预留的60字符地址，触发触摸屏弹窗，操作员确认后需要对应点位置于触发事件回传。

Limits Monitoring：设备自身对SVID进行上下限判定，越限时自身触发报警，而非等Host轮询。推荐在PLC梯形图中实现阈值比较，实时性最佳。

2.6 PLC端配合建议

以下列出了PLC端可能需要配合的工作项，并非所有项都是强制性的，具体取决于项目需求、性能要求和现场条件。

说明：

• 必须：该类功能在PLC端若不实现，Gateway无论如何无法替代。
• 视需求而定：根据客户具体需求决定是否需要，非项目必选项。
• 推荐/可选：不做项目也能跑，但做了能显著优化性能或增强可靠性。

三、结语

PLC工程师对SECS/GEM理解不深，不是他们的错。但如果有人利用这种信息差，向客户承诺“不需要修改PLC”，那就是对客户生产线安全的漠视。

哲方联科的立场很明确：PLC端的必要配合修改是SECS/GEM集成项目的前提条件。 串口场景下更需在PLC端增加变化通知区，否则物理层性能就无法支撑。我们不在合同里藏着掖着，不报“改了才发现要加钱”的流氓价。