一起DCS控制系統網絡異常的分析與處理

李思平

淮南礦業集團電力公司，安徽淮南 232072

1 案例描述

某電廠DCS 控制系統2011 年4 月18 日下午5 點10 左右，運行人員發現1#機組所有操作站中數據丟失，畫面顯示為“???”，但現場設備運行正常。維護人員到達后去電子設備間檢查，發現部分控制器退出同步，維護人員試圖手動同步，發現42 控制器出現X 燈常亮故障。去機柜中檢查發現網絡中原先設定為master 狀態交換機（IP：192.168.11.211）指示燈顯示異常，master 燈從常亮變為閃爍。而同機柜的另一臺交換機（IP：192.168.11.212）master 燈由不亮變化為閃爍狀態。維護人員對服務器做重起，但無效果；對IP：192.168.11.212 的交換機做重新上電處理，網絡恢復了一小段時間運行后再次出現上述情況。經電話咨詢DCS 廠家技術人員，確定把此臺交換機換下，并撥出42 控制器后，網絡恢復正常。5 月31 日下午13：37 前后，1#機組所有操作員站中再次出現部分數據變成“???”，但約一分鐘后自動恢復。

2 原因分析

2.1 4 月18 日網絡異常的分析

網絡出現數據采集中斷時，設定為master 狀態交換機（IP：192.168.11.211）指示燈顯示異常，master 燈從常亮變為閃爍，而同機柜的另一臺交換機（IP：192.168.11.212）master 燈由不亮變化為閃爍狀態。

通常，常態下的環網的狀態是：網絡中有一臺交換機設置為master，在網絡構建成環時，此臺交換機上的master 燈常亮，并且在web 頁面中也可以觀察到。環網中的其他交換機master 燈都不亮，web 頁面觀察到的都是slave 狀態。一般，master 燈變為閃爍狀態只有在環網處于開環狀態時才會出現。而同時出現兩臺交換機master 燈閃爍，有兩種可能性：1）網絡中有兩臺交換機人為設置成了兩個master。（這個可以排除）；2）網絡中出現異常的數據包，或交換機出現了硬件故障時，網絡拓撲發成了改變。從交換機的日志文件中可以看到，在出現問題的時間點，交換機在短時間內記錄了多次拓撲更改信息。從部分控制器保存的事件日志文件能提取到如下記錄：“! 18/04/11 11：01：54 (0x5C004A16) 81F6 Entering Ethernet rate Protection UDP broadcast storm”，可以看出網絡確實產生UDP 數據包廣播風暴！

從交換機和控制器的這些記錄信息，可以發現在數據采集異常時，環網在頻繁的切換狀態，網絡中在那個時間段很有可能存在著很大的數據流量，即發生了網絡風暴，從而使整個網絡的通訊不暢，數據無法正常傳輸，致使操作站畫面數據顯示為“???”。但究竟什么原因誘發了網絡風暴，還有待進一步的試驗分析。

2.2 5 月31 日網絡異常的分析

通過對控制器日志的分析，發現本次異常時鍋爐和汽機網段共有13 對控制器出現中斷，最早出現中斷的控制器是T2550_16，中斷時間是13：37：48，最后恢復的控制器是T2550_30,時間是13：38：28。總體故障時為40 秒。出現數據中斷的控制器都出現了同步退出，退出時間大概在數據中斷前12 秒左右，這13 對控制器的事件記錄中都出現了由數據中斷引起的冗余切換過程。

2.3 兩次網絡異常的比較

5 月31 日的故障與4 月18 日的現象有相似之處，都是在操作站上數據顯示為“???”。但5 月31 日出現“???”的范圍較小，涉及13 對控制器，時間較短，持續40 秒。5 月31日的故障的直接原因與4 月18 日不同。4 月18 日所有的控制器的記錄都顯示出網絡的中斷和堵塞，使得控制器向操作員的數據通訊中斷，畫面顯示都為“???”號。而5 月31 日的故障，沒有任何與網絡中斷和堵塞的記錄。僅為個別通訊中斷引起控制器的同步退出的記錄。同步退出過程，再次強制同步，造成網絡負荷短時加重，13 對控制器上傳數據故障，造成相關數據在畫面上顯示為“???”。

3 對策與性能優化

3.1 4 月18 日網絡異常后所采取的主要措施

4 月18 日異常發生后，該廠邀請相關電力科學研究院專家、DCS 廠家及交換機廠家技術人員一起立即在現場招開了事故分析會。確定：1）立即將交換機送臺灣的生產廠家進行軟、硬件檢測；2）DCS 廠家抓緊對控制器及交換機的日志事件，招集資深人員對整個事件做更深入的分析，找出事件的真正原因。5 月9 日交換機檢測結果出來，認為交換機軟硬件均沒問題。于是再次招開分析會，確定先采取兩條措施：1）對交換機進行流量限制，以抑制廣播包風暴的發生；2）將機爐現在的一個大環網結構改為機爐分開的兩個小環網結構，以減小事故發生的危害程度。這個兩措施實施前后，請電力科學研究院在停運的機組上用網絡攻擊儀分別進行試驗，從試驗結果看，措施實施前網絡發生了大面積癱瘓，而實施后只出現了小部分控制器死機，說明措施實施有一定效果，但并沒有杜絕隱患。

3.2 5 月31 日網絡異常后所采取的主要措施

通過進一步的分析及與同類型DCS 系統比較，提出了以下兩條主要措施。

3.2.1 去除自動同步，避免出現在同步退出時，出現數據中斷

目前每個控制器中設置的自動同步邏輯，每隔2 秒，Red_ctrl 模塊檢測控制器的狀態，如果發現同步退出了，發出一個5 秒的脈沖去同步控制器，此同步指令是90 秒之內只能發出一次。從歐陸控制器的使用要求出發，只有是控制器出現網絡、電源或是其本身出現問題時，才會出現同步退出。退出同步后，應由維護人員檢查故障，確定沒有問題后，才由人為手動同步。因此自動同步一般是不允許設置的。由于T2550V5.0 存在較多的由于通訊中斷產生的同步退出，為了從表面上解決此問題，從09 年11 月增加了自動同步功能。在出現少量控制器退出同步時，自動同步功能沒有產生數據中斷，從表面來看沒有出現問題，經過檢查，在本次事故之前，也有少量的控制器出現退出同步，又被自動同步，出現短暫的通訊中斷，由于數量少，沒有在畫面數據上表現出來 (例如：20110529，9 點左右，20 號控制器) 。在本次故障過程中，大量控制器出現退出同步，又被自動同步邏輯強制進行同步，大量的通訊沖擊造成了數據中斷。去除自動同步之后，去除了通訊沖擊，可以保證在出現同步退出時，不出現數據中斷現象。

3.2.2 升級控制器軟件，盡量減少通訊失敗，避免同步退出

通訊失敗導致同步退出的問題，在T2550V2.2 版本是沒有的，即使出現短暫的通訊中斷，控制器也不會出現同步退出。為了提高控制器對網絡診斷的安全性，歐陸從T2550V4.0 開始增加了控制器對網絡數據的診斷功能，在發現網絡通訊故障時，會主動切換主從控制器，將主控制器退出運行，從控制器接管工作。此項功能的增加反而造成T2550 網絡的穩定性下降，為此歐陸公司后來又推出了V5.0、V6.0、V7.0、V7.2 版本，該廠目前用的是V5.0，比較同為NETWORK-6000 系統的其它電廠使用情況，發現V7.0 版本使用穩定，故確定將該廠控制器軟件版本也升級到V7.0。

3.3 進一步的優化措施

由于網絡故障的原因很多，為進一步提高DCS 系統的可靠性，盡可能避免再次發生類似事件，在以上主要措施基礎上，還采取了一些其它的改進措施。以下為全部措施統計：1）交換機網口帶寬設置限定：掛控制器網口限為10%，掛上位機網口限20%，環口不限；2）改造網絡結構，將目前機爐大環改為機爐兩個小環，減小故障發生時的危害程度；3）去除控制器自動同步功能，并將同步時間由2s 延長到10s；4）控制器系統軟件升級為7.0 版本，提高控制器運行的穩定性；5）調整數據通訊的優先級，將數據供給改為高優先級，即SFC 周期改為task4 770ms，確保故障發生時，現場數據優先通行；6） sis 機優化。Sis 功能移至工程師站，原sis 站單做his 站，his 數據由從控制器直接提取改由從服務器提取，以減輕網絡負荷，并升級歷史曲線軟件；7）報警功能做調整，減輕各工控機的負荷，解決服務器和操作員站易死機或卡澀現象；8）升級lintools 軟件；9）升級交換機軟件；10）所有工控機增加1G 內存，提高工控機性能；11）改善機柜強制通風，確保卡件不超溫運行；12）對系統狀況進行跟蹤，定期安排人員來查看各種日志和記錄，判定系統性能。

4 結論

該DCS 控制系統經過上述優化措施后，再次請相關單位進行性能測試，在測試過程中系統運行正常，未出現錯誤信息，各控制器所屬網段的負荷率均在允許范圍內。同時經兩年多的實際運行驗證，DCS 系統再未發生過服務器數據丟失，操作員站畫面實時數據顯示為“???”號，無法對現場設備進行監控的現象，這充分證明了優化措施取得了預期的效果，為該廠機組的安全穩定運行提供了有力保障，同時也為今后處理類似事件提供了很好的經驗借鑒。

[1]高金源，夏潔.計算機控制系統.北京：清華大學出版社，2007.

[2]王常力，羅安.分布式控制系統（DCS）設計與應用實例.北京：電子工來出版社，2004.

[3]姜學軍.計算機控制技術.北京：清華大學出版社，2006.