一、采集层：先跟传感器死磕到底
很多人以为数据采集就是给设备装传感器，插上采集器，数据就源源不断过来了。哪那么简单！我真正想说的是：传感器选型就是一个大坑。 以我们最常见的滚动轴承监测来说，振动传感器的量程和频率响应必须匹配。你拿一个量程±5g的加速度计去测主轴高速旋转的冲击，迟早要削波。我们常用的压电式加速度传感器，灵敏度有100mV/g，也有10mV/g的。高灵敏度的适合低频小振动，低灵敏度的才能扛得住大冲击。有一次，供应商推荐了一个看起来很美的传感器，结果一装上去，现场有电焊机作业，信号直接淹没在干扰里。原来是对地回路没处理好，屏蔽层在两端都接地了。后来改成单端接地，世界清净了。 采样频率也是个讲究。奈奎斯特采样定理说采样率要大于信号最高频率的两倍，但在工程上，我们通常取5到10倍。比如要分析轴承外圈故障特征频率，可能高达几千赫兹，采样率就得设到20kHz甚至更高。但采样率上去了，数据量就爆炸。一台设备四个测点，一个测点连续采，一天就是好几个GB。数据还没传到平台，本地存储先告急。 说实话，采集层最大的秘密不是那些参数，而是对现场环境的敬畏。温度漂移、线缆磨损、接头松动，这些都是机械振动的源头。你用的线缆，不是普通电源线，而是要带屏蔽层的专用电缆。布置路径也要避开高温、油污区域。有一次，一条电缆从液压站旁边走，没过半个月，绝缘层全部老化开裂，信号时断时续。
二、传输与架构：边缘和云端如何分家
传感器到了网关，这只是第一步。接下来，数据要往哪里走？全上云？老板一听，说那还不简单。可设备控制回路要求毫秒级响应，你从现场传到云端绕一圈，延迟就几十毫秒，加上网络抖动，根本没法做闭环控制。所以，边缘计算是必须的。我们把一些信号处理直接在网关完成，比如FFT频谱计算、特征值提取，只把结果和原始波形片段上传。 这样一来，平台的压力就小了。但架构上的麻烦事一点没少，最棘手的就是协议转换。现场有Modbus RTU、Profibus、EtherNet/IP，还有各种老古董的串口协议，甚至有的设备直接输出0-10V模拟量。网关就像是联合国翻译官，得把这些五花八门的语言统一成MQTT或者OPC UA，才能发到平台。说实话，OPC UA是个好东西，但很多老设备根本没有。你就得用什么协议转换器，兼容性是个坑。去年我们接一台德系机床，对方只开放一个私有协议，折腾了程序员整整一个星期，最后发现人家是把数据封装在了一个奇怪的寄存器偏移量里。 再聊聊存储。时序数据我们用的是InfluxDB，一开始图它轻量。但是随着设备数量增加，存储和查询性能急剧下降。后来才发现，需要做降采样策略，比如原始数据保存一个月，每分钟聚合数据保存一年。这个策略一定要在设计初期就确定，不然后期改数据流，愁死人。
三、数据建模与故障预测：机械量才是灵魂
四、平台落地的血泪史：那些坑你躲不掉
