DCS典型故障原因分析與防范對策

一、前 言
      DCS在國內大型火力發電機組上應用始于上世紀八十年代后期，到目前為止只有二十幾年的運行經驗。華能電力股份有限公司整套引進350MW機組，投資建設的南通、上安、大連、福州電廠是早應用DCS的電廠。
      隨著火力發電機組自動化水平的不斷提高，單元機組DCS系統的功能范圍不斷擴大。近兩年新建和改造機組的單元控制室內除用于緊急停機、停爐用的后備手操外，其余操作全部依賴于DCS。因而，由于DCS本身故障引起的跳機現象時有發生。所以，如何提高DCS的可靠性作為一個重要課題擺在了從事熱工自動化工作的各位人士的面前。
      由于工作關系，有機會到過三十多家火電廠收資、交流或驗收，接觸到應用DCS的100～700MW單元機組近八十臺，幾乎覆蓋了國內應用過的所有類型的DCS，對各種類型的DCS發生的故障有較多的了解，無論是進口DCS，還是國產DCS，盡管在原理、結構上迥異，包含的子系統也不一樣多，但都或多或少地出現過一些相類似的故障，通過對典型故障進行深入細致地分析，找出故障的真正原因，舉一反三，制定出防范措施，并正確地實施，可以很好地防止此類DCS故障的重復發生。本文列舉了幾個典型的DCS故障案例，供從事熱工技術管理及檢修人員參考。

二、案例一 控制器重啟引發機組跳閘
2.1 事件經過
      2001年11月1日，A電廠4號機組停機前有功負荷270MW，無功96MVar，A、B勵磁調節器自動并列運行，手動50Hz柜跟蹤備用。
      14時26分，事故音響發出，發電機出口開關、勵磁開關跳閘，"調節器A柜退出運行"、"調節器B柜退出運行"等報警信號發出，機組解列。對ECS控制系統檢查、試驗，發現#14控制器發生故障已離線，與之冗余的＃34控制器發生重啟，更換了#14和＃34控制器主機板后，機組重新啟動，不久，發變組與系統并列。
2.2原因分析
      根據歷時數據分析，13時31分，#14控制器硬件故障而離線運行，熱備用的#34控制器自動由輔控切為主控。14時26分，#34控制器由于通訊阻塞引起"WATCHDOG"誤判斷，致使控制器重啟。由于控制器控制勵磁調節器的方式為長信號，沒有斷點保護功能，#34控制器重啟后，不能自動回到斷點前的狀態，導致A、B調節器自動退出運行，手動50Hz柜自動投入。由于發電機失磁，發電機端電壓下降，導致廠用電源電壓降低，手動50Hz柜輸出電壓繼續降低，手動50Hz柜投入后發電機沒有脫離失磁狀態，直至切除勵磁裝置，造成發電機失磁保護動作，發電機出口開關跳閘。
#14控制器和#34控制器控制發變組設備，包括廠用電切換的備自投繼電器接點BK，#34控制器重啟后，BK自動復位，繼電器接點斷開，BK投到退出位置，造成6KV電源開關6410、6420開關自投不成功。
2.3防范措施
2.3.1將故障控制器更換。后來制造廠確認這一批主板晶振存在問題，同意免費更換，利用停機機會更換4號機組所有控制器主板。
2.3.2增加任一控制器、I/O卡、通訊卡離線報警功能。
2.3.3程序內部"WATCHDOG"的時間設置太短，易造成誤判斷，對所有控制器進行軟件升級。
2.3.4調節器AQK、BQK方式開關和廠用電備自投BK開關組態圖增加斷點保護功能，防止控制器自啟動后，勵磁調節器和廠用電自投開關退出運行。
2.3.5檢查ECS系統的所有組態，對存在以上問題的邏輯進行修改。
2.3.6調節器廠家，使調節器內部可以作到運行狀態自保持，將控制器控制調節器的方式改為短脈沖信號控制。
2.6.7在ECS內增加手動50Hz柜輸出電壓自動跟蹤功能。

三、案例二在線傳代碼致使機組解列
3.1事件經過
      2002年7月12日，B電廠＃5機組監盤人員發現機組負荷從552MW迅速下降，主汽壓力突升，汽輪機調門開度，由原來的20%關閉到10%并繼續關閉，高調門繼續迅速關閉至0%，機組負荷降低至5MW，運行人員被迫手動緊急停爐，汽輪機跳閘，發電機解列。
3.2原因分析
      DCS與汽輪機控制系統分別由兩家國外公司制造，兩系統差異較大，通訊問題沒有很好地解決，存在一些難以消除的缺陷。熱控人員在DCS工程師站上向負責DCS與汽輪機控制系統通訊的PLC傳送通訊代碼時，DCS將汽輪機閥位限制由正常運行中的120%修改為0.25%，造成汽機1、2、3號調門由20%關閉至0%，機組負荷由552MW迅速降至5MW。
3.3 防范措施
3.3.1機組運行期間，禁止DCS傳代碼工作。
3.3.2機組停運期間，DCS傳代碼時，應經運行班長同意，并做好安全措施。
3.3.2將DCS操作員站對汽輪機控制系統操作員站畫面進行操作的功能閉鎖，但在DCS操作員站上仍能監視到汽輪機控制系統的信息。

四、案例三 DCS工作站時鐘混亂引發DCS失靈
4.1事件經過：
2001年 8月3日，C電廠2號機組負荷200MW，#1至#9控制器處于控制方式，#51至#59控制器處于備用方式。8時23分，各控制器依次發NTP報警，歷史站報警窗口顯示如下：
Aug 3 08：23：50 drop7 ＜7＞ NTP：too many recvbufs allocated（30）
Aug 3 08：23：50 drop4 ＜7＞ NTP：too many recvbufs allocated（30）
………
      8時26分，#2控制器脫網，#52控制器切為主控；11時05分，#52控制器脫網；13時39分，#7控制器脫網，#57控制器切為主控，在#7控制器向#57控制器切換瞬間，由該控制器控制的A、B磨煤機跳閘；15時11分，#9控制器脫網，#59控制器切為主控，在#9控制器向#59控制器切換瞬間，由該控制器控制的E磨煤機跳閘；15時51分，#1控制器脫網，#51控制器切為主控，在#1控制器向#51控制器切換瞬間，由該控制器控制的A引風機動葉被強制關閉。
      15時22分，重啟操作員站drop213（備用時鐘站），NTP報警未消失；15時35分，重啟歷史站，NTP報警未消失；15時59分，重啟工程師站（主時鐘站），NTP報警基本消失；16時09分，重啟歷史站，16時30分，系統恢復正常。
4.2原因分析
      NTP軟件的作用就是維持網絡時鐘的統一，主時鐘設置在工程師站上，備用時鐘設置在操作員站上。控制器脫網原因為主時鐘與備用時鐘不同步造成系統時鐘紊亂，從而造成NTP報警導致控制器脫網。
      NTP故障的原因有兩種可能，一種是主頻為400MHz工作站，不同于1號機組的270MHz（SUN公司在400MHz工作站上對操作系統有較大改進）工作站，2號機組所用的1.1版本軟件在400MHz工作站上未測試過，不能確保1.1版本軟件在此配置上不出問題。另一種是主時鐘與備用時鐘不同步，在8月3日控制器脫網后，曾發現Drop214的時鐘比其它站快了2秒, 當時Drop214的畫面調用速度較慢，經重啟后正常，并且NTP時鐘報警是在系統運行73-75天左右才出現的，估計是系統時鐘偏差積累到一定程度后導致主、備時鐘不同步，而引起系統時鐘紊亂，zui終導致控制器脫網。
      NTP時鐘故障使控制器脫網，處理不及時會使報警的控制器依次脫網，從而導致整個控制系統癱瘓。
4.3防范措施
4.3.1根據本次故障現象，制造商將軟件由1.1版本升級為1.2版本。
4.3.2為確保控制系統可靠運行，定期重啟主時鐘和備用時鐘站。
4.4 D電廠5號機組在2002年試運期間曾發生DCS時鐘與GPS時鐘不同步，引發DCS操作員站失靈事件。由于網 上傳送的數據均帶時間標簽，時鐘紊亂后會給運行機組帶來嚴重后果，基本情況與C電廠2號機組類似。采取的措施是暫時斷開GPS時鐘，待軟件升級和問題得到根本解決后，再恢復GPS時鐘。

五、案例四 CABLETRON集線器總通訊板故障導致MFT誤動
5.1事件經過
      2002年 1月1日，E電廠1號機組負荷250MW，#51至#59控制器處于控制方式，#1至#9控制器處于備用方式，A、B、C、E、F磨煤機運行。18時57分，所有磨煤機跳閘（直吹爐），MFT動作，機組跳閘。
5.2原因分析
      經分析，確認是DCS集線器的總通訊板故障，導致連在其上的所有控制器同時發生切換，在控制器向備用控制器切換過程中，#57、#58、#59控制器PK鍵信號誤發（這三個控制器屬FSSS系統），即CRT上"磨煤機跳閘按鈕"的跳閘和確認指令同時發出，使所有磨煤機跳閘，導致MFT動作。
5.3防范措施
CABLETRON集線器屬于早期產品，目前在市場上購買備件已比較困難，采用CISCO集線器來取代CABLETRON集線器。

六、案例五 冗余控制器失靈造成機組跳閘
6.1事件經過
      2003年3月23日，F電廠＃3機組停機前電負荷115MW，爐側主汽壓9.55MPa，主汽溫537℃，主給水調節門開度43%，旁路給水調節門開度47%（每一條給水管道均能滿足負荷的供水），汽包水位正常；其它各參數無異常變化。
      監盤人員發現鍋爐側部分參數顯示異常，各項操作均不能進行，同時爐側CRT畫面顯示各項自動已處于解除狀態。調自檢畫面發現#3控制器離線，#23控制器處于主控狀態。運行人員立即熱工人員處理，同時借助汽機側CRT畫面監視主汽壓、主汽溫，并對汽包電接點水位計和水位TV加強監視，主汽壓在9.0～9.6MPa波動、主汽溫在510～540℃波動、汽包水位在+75～-50mm波動，維持運行。
      幾分鐘后，熱工人員趕到現場，發現#3控制器離線、#23控制器為主控狀態，但#23控制器主控下的I/O點（汽包水位、主汽溫、主汽壓、給水壓力、等）均為壞點，自動控制手操失靈。經過多次重啟，#3控制器恢復升為主控狀態。在釋放強制的I/O點時，監盤人員發現汽包水位急劇下降，就地檢查發現旁路給水調節門在關閉狀態，手動搖起三次均自動關閉，汽包水位TV和顯示表監視不到水位，手動停爐、停機。
6.2原因分析
      根據能追憶到的歷史記錄分析，可以推斷#3控制器（主控）故障前，#23控制器（輔控）因硬件故障或通訊阻塞，已經同I/O總線失去了通訊。當#3控制器因主機卡故障離線后，#23控制器升為主控，但無法讀取I/O數據，造成參與汽水系統控制的一對冗余控制器同時失靈，給水自動控制系統失控，汽包水位保護失靈。在新更換的＃3控制器重啟成功后釋放強制點的過程中，DCS將旁路給水調節門指令置零（邏輯如此設計是為了在控制器故障時，運行機組向更安全的方向發展），關閉旁路調節門。而旁路調節門為老型號的閥門，相當于解除了自保持的電動門（接受脈沖量信號），切手動時不能做到電氣脫扣，因此，緊急情況下不能順利打開，造成汽包缺水。
6.3防范措施
6.3.1更換#3、#23控制器主機板，同時考慮增加主機板的備品儲備。
6.3.2增加通訊卡，使控制器與I/O卡之間的通訊為冗余的。
6.3.3對所有控制器、I/O卡、BC卡的通訊進行監測，增加脫網邏輯判斷功能，生成報警點并進行歷史記錄。一旦控制器工作異常，可及時報警并處理。
6.3.4增加控制器超溫報警功能，在控制器出現故障之前可以采取措施，將事故消滅在萌芽之中。
6.3.5汽包水位等重要調節、保護系統的輸入信號，一般應為三路相互獨立的信號，通過分流器將這三路信號變成六路信號，分別進六塊端子板和AI卡件，送入兩對控制器，一對控制器用于調節、保護，另一對控制器只參與保護。這樣可以很好地解決一對冗余的控制器同時故障時，重要保護失靈的問題。
6.3.6更換重要自動調節系統的執行機構，使之具有完善的操作功能。
6.3.7 DCS失靈時，若主要后備硬手操或監視儀表不能維持正常運行，運行人員應立即停機、停爐。
6.3.8關閉MIS系統接口站中的所有硬盤共享功能，確保DCS系統同MIS系統只具備單向通訊功能。

七、結 束 語
      以上案例只是在一定范圍內發生的DCS故障的幾個比較典型案例，即使將這些案例的反措全部應用到每套DCS中去，也不能避免DCS故障的再次發生。在更大范圍內，由DCS故障引發的停機事件也不會太少，有些事件肯定會涉及到控制器負荷率高、網絡通訊負荷率高等問題，由于目前還沒有有效的手段監測控制器負荷率和網絡通訊負荷率，找出這類事件的根本原因還有一定的難度，因此，消除這類缺陷也比較困難。
      要防止各類事故的發生，必須從源頭-DCS的設計和制造抓起，將國內應用的各種類型的DCS發生過的故障情況反饋到有關部門，由有關部門召集專家進行分析研究，制定出相應的標準、制度和反措，強制執行，并形成一個大的閉環質量控制體系，長期良性循環。