馮森良，程甫，於國良

（蕭山發(fā)電廠，杭州 311251）

0 引言

蕭山發(fā)電廠#5機組為一套西門子公司生產(chǎn)的SGT5-4000F(6)型燃氣-蒸汽聯(lián)合循環(huán)發(fā)電機組。機組于2012年8月6日完成168h滿負荷試運行。機組采用的DCS系統(tǒng)為西門子公司基于Windows7的SPPA-T3000操作系統(tǒng)。從機組調(diào)試階段到168h試運行，再到正式投入商業(yè)運營，DCS公用系統(tǒng)中信號測點大面積壞點的故障報警時有發(fā)生。本文主要針對該問題進行了全面地分析和處理，為今后同類型機組的類似故障提供借鑒。

1 概述

1.1 DCS公用系統(tǒng)組成

#5機組公用系統(tǒng)主要包括聯(lián)合循環(huán)壓縮空氣系統(tǒng)，儲氫站，天然氣調(diào)壓站，#02高備變，公用饋線報警信號等子系統(tǒng)。其中：

1）聯(lián)合循環(huán)壓縮空氣系統(tǒng)信號首先接入遠程控制柜03CPC12，然后通過光纖將信號送至AP01所在機柜03CPC01機柜。

2）儲氫站的信號點先接至03CPC12機柜，然后再轉(zhuǎn)到03CPC01機柜。

3）天然氣調(diào)壓站的信號點分為兩個部分：一部分測點如調(diào)壓站入口溫度（KA10CT101）、ESD閥前入口壓力（KA10CP101）、ESD閥后入口壓力（KA10CP103）、精過濾器A入口差壓（KE41CP001）等信號先接至調(diào)壓站控制室就地機柜，再通過通訊電纜接至03CPC01機柜；另一部分測點如入口ESD閥開狀態(tài)（03EKA10AA001XB01）、調(diào)壓站#1水浴爐啟動命令（03EKC51AH001XB91）、調(diào)壓站#1水浴爐停止命令（03EKC51AH001XB92）等信號先接至03CPC12機柜，然后轉(zhuǎn)到03CPC01機柜。

以上3個子系統(tǒng)的測點的DCS邏輯組態(tài)都分配在AP01的控制器中。

圖1 公用系統(tǒng)網(wǎng)絡圖1（下層網(wǎng)）Fig.1 Public system network (lower net)

圖2 公用系統(tǒng)網(wǎng)絡圖2（上層網(wǎng)）Fig.2 Public system network (upper)

#02高備變，公用饋線報警信號的信號點直接接至AP02控制器所在機柜03CPC02機柜，DCS邏輯組態(tài)中分配在AP02控制器中。

1.2 公用系統(tǒng)DCS網(wǎng)絡結(jié)構(gòu)

公用系統(tǒng)的DCS網(wǎng)絡結(jié)構(gòu)如圖1、圖2所示[1]。下層網(wǎng)中，A/B側(cè)的設(shè)備路由器A/B、公用服務器A/B層、AP01A/B、AP02A/B、CM01A/B（接調(diào)壓站信號）通過RJ45協(xié)議的工業(yè)以太網(wǎng)雙絞線接在交換機SCALANCE P01/P02上，SCALANCE P01和SCALANCE P02通過光纖互聯(lián)。

圖3 投運初期測點故障曲線圖Fig.3 Initial operation the point breakdown graph

圖4 2014年7月測點故障曲線圖Fig.4 July 2014 point fault graph

在上層網(wǎng)中，A/B側(cè)的設(shè)備路由器A/B、公用服務器A/B層（B層以及公用OPC服務器）通過RJ45協(xié)議的工業(yè)以太網(wǎng)雙絞線接在交換機SCALANCE T01 /T02上。SCALANCE T01和SCALANCE T02通過光纖互聯(lián)。

2 故障現(xiàn)象

公用系統(tǒng)信號測點發(fā)生壞點故障報警時，LCD畫面顯示翻紅，同時顯示“B”故障（壞點故障），測點數(shù)值保持壞點發(fā)生前的正常值。從歷史曲線上看，就是在發(fā)生壞點時曲線由實線變?yōu)樘摼€。發(fā)生故障的測點信號眾多，但不是所有公用系統(tǒng)的測點都發(fā)生故障，通過進一步地檢查，發(fā)現(xiàn)所有發(fā)生故障的點都分配在AP01控制器下，而AP02控制器下的測點都正常。在機組投運初期，每個故障點不一定同時變壞點，但往往比較接近同時恢復正常值，發(fā)生頻率不定，但一般一周左右會發(fā)生一次故障。故障時測點的歷史曲線如圖3所示。

到2014年初，故障發(fā)生頻率大為增加，一般間隔最長15min發(fā)生一次，且各個信號點發(fā)生故障的起止時間不確定。由于壞點發(fā)生過于頻繁，發(fā)生故障時相關(guān)設(shè)備無法遠程操作，嚴重影響了運行人員對公用系統(tǒng)設(shè)備的監(jiān)視和操作，威脅了機組的安全穩(wěn)定生產(chǎn)。圖4是2014年7月份時測點故障的歷史曲線圖。

3 原因分析及現(xiàn)場處理

3.1 網(wǎng)線接口故障

由于所報故障類型為“B”報警，導致該報警發(fā)生的原因通常是信號測點的接線斷開[2]。如果是某一個信號發(fā)生了“B”報警，檢修人員的處理方法一般是先檢查該信號測點的接線是否存在問題。由于每次都是大量的測點發(fā)生“B”報警，所以不太可能是信號測點接線問題。檢修人員想到的首先是通訊電纜連接頭故障的可能性[3]。從圖1中可以發(fā)現(xiàn)，從AP到服務器的網(wǎng)絡連接為：AP-SCALANCE（下層網(wǎng)）-服務器，通過以太網(wǎng)雙絞線連接。西門子公司在調(diào)試安裝時所有的雙絞線接線頭都是現(xiàn)場制作，因而，這是一個可疑的故障發(fā)生點。為此，重新制作了AP01 A側(cè)、B側(cè)至SCALANCE P01的雙絞線兩端的插頭，AP02 A側(cè)、B側(cè)至SCALANCE P02的雙絞線兩端的插頭（當時還未發(fā)現(xiàn)所有故障點均來自AP01），SCALANCE P01至公用服務器A層、SCALANCE P02至公用服務器B層的雙絞線兩端的插頭。通過觀察，故障未消除，說明不是通訊電纜的原因。

3.2 信號干擾問題

排除了通訊電纜接線的問題，根據(jù)故障的現(xiàn)象，分析的第二個可能原因是信號干擾[4]，這與德國西門子方面針對此問題給出的建議相同。

通過仔細核對，發(fā)現(xiàn)所有發(fā)生故障的點都分配在AP01控制器下，而AP02控制器下的測點都正常。由于AP01下面不僅是03CPC01機柜，還連著03CPC12機柜和調(diào)壓站就地機柜通訊過來的信號測點，所以首先懷疑遠程機柜的信號干擾問題。但是通過西門子工程師地檢查發(fā)現(xiàn)，在發(fā)生信號壞點故障的時候，AP01里面的數(shù)據(jù)是完好的，所以可以排除遠程機柜過來的信號存在干擾問題。因為SCALANCE P01和服務器之間的雙絞線很短且不存在干擾可能，所以唯一存在干擾的可能部分就是AP01至SCALANCE P01之間的雙絞線。AP01所在的機柜03CPC01在電子室，SCALANCE P01在#5機工程師站的03CRY81機柜，由于兩者距離不是很遠，大概20m左右，重新敷設(shè)了一根雙絞線，為避免信號干擾問題，敷設(shè)電纜時繞開了所有電纜橋架[5]。通過觀察，故障仍未消除，說明不是信號干擾的原因。

3.3 服務器的硬件故障

既然在發(fā)生信號壞點故障的時候AP01里面的數(shù)據(jù)是完好的，且排除了AP01至SCALANCE P01之間的通訊電纜存在干擾問題，那故障的原因確定在服務器里面。通過西門子工程師再進一步地檢查發(fā)現(xiàn)，發(fā)生壞點故障時，畫面顯示“B”報警，在服務器里查詢可以發(fā)現(xiàn)故障的原因是緩存溢出，就是內(nèi)存不夠用。登陸服務器，可以檢查硬件的健康狀況。檢查后發(fā)現(xiàn)服務器硬件均正常，其中內(nèi)存共8GB分兩條，每條4GB，狀態(tài)顯示均正常。咨詢西門子公司后，答復服務器硬件故障的可能性較小，且檢測狀態(tài)均正常，暫時不考慮該原因。但是緩存溢出的故障原因無法解釋，因為內(nèi)存狀態(tài)正常，且容量有8GB，一般不存在溢出的可能。西門子方面給出的建議是重啟服務器。重啟服務器后觀察，故障仍會發(fā)生，重啟服務器沒有效果。

3.4 T3000里軟件配置的問題

既然暫時排除了服務器硬件的故障可能性，就分析是否是T3000里對AP01的軟件配置出了問題。為此主要采取了以下措施：

1）AP清除代碼。將AP01的代碼清除后重新下載離線代碼，沒有效果。

2）通過西門子工程師對比AP01和AP02的參數(shù)設(shè)置后發(fā)現(xiàn)，兩者的runtime container中的一個通訊方式rtc_cm001的選項設(shè)置不同，AP01在該選項設(shè)置了勾選，而AP02為未勾選此項。因此將AP01的勾選去除，保存設(shè)置后，沒有效果。

3）將AP01的ID號由“1”改為“4”，檢測是否是程序問題，沒有效果。

4）查看報警記錄，逐個檢查報壞點故障的信號測點，篩選出報錯頻率較高的測點。針對每一個篩選出的測點，檢查其邏輯，在保證不影響運算的前提下，盡量延長其掃描周期，以降低程序?qū)?nèi)存的要求。修改一遍后沒有效果。

5）檢查T3000操作系統(tǒng)。#5機DCS所使用的SPPA-T3000系統(tǒng)的版本號為04.34.00，同時使用的硬件為西門子的S7框架。經(jīng)查詢，針對硬件為SPPA-T3000的S7框架，軟件為SPPA-T3000 04.34.00版本的系統(tǒng)，德國西門子工程師專門寫過一篇文章《SPPA-T3000系統(tǒng)04.34.00版本中S7框架高事件率問題》（原文《High S7 event rate in SPPA-T3000 Version 04.34.00》）[6]，闡述了04.34.00版本的T3000系統(tǒng)可能存在的問題：在S7框架的硬件中安裝了04.34.00版本的T3000系統(tǒng)后，由于存儲器整數(shù)端口的問題，在S7的控制器中的事件率可能會增加。而控制器事件率的增加會導致服務器中內(nèi)存的大量消耗，最終報出緩存溢出的故障。所以，服務器中報緩存溢出的故障是真實的，故障時8GB的內(nèi)存真的被消耗完了。根據(jù)文章中給出的解決方案，南京西門子工程師在原T3000系統(tǒng)上重新覆蓋了一個新的T3k_std.zip文件，并重新下裝程序。操作完成后，故障消除。

4 結(jié)束語

本文通過對本廠#5機公用系統(tǒng)信號測點大面積壞點報警故障的原因分析及處理過程的敘述，主要得到以下兩點經(jīng)驗，可以為同類型機組的類似故障提供借鑒。

1）針對常見的大面積信號測點報警或信號質(zhì)量時好時壞的故障，通常人們考慮故障原因是通訊方面問題[7]（如通訊電纜接頭、信號轉(zhuǎn)換器等故障）、接地不良引起的信號電纜干擾問題[8]，而本文中最終的故障原因是軟硬件的匹配問題，即軟件的配置也可能導致類似的故障現(xiàn)象，這是以后遇到類似問題需要拓展思維的一個方面。

2）對于國外引進的設(shè)備和技術(shù)，在消化吸收方面有待加強。雖然由于外國大公司的技術(shù)壟斷或其他原因，無法得到完整的、系統(tǒng)的培訓，但是對相關(guān)軟硬件知識的掌握也可以通過其他的途徑獲得，如本文的例子，德國西門子公司工程師在2011年7月就發(fā)表了相關(guān)的文章，說明他們在此之前已經(jīng)發(fā)現(xiàn)過類似問題，但他們內(nèi)部也缺乏交流機制和及時將問題向用戶通報機制，本廠#5機從2012年8月投產(chǎn)，到2014年8月才找到真正原因，徹底解決該故障，期間兩年的時間，本廠#5機一直在這個本不該存在的安全隱患下生產(chǎn)運行，這是西門子公司和各廠都應該吸取的重大教訓。

[1]蕭山公用系統(tǒng)網(wǎng)絡圖,2012,8.蕭山發(fā)電廠#5機組竣工資料[Z].

[2]來曉,馮冬芹,褚健.分布式網(wǎng)絡故障檢測及恢復技術(shù)研究[J].計算機工程與應用,2010,46(24).

[3]郭東華,陳曉富.安塞LNG項目DCS與各子系統(tǒng)之間的通訊——基于Modbus-RTU及OPC實現(xiàn)ECS700的異構(gòu)通訊[J].儀器儀表用戶,2013,2:23-26.

[4]葉國滿,屠士鳳,林晨,等.抑制信號干擾的方法研究和應用[J].浙江電力,2012,12:67-69.

[5]戴焰明.儀表及控制系統(tǒng)接地措施[J].儀器儀表用戶,2007,5:131-132.

[6]賀賢峰,幾起熱工信號晃動的原因分析[J].浙江電力,2001,3:65-66.

[7]周倩,魯學農(nóng),張文景.火電廠DCS系統(tǒng)信號抗干擾研究及實例[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.