dcs控制系統(tǒng)故障及原因研究

1、dcs控制系統(tǒng)故障及原因研究1 d c s在使用過程中遇到的故障案例1 . 1案例12 0 0 8年9月29日，#1機組負荷6 0 0 mw, 機組處于ccs控制模式及agc投入方式。#1機組突然 出現(xiàn)操作員站部分畫面變粉紅色、參數(shù)檢測不到、機組負荷 等參數(shù)無法控制、汽機d eh控制器b rc狀態(tài)報警等現(xiàn) 象。經(jīng)現(xiàn)場檢查發(fā)現(xiàn)，#1機組deh系統(tǒng)控制柜4號、5 號2個主備控制器同時出現(xiàn)故障報警，2模件狀態(tài)燈同時綠 閃，4號模件狀態(tài)燈1、6燈亮，5號模件狀態(tài)燈7、8燈 亮，2模件皆處于離線狀態(tài)。熱控人員在處理控制器恢復控 制的過程中，模件內(nèi)的運算數(shù)據(jù)自動重置，程序執(zhí)行了初始 狀態(tài)參數(shù)，使汽輪機調(diào)門

2、關閉，2臺汽泵跳閘，最終導致# 1機組跳閘。1 2案例22 0 1 0年1月1 9號，# 2機組在運行中停運，停 運期間準備對2 1號柜3、4號b r c控制邏輯進行下載， 下載完成后在b r c由組態(tài)方式打成執(zhí)行方式時岀現(xiàn)錯誤，無法將b rc打成執(zhí)行方式。對2 1號柜內(nèi)的3、4號brc進行了檢查，發(fā)現(xiàn)3號brc （主）狀態(tài)燈為紅色，同時2、3燈亮，4號b rc正常。對其進行復位操作后重新下 載，邏輯無法下載。此后對3號b rc進行了初始化操作， 重新下載仍然報出相同的錯誤信息無法下載。更換新的br c后重新進行下載仍然無法將其打至執(zhí)行位。此后一段時間 內(nèi)分別對新的brc、原備用b rc進行初

3、始化，將新的b rc與原備用brc調(diào)換位置等，但下載均無法正常進行。同時根據(jù)錯誤信息我們也對控制邏輯進行了檢查，結(jié)果也未 發(fā)現(xiàn)異常。為了徹底排除2 1號柜內(nèi)的通信故障對邏輯下載 的影響，將2 1號柜3、4號b r c移至2號柜5、6號brc處，嘗試在此處看邏輯是否能夠下載，結(jié)果仍然失敗。為了能使# 2機組盡快啟動，決定不再使用原b r c ,更換 2塊新的brc再進行下載，并對控制邏輯進行備份，結(jié)果 下載成功并且順利打至執(zhí)行位，系統(tǒng)恢復正常。1 - 3案例32010年1月20日，# 1機組負荷6 0 02 6mw, ccs自動投入，給水在自動。運行人員發(fā)現(xiàn)21號 柜3號brc （主要控制給水和

4、氣溫）故障，故障導致一、 二級減溫水調(diào)門全開，a、 b給水泵最小流量閥開啟等一系列動作，最終導致主汽溫度4 m i ri下降4運行人員 手動mf t打閘停機，同時熱控人員對故障的b rc進行開 柜門檢查，打開柜門發(fā)現(xiàn)2個卡件狀態(tài)燈都已經(jīng)在離線狀 態(tài)，3號b r c狀態(tài)燈變紅1、2燈亮，4號b r c狀態(tài)燈 7、8燈亮，等機組停下后卡件重新復位打執(zhí)行，恢復正常。2對故障案例的原因分析2 . 1案例1分析熱控人員在處理d e h主輔控制器b r c故障過程 中，對處于離線狀態(tài)的模件置執(zhí)行方式時，系統(tǒng)提示模件進 入錯誤狀態(tài)。在對備用控制器進行初始化后，進行邏輯下載, 仍然不能置于執(zhí)行方式。更換新控制

5、器并完成下載邏輯后， 也出現(xiàn)同樣問題，仍不能使模件置執(zhí)行方式。多次咨詢ab b公司及東方自動控制公司專業(yè)工程師意見，刪除用于汽機 a t c站熱應力計算邏輯的功能塊1 4 3 （塊地址為1 0 0 ）,經(jīng)編譯后，無法完成邏輯下載，多次嘗試仍不能完成 下載任務。在多方研究下，通過gp i編寫了一個引導程序 后，對模件進行下載，結(jié)果成功使模件置執(zhí)行方式。但在控 制器恢復控制的過程中，模件內(nèi)的運算數(shù)據(jù)被自動重置，程 序執(zhí)行了初始狀態(tài)參數(shù)，使汽輪機調(diào)門關閉，2臺汽泵跳閘, 最終導致#1機組跳閘。2 . 2案例2分析 21柜主輔控制器不能夠下載組態(tài)或下載后不能夠切換到執(zhí)行狀態(tài)，經(jīng)檢查，是其模件內(nèi)的組態(tài)不

6、完整。如果進 行組態(tài)下載，下載到1 1 5 3塊時會因故障而中途終止。在 對這2塊模件做17、 16順序初始化后組態(tài)可以正常下 載，模件可以切換到執(zhí)行狀態(tài)。判斷這2塊模件沒有任何故 障，現(xiàn)場不能下載組態(tài)可能是使用了錯誤的初始化順序引 起。模件初始化順序應該是先1 7后1 6操作，其中1 7代表初始化nvram并格式化nvram到廠環(huán)模式；16 代表格式化n vram到i n f i環(huán)模式。而現(xiàn)場使用i n f i環(huán)模式，所以做完1 7初始化后必須做1 6初始化。i nfi環(huán)和廠環(huán)在環(huán)路上傳遞例外報告的一個最大區(qū)別是 廠環(huán)例外報告的功能塊號不能大于1 0 2 3,而i n f i環(huán) 則沒有這個限

7、制。如果使用1 6、1 7錯誤的初始化順序來 初始化模件，那么當下載組態(tài)時遇到第一個塊號大于1 0 2 3的例外報告塊則會因故障而終止下載，經(jīng)檢查組態(tài)1 1 5 3塊號恰恰是第一個塊號大于1 0 2 3的例外報告功能塊， 故障現(xiàn)象與現(xiàn)場反映的現(xiàn)象完全一致。2 . 3案例3分析對#1機組dcs系統(tǒng)以及操作員站、工程師站進行 了必要的檢查，內(nèi)容包括在工程師站composer上做 檢查、在操作員站pgp上做檢查和硬件檢查，以及收集熱工人員對當時情況的反映等?？梢圆槊? 5：c離線,0 6： 0 7恢復正常,中間間隔1 6 m i n 0 ( 1 )從在工程師站c o m p os e f和操作員站p

8、 g p上查到的信息來看，在composer上做exec u t e操作和brc恢復運行的時間基本吻合，可以判斷在c omp os e r上做execute操作后brc恢復正常；(2 )一般主輔控制器組態(tài)是冗余的，當一塊brc出現(xiàn)故障時， 會自動切換至冗余備用控制器，然而當原備用控制器內(nèi)部出 現(xiàn)報警或者錯誤時，還未出現(xiàn)故障（如狀態(tài)燈綠閃、nvr a m數(shù)據(jù)消失而組態(tài)并未消失，即運行可操作而工程師站邏 輯組態(tài)不可操作），這樣主控制器一旦在運行中出現(xiàn)故障， 備用控制器將無法切為主控制器，從而造成主輔控制器同時 報故障。3結(jié)語以上只是abb公司dcs幾個比較典型的案例，除 此之外，在生產(chǎn)中還遇到過很多其他dcs故障，如輸入/ 輸出子模件的故障、端子板的故障等，但這些故障影響范圍 相對較小，而且容易控制。dcs控制系統(tǒng)發(fā)生故障再所難 免，但如何把故障率以及因故障而產(chǎn)生的危險降低，是我們 通