萧山发电厂#5机公用系统信号测点大面积坏点报警故障分析处理

冯森良，程甫，於国良

（萧山发电厂，杭州 311251）

0 引言

萧山发电厂#5机组为一套西门子公司生产的SGT5-4000F(6)型燃气-蒸汽联合循环发电机组。机组于2012年8月6日完成168h满负荷试运行。机组采用的DCS系统为西门子公司基于Windows7的SPPA-T3000操作系统。从机组调试阶段到168h试运行，再到正式投入商业运营，DCS公用系统中信号测点大面积坏点的故障报警时有发生。本文主要针对该问题进行了全面地分析和处理，为今后同类型机组的类似故障提供借鉴。

1 概述

1.1 DCS公用系统组成

#5机组公用系统主要包括联合循环压缩空气系统，储氢站，天然气调压站，#02高备变，公用馈线报警信号等子系统。其中：

1）联合循环压缩空气系统信号首先接入远程控制柜03CPC12，然后通过光纤将信号送至AP01所在机柜03CPC01机柜。

2）储氢站的信号点先接至03CPC12机柜，然后再转到03CPC01机柜。

3）天然气调压站的信号点分为两个部分：一部分测点如调压站入口温度（KA10CT101）、ESD阀前入口压力（KA10CP101）、ESD阀后入口压力（KA10CP103）、精过滤器A入口差压（KE41CP001）等信号先接至调压站控制室就地机柜，再通过通讯电缆接至03CPC01机柜；另一部分测点如入口ESD阀开状态（03EKA10AA001XB01）、调压站#1水浴炉启动命令（03EKC51AH001XB91）、调压站#1水浴炉停止命令（03EKC51AH001XB92）等信号先接至03CPC12机柜，然后转到03CPC01机柜。

以上3个子系统的测点的DCS逻辑组态都分配在AP01的控制器中。

图1 公用系统网络图1（下层网）Fig.1 Public system network (lower net)

图2 公用系统网络图2（上层网）Fig.2 Public system network (upper)

#02高备变，公用馈线报警信号的信号点直接接至AP02控制器所在机柜03CPC02机柜，DCS逻辑组态中分配在AP02控制器中。

1.2 公用系统DCS网络结构

公用系统的DCS网络结构如图1、图2所示[1]。下层网中，A/B侧的设备路由器A/B、公用服务器A/B层、AP01A/B、AP02A/B、CM01A/B（接调压站信号）通过RJ45协议的工业以太网双绞线接在交换机SCALANCE P01/P02上，SCALANCE P01和SCALANCE P02通过光纤互联。

图3 投运初期测点故障曲线图Fig.3 Initial operation the point breakdown graph

图4 2014年7月测点故障曲线图Fig.4 July 2014 point fault graph

在上层网中，A/B侧的设备路由器A/B、公用服务器A/B层（B层以及公用OPC服务器）通过RJ45协议的工业以太网双绞线接在交换机SCALANCE T01 /T02上。SCALANCE T01和SCALANCE T02通过光纤互联。

2 故障现象

公用系统信号测点发生坏点故障报警时，LCD画面显示翻红，同时显示“B”故障（坏点故障），测点数值保持坏点发生前的正常值。从历史曲线上看，就是在发生坏点时曲线由实线变为虚线。发生故障的测点信号众多，但不是所有公用系统的测点都发生故障，通过进一步地检查，发现所有发生故障的点都分配在AP01控制器下，而AP02控制器下的测点都正常。在机组投运初期，每个故障点不一定同时变坏点，但往往比较接近同时恢复正常值，发生频率不定，但一般一周左右会发生一次故障。故障时测点的历史曲线如图3所示。

到2014年初，故障发生频率大为增加，一般间隔最长15min发生一次，且各个信号点发生故障的起止时间不确定。由于坏点发生过于频繁，发生故障时相关设备无法远程操作，严重影响了运行人员对公用系统设备的监视和操作，威胁了机组的安全稳定生产。图4是2014年7月份时测点故障的历史曲线图。

3 原因分析及现场处理

3.1 网线接口故障

由于所报故障类型为“B”报警，导致该报警发生的原因通常是信号测点的接线断开[2]。如果是某一个信号发生了“B”报警，检修人员的处理方法一般是先检查该信号测点的接线是否存在问题。由于每次都是大量的测点发生“B”报警，所以不太可能是信号测点接线问题。检修人员想到的首先是通讯电缆连接头故障的可能性[3]。从图1中可以发现，从AP到服务器的网络连接为：AP-SCALANCE（下层网）-服务器，通过以太网双绞线连接。西门子公司在调试安装时所有的双绞线接线头都是现场制作，因而，这是一个可疑的故障发生点。为此，重新制作了AP01 A侧、B侧至SCALANCE P01的双绞线两端的插头，AP02 A侧、B侧至SCALANCE P02的双绞线两端的插头（当时还未发现所有故障点均来自AP01），SCALANCE P01至公用服务器A层、SCALANCE P02至公用服务器B层的双绞线两端的插头。通过观察，故障未消除，说明不是通讯电缆的原因。

3.2 信号干扰问题

排除了通讯电缆接线的问题，根据故障的现象，分析的第二个可能原因是信号干扰[4]，这与德国西门子方面针对此问题给出的建议相同。

通过仔细核对，发现所有发生故障的点都分配在AP01控制器下，而AP02控制器下的测点都正常。由于AP01下面不仅是03CPC01机柜，还连着03CPC12机柜和调压站就地机柜通讯过来的信号测点，所以首先怀疑远程机柜的信号干扰问题。但是通过西门子工程师地检查发现，在发生信号坏点故障的时候，AP01里面的数据是完好的，所以可以排除远程机柜过来的信号存在干扰问题。因为SCALANCE P01和服务器之间的双绞线很短且不存在干扰可能，所以唯一存在干扰的可能部分就是AP01至SCALANCE P01之间的双绞线。AP01所在的机柜03CPC01在电子室，SCALANCE P01在#5机工程师站的03CRY81机柜，由于两者距离不是很远，大概20m左右，重新敷设了一根双绞线，为避免信号干扰问题，敷设电缆时绕开了所有电缆桥架[5]。通过观察，故障仍未消除，说明不是信号干扰的原因。

3.3 服务器的硬件故障

既然在发生信号坏点故障的时候AP01里面的数据是完好的，且排除了AP01至SCALANCE P01之间的通讯电缆存在干扰问题，那故障的原因确定在服务器里面。通过西门子工程师再进一步地检查发现，发生坏点故障时，画面显示“B”报警，在服务器里查询可以发现故障的原因是缓存溢出，就是内存不够用。登陆服务器，可以检查硬件的健康状况。检查后发现服务器硬件均正常，其中内存共8GB分两条，每条4GB，状态显示均正常。咨询西门子公司后，答复服务器硬件故障的可能性较小，且检测状态均正常，暂时不考虑该原因。但是缓存溢出的故障原因无法解释，因为内存状态正常，且容量有8GB，一般不存在溢出的可能。西门子方面给出的建议是重启服务器。重启服务器后观察，故障仍会发生，重启服务器没有效果。

3.4 T3000里软件配置的问题

既然暂时排除了服务器硬件的故障可能性，就分析是否是T3000里对AP01的软件配置出了问题。为此主要采取了以下措施：

1）AP清除代码。将AP01的代码清除后重新下载离线代码，没有效果。

2）通过西门子工程师对比AP01和AP02的参数设置后发现，两者的runtime container中的一个通讯方式rtc_cm001的选项设置不同，AP01在该选项设置了勾选，而AP02为未勾选此项。因此将AP01的勾选去除，保存设置后，没有效果。

3）将AP01的ID号由“1”改为“4”，检测是否是程序问题，没有效果。

4）查看报警记录，逐个检查报坏点故障的信号测点，筛选出报错频率较高的测点。针对每一个筛选出的测点，检查其逻辑，在保证不影响运算的前提下，尽量延长其扫描周期，以降低程序对内存的要求。修改一遍后没有效果。

5）检查T3000操作系统。#5机DCS所使用的SPPA-T3000系统的版本号为04.34.00，同时使用的硬件为西门子的S7框架。经查询，针对硬件为SPPA-T3000的S7框架，软件为SPPA-T3000 04.34.00版本的系统，德国西门子工程师专门写过一篇文章《SPPA-T3000系统04.34.00版本中S7框架高事件率问题》（原文《High S7 event rate in SPPA-T3000 Version 04.34.00》）[6]，阐述了04.34.00版本的T3000系统可能存在的问题：在S7框架的硬件中安装了04.34.00版本的T3000系统后，由于存储器整数端口的问题，在S7的控制器中的事件率可能会增加。而控制器事件率的增加会导致服务器中内存的大量消耗，最终报出缓存溢出的故障。所以，服务器中报缓存溢出的故障是真实的，故障时8GB的内存真的被消耗完了。根据文章中给出的解决方案，南京西门子工程师在原T3000系统上重新覆盖了一个新的T3k_std.zip文件，并重新下装程序。操作完成后，故障消除。

4 结束语

本文通过对本厂#5机公用系统信号测点大面积坏点报警故障的原因分析及处理过程的叙述，主要得到以下两点经验，可以为同类型机组的类似故障提供借鉴。

1）针对常见的大面积信号测点报警或信号质量时好时坏的故障，通常人们考虑故障原因是通讯方面问题[7]（如通讯电缆接头、信号转换器等故障）、接地不良引起的信号电缆干扰问题[8]，而本文中最终的故障原因是软硬件的匹配问题，即软件的配置也可能导致类似的故障现象，这是以后遇到类似问题需要拓展思维的一个方面。

2）对于国外引进的设备和技术，在消化吸收方面有待加强。虽然由于外国大公司的技术垄断或其他原因，无法得到完整的、系统的培训，但是对相关软硬件知识的掌握也可以通过其他的途径获得，如本文的例子，德国西门子公司工程师在2011年7月就发表了相关的文章，说明他们在此之前已经发现过类似问题，但他们内部也缺乏交流机制和及时将问题向用户通报机制，本厂#5机从2012年8月投产，到2014年8月才找到真正原因，彻底解决该故障，期间两年的时间，本厂#5机一直在这个本不该存在的安全隐患下生产运行，这是西门子公司和各厂都应该吸取的重大教训。

[1]萧山公用系统网络图,2012,8.萧山发电厂#5机组竣工资料[Z].

[2]来晓,冯冬芹,褚健.分布式网络故障检测及恢复技术研究[J].计算机工程与应用,2010,46(24).

[3]郭东华,陈晓富.安塞LNG项目DCS与各子系统之间的通讯——基于Modbus-RTU及OPC实现ECS700的异构通讯[J].仪器仪表用户,2013,2:23-26.

[4]叶国满,屠士凤,林晨,等.抑制信号干扰的方法研究和应用[J].浙江电力,2012,12:67-69.

[5]戴焰明.仪表及控制系统接地措施[J].仪器仪表用户,2007,5:131-132.

[6]贺贤峰,几起热工信号晃动的原因分析[J].浙江电力,2001,3:65-66.

[7]周倩,鲁学农,张文景.火电厂DCS系统信号抗干扰研究及实例[J].中国电力,2012,4:64-67.

[8]Karlsruhe.High S7 event rate in SPPA-T3000 Version 04.34.00[J].SPPA-T3000 Technical News.2011,7.