2. 设备通信中间件需求拆解
设备通信中间件不是“把设备连上网”这么简单。它位于设备与上层系统之间，既要承接设备侧千差万别的协议与数据节奏，又要向 MES/EAP 提供稳定、语义清晰的数据服务，还要让运维人员看得见、管得住、查得清。因此，需求拆解必须从三个视角同时展开：设备侧关注“怎么接、接什么、接多快”，MES/EAP 侧关注“数据准不准、语义对不对、接口稳不稳”，运维侧关注“状态可不可见、故障可不可查、容量可不可扩”。
下面这张图展示了三方需求如何汇聚成需求规格说明书，并最终映射为吞吐量、延迟、可靠性、可扩展性、可观测性等关键指标。
2.1 设备侧：先摸清“接什么、怎么接”
设备侧需求的核心是协议适配与数据采集。以半导体封测车间为例，一台焊线机可能通过 SECS/GEM 上报事件，一台温控器走 Modbus TCP 周期上报温度，而一台老式测试仪只有 RS-232 串口。中间件必须支持多协议接入，并明确每类设备的采集方式：
- 协议清单：SECS/GEM、Modbus TCP/RTU、OPC UA、MQTT、自定义 TCP 文本协议。
- 数据点表：每个设备需要采集哪些变量，如温度、压力、配方号、报警码、运行状态。
- 采集频率：周期采集（如 1s、5s）与事件触发（如报警、状态跳变）并存。
- 连接约束：单台设备最大连接数、串口波特率、超时重连策略。
这些信息不能只停留在“支持 Modbus”这种模糊描述，而要落到可验收的条目。例如：“支持 200 台 Modbus TCP 设备并发连接，单设备轮询周期 1s，采集失败后 3s 内自动重连，连续 5 次失败产生断连告警。”这样的需求才能被开发和测试直接使用。
2.2 MES/EAP 侧：定义“数据怎么用”
MES/EAP 侧不关心底层是串口还是 TCP，它关心的是数据语义、接口契约和一致性。中间件需要把设备原始数据转换为统一模型，例如将不同设备的“温度”统一为 temperature_celsius，单位统一为摄氏度，并附带设备编号、采集时间戳、质量码。
接口层面通常需要提供三类能力：
- 实时推送：通过 MQ 或 WebSocket 将设备状态、报警、参数变化推送给 EAP，延迟要求 P99 ≤ 200ms。
- 查询服务：提供 REST 接口按设备、时间范围、数据点查询历史数据，支持分页与聚合。
- 指令下发：MES 下发配方切换、参数设置、启停命令，中间件负责协议转换、超时控制和结果回执。
一致性要求必须明确：是否允许丢数据？是否允许重复？顺序是否重要？例如报警事件要求“不丢、不重、按发生顺序”，而周期温度数据可以允许少量丢失但要求时间戳准确。这些差异会直接影响中间件的缓冲、重试和去重设计。
2.3 运维侧：让系统“看得见、管得住”
运维侧需求常被忽视，却是高并发接入能否长期稳定的关键。运维人员需要回答四个问题：现在连了多少设备？数据有没有积压？延迟是否超标？出问题怎么定位？
因此，中间件必须暴露以下可观测性能力：
- 指标（Metrics）：在线设备数、连接成功率、消息吞吐量、端到端延迟分位数、队列积压深度、错误率。
- 日志（Logs）：设备连接/断开、协议解析异常、指令下发结果，需带设备 ID 和追踪 ID。
- 追踪（Tracing）：一条数据从设备采集到推送至 EAP 的完整链路耗时，便于定位瓶颈。
- 告警：断连、积压超过阈值、延迟 P99 超标、磁盘或内存不足。
2.4 从需求到规格说明书：关键指标与验收标准
收集完三方需求后，需要将其转化为可量化、可测试的关键指标。下表给出一个示例性的需求规格片段：
| 指标类别 | 需求描述 | 验收标准（示例） |
|---|---|---|
| 吞吐量 | 支持全车间设备并发数据接入 | ≥ 6000 msg/s，持续 30 分钟无丢失 |
| 延迟 | 报警与状态变化实时推送 | P99 ≤ 200 ms，P50 ≤ 50 ms |
| 可靠性 | 中间件故障不影响数据最终一致 | 可用性 ≥ 99.95%，消息不丢不重 |
| 可扩展性 | 设备数量增长时可横向扩容 | 增加节点后吞吐量线性提升 ≥ 80% |
| 可观测性 | 运维可快速定位异常设备与链路 | 指标、日志、追踪三者齐全，告警 30s 内触达 |
需求规格说明书不是一次性文档，而是后续架构设计、开发、测试和验收的共同基线。建议每条需求都附带优先级（必须/应该/可以）和验证方式（测试用例、压测场景、演示步骤）。例如“支持 200 台 Modbus 设备并发连接”可以通过模拟器启动 200 个 TCP 连接并持续轮询来验证；“P99 ≤ 200ms”可以通过在数据包中打时间戳，在接收端统计分位数来验证。
最后，需求拆解要形成闭环：设备侧提供协议与数据点，MES/EAP 侧提供接口与语义，运维侧提供监控与容量约束，三方共同评审后输出需求规格说明书。后续的架构设计、线程模型、队列选型、部署拓扑，都应能追溯到这里的某一条需求。只有这样，中间件才不会沦为“能跑就行”的临时脚本，而是真正支撑高并发接入的基础设施。