烧窑二十年也看不透的工况：一家水泥厂用边缘AI优化回转窑熟料煅烧

今年春节后，一家安徽的水泥厂联系了我们。厂长在电话里说得很直接：熟料质量一直提不上去，煤耗下不来，窑衬平均寿命不到8个月，换一次衬要停产一周。中控室四个操作工都是干了十几年二十年的老手，但同样的配方、同样的原料，同一个操作工不同班次的熟料质量都不一样。

我当时就想，这个问题跟之前做过的陶瓷窑炉优化有点像，但水泥回转窑的工艺复杂度完全是另一个量级——它不只是控温，还牵扯到煤气量、二次风温、窑速、填充率、火焰形状、原料化学成分等一系列耦合变量。

这篇文章记录我们是怎么一步步用边缘AI网关加多传感器方案给回转窑做数据洞察的。不能说什么都解决了，但至少让中控室的人知道了以前看不见的东西。

一、现场情况摸底

去工厂待了两天，把两条生产线看了个遍，发现几个关键问题：

• 设备情况：两条2500t/d新型干法生产线，回转窑规格Ø4.0×60m，配双系列五级预热器和分解炉。DCS系统是浙大中控的，但只有基本的温度、压力、电流信号，没有更细粒度的数据。
• 工况特点：生料配料波动大，石灰石CaO含量在48-53%之间跳变，煤质也不稳定（热值波动区间在5200-5800kcal/kg）。操作工只能凭火焰颜色和电流变化调参数。
• 数据现状：DCS只存了每5分钟的均值，关键信息被平滑掉了。窑壳温度每周拿红外枪打一次，根本看不出趋势。预热器出口气体成分完全没监测。
• IT能力：工厂有个信息科，但主要管ERP和门禁，对工控网络不太熟。DCS系统是封闭的，不能随便往外接设备。
• 预算：先试一条线，预算十多万。

这些条件决定了方案方向：不动DCS原有系统、加装独立传感器、边缘端处理、数据用旁路方式接入。

二、方案设计

最终确定的方案分四层：

采集层：五类传感器

为了在不干扰生产的前提下获取足够精细的数据，我们加装了以下传感器：

• K型铠装热电偶阵列——在回转窑筒体上沿轴向布置3排、每排12个测点（共36个），安装在后窑口至烧成带区域。用磁吸不锈钢箍固定，信号通过滑环式无线发射器传出。测温范围0-500℃，分辨率±1℃。
• 窑壳温度扫描仪——在窑头罩外固定安装一台红外线扫描仪（8-14μm波段），每2秒扫一次窑壳全表面，空间分辨率约0.5㎡/像素。用来监测窑壳温度分布，发现局部高温（红窑前兆）和窑皮脱落。
• 分解炉出口气体分析仪——在分解炉出口管道开孔安装原位激光气体分析仪，连续监测O₂、CO、NOx浓度。这是判断燃烧是否充分的关键参数。
• 电流互感器——在窑主机电机、分解炉喂煤秤、生料喂料秤上加装开口式电流互感器，实时采集电流信号（1秒/次）。电流波动直接反映窑内工况变化。
• 煤粉仓称重传感器——在窑头和分解炉煤粉仓加装称重模块，实时监测煤粉消耗量。

边缘层：边缘AI网关

在窑头控制室部署一台边缘AI网关（RK3588平台），负责：

• 通过RS485总线+Modbus RTU协议采集DCS数据（旁路，只读不写）
• 通过4-20mA模拟量采集模块读取气体分析仪信号
• 通过无线接收器采集筒体热电偶温度
• 通过以太网接收窑壳扫描仪数据
• 本地运行工况识别模型（判断当前窑况：正常/结皮/欠烧/过烧/红窑风险）
• 本地存储高频数据（1秒/点），保留90天
• 把处理后的工况摘要和告警上传到工厂管理网络

选择边缘网关而不是直接上云，主要是因为数据量大（每秒近百个测点）、窑内温度有实时性要求（判断红窑要秒级响应）、以及工厂管理网络与工业网络隔离的安全考虑。

模型层：工况识别与工艺参数关联分析

我们没有上来就搞复杂的神经网络——水泥厂的运行数据变因太多，黑箱模型不好落地。我们用的方法更务实：

• 第一步：基线建立——连续采集两周数据，给每条生产线、每种原料批次、每种煤质建立正常的工艺参数基线。基线是动态的，考虑了生料细度、入窑生料分解率、系统风量等辅助变量的影响。
• 第二步：统计过程控制——对关键工艺参数（烧成带温度、分解炉出口温度、窑电流、NOx浓度、窑尾O₂）建立上下限控制图。当参数连续3个点偏离基线1σ、或1个点偏离2σ时触发预警。
• 第三步：工况聚类——用K-means对历史数据做工况聚类，把窑况分为5类：正常工况、结皮趋向、欠烧工况、过烧工况、冷窑恢复期。每类工况对应不同的操作参数建议。

云端层：工艺看板和分析报告

一个轻量级的Web看板，部署在工厂管理网上，展示：

• 窑壳温度热力图（实时更新，红黄色标表示异常高温区）
• 关键参数趋势（近24小时/7天/30天可切换）
• 当前工况分类及置信度
• 告警记录（什么时间、什么参数、什么级别的异常）
• 每班次熟料质量趋势图（与化验室数据对接后展示）

告警推送到中控室大屏和手机端。因为操作工在窑头、原料磨、水泥磨三个区域来回走动，手机推送比固定工位更实用。

三、实施过程

第一周：传感器安装

热电偶安装是轻松的部分——磁吸箍固定，两个人半天装完36个点。麻烦的是信号传输。筒体在旋转，我们试了三种方案：

• 方案一：滑环——装了1天就坏了，窑面温度高加上粉尘大，滑环触点接触不良。
• 方案二：无线发射器+接收器——某宝买的433MHz模块，装在筒体上随窑转。信号时断时续，12个接收器只有8个能稳定收到。
• 方案三：工业级无线温度采集系统——换了专业厂家的产品，发射器用耐温不锈钢壳体封装，接收器天线做了定向增强。36个点全部稳定接收。

气体分析仪的安装也费了点周折。分解炉出口管道是负压状态，开孔必须用专门的带球阀安装座，防止开孔时空气进入破坏工况。工具不趁手，多花了半天。

窑壳扫描仪的安装反而简单——固定在窑头罩钢结构上，通电、配置IP、调好焦距就行。但扫描仪装完后发现附近有焊机作业，电磁干扰导致数据丢包。后来给扫描仪供电线加了磁环，解决了。

第二周：DCS数据对接

这是整个项目最头疼的部分。浙大中控的DCS系统使用自研的通信协议，不开放标准接口。工厂找原厂来报价——数据采集接口改造报价小十万，远超预算。

后来我们用了一个取巧的方法：在DCS操作站上安装了一台串口服务器，从DCS的RS232打印口上读取数据（DCS系统默认会把实时数据通过打印口输出）。工控圈的人管这个叫"打印口窃听"。这个方法不需要改DCS配置，不花钱，缺点是有大约500ms的延迟——但对工艺分析来说完全够用。

教训：水泥这种传统流程行业，DCS系统封闭是常态。准备方案时一定要把协议对接的风险和成本算进去。打印口窃听这种野路子不一定处处管用。

第三到四周：基线采集和模型训练

两周的数据采集期间，我们发现了几个有意思的现象：

• 煤质波动对烧成带的冲击比想象中大得多。换了煤批的当天，烧成带温度在30分钟内降了80度，操作工调了40分钟才稳住。但DCS的5分钟均值完全看不出这个冲击过程。
• 窑电流和NOx浓度之间存在明显的反向关联。NOx升高时窑电流会下降，滞后约3-5分钟。这个现象好几个操作工知道，但之前没有量化过。我们把这个关系做成了预测模型的一个特征。
• 夜班和中班的操作风格差异很突出。其中一个操作工偏向"偏烧偏低"（在欠烧边界操作，省煤但风险大），另一个偏向"过烧偏高"（质量稳但煤耗高）。数据第一次把这种差异量化了出来。

模型训练方面，我们把两周的数据做了清洗，去掉了停窑、开窑、大幅波动这些非稳态数据，最终保留了约180小时的稳态运行数据用来训练。K-means聚类分了5类工况，轮廓系数0.62，不算好但能用。后来随着数据积累，分类精度逐步提升。

第五周：试运行和参数调优

系统上线第一周，每天几十条告警。但大部分是"参数偏离基线"级别的轻度预警，真正需要干预的"工况改变"告警每天只有3-5条。操作工反馈"大部分告警都知道，不用系统提醒"。

我们调整了策略：

• 日常告警只推送到手机，中控大屏只显示"工况变更"和"红色告警"
• 增加了趋势提前预警：当某个参数连续向恶化方向偏移超过基线1σ时，提前30分钟推送"注意"级别告警
• 引入了"同类工况对比"功能：当前工况和历史上类似工况比对，显示当时操作工的参数调整和效果

调整后，真正有用的告警占比从约15%提升到了约60%。

四、实际效果

系统运行了3个多月后，我们统计了几个维度的数据：

五、遇到的问题和解决办法

热电偶寿命

窑筒体上的K型热电偶在高温区（烧成带附近）的寿命只有约3个月。因为筒体表面温度在200-350℃之间，加上窑体振动和物料撞击，热电偶套管容易疲劳开裂。解决方案是定期更换（每季度一次），并在每个位置预留备件接口。我们也试验了红外测温替代方案，但精度和响应速度不如接触式。

粉尘对气体分析仪的影响

分解炉出口气体含尘量高（约80-120g/Nm³），激光分析仪的透镜每2周就会被粉尘覆盖，导致信号衰减。后来加装了反吹系统（每4小时用压缩空气吹扫一次镜面），维护周期延长到了1个月。

中控室操作工的抵触

系统上线第一个月，操作工基本不看。他们说"我烧了二十年窑还要电脑教我？"态度转变是在发现C4预热器堵塞预警之后的——那次预警给了他们5小时的提前量来安排停窑清理，避免了非计划停机。从那以后，每天接班后先看一眼看板成了习惯。

信任是用一次一次正确的预警换来的。第一印象很重要——如果前3次告警都是误报，后面你再准也没人信。

数据断流

第三个月，串口服务器的数据突然断了3天。排查发现是DCS操作站重启后串口配置丢失。后来在操作站上加了开机自启脚本，每次启动自动配置串口参数。

六、个人的思考

这个项目做完之后，我对流程行业的AI落地有了新的认识。

水泥企业的数字化基础比想象中还薄弱。很多人觉得水泥是现代化流程工业，DCS应该很完善。但实际上大多数中小水泥厂的DCS只提供基本的PID回路控制，数据采集频率低、存储周期短、传感器覆盖面窄。想靠现有DCS数据做AI分析，基本不可能。

加装传感器才是真正的门槛。数据分析、模型训练这些反而是相对标准化的流程。难点在于：传感器耐不耐高温、信号传不传得出来、装上去会不会影响生产、坏了好不好换——这些才是最花时间的。

不要试图替代操作工。一开始我设想过用模型直接给出操作建议（"增加2%喂煤量"），但操作工完全不接受。后来改成"数据显示当前工况类似3月15日XX班次，那次操作后熟料质量偏高"，操作工自己会判断。辅助决策比自动决策更容易落地。

数据价值有滞后性。刚上线两周，厂长问"有什么发现？"我答不上来。真正有价值的发现都是运行一个月以后才出现的——数据需要积累到足够体量才能看到模式。这个预期管理很重要。

七、给你的建议

如果你也在水泥厂或类似流程行业想做类似的数字化改造，几点参考：

1. 从一条线开始。选一条运行相对稳定的线做试点，别上来就全部铺开。一条线跑通了，再去第二条线会快很多。
2. 传感器先行，AI后行。先解决"有没有数据"的问题，再解决"数据怎么用"的问题。没有好的数据基础，再好的算法也是空中楼阁。
3. 预留至少1个月的"信任期"。操作工不会因为你系统上线了就马上用。给系统时间证明自己，给人时间接受新工具。
4. 自动化和信息化的边界要清楚。边缘AI只做监测和辅助决策，不做控制回路干涉。动DCS的设定值是自动化工程师的事，不是AI的事。
5. 数据断流的预案要做好。DCS重启、传感器故障、网络中断都是常态。系统要在数据不全的情况下保持可用，不是数据全了才工作。