刚开完会。又被产线主管怼了——‘系统里报工数不准，设备状态延迟，MES就是个摆设！’ 我哑口无言。说实话，这还真不全是MES的错。数据采集软件没选对，或者压根就没上到位，你上层系统再牛也是白搭。对吧？
干了十几年自动化，见过太多花里胡哨的项目死在这个环节。一套靠谱的数据采集软件，不是简单的把PLC数据读上来，你得考虑协议、架构、断点续传、边缘缓存……甚至还要祈祷厂里的老机床别动不动就掉线。
协议！永远是第一道坎
上个星期去一家汽配厂，他们有台意大利进口的成型机，用的还是Profibus-DP，别笑，我真的见过。然后新加的机器人是Profinet，传送带控制是Modbus TCP，视觉检测那边又抛出来个EtherNet/IP。一个车间，四世同堂。我就问，你的数据采集软件能一口全吃下吗？
真正好用的数据采集软件，必须是一个多协议翻译官。它底层要能直接与西门子、三菱、罗克韦尔这些主流的PLC通信，支持OPC UA更是必备，因为这是工业4.0的通用语言。但更重要的是，对于那种老旧的串口设备，你得有办法把它转换成以太网信号接入，而不是直接告诉客户‘这台机器太老，接不了’——那项目就黄了。
我尤其反感那些标榜‘支持百种协议’的软件，看上去唬人，可一用发现，驱动全是需要单独付费的。一个驱动几百块，你当是买皮肤呢？坑。
别在‘实时’和‘完整’之间二选一
有一个常见的误区：数据采集就是把设备当前值不断往上送。错！如果碰到网络闪断怎么办？如果数据量突然爆发，比如注塑机一个开合模周期就几百个参数瞬间变化，你后端数据库扛得住吗？
所以现在好的数据采集软件，都内置了边缘计算能力。不是简单的缓存，而是可以在靠近设备的一端做数据预处理——过滤、聚合、甚至直接触发本地报警。我去年给一家电子厂部署的方案，就是在车间层用带边缘功能的采集软件，把振动传感器的高频波形数据，通过FFT（快速傅里叶变换）转成频域特征值后再上传，既保留了关键信息，又省了90%的带宽。爽。
问：那我不用边缘，直接用PLC往数据库写不行吗？
答：行，但你会哭。第一，PLC的通讯资源很宝贵，你让它频繁写数据库，扫描周期可能就乱了，直接影响控制精度。第二，万一网络断掉，数据就丢了，没有回头路。专业的采集软件有断点续传，能记住断网时的时间戳，恢复后自动补传，确保数据完整。这不是PLC自己能干好的活。
选型时，我必问的三个问题
这几年参与了大大小小十几套MES、WMS项目的数据采集选型，总结出一套自己的‘灵魂拷问’清单。你要是正在选，拿走不谢。
第一个，授权模式。是按点数收费，还是按设备数量？我吃过亏，一开始按500点买的，结果项目实施中客户说想把能耗也采进来，又加100点，费用直接超标。所以现在宁愿选那种按连接设备数或者按采集链路授权的，弹性更大。
第二个，可视化配置程度。别指望所有工程师都会敲代码。好的软件应该提供拖拽式的数据流搭建，像Node-RED那样直观。上周我们一个年轻技术员，用某软件的图形化界面，半小时就把一条包装线的14个测点接好并推送到MQTT了。他兴奋得直拍桌子——我就喜欢这种不用写脚本的感觉！
第三个，虚拟化/容器化支持。现在都上云或者上超融合了，你给我一个只能装在物理机Windows上的镜像？谢谢，不用。我要求采集软件必须支持Docker部署，能跑在K8s上更好。毕竟生产环境容灾和弹性扩容不是闹着玩的。
问：市面上有些开源的数据采集软件，比如Kepware的某些版本或者Ignition的免费层，能用在产线吗？
答：可以尝鲜，但慎用核心产线。开源的潜力大，可是工业稳定性第一。你半夜两点被叫醒，就因为一个开源驱动内存泄漏……那种绝望我体会过。如果预算有限，至少选一个有稳定商业支持的开源发行版，或者混合架构，核心设备用成熟商用软件，辅线用开源试试水。
另外，别忘了安全。数据采集软件往往横跨IT和OT，是攻击的跳板。一定要带白名单、加密传输、操作审计日志。去年有个同行工厂，因为采集软件的默认SNMP社区字符串没改，被勒索病毒从摄像头网段窜到PLC网段，最后……唉，半条线停产两天。
总之，数据采集软件这事儿，水很深。它不像买个ERP，有标准流程。每个车间都是独一无二的难题组合。我能给出的最实在建议就是：先搞试点，从小范围验证开始。别被厂商的PPT带偏，直接让他们来你现场，接几种不同类型的老设备试试。行不行，跑起来就知道。对了，如果测试的时候软件频繁死机或者CPU飙升到下不来，别自我安慰是‘环境问题’，大概率是架构缺陷，果断换。
就这样吧。希望下次开会，能听到产线主管说：‘嘿，今天数据挺准的！’