搞机械设计的，对“物联平台”这四个字，最初是有点鄙夷的。总觉得是软件人的花架子。直到自己亲手推动一个车间级的改造项目，才发现这平台要落地，光有IT知识远远不够。你得懂设备，懂现场，还得懂那帮老师傅的操作习惯。
去年接手一个轴承车间的数采项目，一百多台设备，型号横跨二十年。有带以太网口的崭新车床，也有只有继电器触点的老古董。我先把话撂在这儿：设备接入，是整个项目的起点，也是后来埋雷最多的地方。
设备接入：先把老古董们拉上线
车间里有一台1998年富士通的卧式加工中心，数控系统是FANUC传统系列。想读主轴负载、进给电流？原厂通讯协议已经失传，手头只有一份纸质的参数表。没办法，只能在电气柜里加一个霍尔电流传感器，专门测主轴驱动器的三相输入线。传感器选型时要注意量程和响应时间，当时用了莱姆的LAH系列，响应时间小于1微秒，但输出是4-20mA模拟量，还得配一个Moxa的采集模块转成Modbus TCP。
这种硬改造倒是直接，但痛点在于接线。原来电柜本来就塞得满满当当，加传感器和模块得重新理线，一不小心就碰到其他回路。那段时间电工师傅天天骂娘。后来学乖了，在动工之前先用CAD画好电柜平面图，给每个新部件预留位置，再动手。这个经验后来写进了项目流程。
有些设备其实自带通讯口，但协议五花八门。Siemens S7-1200用Profinet，Mitsubishi FX系列走MC协议，还有的用OPC UA。这里就遇到一个选择：是每个设备都直接采集，还是先汇总到车间网关？我们试过前者，结果软件配置逻辑爆炸。后来统一采用边缘网关方案，比如用树莓派加Codesys软PLC，或者直接用一台研华工控机跑Node-RED。网关负责协议转换和预处理，再把数据上行到平台，明显清爽多了。
平台选型：开源还是商业，这是个问题
平台这一层，说实话，水很深。我们对比过ThingsBoard、JetLinks，还有西门子的MindSphere。开源的好处是便宜，而且代码可控，但需要自己养人维护。商业方案省心，可价格不菲，而且往往要与自己的生态绑定。我们团队都是机械出身，对Java、K8s这些不熟，最后选了ThingsBoard社区版，主要用来做设备管理、数据可视化和简单告警。它能直接支持Modbus和MQTT，对我们足够用了。
但注意，社区的ThingsBoard没有规则引擎的高级功能，比如实时流处理、机器学习那部分。我们其实也不需要用那么复杂，关键是能把数据存下来，画曲线，做报警。倒是有些设备的数据频率高，比如振动传感器每秒2K个点，直接传平台扛不住。后来在网关端做了抽稀，只上传有效值、峰值和均值，瞬间压力小很多。
这里还有个坑：平台的数据模型得提前设计好。我们一开始用设备的IP作为设备标识，后来换了设备改名，导入数据全乱了。教训是设备标识得用ID，而不是IP。别问我怎么知道的。
数据与网络：看不见的瓶颈
数据从传感器到平台，走的都是车间局域网。但车间的网络环境，比办公室恶劣得多。金属切削液蒸汽、油雾、还有电焊机的高频干扰，对无线的干扰非常严重。我们一开始想全用WiFi，结果掉线频繁，延迟能飙到好几秒。最后关键工位都改成了有线，或者用支持工业协议的光纤链路。
有线的走线也是学问。桥架要远离大功率变频电缆，至少隔30公分。接地必须单点，否则地环流会让串口通讯瞎搞。有一次我们调试时，触摸屏和PLC通讯时好时坏，最后发现是两头都接了地，形成环流，把一端地线断开就正常了。
数据质量上，采样频率和精度要平衡。温度传感器迟滞大，采样太快没用，1Hz就够。振动信号则需要5K以上，但这样带宽就上来了。所以我们把采集策略做成可配置的，像温度、压力这种慢变量走轮询，振动走周期突发上传。平台端再做一次滤波，把尖刺剔掉，曲线才好看。
安全：别被OT和IT撕扯
最后讲安全。工厂物联平台一旦上了云，就意味着你的产线暴露在互联网上。我们当时把网关直接做了端口映射，结果上线第二天防火墙日志里就有人扫描。吓得赶紧关上。后来用了专用VPN通道，而且把设备网络和办公网络用VLAN隔离，核心交换机上配了ACL，只允许特定IP访问。
老实说，安全这部分我们才刚入门。但有一点可以给同行建议：千万不要图方便让设备直接联网。工业防火墙和单向隔离产品，虽然贵，但值得。还有，所有密码不要用默认的，这是最基本的。
写这些，是想让大家知道，工厂物联平台不是简单的装个软件。它跟机械设计一样，是门手艺活。每个环节都有细节，踩坑了才知道怎么做。希望各位少走点弯路。
