有一次看产线看板，班长指着屏幕说：这台锁螺丝机明明在跑，为什么 MES 显示停机？
软件侧先查日志。接口正常，消息队列没有积压，实时处理服务也没报错。
电气侧看 PLC。设备运行点位在跳，自动模式点位也正常。
最后把点位表翻出来才发现，MES 接入时把“自动模式”当成了“运行状态”。设备没有停，只是那个点位的语义被理解错了。
这类问题很常见。它不是业务逻辑错，也不是数据库慢，而是现场数据进入 MES 的第一道关没有守好。
边缘采集最容易被低估。
在方案里它可能只是一个“采集服务”，但到了现场，它要面对的是不同品牌控制器、不稳定网络、设备改造历史、点位命名习惯，还有师傅口中的“这个信号以前就这样”。
我遇到过一种情况，MES 页面显示设备停机，设备工程师看 PLC 又觉得设备没问题。最后查下来，不是系统错，也不是设备错，而是大家对“运行中”这个点位的理解不一样。
这种问题如果不在边缘层处理清楚，后面的业务层只会越来越乱。
一、边缘采集层到底在守什么
边缘采集层表面上是在读设备数据。
实际上，它在守三件事。
第一，守协议差异。
西门子、三菱、欧姆龙、台达、汇川，还有扫码枪、测试机、视觉设备，不会天然说同一种语言。
第二，守点位语义。
一个地址里的值到底代表什么，什么时候变化，是否清零，单位是什么，是否需要换算，这些都要在边缘侧和配置里说清楚。
第三，守现场不稳定。
网络会断，PLC 会重启，工控机会蓝屏，测试机会晚几秒吐结果，扫码枪可能重复扫。边缘层要尽量把这些波动挡住，不要让 MES 业务层直接受冲击。
所以边缘采集层不是“读几个点位”。
它更像 MES 和现场之间的翻译、缓冲和第一道质检。
二、不同设备，接法真的不一样
一个散热器工厂里，设备来源可能很杂。
比如：
- 西门子 S7-1200 / S7-1500。
- 三菱 MELSEC。
- 欧姆龙 NX / CJ / CP 系列。
- 台达、汇川等 PLC。
- 自动锁螺丝机。
- 风扇测试机。
- 扫码枪。
- 视觉检测设备。
- 厂商专机。
西门子可能走 OPC UA，也可能通过 S7 通信读取开放 DB。
三菱常见 MC Protocol / SLMP，读 D、M、X、Y 这些软元件。
欧姆龙可能走 FINS/UDP、FINS/TCP，也可能通过 EtherNet/IP 或上位机转接。
台达、汇川常见 Modbus RTU / Modbus TCP。
测试机更灵活。有的主动推 TCP，有的写 CSV，有的提供 HTTP API，有的只能查本地数据库。
所以边缘层不能只抽象成一个 PLCClient。
它至少要有一套设备接入模型：
device_code: 设备编号
vendor: Siemens / Mitsubishi / Omron / Delta / Inovance
protocol: OPC UA / S7 / SLMP / FINS / Modbus TCP / Socket / File
endpoint: IP、端口、站号、节点号
tag_address: DB 地址、D 寄存器、DM 区、Holding Register
data_type: bool / int16 / int32 / float / string
byte_order: ABCD / BADC / CDAB / DCBA
read_cycle: 采样周期
access_mode: read_only / read_write
business_usage: 运行状态 / 产量 / 报警 / 测试结果 / 工艺参数这些字段看起来细，但现场就是靠这些细节活着。
三、点位表不是附件，是合同
我现在会把点位表当成软件和电气之间的合同。
一张能用的点位表，不应该只写：
D100 产量
M200 运行
M201 报警这太容易出问题。
更好的写法应该接近这样：
设备：screw-01
点位：current_order_output
地址：D100
类型：int32
单位：pcs
含义：当前工单产量
清零规则：切换工单后 PLC 清零
采样周期：1s
存储策略：产量事件入业务库，实时值进 Redis
负责人：电气 / MES 双方确认如果 D100 实际是设备生命周期累计产量，那 MES 就不能直接把它当成当前工单产量。要么让 PLC 提供当前工单计数，要么 MES 在工单开始时记录基准值，再用差值计算。
这个差别很小，但它决定看板准不准。
四、边缘层要处理“读到了，但不能直接用”的数据
现场数据经常不是读到就能用。
比如 Modbus 读到两个寄存器：
0x41B8 0x0000这可能是一个 float，也可能是两个 int16。字节序不同，解析出来的值就完全不一样。
再比如温度点位读到 253，可能表示 253 摄氏度，也可能表示 25.3 摄氏度，因为设备侧用了 0.1 的缩放系数。
再比如报警点位不是一个 bool，而是一个报警码：
0: 正常
101: 气压不足
205: 扭矩超限
302: 急停边缘层要把这些原始数据转成中心系统能理解的标准数据。
否则业务层会被各种设备细节拖乱。
五、本地缓存是现场系统的保险
车间网络不可能永远稳定。
边缘节点采到数据以后，如果中心消息队列不可用，或者网络断了，不能直接丢。
这些数据尤其要先落本地缓存：
- 工序过站。
- 测试结果。
- 报警开始和恢复。
- 产量计数变化。
- 质量检测结果。
网络恢复后再补传。
补传时必须带唯一消息 ID 或业务唯一键，中心侧做幂等。否则断网十分钟恢复后，可能会出现重复过站、重复报警、重复产量。
这里真正要防的不是“网络断了”，而是网络恢复以后系统悄悄变脏。
六、边缘层最终要输出业务事件
不是所有点位变化都应该直接进业务库。
设备运行状态每秒变化一次，适合更新实时状态。
温度、压力、电流这类高频数据，适合进时序库。
测试完成、报警发生、工序过站，这类才是业务事件。
比如测试机输出：
SN: F202404210001
转速: 1850 rpm
电流: 0.18 A
噪音: 31 dB
结果: OK中心系统真正需要的是：
event_type: test_completed
sn: F202404210001
work_order_no: WO2024042103
station_code: fan-test-02
device_code: tester-01
items:
speed: 1850 rpm
current: 0.18 A
noise: 31 dB
result: OK
event_time: 2024-04-21 14:32:18这样质量追溯、工序过站、看板刷新才能接上。
七、我会怎么落地第一版
如果是第一阶段，我不会一上来做复杂的边缘平台。
我会先做一个能跑的边缘 Agent：
- 支持一到两种核心协议。
- 点位配置从文件或数据库加载。
- 关键数据本地持久化。
- 上传中心消息队列。
- 本地日志能查。
- 有健康检查。
- 支持重启后继续补传。
同时要求现场给出设备清单和点位表。
没有点位表，就不承诺数据准确。
这句话有点硬，但很重要。否则 MES 会替现场混乱背锅。
八、小结
边缘采集层做得好，MES 后面的业务模块才有可信数据。
它不是一个简单接口，而是现场复杂度的缓冲层。
它要懂协议，要尊重点位表，要处理字节序和缩放，要能断网缓存，要把原始数据变成业务事件。
这层如果做薄了，后面所有“实时看板”“质量追溯”“OEE 分析”都会变得不可靠。
本系列：
暂无评论