★ FEATURED ARTICLE 做锅炉控制器项目之前我一直以为难度最大的地方是把程序写对、把DCS画面做得漂亮。做完这个项目才明白程序只是最后承受结果的那个环节。真正的难点是从客户一句“想省人、想安全、想把三台炉子统一管起来”到这套控制系统在高温、高湿、高粉尘的车间里连续运行中间隔着一个巨大的工程化黑盒。我参与的是某动力车间三台蒸汽锅炉的集控改造烧天然气的卧式锅壳炉原来每台炉子都有自己的独立仪表盘操作全靠老师傅看火听声夜班的时候人根本盯不住。企业想上一套锅炉控制器统一管理又希望保留原有燃烧器不折腾土建和管路。这个项目最值得说的不是某一项黑科技而是把散落的机械、电气、仪表、程序、工艺经验整合成一套能落地的系统。下面这篇复盘从需求边界、控制架构、安全联锁、燃烧PID整定、现场仪表、HMI设计、调试并汽到交付运维尽量把能直接用的经验写出来适合准备接手锅炉控制、燃烧控制、SCADA改造项目以及正在被现场仪表干扰折腾的工程师参考。1. 这个项目真正要解决的问题三台锅炉怎么用一个大脑协调1.1 客户需求背后的实际痛点第一次去现场客户给的需求只有三句话“让我们不用爬上爬下开阀门希望压力稳一点出事要自动停车。”听起来很简单但问深一层痛点非常具体。三台锅炉通过一根蒸汽母管并联供气用汽侧有两条生产线负荷波动很大尤其是换班和设备启动的几分钟内蒸汽压力能从设定值掉下来一大截。原来每台炉子独立手动操作司炉工需要频繁盯着压力表开大或关小燃气阀门。炉子之间没有协同经常出现两台炉子出力不够、一台炉子又憋压的情况。夜班人员少注意力一分散水位报警响了都不一定能及时处理。还有一个隐性需求是数据追溯。之前出现过一次安全阀起跳事件客户说不清楚当时汽包水位、燃料压力到底是什么状态因为没有记录。所以这次我们不但要把控制做上去还要把关键运行参数的存储和追忆做出来让每一次联锁动作都有据可查。1.2 项目组的工作边界与分工这类项目最忌讳一上来就画系统图。我们是先和客户、工艺操作工、设备科做了三次访谈把基本边界划清楚锅炉本体、燃烧器、阀门管路属于机械部分由客户自己的检修班组处理我们只提控制需求。现场仪表选型、供货、安装、接线、调试由我们总包但仪表套管、法兰等机械接口需要客户配合。控制系统软件、硬件、控制柜、操作站、历史记录全部由我们完成。涉及锅炉安全运行逻辑的部分要与当地监检、验收单位认定的方案保持一致我们提供逻辑图最后由他们的专家审核。这个边界划分非常重要。如果多管一点项目周期会被机械检修拖死如果少管一点接线不配合调试时到处扯皮。企业级项目的推进方式就是先谈清楚谁对什么负责尤其是锅炉这种特种设备边界就是安全线。我建议后来者做类似项目时把访谈记录整理成一份需求表格每条都要标明“客户确认工艺确认我们确认”避免后期加需求时扯不清楚。2. 控制架构选型为什么是 PLC 做主机加分布式IO而不是上一套 DCS2.1 三种方案的对比锅炉控制系统最常见的技术路线有三类分布式控制系统也就是常说的DCSPLC加分布式IO和触摸屏/上位机还有基于板卡或嵌入式工控机的方案。这个项目我们最终选的是PLC加分布式IO道理很简单但值得展开讲一下。DCS在大型电厂、化工联合装置里确实更强它擅长处理几百上千个模拟量回路系统冗余、历史库、操作站都是整套配套好的可靠性很高。但用在三台中小型锅炉上问题也很明显一是价格高一套DCS的IO卡件和软件授权费用可能比三台锅炉的控制系统总预算还高二是维护门槛高很多企业电仪班组以前没接触过DCS出现一个模块故障只能等原厂到场三是项目周期长配置DCS至少要经过组态、下装、调试几轮大的流程对于快速改造项目来说等不起。嵌入式板卡方案的问题在于非标性太强。我曾经见过某项目用一片单片机板直接做燃烧控制确实省了成本但后期没人敢维护代码没有文档图纸和实际接线对不上最终只能整柜推翻重来。中小型锅炉控制要的是“看得懂、查得开、改得动”这一点PLC生态有天然优势。2.2 最终采用的主控分层结构我们最后定的结构是一台主控PLC作为控制大脑通过现场总线和分布式IO子站通信三个子站分别放在每台锅炉附近的机柜里采集本机的温度、压力、液位、火焰信号输出阀门控制和点火器指令。主站负责统一协调负荷分配和三台锅炉的启停顺序同时把数据传到中控室上位机。为什么做分层而不是三台PLC各自独立因为客户希望三台锅炉能够自动分配负荷。如果每台PLC各自为战没有主站协调就仍然需要操作员手动判断哪台多烧、哪台少烧。用主站统一计算热负荷需求再按顺序向各台炉子下发目标压力这样控制逻辑集中在主站单台炉子的本地逻辑还是保留在子站PLC里子站即使和主站通信断开也能按本机PID维持运行不会一下子全停。这个架构本质上是一个“居中协调、底层自治”的思路它比全集中式可靠又比全分布式好管理。我画完图以后给客户电仪班里的小伙子讲了一遍他很快就理解了主站像班组长负责分配活儿子站像每个岗位的人活儿接过来就能自己干。用这个类比去和现场沟通比讲什么冗余概念都管用。实际配置上主站和子站之间用了环形冗余的通信介质控制柜内用不间断电源给PLC供电外电网晃电时还能保持控制器工作几十秒让阀门保持安全状态而不是乱跳。这个细节被很多人忽略锅炉控制柜如果直接接在可靠系数不高的电源上电网一个波动就可能让所有联锁误动客户会被误停车气死。3. 安全联锁链路每个“万一”都要落到硬线和硬逻辑而不是只靠程序3.1 安全联锁信号清单与触发逻辑锅炉的安全联锁是整套系统里最不能“灵活发挥”的部分。这个项目的安全联锁主要包括燃气泄漏报警、供气压力过高/过低、炉膛吹扫条件不满足、汽包水位超高/超低、火焰检测信号丢失、排烟温度异常、风机故障、上位机急停按钮。每一项都要按“异常时切断燃料供应”的最终动作来设计。这里我要强调一个原则凡是涉及人员安全和设备损坏风险的联锁必须用硬接线回路做最低层的保障程序逻辑可以做第一层快速响应但最后一定要有一道不依赖CPU的物理回路。比如汽包水位低低联锁除了PLC程序里跳闸外我们还单独接了一个水位控制器的报警节点直接串在燃料切断阀的电源回路上。也就是说哪怕PLC死机、触摸屏黑屏、通信中断只要机械式水位开关动作切断阀就会失电关断燃料进不去系统就是安全的。这个原则不是我们乱定的而是付了学费换来的。以前有个项目把所有联锁都写在PLC程序里结果PLC某块IO卡件故障导致联锁条件没有生效虽然最后没有出大事但排查过程非常吓人。从那以后我对锅炉控制器的设计一直坚持“程序负责管理硬回路负责保命”。3.2 燃烧器启动许可与炉膛吹扫逻辑燃烧器点火前必须完成炉膛吹扫这是锅炉控制里最无聊但最要命的环节。燃气锅炉如果炉膛里有残留可燃气体点火瞬间就是爆燃。我们用梯形图逻辑实现了一个启动许可链实际上也是一段有序状态判断// 以下为伪代码用于说明吹扫许可逻辑 IF NOT 点火请求 THEN BurnerState : IDLE; END_IF IF 点火请求 AND 风门全开 AND 风量 吹扫风量下限 THEN PurgeTimer.Run(TRUE); END_IF IF PurgeTimer.Done() AND 无燃气泄漏报警 AND 供气压力正常 THEN BurnerState : READY_TO_IGNITE; ELSE BurnerState : BLOCKED; END_IF IF BurnerState READY_TO_IGNITE THEN 允许打开主燃料阀; END_IF吹扫风扇、风门开度、风量差压开关、吹扫时间四个条件必须全部满足而且时间必须连续有效中间任何一项抖动计时器归零重新计时防止有人用短接信号骗过系统。现场的吹扫时间要按照设备运行要求的1.1到1.2倍整定留出余量但不能为了赶生产去缩短。我们通电调试时遇到过风压开关触点抖动吹扫总是中断后来换了质量更好的微动式风压开关问题才消失。吹扫完成以后点火阶段还需要处理“火焰检测信号”的问题。很多燃气锅炉采用电离式火焰电极或紫外火焰探测器。点火时点火变压器先放电建立点火火花延时1到2秒后打开燃料阀。如果在设定时间内火焰信号没有建立必须自动关闭燃料阀并进入“点火失败锁定”状态需要人工在复位后才能进行下一次吹扫。这种锁定功能很多非标控制器做得不够结果就是多次点火失败后炉膛内积存燃气非常危险。这个项目里我们特意把失败锁定状态做成红色指示灯加触摸屏弹出让操作员知道必须手动确认有效避免盲目重复点火。4. 燃烧控制的核心风煤比、氧量校正与 PID 整定的现场手感4.1 核心控制回路的结构锅炉控制器真正考验内功的地方是燃烧调节。燃气锅炉虽然比燃煤简单但做不好照样压力波动、热效率低、污染物排放超标。这个项目我们采用了典型的“压力为主环、燃料为副环、风量跟随燃料并加尾气氧量校正”的结构。压力主环接受蒸汽母管压力设定值和实际值经过PID运算出来一个“燃料量需求”信号作为燃气调节阀副回路的设定值。副回路再通过阀位反馈快速调节燃气量。燃气发生变化的同时送风机风量指令跟着燃料量指令按一定比例前馈变化保证风煤比不脱节这就是“前馈加串级”的概念。之所以要串级而不是单回路直接调燃气阀是因为蒸汽压力惯性很大。母管压力是很多设备共同作用的结果如果直接用压力偏差去调阀门阀门动作会非常频繁容易磨损且效果未必好。串级相当于让一个反应快的副回路先把燃气稳定住再用主回路的输出去修正燃料需求的设定值整体控制品质会好很多。4.2 PID整定过程中的观察方法整定PID参数时我们没有一上来就用自整定工具而是先做了几组手动阶跃试验。具体做法是把系统切到手动状态固定风机开度然后手动改变燃气阀门开度比如从40%直接跳到50%记录蒸汽压力变化曲线。这样做的好处是能直观看出被控对象的惯性大小、延迟时间和增益。这个项目锅炉的蒸汽压力对象有明显滞后燃气量变化后要经过十几秒到几十秒母管压力才开始变化。所以PID参数不能给太大比例否则很容易引起振荡。我们最后的经验参考值大致是主环比例度在120左右积分时间30到60秒微分基本不用副环比例度80左右积分时间5到10秒。不同锅炉参数差别很大我这里写的是这个项目的曲线特征不一定适合所有设备真正现场还是要按阶跃响应来推。整定过程中有一个被很多人忽略的环节烟气氧量校正。我们给每台锅炉装了氧化锆氧量分析仪通过它测到的排烟含氧量去微调风量设定值让燃烧保持相对恰当的过量空气系数。如果只按风煤比盲调燃气热值波动、气温变化、过滤器堵塞这些因素都会让实际燃烧状态偏离。氧量的变化比较慢所以校正回路我们用了一个很长的积分时间PID输出只限制在小范围内防止氧量信号波动干扰主风门控制。有一次烟气氧量仪显示突然飙升现场检查发现是取样探头漏水这类仪表故障被叠加到燃烧控制里以后很容易造成误调所以必须加上量程和变化速率判断异常时切掉氧量校正回到固定风煤比模式。4.3 从曲线里找问题而不是急着调参最难的一次参数调整是在并汽运行后客户反映蒸汽压力升到设定值附近后还会缓慢漂移。我们当时反复调PID积分时间都没用后来把历史趋势调出来发现压力漂移的周期和燃气流量计的量程切换点完全吻合。原因是那个量程切换段的差压变送器线性度不好阀门开度不变但测量值有变化副回路误以为燃气量变了一直在校正最后把主压力带偏了。找到根因后我们绕过了该段量程把流量计算切到另一只压力补偿后的变送器问题立刻消失。也是这次经历让我意识到调试锅炉控制时最重要的工具不是笔记本电脑而是历史趋势曲线。上位机里必须把蒸汽压力、燃气流量、风量、炉膛温度、烟气氧量、阀门开度这几条曲线放在同一个时间轴下选横坐标要能拉到30分钟级别才能看清过程的整体趋势。很多人只看几秒级实时曲线看到波动就认为是PID问题结果折腾半天其实根源在仪表。5. 现场仪表与通信协议的教训流量不稳折腾了三天最后是一根屏蔽线的问题5.1 仪表选型关注点锅炉控制要看得准、控得稳仪表基础必须打好。这个项目涉及的现场仪表主要包括测点仪表类型信号方式选型要点汽包水位差压变送器4-20mA三取中逻辑带截止阀和排污阀蒸汽压力压力变送器4-20mA选择耐温余量大的膜片燃气流量差压式流量计4-20mA带温压补偿风量差压变送器4-20mA取压管防堵烟气氧量氧化锆分析仪4-20mA注意探头温度要求火焰检测UV火检/电离电极开关量需要冷却风清洁透镜仪表这块我们踩过一个很典型的坑燃气流量差压变送器的取压口位置选得太靠近弯头导致涡流干扰流量信号毛刺很重副回路追着毛刺走阀门来回摆。后来重新计算了直管段要求调整工艺管路换了取压位置毛刺才下来。做锅炉控制系统仪表安装位置必须提前介入不要等仪表装完再去提控制方案否则先天不足程序再努力也没用。5.2 通信和信号干扰的排查过程项目施工后期我们遇到过一次特别折磨人的问题三号炉的燃气流量信号在运行中每隔几十秒就会出现一次明显的波动幅度有5%左右但现场变送器表头显示很稳定。PLC上位机中控显示一致说明不是显示问题而是信号链路中某个环节引入了干扰。排查过程遵循了先易后难的原则先看接线端子是否松动结果正常。换一个备用通道重新组态波动依旧。检查变送器供电电源发现该变送器和其他电动执行器共用一个直流电源回路执行器动作时电压有波动但用示波器测下来幅度并不大似乎不至于造成这个现象。把变送器信号从导轨端子直接短接到PLC侧仍然波动但频率变了。最后打开电缆沟盖板才看到信号电缆和风机变频器输出电缆走了一个线槽屏蔽层虽然接地但存在两头接地形成地环路变频器高频谐波耦合进了信号回路。处理办法是把信号电缆挪到另一侧线槽屏蔽层改为PLC柜单端接地再把变送器供电单独分了一支回路。做完这三件事流量曲线恢复成一条直线。这个过程前后花了三天但真正干活的时间其实只有一个小时。这种问题不会写在任何组态手册里只能靠现场经验和排查逻辑去怼。5.3 通信协议的工程化处理主站和子站之间用的是工业现场总线通信参数必须和IO模块匹配。我们连PLC之间的总线时发现一个有价值的细节总线的现场接线端子如果采用手拉手串联最后一个节点必须加终端电阻否则数据反射会导致通信偶发中断。这个知识点很多工程师知道但现场施工很容易漏掉因为有些网关自带终端电阻有些需要拨码开关接线工人不一定清楚。我们调试时就出现过子站通信偶尔掉线后来逐个节点检查发现两个子站的终端电阻拨码都没有打开。总线通信中断时子站的本地逻辑要保持安全状态这个设计比通信恢复更重要。我们在每个子站里都写入了“丢失主站通信后本机按原设定点维持PID运行燃烧器不关机但不允许新的点火启动”的逻辑。这是和客户确认过的策略因为锅炉失去通信不代表立即不安全维持运行比盲目切断更好只要有人到现场确认就行。但如果通信中断超过了设定时间子站还是要执行安全停车。6. HMI 与上位机之间的门道报警策略、趋势查看和操作权限6.1 报警信息的分类与防误报很多锅炉改造项目上位机一做出来就是满屏报警风压波动也报、电源波动也报、信号毛刺也报。最后操作员看见报警弹窗根本不看直接点确认这叫报警疲劳是安全事故的温床。我们设计报警策略时把报警分成了三层第一层是立即动作型包括火焰消失、水位低低、燃料压力低低、急停按钮动作这些必须弹窗加声音而且声音不能用普通蜂鸣器要使用能跟其他设备区分开的报警音防止在嘈杂车间被人忽略。第二层是延迟确认型比如水位偏高、供气压力波动、排烟温度偏高这一类我们设了延迟时间信号持续5秒才触发报警避免瞬时扰动造成误报。第三层是巡检型比如某个变送器故障、阀门正反馈消失这类只做记录不弹窗提示操作员在空闲时检查。实测下来报警量一下降了七成。操作员反而更重视报警因为每次响起来都是真有问题。6.2 操作权限与审计日志锅炉操作要求有权限管理。现场触摸屏、中控操作站、工程师站三级权限分开。现场操作员只能进行正常的负荷设定、手动/自动切换、复位班组长权限可以调整PID参数、修改报警限值工程师权限才能修改逻辑下装程序。每一次操作都要记录到审计日志里包括操作人账号、操作时间、操作对象、修改前后数值。有一次客户的两个操作员对责任问题争论了很久通过审计日志查出是谁在交班前改低了压力报警值。这种追溯能力在企业级项目里特别重要它建立的是信任。做HMI时千万别省这个功能虽然它前期工作量不大但后期省掉的口水官司比整天陪客户“复盘会议”省多了。6.3 趋势页面的设计值得多花一倍时间趋势页面是我们后来被客户表扬最多的功能。很多项目只是象征性放一个曲线框数据长度只有几分钟根本不够用。我们把历史数据做了两级缓冲PLC侧保存三十天以上的分钟级数据上位机数据库保存两年的关键测点数据。画面上同时显示四到六条曲线小组件可以拖动时间轴。锅炉控制有一个特点问题往往不是立刻暴露的而是积累出来的。比如燃气热值变化、风机皮带打滑、氧量探头脏污都是靠趋势慢慢看出来的。客户以前没有趋势页面总觉得控制系统是个“黑盒子”有了这些曲线以后操作员自己也学会看图了甚至能从趋势里提前发现设备故障他们对项目的认可度一下子高了很多。7. 冷态试车到并汽运行把整个调试拆成一张能打勾的清单7.1 冷态试车把所有隐患都挡在点火之前锅炉调试最忌讳直接点火。我们的流程是先做冷态试车也就是在锅炉不点火的情况下把控制系统、阀门、风机、仪表全部验证一遍。冷态阶段主要检查这些项目检查对象检查内容常见问题控制柜接线端子紧固、线号核对强电和弱电混走PLC IO信号逐个点动、强制、回读源型/漏型接反燃气切断阀开阀动作时间、关闭严密性阀位反馈方向搞反风门执行器手动开关到位、反馈角度行程和风门轴不匹配水位变送器排污、零点迁移、量程验证差压正负压接反声光报警每个联锁条件触发灯泡损坏、接线松脱我在锅炉改造项目里养成了一个习惯冷态试车时把所有信号逐个强制到报警状态观察联锁动作是否按要求触发。比如强制火焰丢失信号看燃料阀是否立即关闭强制水位低低信号看是否产生停车、且声光报警。这一步看起来枯燥但几乎所有的问题都能在这一阶段暴露等到点火后再出问题时查起来成本成倍上升。7.2 热态点火、升温升压与并汽边界的把握冷态合格后才允许热态点火。点火初期先小负荷运行持续观察炉膛温度、排烟温度、蒸汽温度的变化。升温升压阶段不能追求快要按照锅炉升压曲线来控制让金属壁温均匀起来否则容易出现应力问题。整个过程中锅炉控制器要记录完整的压力和温度曲线。并汽是三台锅炉由独立运行转为母管并联运行的关键步骤。我们当时的做法是逐台并入先让一台炉子稳定运行带基础负荷母管压力稳定在规定范围内然后第二台炉子升压至接近母管压力两侧压差小到一定程度后再缓慢打开并汽阀并汽阀开至全开过程中持续观察母管压力波动。并汽后立即测试负荷分配功能短时改变一台炉子的目标出力观察其他两台是否能够自动调整补足完成了这个测试整套控制逻辑才算真正通过。但这个项目里我们最开始并没有让系统自动分配负荷而是先手动并汽确认机械和仪表正常才切换自动。这个“先手动、后自动”的顺序是我反复和现场老师傅确认过的因为他们比任何程序都更懂锅炉特性。自动逻辑上线前让老师傅在手动模式下运行几天把运行参数留在趋势里我们再根据实际曲线去微调主控参数这样自动投用后不会出现太离谱的偏差。8. 交付后的反思控制系统不是上线那天就结束数据才是下一步的开始8.1 备件、图纸和培训缺一样都会变成烂摊子项目交付以后最重要的不是签验收单而是把“后期怎么活下去”这件事安排好。锅炉控制器项目往往要服役十年以上原厂工程师不会天天守在厂里。我们给客户留了一套完整的竣工资料包括端子接线图、IO分配表、程序备份、操作说明书、常见问题排查手册。另外每个设备类别都列了最小备件清单比如一块数字量输出模块、一块模拟量输入模块、一个火焰检测器、两只压力变送器这些备件不贵但一旦故障没有备件停炉损失是备件的几千倍。给客户的现场培训也非常重要。我们不只是讲操作而是每人发一套简化版的逻辑流程图带他们过了一遍各联锁的触发条件和复位步骤。很多项目后期出问题不是程序错了而是操作员不知道“系统为什么停”误以为是故障频繁复位反而产生危险。培训完以后现场操作员至少知道该看什么、不该乱按什么。8.2 历史数据要变成客户看得懂的东西交付后我们隔了一个月回去回访把系统记录的历史数据整理成了一份简单的运行分析报告内容包括单位蒸汽耗气量曲线的变化趋势、峰值负荷发生的时间段、报警次数的周分布、PID输出饱和频次等。客户第一次意识到他们这台锅炉平时最忙的时段是上午开工后的第一个小时而那时母管压力波动最剧烈。基于这个数据我们建议他们在开工前一小时提前把第三台炉子切入自动备压模式而不是等到压力跌下来再升负荷。表面上是控制策略优化实际上是用历史数据重新理解生产班次。客户认可后我们对负荷分配程序做了第二轮小改动增加了一个“班次预加载”参数操作员在交班前可以设置下个班次的预判负荷系统提前半小时提高运行炉膛温度压力波动明显减小。这个优化几乎没花任何硬件成本全部收益来自数据驱动。8.3 把这次的经验固化成自己的调试检查单我把这次锅炉控制器项目的经验总结成了一份自己的检查单。包括每个阶段必须完成的测试项、必须看到的曲线形态、必须记录的参数快照。后来再遇到类似的燃烧控制项目我基本不会再被一些低级问题绊住整个人从容了很多。最后说一点个人心得锅炉控制器这个领域的知识很大一部分不是从手册里学来的而是在现场被“逼”出来的。程序逻辑可以自己推演但阀门老化、电缆受潮、电磁干扰、操作习惯这些因素只有在真实的工业现场才会全部撞到一起。做这类项目留足调试时间尊重现场老师傅的经验把每一条报警都当成一次学习机会系统的可靠性和自己的工程能力都会同步长起来。
阅读完成 · 觉得有帮助？
