上个月去佛山三水的陶瓷厂收尾窑炉监测项目，差点栽在设备数据上传这件小事上。整整三天，后台的温度曲线要么缺块，要么跳得像股票崩盘，甲方生产经理天天蹲在控制柜门口催，我连喝早茶的心思都没有。
说白了，绝大多数做设备联网的中级工程师，都把注意力放在了协议适配、平台对接上，觉得数据上传不就是把采集到的数据发出去？能有什么难的？真到现场跑起来，各种妖魔鬼怪全出来了。
摘要：本文结合多个实际工业现场项目经验，梳理了工业设备数据上传设计中容易忽略的带宽计算、断网缓存、数据校验三个核心设计要点，给出了符合行业规范的落地选型和避坑方案。
别光调通协议，先算清楚上传带宽账
很多人刚接设备数据上传的需求，上来就是Modbus读寄存器，转MQTT发云平台，调通测试能收到数据就交差了。根本不会去算流量和带宽的账。
就拿我这次碰到的窑炉项目来说，一条生产线120个温度测点，要求监测精度0.1℃，很多人直接写死1秒上传一次。算笔账：每个测点数据2字节，加上MQTT报文头、地址戳，每个上传包差不多30字节，120个测点就是3.6KB每秒。看起来不大对不对？一个车间12条窑，那就是43.2KB每秒。百兆有线当然没问题，但是项目为了省布线成本，用的是运营商的4G Cat.1定向流量卡，每月配额才1G，峰值带宽限1Mbps。
你算一下，43.2KB每秒，一小时就是152MB，一天多一点就把整月流量造完了，超了之后直接限速断网，数据当然传不上来。
GB/T 33703-2017 《物联网 感知终端 通用技术要求》里明确要求，感知终端数据上传应根据数据变化率自适应调整上传周期。说白了，就是别瞎发。温度稳定在±0.5℃以内的时候，1分钟发一次都完全满足监测需求，只有温度波动超过阈值的时候，才把上传频率提到1秒一次。就这个小调整，整个车间每月流量才不到300MB，剩下的配额全留着应对异常工况，舒服多了。
不少人觉得不缺那点流量钱，那峰值带宽呢？厂区上百台设备同时满频率上传，核心网关的带宽直接被占满，其他设备的数据全堵死，一样出问题。
断网重连的坑，90%的项目都栽过
工业现场哪有一直稳定的网络？园区月底维护断个网，基站信号被新楼挡住，大风刮断光缆，都是大概率会碰到的事。
我见过太多项目的上传逻辑：网络断了，数据直接丢，重连之后从当前时间开始发。那断网两三个小时，窑炉超温的那段关键数据直接没了，出了质量事故要溯源，找不着数据，锅不还是你做项目的背？
我们现在做项目，固定要求加本地环形队列缓存，缓存大小按最大数据上传量算，至少留够8小时的存储容量。存储介质别选普通Nor Flash，频繁擦写用不了一年就出坏块，直接上SPI接口的铁电FRAM，擦写次数能到10^14次，随便写，8Mbit的也就一块多钱，比Flash靠谱一万倍。
重连之后发数据也有讲究，先发缓存里的历史数据，补发完再发当前实时数据，每个包必须带全局递增序列号，平台端要做乱序重排。我之前碰过一个项目，缓存数据直接按时间戳乱序发，结果网络抖动，后产生的包先到平台，先产生的后到，平台直接把旧数据当成新数据存了，温度曲线直接从1200℃跳到300℃再跳回去，甲方老板指着鼻子骂了整整一上午。
还有个细节，缓存满了怎么办？别覆盖最新数据，一定要丢最早的旧数据，保最新的数据。这个逻辑，我见过三个工作三四年的工程师搞反，你说去哪说理去？
数据校验和去重：别让垃圾数据毁了整个项目
工业现场电磁干扰多大？旁边伺服电机启动，变频器满负荷运行，RS485总线上的误码率能冲到1%，你不做全链路校验，传上去一堆错数，平台做的预测性维护、能耗分析全是错的，最后项目验收都过不了。
很多人觉得我加了Modbus的CRC校验就完事了，不对。Modbus的CRC只能校验这一次寄存器读写对不对，从设备总线到云平台整个传输链路，还要加端到端的校验。用MD5太占带宽，16位的CCITT校验就够了，才两个字节，误判率不到万分之一，完全满足工业场景需求。
还有去重，设备断网重连之后会重发缓存数据，平台如果重复存储，数据量翻倍，统计出来的结果全错。所以每个上传包必须带唯一的序列编号，平台收到重复编号直接丢弃就行，成本很低。
传感器本身的坏值也要拦在本地，比如PT100短路，出来个1600℃的数，你也往平台传？那不扯淡吗？本地一定要做量程范围校验，超出传感器标称量程直接扔掉，标记成异常数据，别把垃圾往上传。不过话说回来，异常也别直接 silent 掉，要给平台发异常标记，告诉平台这里缺数据，别让平台把空值当成0处理，那算出来的平均温度错得离谱。
设备数据上传这件事，说穿了没有什么高深的算法，也没有复杂的协议，全是细节，全是现场踩坑踩出来的经验。很多项目觉得调通协议就万事大吉，跑上半年一年，各种问题集中爆发，最后推倒重来，钱没赚到还砸了招牌。多站在现场运维的角度想问题，多留一点冗余，多做一点异常处理，项目才能跑得稳，收钱才能收得安心。
