火电厂辅助车间集中控制：从分散看守到少人值守的架构与实施要点

简介：火电厂辅助车间系统集中控制方案探讨.doc是一份面向火电厂热工自动化设计及运行管理人员的专业技术资料，聚焦除灰、补给水、凝结水精处理、废水、输煤等辅助系统由分散控制走向集中控制的规划思路。文档从当前PLC+CRT站相互独立、控制室过多的现状出发，对比德国尼德豪森电厂、黑泵电厂及日本矶子电厂的全厂管控一体化案例，并结合新版火力发电厂设计技术规程，归纳辅助车间控制点合并原则、控制策略优化方向与新技术应用思路，对实施集中控制的人员配置、备件管理和系统安全性也有涉及。资源包共1个doc文件，大小224KB，适合作为火电厂辅助车间自动化改造、设计方案比选及技术培训的参考资料。目前已有78人学习，内容较系统，便于快速把握集中控制的关键环节与实施要点。

1. 火电厂辅助车间系统集中控制：从“分散看守”到“少人值守”的关键一步

火电厂辅助车间系统集中控制方案，近几年几乎成了每个电厂技改项目的必选项。辅助车间指的是化学水处理、输煤、除灰除渣、脱硫、空压机站、暖通这些围绕机组运行但不属于主机DCS管控范围的系统。过去每个车间配一套PLC、一台操作员站、一个值班点，夜间至少两三个人轮流转；数据彼此隔离，机组工况一变化，辅助系统告警靠电话一层层传。集中控制要做的就是把这些系统收拢到一个监控平台上，由一组值班员同时管理多套系统，把“分散看守”变成“少人值守”。它能解决的问题很直接：减少重复岗位、压缩调度链路、让历史数据能统一回看。适合正在做降本增效或智能化改造的工艺、热控和信息化工程师。

2. 集中控制架构怎么搭：网络分区、实时数据库与网关选型

2.1 为什么集中控制不是“把操作员站搬进一个房间”

我在现场见过一个做得特别“省事”的改造：把化水、输煤、除灰三个车间的操作台搬到集控室，每套系统原封不动地摆一台操作员站，值班员面前放三把椅子来回滑。表面看是集中了，实际值班员要从三套画面里反复切换，告警铃声混在一起分不清来源，数据还是各自存各自的。这不叫集中控制，叫换了个地方分散看守。

集中控制真正要跨过的边界有三条：数据要汇集到同一套实时数据库里，操作指令要经过统一权限校验，运行记录要能跨系统关联查询。只有把这三件事做掉，岗位才能真正压下来，报表和事故分析也不用再去各台机器上拷历史数据。如果只是搬设备、搬椅子，那改造投入换不回任何回报。

2.2 集中控制的三层系统架构与网段划分

我一般会按三层来规划这个系统。第一层是过程控制层，保留各辅助车间原有PLC和现场逻辑，这一层的任务是保证设备联锁保护不因集中控制改造而弱化。第二层是数据采集与网络传输层，通过协议转换网关把不同品牌PLC的数据统一成OPC UA或Modbus TCP，送入冗余工业以太网。第三层是集中监控层，包含实时历史数据库服务器、操作员站、工程师站，以及后续要用的视频联动服务器和报表服务器。

网络分区是集中控制方案里最容易在施工阶段被“简化”掉的部分。常见做法是把网络分成两个区：控制网和管理网。控制网承载PLC与集中监控平台之间的实时数据，原则上不允许外部设备直接接入；管理网用于报表、Web发布和办公终端访问历史数据，与控制网之间用单向隔离装置或工业防火墙连接。

IP地址规划上，我会坚持两套独立网段。控制网用172.16.10.0/24和172.16.20.0/24，前者给PLC和网关，后者给服务器和操作员站；管理网用192.168.1.0/24。网关设备单独留一段固定管理地址，避免后期扩展时地址冲突。地址规划表一经分发，现场施工必须逐一核对，不能出现网关和操作员站跨网段通信的情况。

实时历史数据库建议只建一套，不要为每个车间各建一套。集中控制的一个隐含收益是历史数据放在一起，分析泵组启停频繁度、对比同型号设备运行参数时才不用导出多套数据再拼接。数据库容量按预估点数的两倍以上规划，压缩存储打开，趋势数据按一年起步估算磁盘。如果前期容量规划偏紧，半年后就要开始清理历史数据，事故分析时会很被动。

2.3 数据采集网关选型：协议、点数、冗余三件事

集中控制方案里最挑设备的是数据采集网关。电厂辅助车间里什么品牌的PLC都可能出现：西门子S7-300/400走ProfiBus-DP、施耐德M580走Modbus TCP、ABB AC800走OPC DA，还有一批国产品牌走私有协议。网关选型不能只看协议支持清单，至少要确认三件事。

第一，单网关可组态点数。很多网关标称容量很大，实际分配完各类数据块后，AI/AO点数打个对折就不够用了。建议按实际接入点数的1.5倍估算容量，并给每个网关预留20%余量。第二，冗余能力。集中控制投运后，网关就是单点故障点，网卡、电源、CPU都要支持冗余配置，两个节点之间要能自动同步配置。第三，断网缓存。管理网与控制网之间偶尔因隔离装置重启导致短时中断，网关要能本地缓存至少24小时数据，恢复后自动续传。选型时忽略这项，事后补数会非常痛苦。

选型阶段我会做一轮压力测试。搭一个临时环境，用网关模拟接入5000点以上，按1秒刷新周期持续跑24小时，观察CPU利用率和丢包率。很多网关在这个测试里会露馅——初始2000个点很流畅，点数一上去CPU持续超过60%，叠加断线重连，通信就卡死。另外要在技术协议里写明一句话：网关断电或重启不得影响原PLC系统运行。这条看似多余，实际能挡掉一批设计毛糙的设备。

提示：集中控制项目的责任边界必须在设计阶段写清楚。网关、服务器、监控平台归热控维护，PLC程序仍然归原车间维护班组负责。辅助车间分属不同部门的情况很常见，界面不清会导致实施后期扯皮。

3. 各辅助车间接入顺序与典型改造路径：化水、输煤、脱硫怎么做

3.1 车间接入优先级评估：先改造哪些车间才不白折腾

集中控制不是一天把全部车间接完，分批次投运比“一锅端”更稳。批次怎么排？我一般按四个维度打分：故障后对机组负荷的影响、该车间每天的值班人数、现有控制系统的自动化程度、通信改造工作量。四个维度各占25分，总分决定批次。

分批背后还有一个考虑：先接逻辑简单、设备不多、容易出成果的系统，让运行人员在集中监控平台上积累信任；一批投运稳定后再接下一批。一次性把所有系统接上去，出了问题互相干扰，现场也难排查。第一批接入的系统最好具备“改造前后肉眼可见”的效果，比如化水车间，设备数量少，逻辑流程固定，改造风险可控。

3.2 化水系统接入：从DP到OPC UA的典型路径

化水车间往往是第一个接入的，设备量不大、流程逻辑清晰。以西门子S7-300为例，原控制系统配置的ProfiBus-DP网络和操作员站可以保留不动，改造只增加一条独立路径：在DP网络上挂一台协议转换网关，从PLC读取需要集中的数据，网关将数据映射为OPC UA节点，接到集中控制网。

这样做的好处是：不修改PLC原有程序，不影响本地调试功能，原有操作员站继续当本地维护终端用。工作量集中在数据点位表的建立上。点位表是化水接入最耗时的部分，要把需要集中的模拟量、开关量、报警、SOE信号逐一列出来，标注好量程、偏移、报警死区、单位换算。很多项目在划点阶段图省事，把PLC里的原始地址照抄到网关里，结果画面上显示的温度带两位小数，实际量程对不上，最后还是返工。

点位表里有一类信号特别容易被漏掉：设备运行状态的“就地/远方”反馈。化水车间靠就地控制柜手动操作设备太常见了，如果集中侧看不到就地状态，值班员看到设备停了，远程也启不动，根本不知道是不是因为就地开关在动作，最后把故障归到集中控制系统头上。点位表做完后要和老值班员一起走一遍现场设备，逐台核对每一个状态位。

3.3 输煤系统接入：控制与视频联动必须一起做

输煤系统是另一个高优先级车间，接入难点不在PLC，而在皮带和碎煤机的监视。输煤走廊几十条皮带，远程操作皮带启动后，集中值班员必须能看到现场画面确认无人，才算安全。所以输煤接入集中控制不是把PLC数据接上来就完事，还要做视频联动。

常见做法是在集中监控平台上绑定设备编码与摄像头编号：操作员选中某条皮带，画面自动弹出对应摄像机画面，同时联动语音对讲。视频流和控制流最好不要共用交换机，视频走独立VLAN，避免视频帧率波动影响控制网传输质量。开关量信号如皮带运行、拉绳、跑偏，刷新周期做到1秒以内；视频画面允许2～3秒延迟，两者不能混在一个优先级里。

接入输煤PLC时还要特别注意就地操作箱。输煤系统现场有大量就地控制箱，改造时这些按钮不能拆，要在PLC程序里和集中控制的操作权切换做联锁，否则集中把设备启动了，就地有人按停，两边状态就打架。我当时的做法是把就地/远方切换信号作为启动允许条件写进逻辑，就地状态下集中侧操作被硬性屏蔽，联调时少了很多麻烦。这一条同样适用于除灰和空压机站。

3.4 脱硫系统接入：别在主机DCS改造时顺手做

脱硫系统如果用的是独立DCS，不建议和主机组DCS改造混在一起做。两个系统的时钟源、通信协议、维护班组都不一样，一次大修里塞两个项目，出了问题两边都说不清是谁的责任。合理的节奏是主机DCS改造稳定运行一个检修周期后，再单独把脱硫系统接入辅助车间集中控制平台。

接入时重点核对SOE数据。脱硫DCS自身的事件顺序记录分辨率一般能做到1ms，但通过网关传输到集中平台时，时标往往被重新打上，精度会降到秒级甚至丢失。要在技术协议里明确要求网关透传事件时标，不能自行重新生成。验收时做一次故障模拟，对比脱硫DCS本地SOE和集中平台收到的顺序是否一致，不一致就不能验收。

提示：每个系统接入前，先确认对方的时钟同步方式。不用NTP对时的车间，集中侧要有统一校时机制，否则跨系统报警分析时时间轴对不上，查异常像开盲盒。

4. 集中监控平台的画面组织、报警参数与操作权限设置

4.1 三层画面结构：总貌、流程、操作面板

集中监控平台投运后，值班员面前的画面数量可能是原来的3到4倍。如果不做分层组织，夜班盯盘就成了找茬游戏。我一般把集中监控画面分成三层：总貌层显示全厂辅助系统的运行概貌、主要设备启停状态和报警汇总，让值班员在正常工况下只需要盯一个画面；流程层对应每个辅助车间内部的工艺细节；操作层是设备级或阀组级的操作面板，包含联锁条件和操作反馈。

每层之间的跳转要有严格的上下级关系。总貌到流程用系统导航栏，流程到操作面板用鼠标点击设备图形。要特别避免的是“全局可跳转”的平面式组织——看似方便，实际使用中会让值班员失去方位感，操作时容易进错画面。操作面板上还要显示当前设备处于“就地”还是“远程”状态，以及最近一次操作的账号和时间，方便出问题时追溯。

4.2 报警参数设置：防止集中后出现报警洪水

分散控制时每个系统报警量不大，值班员还盯得住。集中控制后，所有报警集中到一个平台，如果不做报警收敛，夜班基本是报警声不断，最后值班员集体选择屏蔽报警，这比没有报警更危险。我在方案里一般会提前定一组报警参数：

报警分级也要做。辅助车间里真正需要立即响应的报警不多，大部分是设备状态提示。我把报警分为“提示、预警、事故”三级，只有事故级报警触发声音，预警级只在画面闪烁，提示级只进报警列表。这样做的直接收益是夜班报警音触发次数明显下降，值班员不再产生报警疲劳。报警参数不是一次调完就结束，试运行第一周每天要导出一份报警清单，逐条确认哪些报警是必要的、哪些是冗余的。

4.3 操作权限与安全互锁：三把锁不能少

集中控制之后，远程操作跨越物理距离，安全闭锁必须比就地操作更严。核心设置是三把锁：操作权切换锁、操作员权限锁、联锁条件锁。就地控制柜或现场PLC侧有一个“就地/远程”转换开关，拨到就地时集中侧操作被硬性屏蔽；拨到远程时，就地操作按钮失效。这个开关的状态必须作为硬接点接入PLC的DI通道，并写进设备启动逻辑，而不是只在监控画面上做限制，否则就地和集中同时操作时，设备状态根本对不上。

操作员权限按角色分开，值班员只能操作本班负责的系统；重大操作，比如切换水源、启动备用输煤线，需要工程师及以上账号二次确认。权限配置表要归档，每人一个账号，不允许共用。很多电厂初期为了省事给所有值班员一个公共账号，一旦出了误操作，连是谁操作的都查不出来，这个后悔药可不好咽。

4.4 试运行期间的值班制度调整

集中控制改造完成后，最容易被忽视的是值班制度和操作规程的配套。原来每个车间各有一份操作规程，集中以后所有系统由一组人操作，原有的操作票、工作票、巡检路线都要重新修订。我建议试运行第一周实行“双岗过渡”：每个原车间保留一名熟悉系统的师傅在中控室旁边指导，第二周逐步撤掉，只留集中值班班组。

试运行期间的每个操作、每次报警，都要留日志记录。这一周的数据直接用来微调报警参数和权限配置，不能等到正式投运后才发现报警设得不对。还有一个细节：中控室的值班电话要重新分配，原来打到各个车间的调度电话要统一转到集中值班台，避免电话打到空荡荡的车间没人接。

5. 集中控制调试与运行中的避坑清单：五条反复踩过的坑

5.1 网关接入后PLC通信中断，先怀疑轮询

现象：集中监控网关刚投运，化水车间PLC的CPU通信指示灯频繁闪红，现场操作员站操作卡顿，网关断电后一切恢复，接上又出问题。

原因：网关默认按全点位1秒周期轮询，存量PLC的通信模块负载本来就紧，点位数达到数千后轮询把通信端口占满，正常的人机交互反而进不去了。这不是设备坏了，是采集策略太粗暴。

解决：把轮询周期按数据类型分开，模拟量放到2秒，开关量保持1秒；将大点位按PLC分组分配到多个网关实例，避免单台网关负载过高。开启网关的“变化上报”模式，开关量只在状态翻转时主动上报。这个坑几乎每个项目都会遇到，排查时先看网关的CPU利用率和端口流量，别一上来就怀疑PLC程序被改坏了。

5.2 集中画面状态与PLC本体不同步

现象：现场PLC侧显示设备运行，集中监控画面长期停留在停止状态，手动刷新一次恢复，过几秒又错回去。

原因：该点位开了变化上报模式，但PLC程序里某些开关量按周期重新赋值，值没变化，集中侧就没收到新数据；另一种可能是字节序配置错误，开关量打包在16位整数内，高低字节被交换，解析出来全是乱的。

解决：对关键设备状态位设置独立扫描周期，不依赖变化上报；检查网关的字节序配置，西门子与AB设备的数据高低字顺序不一致，需要逐条调试。调试阶段用一个便携式测试仪在PLC侧数数据帧，对比集中侧接收内容，很快就能定位是网关解析问题还是点位映射问题。

5.3 通信中断被误判为设备故障

现象：输煤皮带画面所有测点突然变成0，值班员以为皮带全部停运，准备走停机流程，后来发现是网络交换机失电，现场设备其实还在运行。

原因：监控画面没有区分“数据无效”和“数据为0”，通信中断时数据质量位变坏，画面仍然显示数值0，值班员把通信故障读成了设备状态。

解决：在画面组态中对每个模拟量和开关量增加质量位判断，数据无效时显示灰色并打叉，不显示具体数值；单独做一张通信状态总览页，展示每个采集网关的在线状态、数据刷新延迟、断线次数。这样值班员看到灰色就明白是通信问题，不会被误导成设备状态。这个改进虽然简单，但能避免一次严重的误判断。

5.4 就地与远程操作权切换不到位导致冲突

现象：集中监控操作员远程启动除灰空压机，设备没动作，现场人员说就地控制柜按钮被人动过，两边都不知道对方处于什么状态。

原因：部分就地柜没有把就地/远方切换开关的硬接点接入PLC，只靠通信状态字判断，状态字在通信中断时失真。个别设备原厂程序没有做硬互锁，本地和远程操作指令同时有效。

解决：逐台设备排查，把就地/远方切换开关的硬接点全部接入PLC DI通道，作为启动逻辑的硬闭锁。改造期间逐一验证：就地状态下远程启动被拒绝，远程状态下就地按钮失效。验证要留记录，不能口头确认。这个问题的教训是：集中控制方案里任何依赖软件判断的安全措施都不可靠，必须落成硬接线。

5.5 夜班报警泛滥，值班员主动“静音”

现象：系统投运两周后，夜班报警平台高频报警，值班员开始在报警器上贴胶带，或者在画面里大量屏蔽点位，报警形同虚设。

原因：夜间负荷波动导致辅助设备频繁启停，报警死区和延时设置不够，大量报警属于正常工况变化而不是故障。比如水位波动触发高报警，液位波动在设定值附近来回穿越，每穿越一次报一条。

解决：分时段调整报警参数，负荷波动时段使用更大的死区和延时；对频繁启停的泵组增加状态变化报警抑制策略。更重要的是一点一点收敛——导出夜班报警记录，按点位统计触发次数，找出前20个高频报警点，逐条确认是否合理，而不是一次把报警功能全部关掉。这周做一点，下周再收敛一点，报警准确率才能稳住。

6. 集中控制验收之后：智能监盘的两个落点与三个验证指标

6.1 第一个进阶落点：把报警收敛成“事件”

集中控制平台稳定运行后，可以先加一个不强依赖AI的进阶功能：报警事件化加工。把同一设备短时间内连续产生的报警序列聚合成一条“事件”，比如“1号复用水泵跳闸”自动关联“电气故障信号”“出口压力低”“备用泵联锁启动”三条相关报警，值班员看到的就不是几百条零散报警，而是三四条带因果关系的设备事件。实施时不需要复杂算法，在实时库里配置报警关联模板，引入设备关系模型就能做。

6.2 集中控制改造是否达标的三个验证指标

验证方法我一般盯三个数字。一是单班值班人员数量，集中后至少减掉一个值守班组，否则改造没有经济账可算。二是报警响应时间，从报警发生到值班员确认的平均时长比改造前缩短50%以上。三是数据完整率，经过网关采集的数据在实时库中存储完整率不低于99.9%，达不到就要回头查网关缓存和断线续传机制。

我自己的习惯是每投运一个车间，就拉着运行和检修一起把操作票重新问一遍。问一遍就会发现新集中监控模式下有哪些步骤和原操作票对不上，提前在规程里改掉，比等正式投运后出了误操作再补要划算得多。集中控制这个方向，做了一半和做完是两回事，前期的点位表和后期的报警收敛都是慢功夫，急不来。希望帮到你。

本文还有配套的精品资源，点击获取