某电厂装机为2×150 MW 凝汽式汽轮机组。 2014-09-01T18：18，集控室操作员站突然发生2号 机组锅炉汽包及给水系统所有参数显示为粉色、给 水系统设备无法操作故障，汽轮机除氧器、凝汽器 水位迅速上升。故障发生后机组负荷从150 MW升 高至163 MW，1号给水泵勺管执行机构无法操作， 汽包水位无法维持。运行人员就地发现1号给水泵 勺管执行机构从52%关至19%，随后因汽包实际水 位降低至-387 mm（低Ⅲ值）引发锅炉MFT和锅炉大 联锁保护动作，给煤机和所有风机全停，汽轮机组 负荷降至26.5 MW。故障发生前，2号机组主要运行 参数见表 1。

表 1(Table 1)

表 1 故障发生前2号机组主要运行参数

表 1 故障发生前2号机组主要运行参数

现场检查发现2号工程师站DCS自检程序显示 DPU2在主控状态，DPU22为初始化状态（黄色）， 人为登录DPU2失败，初步判断为DPU2故障^{[1, 2, 3]}。检 查电子间2号控制柜，2个DPU指示灯均指示正常， 网卡指示灯闪烁正常，判断DPU2可能存在死机情况。

18：28对DPU2进行断电强制复位，DPU22切为 主控后，给水系统参数恢复正常；运行人员开始恢 复各辅机系统，18：46风机和给煤机启动，至20：00 机组负荷恢复至150 MW。 2.1 给水系统无法监视和操作原因分析

2号机组DCS历史数据和操作记录文件中各时 间段的描述及分析如下。 2.1.1 过程Ⅰ

2.1.1.1 过程记录

2014-08-31T06：05：39，操作记录文件记录 DPU22通告“DPU into the main（控制器升主控）”， 操作员站出现DPU2 网路故障报警；06：05：41， DPU22 报“WSAEWOUND BLOCK，Send Fail（发送 缓存区满，发送失败）”。之后大约每隔22 s发1次 “Create Connect Partner Thread OK! Network Connect Fail（创建连接副控线程成功，网络连接失 败）”，历史报警记录画面如图 1所示。

图 1(Figure 1)

图 1 过程Ⅰ历史报警记录画面

06：05：39 开始，DPU2 的A、B 网网络故障， DPU22 升为主控。DPU22 升主控后，开始查询DPU2的网络状态，但由于DPU2此时网络异常，无 法回复A、B网的网络状态，导致DPU22持续查询其 网络状态，周期为22 s左右。 2.1.2 过程Ⅱ

2.1.2.1 过程记录

2014-09-01T06：45：49开始，DPU22每隔3 s左 右发1次“Create Connect Partner Thread OK! Net⁃ work Connect Fail（创建连接副控线程成功，网络连 接失败）”，历史报警记录画面如图 2所示。

图 2(Figure 2)

图 2 过程Ⅱ历史报警记录画面

由于DPU22无法查询到DPU2的网络状态，所 以查询频率逐渐加快。 2.1.3 过程Ⅲ

2.1.3.1 过程记录

2014-09-01T12：05：57开始，DPU22每隔1 s发 1次“Create Connect Partner Thread OK!（创建连接 副控线程成功）”。该报警状态一直持续到18：18： 04，历史报警记录画面如图 3所示。

图 3(Figure 3)

图 3 过程Ⅲ历史报警记录画面

因DPU22控制器对DPU2的A、B网网络状态查 询周期加快，导致DPU22负荷不断增加，最终造成 DPU22满负荷^[4]。 2.1.4 过程Ⅳ

2.1.4.1 过程记录

2014-09-01T18：18：56，DPU22 发出“DPU be⁃ gin to run！（控制器升主控）”，历史报警记录画面如 图 4所示。

图 4(Figure 4)

图 4 过程Ⅳ历史报警记录画面

对DPU2的A、B网网络状态进行高频率查询持 续了21 679 s，导致DPU22 满负荷运行，控制器内 Watch Dog（看门狗）程序动作；18：18：05 DPU22重 新启动，DPU2 随即升为主控。但DPU2 虽升为主 控，因其网络本身存在问题，并未发出“DPU2 into the main（控制器升主控）”通告。同时，由于DPU2 网络故障无法跟踪，导致DPU22和DPU2内组态数 据不一致，DPU22 重启后显示为初始状态，并且 DPU2仍然停留在故障初始时的数据状态^{[5, 6]}。 2.1.5 过程Ⅴ

2.1.5.1 过程记录

2014-09-01T18：28：23，DPU22 发出“DPU（XCU） into the main（控制器升主控）”；18：29：08， DPU2发出“DPU（XCU） begin to run！（控制器开始 运行）”，历史报警记录画面如图 5所示。

图 5(Figure 5)

图 5 过程Ⅴ历史报警记录画面

由于网络故障，DPU2主控状态下无法正常控 制，DPU22 初始态不能升为主控。18：28：23 断开 DPU2电源并予以重启。DPU22强制升为主控，约 40 s后DPU2也正常启动，同时网络也因复位而得到 了恢复。 2.2 给水泵勺管开度及报警问题分析 2.2.1 过程记录

DPU2网络正常及故障时1号给水泵勺管开度 及报警信号记录如图 6所示。

图 6(Figure 6)

图 6 1号给水泵勺管开度趋势波形图

2014-08-31T06：05：39，由于DPU2网络故障， DPU22升主控运行。DPU2内部逻辑正常工作，但 因网络故障，导致DPU2实时数据无法与DPU22数 据保持同步，而是保持在网络故障时刻（1号给水泵 勺管执行器指令为27.11%）^[2]。但在2014- 09-01T18：18：05 DPU22重启，因切换部分功能正 常，DPU2升主控且自检显示主控，此时除实时网络 故障外，DPU2其他功能均正常，于是按照8月31日 故障发生时的初始数据进行1号给水泵勺管的自动 调节。 2.3 机组负荷升高 2.3.1 故障现象

故障发生后，机组负荷从150 MW 升高至163MW。 2.3.2 原因分析

由于1号给水泵勺管位置由50%降至19%，给 水流量的减少导致通过高压加热器的水量下降，所 以1号、2号高压加热器所需抽汽量大幅减少，因汽 轮机内部做功蒸汽量的增加导致机组负荷增加。 2.4 结论

进一步检查发现，DPU网络故障是由于DCS中 DPU2硬件（网络芯片）某一触点存在虚焊问题（经 设备返厂检测分析确认），导致控制器双网同时出 现能发送但不能接收报警信息造成的。8月31日在 DPU2网络故障后，DPU22自动切为主控，而DPU2 一直处于假备用状态，2个DPU内部数据已经不一 致。当9月1日DPU22进行软复位操作后，DPU2切 为主控，由于两者数据仍不一致，导致DPU22进入 初始化状态，此时因DPU2虽监测到故障但不能自 动切回DPU22，造成操作员站参数一直显示为粉点 且不能操作，只能进行人为强制切换。给水泵勺管 关回原因是由于8月31日DPU2故障后，DPU2内部 运算一直保持在故障时状态，当9月1日DPU2重新 切回主控时，DPU2 输出指令使给水泵勺管关至 19%。

经返厂更换触点虚焊的网络芯片后，2号机组 DPU网络故障问题得到彻底解决。 3 预防措施及建议

（1） 定期查询上位机操作记录文件，检查是否 有异常通告信息并及时进行分析处理。运行人员 对滚动条格式、无声光显示的报警记录应引起足够 重视，并立即通知检修人员处理，避免事件扩大。

（2） 在日常点检中应加强对报警历史记录文 件的检查，发现问题及时解决。日常点检中，通过 “自检”程序加强对控制器状态的监视，包括主副控 制器状态、网络状态、CPU负荷率、内存占用率等^[5]； 通过“报警历史”程序监视是否存在异常报警信息。

（3） 如遇DPU发生异常，应结合报警信息和通 告信息进行判断，及时软复位或者硬复位DPU。

（4） 对DCS的自检排查逻辑功能进行优化改 进。提高DCS/DEH 系统硬件故障报警级别，将 DCS/DEH系统硬件故障报警列入声光报警中进行 监控。建议制造厂家对DPU内部逻辑进行优化，当 主DPU长期检测不到备用DPU控制器网络时，即判 断备用DPU故障并进行隔离操作；同时发出硬件报 警及时提醒处理；当主DPU判断备用DPU故障后， 不再进行数据传输，防止增加主DPU运行负荷^{[7, 8]}。