2. EAP与设备通信基础
在EAP（Equipment Automation Program，设备自动化程序）与多厂商设备适配的工程实践中，通信基础决定了整个系统的稳定性、实时性与可扩展性。不同厂商、不同年代的设备可能同时提供RS-232串口、RS-485总线、TCP/IP以太网、SECS/GEM、OPC UA或MQTT接口。理解这些协议栈的层次差异、角色划分与典型数据流，是后续做协议适配、消息映射和异常排障的前提。
一、协议栈对比：从物理层到应用层
这些协议并非同一层级的概念。RS-232/485属于物理层与数据链路层规范，只解决“比特怎么传”；TCP/IP解决“数据包怎么可靠到达”；SECS/GEM、OPC UA、MQTT则是应用层或会话层协议，解决“设备与EAP之间交换什么语义”。实际项目中常见组合是：RS-232 + SECS-I + SECS-II/GEM，或TCP/IP + HSMS + SECS-II/GEM，或TCP/IP + OPC UA，或TCP/IP + MQTT。
| 协议 | 典型层次 | 传输方式 | 实时性/吞吐 | 典型场景 |
|---|---|---|---|---|
| RS-232 | 物理层 | 点对点、全双工 | 低，通常≤115.2 kbps | 老式量测机、单机台 |
| RS-485 | 物理层/链路层 | 多点总线、半双工 | 中低，≤10 Mbps（短距） | 多台传感器、PLC轮询 |
| TCP/IP | 网络层/传输层 | 面向连接、可靠 | 高，取决于网络 | 所有现代设备接入底座 |
| SECS/GEM | 应用层/会话层 | 基于SECS-I或HSMS | 中高，事件驱动 | 半导体前道/后道设备 |
| OPC UA | 应用层 | 客户端/服务器、发布订阅 | 高，支持信息模型 | PLC、SCADA、智能制造 |
| MQTT | 应用层 | 发布/订阅、Broker | 高，轻量、弱网友好 | IoT设备、边缘采集 |
选择协议时，不能只看“新不新”。例如一台老式探针台只有RS-232，就必须用串口服务器转TCP，再在EAP侧实现SECS-I或自定义报文解析；而一台支持OPC UA的PLC，则可以直接通过信息模型读取结构化数据，减少私有报文解析成本。
二、设备端与EAP端的角色划分
在SECS/GEM体系中，角色划分非常明确：设备端称为Equipment，EAP端称为Host。设备端负责采集自身状态、执行动作、产生事件；EAP端负责下发指令、收集数据、做流程编排与MES交互。两者通过SECS-II消息（如S1F1、S2F41、S6F11）通信。HSMS则把消息封装到TCP连接上，支持主动/被动模式。
在OPC UA体系中，设备或网关通常作为Server，EAP作为Client；在MQTT体系中，设备作为Publisher，EAP作为Subscriber，Broker居中转发。角色不同，意味着连接建立、心跳、重连、权限和QoS策略都不同。例如SECS/GEM中EAP通常主动建立HSMS连接，而MQTT中设备主动向Broker发布，EAP订阅主题即可。
三、典型数据流与消息时序
以SECS/GEM的“设备状态上报”为例，典型时序是：EAP建立HSMS连接 → 设备上线后发送S1F1（Are You There） → EAP回S1F2 → 设备产生事件（如ProcessStart） → 设备发S6F11携带报告 → EAP回S6F12确认 → EAP根据数据更新界面或写入MES。若EAP需要主动查询，则发S1F3，设备回S1F4。
在MQTT场景中，设备发布主题如 eqp/ETCH01/status，载荷为JSON；EAP订阅 eqp/+/status，收到后解析并入库。OPC UA场景中，EAP通过Read或Subscription读取节点，设备端在值变化时推送MonitoredItem通知。
四、适配实战中的关键判断
面对多厂商设备，第一步不是写代码，而是确认三件事：物理接口是什么、协议栈组合是什么、角色与连接方向是什么。例如某台设备手册写“支持SECS/GEM”，但实际只提供RS-232口，那么EAP侧必须准备串口服务器，并确认SECS-I的波特率、字符格式、块大小和超时参数。若设备提供HSMS，则要确认主动/被动模式、IP端口、Device ID和心跳间隔。
第二步是建立最小可观测链路。以HSMS为例，可先用 telnet 192.168.1.50 5000 确认端口可达，再用EAP的HSMS日志观察Select.req/Select.rsp是否成功。若失败，优先检查Device ID、Session ID和T3超时。对于MQTT，可用 mosquitto_sub -h broker -t 'eqp/+/status' -v 验证主题与载荷格式。对于OPC UA，可用UaExpert浏览节点，确认NodeId和数据类型。
第三步才是消息映射与状态机设计。设备端上报的S6F11报告可能包含多个VID（变量ID），EAP需要把VID映射为内部字段，并处理重复上报、乱序和丢失。对于MQTT，要处理QoS 0/1/2的差异；对于OPC UA，要处理订阅采样间隔与死区。最终目标是让EAP面对不同协议时，上层业务逻辑保持一致，差异被隔离在适配层内。
总结来看，RS-232/485解决“连得上”，TCP/IP解决“传得稳”，SECS/GEM、OPC UA、MQTT解决“看得懂”。设备端与EAP端的角色划分决定了连接方向与责任边界，而典型消息时序则是联调时最直接的排障依据。掌握这三层关系，后续的多厂商适配才有稳固基础。