一盘混凝土偏了3公斤：一家搅拌站用边缘AI优化称重配料系统

去年开春，一个做商混的朋友找我吐槽：每天出几百方料，工地退回来的比例一直降不下来。试块抗压不合格、塌落度忽大忽小，质检员天天跟工地吵。最头疼的是，同样配方的料，不同时段出来的质量就是不一样，工艺员也说不清原因。

我去他站上实地待了一周。站不大，一条HZS180生产线，配料站4个骨料仓、2个粉料仓，加水靠电动阀，外加剂靠人工倒。搅拌楼三楼的操作室，两个师傅倒班，靠屏幕上的称重数值判断配料是否正常。

站上其实有配方管理系统——5年前的，硬接线控制仪表，数据只能看不能存。操作师傅的经验就是"听声音"：搅拌电流声音大了说明料太干，小了说明太稀。听起来很江湖，但这确实就是大多数中小搅拌站的现状。

这篇文章记录我们是怎么一步步用边缘AI网关改造这套称重配料系统的。不吹效果多好，就说做了什么、遇到了什么问题、最后效果怎样。

一、现场情况摸底

蹲点的第一件事，是搞清楚"配料不准"到底是哪个环节出的问题。我干了三件事：

1. 看数据

问操作室要最近的出料记录。回答是没有——配料的称重数据只在PLC里走一趟，用完就丢，没有任何历史记录。唯一能看的是每天出货单上配方名称和方量。

我从PLC的MODBUS口接了台笔记本，连续采集了3天的称重数据。采集频率设成每秒一次——实际够用了，配料秤的采样周期本身也就100ms级别。3天后看到的数据让人头大：

• 砂子实际下料量跟目标值偏差能到±5%，最严重的一次5号水泥仓一下少了80公斤
• 水称精度相对好一些，但加减水全靠电磁阀的开阀时间，温度变化导致水的密度变了，同一开阀时间水量能差十几公斤
• 外加剂是人工倒的，误差更大

2. 看现场

配料站有几个问题不属于技术范畴，但直接影响精度：

• 骨料仓的落料口积料严重，砂子水分大（当天下了雨），堆积在口子上不下料，导致实际落料时间短、重量偏低
• 地磅机械结构有老化，称重传感器底座锈蚀，归零漂移——每次开机归零后的数值都不一样
• 胶带输送机皮带跑偏，洒料严重

3. 看工艺

配方单上写的配合比是干基（假定砂子含水率为0%）。但实际的砂子含水率每天都在变——下了雨含水率可能到8%，晴天可能4%左右。操作师傅凭经验往配方里"补砂"，补水减水全凭手感。上午的师傅保守，下午的师傅大胆，出来的料品质根本没法统一。

这三点看完，我就清楚问题出在哪了：

不是配方不对，是配方的执行环节完全失控。没有数据、没有补偿、没有闭环——全靠人的经验在支撑，而人的经验是离散的、不可复制的。

二、方案设计

改造目标定得很窄：把"配方的执行精度"拉到可控范围内。不需要大改产线，不换设备，不改变现有控制逻辑。

最终方案分三层：

采集层：加装传感器和数据采集模块

• 骨料称重：原有传感器信号分一路给PLC、一路给边缘AI网关（信号隔离器，不干扰原系统）
• 砂含水率在线检测：在胶带输送机上方装电容式含水率传感器，实时检测砂子含水率（水分变化影响补偿量）
• 粉料称重：水泥/粉煤灰仓底加装称重传感器监测实际落料量
• 水称/外加剂：水称装电磁流量计，外加剂称装计量泵配合流量计
• 搅拌电流：接搅拌电机电流互感器，作为塌落度的间接指标

选型的几个坑后面再说，先讲总体逻辑。

边缘层：现场部署边缘AI网关

方案的核心是这个边缘AI网关，它干四件事：

1. 实时采集所有传感器数据（100ms周期），与PLC通过Modbus TCP通信获取配方目标值和当前生产状态
2. 运行含水率补偿算法——根据检测到的实时含水率，自动调整砂子和水的设定值，确保干基配比不变的前提下总水量不超额
3. 落差补偿——每次称重结束后记录超调量（过冲/欠冲），累进校正下一盘的落料关门点。这是最核心的功能
4. 本地存储所有生产数据（6个月滚动覆盖），断网不影响继续工作

为什么不用云方案？因为搅拌站网络条件不稳定——操作室的工控机能上网，但机房里各种电磁干扰，WiFi断了是常事。网关在本地跑补偿算法，就算断网也不影响配料精度。

云端层：Web看板和数据报表

轻量级的看板，展示：

• 每盘配料偏差实时曲线（能看到哪一车配料走样了）
• 日/周/月偏差统计（按物料分类，看趋势）
• 含水率变化曲线（跟配料偏差放在同一个时间轴上）
• 每车料的出站质量报告（塌落度估算、强度预测区间、试块标记）

告警通过企业微信推送到站长的手机上——连续3盘偏差超过±2%就告警，强制停线检查。

三、实施过程

第一周：现场安装和调试

最轻松的环节反而是硬件安装。传感器布线半天搞定，边缘AI网关放在操作室的机柜里，跟PLC走网线Modbus TCP。

真正麻烦的是两件事：

第一，含水率传感器标定。电容式含水率传感器需要针对具体的砂子类型做标定曲线。不同来源的砂子（河砂、机制砂、混合砂）的介电常数不一样，同样的电容读数对应的含水率可能差2-3个百分点。我们的做法是在胶带输送机旁边备了5个已知含水率的砂样，做了标定曲线。但第三天发现换了批砂后又不准了，后来加了温度补偿才稳定下来。

第二，信号干扰。称重传感器的mV级信号从配料站拉到操作室，经过变频器强电区域时噪声严重。试了几种方案，最后走屏蔽双绞线加磁环解决。如果早知道，买传感器时就直接配好信号隔离器了。

第二周：落差补偿模型调试

落差补偿是这套方案最核心也最折腾的部分。

简单说：配料秤在关门的时候，骨料从皮带掉下来到秤上是有惯性的。关门指令发出后，还有一部分料在"空中飞"，这部分重量叫做"落差"。如果每盘的落差不一样，配料偏差就大。

传统做法是设定一个固定落差补偿值（比如50kg），每次目标值减去这个补偿值就关门。但实际落差跟落料的流速有关，跟仓内料位高度有关，跟物料的流动性能有关——固定补偿根本不够用。

我们的做法是让边缘AI网关跑自适应落差补偿算法：

# 伪代码示意：自适应落差补偿逻辑
每盘称重完成后:
  实际偏差 = 实际下料量 - 目标值
  本次落差 = 总下料量 - 关门点累计量
  
  如果实际偏差 > 阈值:
    补偿值 += 衰减率 × (本次落差 - 上一盘落差)
  否则:
    保持当前补偿值

  下一盘关门点 = 目标值 - 补偿值

用了将近一周的时间调这个参数。衰减率设太大，补偿太激进，一盘超调一盘欠调来回震荡；设太小，收敛太慢。最后设成0.3，大概5-6盘后稳定下来。

这中间有一个插曲：试调阶段，砂仓突然换了一种料（粗砂换成细砂），落差一下子变了30多公斤。因为细砂流动性好，下料速度快，来不及关门就超了。补偿算法花了大约10多盘才收敛到新状态。后来我们在算法里加了一个快速响应机制——一旦检测到物料类型变化（通过下料速度曲线判断），自动把衰减率提高一倍，缩短收敛时间。

第三周：含水率补偿上线

含水率补偿的逻辑不复杂：

• 电容传感器每5秒采一次含水率，取1分钟滑动平均
• 如果当前含水率跟配方默认值偏差超过1%，则自动调整砂子和水的设定值
• 调整后的总用水量限制在配方许可范围内（避免塌落度超标）

但上线第一天就出了状况。中午下了一场大雨，砂子含水率从4%飙升到8%+。算法循规蹈矩地减了很多水，结果第一盘料出来太干，搅拌电流偏高。操作师傅一看不对劲，直接切回了手动模式。

后来分析原因：大雨后砂子表面含水率高，但内部还没渗透均匀。电容传感器测到的是表面含水率，而实际拌合时内部的水还没释放出来。简单压低用水量导致拌合水不够。

修复方案：在含水率传感器数据之外，引入"搅拌电流-塌落度"的反馈修正。如果含水率检测说加了多少水、但搅拌电流显示料太干，网关自动补加少量水（每次5升），直到电流回落到正常区间。

教训：单一传感器不可靠，必须双通道校验。含水率传感器作为"前馈"，搅拌电流作为"反馈"，两个信号互相印证，系统才稳定。

四、实际效果

系统上线满打满算3个月后，我们统计了几个数据：

当然也有一些没预料到的情况：

正面：站里的操作师傅反馈说"现在轻松多了"。以前每盘要盯着屏幕看称重值，到了关门点手动切，精神高度紧张。现在AI自动补偿，师傅只需要巡视监视看板，偶尔异常时介入。

负面：有一天地磅传感器信号突然跳变，网关以为是正常偏差，连续补偿了5-6盘。等到操作师傅发现时已经出了快30方料，全部拉回来重拌。后来加了传感器健康监测——如果传感器的信号噪声突然增大超过历史值3倍，自动切换为固定补偿模式并告警。

五、遇到的其他问题和解决方法

问题1：传感器环境耐受性

骨料仓的振动非常大，传感器的线缆接头一个月内松脱了两次。后来全部改用航空插头加锁紧环，再也没有出过这个问题。

问题2：粉料仓结拱

水泥仓有时候物料板结，下料不畅。算法检测到持续欠冲后会判定为粉料仓结拱，推送给操作室提示"需要振仓"。这是一个无心插柳的功能，但站长说这个比配料补偿还实用。

问题3：操作师傅的信任周期

自动模式下，操作师傅会习惯性地盯着屏幕、随时准备切手动。前两周师傅切换了不下20次。到第三周，师傅发现自动补偿比他自己手动调准得多，才开始真正放手。这件事花了我们一些时间去沟通——让算法透明化，在屏幕上显示"当前含水率XX%，补偿后砂子设定值XXkg，补偿量XXkg"，师傅看得懂了才敢信任。

六、我的思考

这个项目做完我的感触挺深的：

"配料不准"是个工程问题，不是AI问题。很多人一听"AI优化配料"，以为要用多复杂的模型。实际上90%的工作是信号采集、干扰排查、补偿逻辑设计。真正用到的AI只是简单的自适应算法，不是深度学习。

传感器的可靠性比精度重要得多。我们踩的坑里，真正影响系统稳定性的不是模型准不准，而是传感器信号稳不稳。一个漂移的传感器，给再好的算法都是白搭。

改旧系统比建新系统难。这套搅拌站的控制系统已经有七八年了，走的是硬接线+PLC的老路子。在不改变原有控制逻辑的前提下插入一个边缘AI网关，挑战不是"怎么加"，而是"怎么不影响原有系统运转"。信号隔离、通信中断兜底、异常时自动切回原模式——这些才是真正的设计难点。

数据本身就是价值。这个项目投产后，站里终于有了完整的配料数据。站长自己说，现在跟供应商谈砂子质量的时候有数据可以说话——以前纯属扯皮。换了几个批次的砂子后，调出数据一看，某家供应商的砂子含水率波动明显偏大，直接换了供应商。

七、如果你想尝试

如果你们站的配料精度也不太理想，几点建议：

1. 先把现有数据看一遍——有些站连基本的称重记录都没有，先确保有数据再谈优化
2. 别一上来就上AI——先排查机械问题（传感器底座锈蚀、皮带跑偏、积料），机械问题不解决，AI来了也白搭
3. 落差补偿优先级高于含水率补偿——落差不解决，配料偏差的主体部分就还在
4. 给操作师傅留一个"一键切手动"的按钮——他们需要安全感，过度自动化反而是阻力
5. 传感器标定不能省——省一天标定的时间，后面可能花一个月填坑

总的来说，这次改造的经验让我觉得：工业场景里"小改小革"比"推翻重来"靠谱得多。不改硬件、不动控制逻辑、不依赖稳定网络——在现有产线基础上加一层边缘AI感知和补偿，就能大概解决问题。这个思路不止适用于搅拌站，很多行业的配料工位都适用。