李思平
淮南礦業(yè)集團電力公司,安徽淮南 232072
某電廠DCS 控制系統(tǒng)2011 年4 月18 日下午5 點10 左右,運行人員發(fā)現(xiàn)1#機組所有操作站中數(shù)據(jù)丟失,畫面顯示為“???”,但現(xiàn)場設備運行正常。維護人員到達后去電子設備間檢查,發(fā)現(xiàn)部分控制器退出同步,維護人員試圖手動同步,發(fā)現(xiàn)42 控制器出現(xiàn)X 燈常亮故障。去機柜中檢查發(fā)現(xiàn)網(wǎng)絡中原先設定為master 狀態(tài)交換機(IP:192.168.11.211)指示燈顯示異常,master 燈從常亮變?yōu)殚W爍。而同機柜的另一臺交換機(IP:192.168.11.212)master 燈由不亮變化為閃爍狀態(tài)。維護人員對服務器做重起,但無效果;對IP:192.168.11.212 的交換機做重新上電處理,網(wǎng)絡恢復了一小段時間運行后再次出現(xiàn)上述情況。經(jīng)電話咨詢DCS 廠家技術人員,確定把此臺交換機換下,并撥出42 控制器后,網(wǎng)絡恢復正常。5 月31 日下午13:37 前后,1#機組所有操作員站中再次出現(xiàn)部分數(shù)據(jù)變成“???”,但約一分鐘后自動恢復。
網(wǎng)絡出現(xiàn)數(shù)據(jù)采集中斷時,設定為master 狀態(tài)交換機(IP:192.168.11.211)指示燈顯示異常,master 燈從常亮變?yōu)殚W爍,而同機柜的另一臺交換機(IP:192.168.11.212)master 燈由不亮變化為閃爍狀態(tài)。
通常,常態(tài)下的環(huán)網(wǎng)的狀態(tài)是:網(wǎng)絡中有一臺交換機設置為master,在網(wǎng)絡構建成環(huán)時,此臺交換機上的master 燈常亮,并且在web 頁面中也可以觀察到。環(huán)網(wǎng)中的其他交換機master 燈都不亮,web 頁面觀察到的都是slave 狀態(tài)。一般,master 燈變?yōu)殚W爍狀態(tài)只有在環(huán)網(wǎng)處于開環(huán)狀態(tài)時才會出現(xiàn)。而同時出現(xiàn)兩臺交換機master 燈閃爍,有兩種可能性:1)網(wǎng)絡中有兩臺交換機人為設置成了兩個master。(這個可以排除);2)網(wǎng)絡中出現(xiàn)異常的數(shù)據(jù)包,或交換機出現(xiàn)了硬件故障時,網(wǎng)絡拓撲發(fā)成了改變。從交換機的日志文件中可以看到,在出現(xiàn)問題的時間點,交換機在短時間內(nèi)記錄了多次拓撲更改信息。從部分控制器保存的事件日志文件能提取到如下記錄:“! 18/04/11 11:01:54 (0x5C004A16) 81F6 Entering Ethernet rate Protection UDP broadcast storm”,可以看出網(wǎng)絡確實產(chǎn)生UDP 數(shù)據(jù)包廣播風暴!
從交換機和控制器的這些記錄信息,可以發(fā)現(xiàn)在數(shù)據(jù)采集異常時,環(huán)網(wǎng)在頻繁的切換狀態(tài),網(wǎng)絡中在那個時間段很有可能存在著很大的數(shù)據(jù)流量,即發(fā)生了網(wǎng)絡風暴,從而使整個網(wǎng)絡的通訊不暢,數(shù)據(jù)無法正常傳輸,致使操作站畫面數(shù)據(jù)顯示為“???”。但究竟什么原因誘發(fā)了網(wǎng)絡風暴,還有待進一步的試驗分析。
通過對控制器日志的分析,發(fā)現(xiàn)本次異常時鍋爐和汽機網(wǎng)段共有13 對控制器出現(xiàn)中斷,最早出現(xiàn)中斷的控制器是T2550_16,中斷時間是13:37:48,最后恢復的控制器是T2550_30,時間是13:38:28。總體故障時為40 秒。出現(xiàn)數(shù)據(jù)中斷的控制器都出現(xiàn)了同步退出,退出時間大概在數(shù)據(jù)中斷前12 秒左右,這13 對控制器的事件記錄中都出現(xiàn)了由數(shù)據(jù)中斷引起的冗余切換過程。
5 月31 日的故障與4 月18 日的現(xiàn)象有相似之處,都是在操作站上數(shù)據(jù)顯示為“???”。但5 月31 日出現(xiàn)“???”的范圍較小,涉及13 對控制器,時間較短,持續(xù)40 秒。5 月31日的故障的直接原因與4 月18 日不同。4 月18 日所有的控制器的記錄都顯示出網(wǎng)絡的中斷和堵塞,使得控制器向操作員的數(shù)據(jù)通訊中斷,畫面顯示都為“???”號。而5 月31 日的故障,沒有任何與網(wǎng)絡中斷和堵塞的記錄。僅為個別通訊中斷引起控制器的同步退出的記錄。同步退出過程,再次強制同步,造成網(wǎng)絡負荷短時加重,13 對控制器上傳數(shù)據(jù)故障,造成相關數(shù)據(jù)在畫面上顯示為“???”。
4 月18 日異常發(fā)生后,該廠邀請相關電力科學研究院專家、DCS 廠家及交換機廠家技術人員一起立即在現(xiàn)場招開了事故分析會。確定:1)立即將交換機送臺灣的生產(chǎn)廠家進行軟、硬件檢測;2)DCS 廠家抓緊對控制器及交換機的日志事件,招集資深人員對整個事件做更深入的分析,找出事件的真正原因。5 月9 日交換機檢測結果出來,認為交換機軟硬件均沒問題。于是再次招開分析會,確定先采取兩條措施:1)對交換機進行流量限制,以抑制廣播包風暴的發(fā)生;2)將機爐現(xiàn)在的一個大環(huán)網(wǎng)結構改為機爐分開的兩個小環(huán)網(wǎng)結構,以減小事故發(fā)生的危害程度。這個兩措施實施前后,請電力科學研究院在停運的機組上用網(wǎng)絡攻擊儀分別進行試驗,從試驗結果看,措施實施前網(wǎng)絡發(fā)生了大面積癱瘓,而實施后只出現(xiàn)了小部分控制器死機,說明措施實施有一定效果,但并沒有杜絕隱患。
通過進一步的分析及與同類型DCS 系統(tǒng)比較,提出了以下兩條主要措施。
3.2.1 去除自動同步,避免出現(xiàn)在同步退出時,出現(xiàn)數(shù)據(jù)中斷
目前每個控制器中設置的自動同步邏輯,每隔2 秒,Red_ctrl 模塊檢測控制器的狀態(tài),如果發(fā)現(xiàn)同步退出了,發(fā)出一個5 秒的脈沖去同步控制器,此同步指令是90 秒之內(nèi)只能發(fā)出一次。從歐陸控制器的使用要求出發(fā),只有是控制器出現(xiàn)網(wǎng)絡、電源或是其本身出現(xiàn)問題時,才會出現(xiàn)同步退出。退出同步后,應由維護人員檢查故障,確定沒有問題后,才由人為手動同步。因此自動同步一般是不允許設置的。由于T2550V5.0 存在較多的由于通訊中斷產(chǎn)生的同步退出,為了從表面上解決此問題,從09 年11 月增加了自動同步功能。在出現(xiàn)少量控制器退出同步時,自動同步功能沒有產(chǎn)生數(shù)據(jù)中斷,從表面來看沒有出現(xiàn)問題,經(jīng)過檢查,在本次事故之前,也有少量的控制器出現(xiàn)退出同步,又被自動同步,出現(xiàn)短暫的通訊中斷,由于數(shù)量少,沒有在畫面數(shù)據(jù)上表現(xiàn)出來 (例如:20110529,9 點左右,20 號控制器) 。在本次故障過程中,大量控制器出現(xiàn)退出同步,又被自動同步邏輯強制進行同步,大量的通訊沖擊造成了數(shù)據(jù)中斷。去除自動同步之后,去除了通訊沖擊,可以保證在出現(xiàn)同步退出時,不出現(xiàn)數(shù)據(jù)中斷現(xiàn)象。
3.2.2 升級控制器軟件,盡量減少通訊失敗,避免同步退出
通訊失敗導致同步退出的問題,在T2550V2.2 版本是沒有的,即使出現(xiàn)短暫的通訊中斷,控制器也不會出現(xiàn)同步退出。為了提高控制器對網(wǎng)絡診斷的安全性,歐陸從T2550V4.0 開始增加了控制器對網(wǎng)絡數(shù)據(jù)的診斷功能,在發(fā)現(xiàn)網(wǎng)絡通訊故障時,會主動切換主從控制器,將主控制器退出運行,從控制器接管工作。此項功能的增加反而造成T2550 網(wǎng)絡的穩(wěn)定性下降,為此歐陸公司后來又推出了V5.0、V6.0、V7.0、V7.2 版本,該廠目前用的是V5.0,比較同為NETWORK-6000 系統(tǒng)的其它電廠使用情況,發(fā)現(xiàn)V7.0 版本使用穩(wěn)定,故確定將該廠控制器軟件版本也升級到V7.0。
由于網(wǎng)絡故障的原因很多,為進一步提高DCS 系統(tǒng)的可靠性,盡可能避免再次發(fā)生類似事件,在以上主要措施基礎上,還采取了一些其它的改進措施。以下為全部措施統(tǒng)計:1)交換機網(wǎng)口帶寬設置限定:掛控制器網(wǎng)口限為10%,掛上位機網(wǎng)口限20%,環(huán)口不限;2)改造網(wǎng)絡結構,將目前機爐大環(huán)改為機爐兩個小環(huán),減小故障發(fā)生時的危害程度;3)去除控制器自動同步功能,并將同步時間由2s 延長到10s;4)控制器系統(tǒng)軟件升級為7.0 版本,提高控制器運行的穩(wěn)定性;5)調(diào)整數(shù)據(jù)通訊的優(yōu)先級,將數(shù)據(jù)供給改為高優(yōu)先級,即SFC 周期改為task4 770ms,確保故障發(fā)生時,現(xiàn)場數(shù)據(jù)優(yōu)先通行;6) sis 機優(yōu)化。Sis 功能移至工程師站,原sis 站單做his 站,his 數(shù)據(jù)由從控制器直接提取改由從服務器提取,以減輕網(wǎng)絡負荷,并升級歷史曲線軟件;7)報警功能做調(diào)整,減輕各工控機的負荷,解決服務器和操作員站易死機或卡澀現(xiàn)象;8)升級lintools 軟件;9)升級交換機軟件;10)所有工控機增加1G 內(nèi)存,提高工控機性能;11)改善機柜強制通風,確??怀瑴剡\行;12)對系統(tǒng)狀況進行跟蹤,定期安排人員來查看各種日志和記錄,判定系統(tǒng)性能。
該DCS 控制系統(tǒng)經(jīng)過上述優(yōu)化措施后,再次請相關單位進行性能測試,在測試過程中系統(tǒng)運行正常,未出現(xiàn)錯誤信息,各控制器所屬網(wǎng)段的負荷率均在允許范圍內(nèi)。同時經(jīng)兩年多的實際運行驗證,DCS 系統(tǒng)再未發(fā)生過服務器數(shù)據(jù)丟失,操作員站畫面實時數(shù)據(jù)顯示為“???”號,無法對現(xiàn)場設備進行監(jiān)控的現(xiàn)象,這充分證明了優(yōu)化措施取得了預期的效果,為該廠機組的安全穩(wěn)定運行提供了有力保障,同時也為今后處理類似事件提供了很好的經(jīng)驗借鑒。
[1]高金源,夏潔.計算機控制系統(tǒng).北京:清華大學出版社,2007.
[2]王常力,羅安.分布式控制系統(tǒng)(DCS)設計與應用實例.北京:電子工來出版社,2004.
[3]姜學軍.計算機控制技術.北京:清華大學出版社,2006.