蕭山發電廠#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.