★ FEATURED ARTICLE SECS/GEM/GEM300/EAP 这套协议体系在半导体工厂里是设备自动化的地基。只要你在FAB里待过肯定见过设备工程师对着日志抓耳挠腮也见过软件工程师在调试终端前一行行敲命令。这玩意儿说复杂也复杂消息类型上百种状态模型绕来绕去说简单也简单本质上就是设备和主机之间“约好怎么说人话”。这篇是系列的第二篇专门把协议层拆开揉碎讲清楚从最底层的字节传输到消息怎么组包再到GEM标准里定义的各种行为规范最后把GEM300和EAP的位置摆明白。适合刚入行准备做设备自动化、或者要和设备厂商对接的工程师参考读完之后你能自己看懂抓包日志也能在联调会议上不被厂商唬住。1. 协议栈全景先搞清楚每一层在干什么1.1 从SECS-I到EAP一次类比说清层次关系打个比方。两个人要聊天得先解决三件事声音怎么传过去物理层、说出来的话怎么断句成一句句完整的句子会话层、每句话用什么语言和语法规则表示层。SECS/GEM/GEM300 这套体系就是半导体设备自动化里的“聊天规范”。SECS-ISEMI E4定义物理层也就是RS-232串口上的字节传输规则。HSMSSEMI E37替代SECS-I的新物理/传输层跑在TCP/IP之上是现在FAB的主流。SECS-IISEMI E5定义消息的语法也就是主机和设备之间互相传输的“消息格式”和“具体用词表”。GEMSEMI E30定义设备的行为规范比如什么时候该报告状态、报警怎么上报、远程命令怎么处理相当于“聊天时双方该遵守的礼貌和流程”。GEM300面向300mm工厂的扩展协议族包含E39、E40、E84、E87、E90等一堆新标准主要解决装载端口、载具追踪、设备间通信这些更细的问题。EAP不是SEMI标准而是MES与设备之间的自动化逻辑中间层负责把GEM的底层消息翻译成业务动作。这套分层结构和网络协议里的OSI七层模型有点像但是更专一它只服务于半导体制造设备。理解每一层是干什么的是在协议层排错之前必须打好的底子。我见过太多人直接把SECS-II消息打印出来看看不懂就开始瞎猜其实问题可能出在最底层的HSMS心跳断连或者SECS-I的波特率设置错了压根没到消息解析这一步。1.2 为什么协议要分层以及SEMI标准族全景分层最大的好处是解耦。换句话讲各层可以独立升级。早期设备用SECS-I跑串口后来FAB网络化普及大家想用TCP/IP来跑如果协议不分层整个消息格式就得推翻重来。SECS-II的消息格式和物理传输方式无关今天你可以用RS-232传明天换HSMS用TCP传SECS-II照用不误。这就是标准的魅力也是为什么SEMI把标准拆成E4、E5、E37、E30等多个族。协议标准全称说明对应层次核心作用SEMI E4SECS-I物理/传输层基于RS-232的字节流传输SEMI E5SECS-II消息层消息格式、数据项、流与功能码SEMI E30GEM行为层设备行为建模、事件/报警管理SEMI E37HSMS传输层基于TCP/IP的高速消息传输SEMI E39对象服务应用层扩展对象实例管理如载具、工艺配方SEMI E40工艺流程管理应用层扩展Run Management、配方管理SEMI E84载物台通信传输扩展装载端口与载具的通信协议SEMI E90追踪应用层扩展WIP追踪与物料路由SEMI E94控制作业管理应用层扩展多任务控制作业的协调SEMI标准还有很多E87载具管理、E88物料搬运、E116设备追踪等等实际项目中按需采用。但从“协议层”这个主题出发E4、E5、E30、E37是绝对核心。EAP是在这些核心标准之上做业务编排的。2. 传输层的两台“信使”SECS-I与HSMS2.1 SECS-I老当益壮的RS-232实现SECS-I把SECS-II消息块封装成“块Block”通过RS-232串口逐字节发送。它有一些非常硬核的规定每个块最长不超过244字节块与块之间用长度字节分隔字符帧格式是“起始位数据位奇偶校验停止位”的串口标准。实际项目中波特率常见9600或19200但选串口就意味着速率天花板——9600波特率下每秒只能传大约960字节算上消息开销传一个几百字节的SECS-II消息就要1秒起步。SECS-I有个特点值得注意它是单主机对单设备的点对点通信。一台设备只能和一个主机建立连接主机唯一设备地址Device ID是0或者某个特定值。这在老式的单机台自动化里没问题但到了300mm工厂一台设备既要和MES通信又要和AMHS自动物料搬运系统通信点对点很明显不够用。SECS-I还有一个“时间戳”机制块里带Length字段和奇偶校验保证串口上噪声干扰下还能发现丢字节、错字节。然后是消息的发送机制。SECS-I分“多块消息”一个SECS-II消息如果超过244字节会被拆成多个块依次传送。接收方必须把所有块收齐才能还原成完整消息块信息里包含块号、总块数还有一个特殊的“结束块”标记。这意味着如果你在抓串口数据看到的是带序号的块而不是直接看到一条完整消息。协议层联调时如果发现某个多块消息总是不完整先别怀疑SECS-II解析去查串口是不是丢了字节或者是不是两块消息之间间隔过大导致超时。2.2 HSMSTCP/IP时代的消息高速路HSMSHigh-Speed Message Services解决了SECS-I的两大痛点速率和连接数。它基于TCP/IP走以太网消息响应速度是毫秒级并且一台设备可以同时与多个远程实体通信不再是一对一。HSMS也定义了更清晰的连接管理不是直接从设备进程启动就开始传消息而是有一个“未连接→连接→通信中”的握手流程。HSMS的消息格式分两层传输头Header和正文Data。传输头是固定的26字节里面包含消息长度、会话ID、消息头字节、期待响应位等关键信息。实际操作中HSMS最常见的坑有两个一个是心跳超时。HSMS规定如果一段时间内没有消息通信连接双方应发送心跳请求Selective Data维持连接默认心跳间隔常见10秒、20秒。如果对端设备因网络抖动没有回应TCP连接会被判定断开设备就会进入离线状态MES里显示“Equipment Offline”。另一个是端口冲突。HSMS默认端口5000但实际FAB里经常由设备厂商随意指定几千台设备很容易撞端口排查时先查端口占用。HSMS 三种连接模式也需要掌握Active模式主动发起TCP连接适合设备寻址到主机。Passive模式被动监听主机发起的连接。Active-Passive混合模式设备上起TCP服务同时可以尝试连主机备用地址。实际项目里最常用的是主机Active、设备Passive。设备只需要配置“控制端IPPort”和“设备IPPort”主机负责连接管理。但这也会带来一个麻烦主机重连设备之前必须主动断开旧连接否则设备端只认一个TCP连接新连接会被拒绝。联调时遇到“连不上设备”多半是连接没断开干净。2.3 传输层选型的实操建议当前新建FAB的项目不需要犹豫直接选HSMS。只有在老旧设备改造、或设备控制器只有串口没有网口的极端场景下才保留SECS-I。如果你在做上位机软件直接按HSMS实现顺便兼容SECS-I作为一个底层驱动选项就够了。选型不是技术问题而是维护成本问题。串口方案还需要光电隔离、串口服务器调试难度和排错成本远高于TCP。尤其在远程诊断、多主机协同、日志采集这些场景没有IP一切都白搭。对比维度SECS-IHSMS物理介质RS-232串口以太网TCP/IP通信拓扑一对一一对多典型速率9600/19200 bps100M/1Gbps连接建立物理链路握手TCP连接握手心跳机制无标准定义周期性心跳适用场景老旧设备、改造现代FAB主流具体到手写代码我建议先实现HSMS的以下消息收发原语建立连接、释放连接、发送数据块、接收数据块、心跳响应、连接状态回调。消息体解析放在下一层做传输层只关心字节流完整送达。这里的“完整送达”很关键TCP虽然是可靠传输但不保证“一条应用消息恰好一个TCP包”所以HSMS层必须自己做粘包拆包。常见做法是先用4字节存长度再等够长度再parse。3. SECS-II协议层消息的语法与语法3.1 消息头结构SECS-II消息是SECS-I/HSMS传输的“载荷”。一条消息由消息头Message Header 正文Body组成。消息头固定10字节是整个协议里最需要背下来的东西。字节0-1Device ID会话ID但只有低7位有效高1位是“是否包含会话ID”的标志。实际抓包里你会发现DC位设备ID标志经常是0表示不区分设备地址。字节2Stream流和Function功能。字节3W位期待响应位、R位恢复请求位。字节4-5会话IDSession ID用于多块消息的事务关联。字节6-9系统字节起“事务标识”作用用于匹配“请求-响应”对。这里最容易被忽视的是字节4-5的会话ID。它本质上是“该条消息所属的事务ID”。当你发一个请求需要等待回复时回复消息的系统字节要和请求消息相同这样发送方才能知道这个回复是针对哪条请求的。多块消息的每一块也都带同一个Systen Bytes接收方才能把分散的块重新组装成同一条消息。抓包时如果发现响应消息的System Bytes对不上请求的基本都是上层业务实现有bug而不是网络问题。3.2 事务机制对话ID与W-BitSECS-II的通信模式可以分三类无响应请求Primary Message without reply、有响应请求Primary Message with reply、以及由主机发起的事务。W位Wait-Bit就是关键开关。W0表示不收回复W1要求接收方必须回一条对应Stream/Function的消息。这是一种“谁提问谁收尾”的机制跟聊天中对讲机“我说完你回我”一样。事务建立的细节是主机发送一条W1的请求设备端收到后必须以一条“与此请求匹配的”Secondary消息通常Stream和Function有关联回复。这个回复里要求System Bytes与请求一致。同时消息头里的W位为0表示该消息是应答消息。设备不能自己主动“回答”一条不存在的请求也不能在收到请求前就开始发送应答。联调中最常见的错误是设备端自作主张乱发Secondary消息或者主机端没有维护好等待中的会话表导致响应到了却匹配不到任何请求直接丢弃。主机端的事务管理强烈建议实现一个“等待响应队列”。发送请求时把System Bytes注册进队列设置超时时间常见10秒~30秒收到响应后按System Bytes匹配出对从队列弹出。超时未响应的还要触发超时重试或报警逻辑。这个队列在EAP里尤其重要因为EAP可能同时向多台设备发请求没有队列管理根本搞不清哪条响应属于哪条请求。3.3 数据项与SML格式SECS-II消息正文不是普通字符串而是一棵数据项树。数据项的类型包括二进制Binary、布尔Boolean、ASCII字符串、8字节整数I8、4字节整数I4、2字节整数I2、1字节整数I1、8字节浮点F8、4字节浮点F4、列表List等。每个数据项以格式代码开头格式代码后跟长度字节表示该项占用的字节数。List类型可以嵌套任意多个数据项这构成了设备消息的层级结构。举个例子一条S2F41主机请求设备列表的响应消息S2F42里正文常常是一个巨大的List嵌套着多个子List每个子List描述一台子设备的信息。如果直接拿十六进制打印看正常人根本看不懂。所以要引入SMLSECS Message Language这种文本格式。SML看起来像这样的伪代码S2F42 L [3] A 设备1 A 设备2 A 设备3 SML是调试和联调的“通用语言”几乎所有SECS/GEM调试工具都支持SML格式的发送和解析。上手时你需要会读SML、会写SML、会把SML翻译成字节流以及反着来。字节流和SML之间的转换就是SECS-II库要做的事。自己写这个转换不难但要注意边界问题长度超过127字节的字符串要用“长数据项”表示否则解析会错位嵌套List的元素个数也要数清楚漏一个元素后面的全部错位查起来极其头疼。3.4 流和功能码SECS-II的消息类型用“流/功能”SxFy来标识。流表示大类功能表示具体动作。常见的有S1F0约定测试Are You There的回应。S1F1主机询问设备是否在线。S1F2F1的响应携带设备状态。S1F13建立通信请求。S1F14F13的响应建立通信确认。S2F17请求设备时间。S2F18F17的响应设备上报时间。S2F41/42主机请求设备列表设备返回。S5F1设备主动上报报警。S6F11设备主动上报事件。S6F12F11的响应事件报告确认。S1F13/S1F14特别值得单独说它是SECS-II通信层“建立连接”的第一步。设备连上HSMS之后主机端一般要先发S1F13协商通信是否建立双方交换协议版本号、设备支持的功能块信息。如果在抓包日志里看到S1F13之后没有S1F14说明通信建立失败常见原因是设备端返回了错误代码比如协议版本不支持。这些“建立通信”消息是GEM最底层的基础任何设备自动化项目联调第一天就应该确认S1F13/S1F14能正常往返。功能码还有一个细节同一流的不同功能可以带不同方向的“主/从”属性。比如S1F1是主机到设备的PrimaryS1F2是设备回给主机的Secondary。理解主从关系才能正确设置W位。调试时可以用工具主动发S1F1观察设备是否回S1F2、System Bytes是否匹配、设备回的数据内容是否符合预期。这三步验证通过说明SECS-II消息层的“收发链路”已经通了可以开始更复杂的业务消息调试。4. GEM标准让设备“行为规范”起来的SOP4.1 设备状态模型与通信状态模型GEMSEMI E30把所有设备的自动化行为规范成一套标准状态模型这是它最核心的贡献。没有GEM之前每台设备的厂商状态五花八门有的用0/1表示运行/停止有的用英文字符串主机端只能针对每台设备写专属逻辑维护成本爆炸。GEM统一之后设备状态被归纳成几个标准状态集合比如设备状态POWER_ON、IDLE、READY、RUNNING、STOPPED等、报警状态、事件状态。通信状态模型则描述主机与设备之间的“会话状态”COMM_NOT_ESTABLISHED通信未建立。COMMUNICATION_STARTED主机已发出通信建立请求S1F13。COMMUNICATION_ESTABLISHEDS1F14确认通信正常。COMMUNICATION_ABORTED通信中断。我特别要提醒一个状态切换细节GEM规定设备在COMMUNICATION_ESTABLISHED之前不能向主机发送事件报告S6F11也不能接收远程命令S2F41之类的。很多设备软件在通信刚建立时会立刻尝试发事件结果主机还没准备好消息直接出错。主机端处理时最好在“通信已建立”事件触发后再启动事件订阅、时间同步等动作给设备一点缓冲时间。4.2 事件通知与数据收集GEM的事件报告机制是设备自动化的“感觉神经”。设备状态发生变化、报警发生、工艺步骤切换都会通过S6F11主动上报给主机。每条S6F11里有一个事件IDCEIDCollection Event ID和一组数据变量DVVAL。主机端只需提前配好“事件订阅表”告诉设备“哪些事件发生后报哪些变量”之后就能实现实时监控。事件收集的关键是“收集计划”Collection Plan。通过S2F33定义数据收集计划和S2F35请求事件报告来配置。操作中最大的坑是设备端收集计划的数量是有限的很多老设备只有8个或16个配置多了设备会拒绝。而且不同事件ID对应的DVVAL列表粒度很细一个变量名对不上设备端会返回错误代码。因此建议在写配置前先拿设备手册核对一下事件ID和变量ID的映射表不要凭空猜。事件上报的W位也值得注意。S6F11默认W0不需要响应但有些设备配置成W1要求主机回S6F12确认。主机端必须无条件支持这两种模式。如果主机没回S6F12而设备又等了超时后续事件可能会被设备端缓存但不再发送导致数据丢失排查时看设备日志才能发现。4.3 报警管理报警上报走S5F1设备主动上报报警或S5F3主机请求报警列表。一条报警消息里包含报警代码ALCD、报警IDALID、报警文本和报警时间戳。报警代码分4类FATAL致命、ERROR、WARNING、INFO。GEM还定义了报警启用/停用机制S5F3/S5F4不是报警发生了就一定要主动报而是取决于报警是否在“启用”状态。我在项目里遇到过一次很典型的报警问题设备发生了一次瞬时欠压报警马上又恢复了设备端发了S5F1然后又发“报警清除”主机这边由于报警处理逻辑写得激进直接把批次给Abort了。后来改成报警“确认延迟”机制报警发生后等待数秒如果设备端报清除就不处理只有持续报警才触发业务停机逻辑。设备工程师都说这个设计合理。处理设备报警关键不是看到报警就慌而是想清楚报警是“需要立即停止流程”还是“提醒”两者在EAP里处理路径完全不同。4.4 远程命令GEM的远程命令机制是设备自动化的执行器官。主机通过S2F41发送一个远程命令RCMD命令名和参数都放在正文里。设备执行后回S2F42携带完成状态比如“命令完成”“命令拒绝”“参数错误”。S2F41通常带W1要求强制响应。远程命令的位置必须明确远程命令是GEM规定的“主机控制设备”的通道。比如主机想让设备开始跑工艺Process Start、终止工艺、切换配方都通过S2F41发送。为了能执行远程命令设备端需要实现“命令解析→权限校验→执行→返回状态”的逻辑。联调时常见问题有命令名大小写不敏感但设备端没有做标准化导致主机发“ProcessStart”设备却要求“ProcessStart”或“PROCESSSTART”完全匹配不上命令参数的类型不匹配比如主机传字符串“1”而设备期望整数1也会被拒。调试时一定要把S2F41和S2F42的完整SML打出来对比参数格式一个字符都不能差。远程命令还有一个“可写设备状态”的交叉检查。GEM状态模型会定义某些命令只能在特定状态下执行比如“开始工艺”只能在READY状态执行如果设备处于IDLE或PAUSED命令会被拒绝。主机端下发命令前先查询设备状态能省去大量尝试成本。4.5 变量集Vid与追溯GEM中设备有很多变量SV状态变量、EV事件变量、DV数据变量、ECV设备常量。主机通过S2F13请求变量查询和S2F17请求时间来读取。变量IDVID是每个变量的唯一编号。不同设备厂商对VID的定义不同但GEM会约定义一些通用VID比如设备状态SV、工艺配方号SV等。实际项目里最常见的问题是“VID表维护不到位”。新设备上线、软件版本升级后VID表经常变主机端如果还按旧的VID去读拿到的是空值或者错误类型。追溯Trace Data是GEM里很实用的功能。通过S2F23定义追溯请求可以让设备周期性或者按指定条件上报一组变量。这个功能在做设备稼动率分析和工艺过程监控时非常香。举个例子我做过一个项目的设备追溯采集每500ms采集一次当前设备状态、运行模式、主腔体真空度等SV设备端通过S2F24持续上报主机端把数据灌进时序数据库做成了实时曲线。效果比从设备日志里抓字符串强了一个档次。追溯功能也会有性能隐患。采集周期太短比如50ms、变量数量太多会挤爆网络和主机端的接收处理。建议做追溯前先估一下数据量每个变量平均4字节×变量数×每秒采集次数算一下带宽超过5Mbps就危险。反正实际项目里因追溯配置过密导致网络拥堵的案例我见过不止一两次。5. GEM300300mm时代的设备自动化扩展5.1 从300mm需求到协议族扩展300mm晶圆厂相比200mm最大的变化是高度自动化、少人化。晶圆盒一个接一个通过AMHS运输设备要能自动装卸、自动识别、自动做工艺。GEM标准面向的是“单台设备的自动化”但300mm工厂需要的是“设备与物料搬运系统的联动”这就催生了GEM300协议族。它不是单独一个标准而是一捆E84负责装载端口和搬运系统之间的通信E87管理载具信息E90做物料追踪E40管工艺配方和流程控制E94做控制作业调度。GEM300的推进还有一个现实压力300mm晶圆特别重人工搬运不现实必须靠自动化搬运设备。而搬运设备和工艺设备之间的接口必须有统一规范不能一家一个说法。这就像物流公司必须和仓库约定好托盘尺寸和扫描枪扫码格式不然货根本卸不下来。5.2 E84与装载端口通信E84是GEM300里最核心也最容易出对接问题的协议。它定义了“搬运设备如OHT/天车与工艺设备装载端口LoadPort之间的通信方式”使用光通信SEMI E84光接口在设备之间交换控制信号。通过E84OHT会把载具放在装载端口上然后装载端口执行“载具到达”的信号序列工艺设备接收后的下一步动作是进行载具ID读取自动条码扫描和Mapping晶圆位置映射。E84的通信模型非常精细握手信号序列包括搬运设备发出“载具放置请求”。装载端口确认“已就位”。搬运设备释放载具并升起。装载端口执行“载具就位检测”CLAMP、FOUP presence switch。设备侧开始载具ID读取和Mapping。E84常见的问题集中在这几个方面一是信号电平问题光接口的发射/接收功率不达标通信时断时续二是GEM300标准版本不一致设备固件老版本和新搬运设备的E84实现之间有兼容性差异三是握手超时时间设置太短。有一次联调OHT放FOUP的动作稍慢E84握手序列跑到一半就超时设备端报警“LoadPort Timeout”工艺还没开始就停了。最后把超时时间从5秒放宽到15秒问题再没出现。E84另外一个“联动点”是Mapping报告。设备完成晶圆位置映射后通过SECS-II消息把Mapping结果报给主机。Mapping错误比如晶圆跨槽、缺片会导致后续工艺执行异常所以EAP里必须有明确的Mapping校验逻辑一旦报告异常立即阻止工艺释放并报警。5.3 对象服务E39/E40/E90等简述E39定义了“对象服务”让主机能像操作对象一样管理设备里的实体载具、配方、工艺批次、数据收集计划等。E39的引入本质上是把设备内部的数据模型“对象化”外部系统通过通用的创建、删除、修改、查询接口来操作它们。这对主机的开发很友好因为不需要针对每台设备写一套资源管理逻辑而是统一用“对象服务”的接口去访问。E40是“工艺流程管理”核心概念是Process Flow工艺流它把一套完整工艺定义为一个FlowFlow里有多个Step每个Step对应设备动作和配方参数。E40帮助EAP实现“一键下发工艺流、分步执行、实时反馈”的目标。实际效果有点像播放器里的播放列表一份歌单工艺流定义了要播哪些歌工艺步骤每首歌有参数配方。E40的好处是让主机不需要知道设备内部具体的配方格式只需要管理“工艺流”这个高层对象。E90设备追踪是GEM300时代的“事件追踪升级版”定义了设备和载具之间更细的关联关系。主机可以通过E90查询“哪个载具在哪个设备的哪个装载端口上里面每个槽的晶圆状态是什么”。这对FAB的实时WIP追踪非常重要。和传统GEM的SV查询相比E90是标准化的对象级查询语义更清晰。GEM300协议族数量多要在项目里全实现是不现实的。绝大多数设备厂商会优先实现E84、E87、E39、E40的核心子集后面的E90、E94看设备类型和客户需求。作为对接工程师你最先要确认的是设备支持哪些协议版本、哪些GEM300功能块。我建议在设备采购技术协议里就写死这些标准版本和功能块清单不然后期扯皮成本极高。6. EAP设备自动化的“粘合剂”与MES脑6.1 EAP是谁和MES什么关系EAPEquipment Automation Program经常被误解为一个标准协议其实它不是SEMI标准而是一个系统模块。可以理解为“MES派到设备旁边的自动化代理人”。MES管的是业务订单层面一批活什么时候投料、由哪台设备做、做完怎么流转。EAP管的是设备执行层面哪台设备在线、当前做什么配方、做到哪一步了、遇到报警怎么处理然后把执行结果回报给MES。EAP和MES的交互才是主线。EAP接收MES下发的作业指令比如“执行批次BatchA的某工艺Step”把指令翻译成GEM/SECS-II消息下发到设备端设备端执行过程中的所有事件、报警、数据EAP负责收集和过滤再汇报给MES。MES不直接面对GEM设备原因很实际MES是面向生产管理的系统如果让它去处理S1F13、S5F1、S6F11这些细碎消息开发和维护成本不堪重负。EAP做了一层翻译和业务编排让MES只关心生产业务不关心设备通信细节。6.2 EAP如何与GEM设备交互EAP内部常见的模块划分是通信层负责SECS-I/HSMS连接、消息收发、协议层解析SECS-II、调用GEM功能、业务层实现EAP的逻辑比如配方管理、作业调度、报警判定、接口层与MES集成比如通过WebService、消息队列或文件接口。在实际项目中EAP的关键能力是“多设备并发管理和状态机编排”。一个EAP实例可能同时管理十台甚至几十台设备每台设备处于不同的通信状态、作业状态、报警状态。EAP需要一个设备状态机来管理每台设备的生命周期还要有事务队列确保每条命令都能得到匹配的响应。没有这些一台设备触发大量事件时其他设备的消息就会排队积压业务逻辑被拖垮。EAP和GEM设备之间的一个典型交互流程以“配方下载并启动工艺”为例MES向EAP下发“批次A、设备D、配方R启动”的指令。EAP先查询设备D的状态确认设备在线且处于READY状态。EAP通过S2F41发送“RCMDRecipeDownload”参数里带配方ID和设备参数。设备执行配方校验和加载返回S2F42状态OK。EAP再发送“RCMDProcessStart”。设备开始工艺EAP持续接收S6F11事件工艺开始、工艺进行、工艺结束。EAP收集到“工艺结束”事件后通知MES批次完成可流转到下一道工序。这个流程里EAP必须处理异常分支配方下载失败、设备状态错误、事件超时未到、报警打断工艺等。真正成熟的EAP最复杂的不是消息发送而是“异常分支”的处理。这也是EAP开发中最耗时的地方。EAP和GEM设备对不上时排错的关键是“分层定位逐层排查”先确认TCP层通不通能Ping通、HSMS连接正常再确认SECS-II收发正不正常S1F13/S1F14能通然后才去查业务消息S2F41/S6F11。很多新人上来直接说“EAP和设备和MES数据对不上”结果一查HSMS连接都没建立业务消息当然发不出去白折腾半天。7. 实战排错清单与踩坑心得7.1 常见问题速查表现象可能原因排查手段解决方向设备始终离线TCP连接未建立检查IP/PortPing设备、Telnet端口修正IP配置重启设备服务S1F13发出无S1F14回复协议版本不匹配抓包看S1F13报文对比设备协议版本调整主机协议版本到设备支持的版本请求发出后超时System Bytes不匹配检查消息头的System Bytes核对等待队列修正事务管理逻辑事件上报丢失S6F11的W位处理不当确认设备端是否需要S6F12响应主机实现S6F12自动应答远程命令被拒命令名或参数不匹配打印S2F41/S2F42完整SML校正命令名和参数格式报警误处理报警等级理解偏差检查报警ID与ALCD代码调整EAP报警判定策略E84握手失败信号异常或超时太短用光通信测试仪看序列调整超时时间检查硬件灵敏度追溯数据丢失采集频率过高统计网络带宽降低频率、减少变量数这些坑我每条都踩过。尤其是System Bytes匹配几乎是所有新手的第一道坎。抓包工具打开后能看到请求和响应两边的System Bytes是否一致如果发现设备端回的是固定值而不是回显请求值说明设备端的堆栈实现有bug该找设备厂商开发聊。7.2 联调工具与必备技能做SECS/GEM联调手头必须有趁手的调试工具。常见的有两种路线商业工具如Ethernet SECS/GEM调试模拟器支持SML编辑、消息收发、状态模拟开源方案则是自己写一个基于SECS/GEM库的上位机再加一个协议分析器抓包。商业工具的优点是上手快但到了高级调试比如自定义错误注入、大规模消息压力测试还是得自己写脚本。SML调试能力是必须练的。我建议任何做设备自动化的工程师都花时间把SML的语法规则吃透至少能做到拿到一份SML能脑内转换成字节流或者看到一段十六进制正文能大概还原出SML结构。这个能力在分析设备端异常报文时极其有用。还有一个小技巧在调试工具里把S6F11事件上报的SML全部打印出来对照设备手册的变量表一条条核对绝大多数数据不匹配问题都能在十分钟内定位。抓包工具方面Wireshark肯定要装但要让Wireshark正确解析SECS-II你需要加载对应的解析插件或使用自定义Decoder把TCP负载按HSMS头拆开再看SECS-II消息格式。没有解码器时Wireshark只能看到TCP层HSMS那几个字节还能勉强认出搜索“Length”字段再往里的SECS-II正文就全是天书了。实际干活我常备两个工具一个支持SML编辑的模拟器一个能解析HSMS头的抓包器配合使用效率最高。7.3 我的三点经验建议第一协议补全太重要。联调一般不允许“边界情况”出现在现场所以前期一定要把设备端的消息响应矩阵梳理清楚。怎么梳理拿设备手册的功能块列表逐项测试造一份“设备行为确认表”把每条消息的请求、响应、异常分支全过一遍。这个过程很枯燥但能帮你提前发现80%的联调坑。第二版本管理要严格。SECS/GEM/GEM300标准年年更新设备固件一升级可能行为就变了。我遇到过设备从GEM版本A升级到B之后S2F41的返回数据结构多了一个字段旧EAP解析直接崩溃。设备升级前一定要做协议兼容性测试最好在测试环境先跑一轮完整回归。第三日志必须分级且可回溯。生产环境里协议层的日志应该分三级ERROR无法恢复的错误、WARN可疑但未中断流程、DEBUG每条消息的SML原文。DEBUG日志默认关闭排查问题时打开并且要支持按设备、时间段、消息类型过滤。没有好用的日志系统在几百台设备的FAB里排查协议问题等于大海捞针。我个人实际操作中最深的体会是这套协议栈看着复杂但一旦理解了分层思想和状态机其实没有真正的难点。你只需要记住物理层负责传输字节消息层负责表达语义GEM负责约束行为EAP负责业务翻译。每一层出问题都有各自的排查工具和方法别跨层乱猜把层与层之间的接口看好绝大多数坑都能稳步绕过去。后面如果再写我打算把SML和HSMS的字节级解析单独拎出来用一组真实抓包数据带着大家逐字节拆一遍那个过程会特别过瘾。
阅读完成 · 觉得有帮助？
