2．1．3．1 現(xiàn)象
第3次公用系統(tǒng)服務器死機現(xiàn)象與前2次相同，排除了上述原因后，結(jié)束服務器內(nèi)相關(guān)進程重新啟動服務器后正常。所以認為死機原因為相關(guān)進程內(nèi)部數(shù)據(jù)設置錯誤，不能滿足現(xiàn)場正常運行條件．相關(guān)服務器進程發(fā)生數(shù)據(jù)溢出，最終導致服務器運算速度變慢并死機。根據(jù)分析。最終經(jīng)西門子公司遠程登錄系統(tǒng)檢查。發(fā)現(xiàn)服務器alarm container（AC）進程設置容量為128 Mbytes，而調(diào)試過程中報警點比較多，容量為145 Mbytes，已經(jīng)超過128 Mbytes。
2．1．3．2 解決方法
按照德國西門子建議將AC進程容量修改為256 Mbytes。但本次修改未能根本解決系統(tǒng)死機的問題。
2．1．4 第4次死機
2．1．4．1 現(xiàn)象
第4次DCS系統(tǒng)再次發(fā)生通信故障，故障現(xiàn)象為機組各個AP不定時發(fā)生通信故障，故障過程時間不等，一般為2～10 S，最長時間為4 rain，之后系統(tǒng)恢復正常。在故障期間，DCS系統(tǒng)失去對現(xiàn)場設備的監(jiān)視和操作功能，并且不能保證保護聯(lián)鎖的正確動作。經(jīng)過現(xiàn)場分析，造成的原因仍是內(nèi)部設定問題，發(fā)現(xiàn)服務器CC進程容量為128 Mbytes（容量不足），造成服務器運算速度變慢。
2．1.4．2 解決方法
按照德國西門子建議將CC進程容量修改為256 Mbytes。但本次修改未能徹底解決系統(tǒng)死機問題。
2．1.5 第5次死機
2．1．5．1 現(xiàn)象
第5次系統(tǒng)死機現(xiàn)象為DCS10一l機柜AB、AC兩排卡件中所有DI卡件系統(tǒng)認為未安裝，導致該機柜控制的現(xiàn)場設備失去控制，即定子冷卻水泵和C給水泵油泵發(fā)生自啟?，F(xiàn)象。經(jīng)過分析，可能是更換該機柜內(nèi)卡件未復位造成的，也有可能為該AP外供電方式模擬量信號大范圍跳動導致AP運算變慢造成的。
2．1．5．2 解決方法
對機柜內(nèi)更換任意卡件時均進行復位處理后，該問題再未發(fā)生。
2．1．6 第6次死機
2．1．6．1 現(xiàn)象
第6次系統(tǒng)發(fā)生嚴重死機，現(xiàn)象為系統(tǒng)報警窗故障，且畫面切換遲緩，畫面顯示點均為壞點，操作員畫面無法對設備監(jiān)視操控。當時的處理方法在服務器上重啟AC進程后系統(tǒng)恢復正常。幾天后DCS再次發(fā)生嚴重的死機事故，所有操作員站和工程師站全部失去功能。經(jīng)過觀察，當時系統(tǒng)服務器個別進程超出其被分配的動態(tài)內(nèi)存空間，由于這些進程的溢出導致服務器CPU負荷率大幅度上升，系統(tǒng)處理數(shù)據(jù)的過程變得極其緩慢，最終導致系統(tǒng)癱瘓。經(jīng)重新啟動服務器后，系統(tǒng)恢復正常，但未能從根本上解決該問題。
2．1．6．2 解決方法
經(jīng)過以上2次事故．現(xiàn)場決定暫時停止機組試運。針對以上問題，根據(jù)以往調(diào)試經(jīng)驗，提出了如下解決方法：
?。?）對外供電模擬量輸入信號增加隔離器，保證信號的穩(wěn)定性，大幅度減少由于模擬量信號劇烈波動造成對系統(tǒng)資源的占用；
?。?）改變部分信號、邏輯系統(tǒng)采樣時間和分辨率，減少系統(tǒng)負荷；
?。?）限制操作員站和工程師站同時打開畫面的數(shù)量，減少系統(tǒng)負荷；
?。?）對系統(tǒng)報警點進行整理，刪除無用的報警點，優(yōu)化報警復位功能，減少系統(tǒng)負荷。
實施以上各項措施后，各個進程占用容量大幅度減少，如AC進程由最高的312 Mbytes減少到120 Mbytes左右。根據(jù)德國西門子的意見又對系統(tǒng)內(nèi)5個進程的容量進行了擴充，隨后對機組進行了點火啟動，DCS未再發(fā)生嚴重的死機、系統(tǒng)通信阻塞中斷等現(xiàn)象，并順利完成吹管。寄存器參數(shù)調(diào)整為：AC、CC為384 Mbytes （原始默認值為128Mbytes），ARC 196 Mbytes （原始默認值為64Mbytes），RC 128 Mbytes （原始默認值為64Mbytes），PDS 256 Mbytes （原始默認值為128Mbytes）。
德國西門子總部T-3000開發(fā)組對國華準電現(xiàn)場數(shù)據(jù)進行分析研究，并針對本工程對系統(tǒng)提出的要求，專門編寫了系統(tǒng)軟件升級包，對3‘號、4號機組DCS進行了軟件升級，升級后直到2臺機組168h結(jié)束，該系統(tǒng)再未發(fā)生系統(tǒng)軟件死機事故。
2．2 調(diào)試期間系統(tǒng)其他故障原因分析以及處理
2．2．1 3號、4號機組DCS系統(tǒng)功能塊設計錯誤
發(fā)現(xiàn)3號機組在沖車階段DCS系統(tǒng)部分自動控制系統(tǒng)的PID調(diào)節(jié)器工作不正常，調(diào)節(jié)器在DCS內(nèi)部被集成為CCTRL功能塊。該功能塊具備PID計算以及操作器的功能。該問題具體表現(xiàn)為：投入自動后一段時間，發(fā)生調(diào)節(jié)器輸出大幅度變動狀況，變動范圍為0～100％，如圖1所示。圖中黑色部分為PID輸入偏差，該數(shù)據(jù)幾乎不變；藍色為PID調(diào)節(jié)器輸出．瞬間突增至100％ ；紅色為執(zhí)行機構(gòu)反饋跟隨PID指令。以上現(xiàn)象主要發(fā)生在軸封的3套自動中。隨后對這3套自動邏輯進行了檢查，根據(jù)歷史趨勢，發(fā)現(xiàn)以上現(xiàn)象發(fā)生時PID調(diào)節(jié)器輸入偏差幾乎不變．且自動控制原理十分簡單，沒有微分以及前饋等作用，從控制原理來講不應發(fā)生以上現(xiàn)象，所以判斷為該PID功能塊設計存在問題。
通知南京西門子現(xiàn)場服務人員進行處理，最終確認由于PID調(diào)節(jié)器微分環(huán)節(jié)設計有問題導致輸出突跳。之后德國西門子對該功能塊進行了在線升級。升級后該問題再未發(fā)生。
2．2．2 DCS系統(tǒng)DI通道的問題
在調(diào)試過程中發(fā)現(xiàn)每個開關(guān)量輸入通道（DI）都配有1個0．2 A的玻璃管保險，在機組運行過程中如果保險損壞且不能被及時發(fā)現(xiàn)，重要的保護聯(lián)鎖信號將不能傳遞到DCS，造成保護拒動，給機組設備帶來災難性的后果。發(fā)現(xiàn)這個安全隱患后，調(diào)試人員將2臺機組共400余塊DI卡件FIM卡進行了更換，對所有DI卡件通道重新進行了傳動。該卡件需要進行經(jīng)常性巡視，觀察卡件內(nèi)保險報警顯示燈，一經(jīng)發(fā)現(xiàn)有損壞，立即進行更換，保證機組在運行過程中不發(fā)生保護拒動。
2．2．3 模擬量信號隔離問題及處理
在調(diào)試中發(fā)現(xiàn)，外供電模擬量輸入信號與DCS的AI卡件不匹配，使得測量信號在大范圍內(nèi)突跳，無法使用，且嚴重影響該信號所在機柜內(nèi)CPU的運算速度，導致系統(tǒng)運算速度變慢，機柜內(nèi)其他正常信號采集不到，導致DCS系統(tǒng)機柜內(nèi)CPU死機，失去對就地設備的控制，使就地設備發(fā)生自啟?，F(xiàn)象。該問題還大量占用系統(tǒng)資源，DCS系統(tǒng)AC等進程占用容量急劇增加，導致系統(tǒng)死機不可用。依據(jù)以往調(diào)試經(jīng)驗，在DCS系統(tǒng)AI卡件輸入側(cè)加入了信號隔離器，2臺機組共增加雙通道隔離器322個．徹底消除了該缺陷。
3 調(diào)試效果
在準電調(diào)試過程中，通過對西門子公司新研制的DCS系統(tǒng)的優(yōu)化，實現(xiàn)了機組168h結(jié)束時，熱控系統(tǒng)各項指標均達到優(yōu)良，DCS系統(tǒng)能完全適應現(xiàn)場應用要求。實現(xiàn)了2臺機組168h結(jié)束后連續(xù)穩(wěn)定運行100d以上。
參考文獻
[1]羅穎堅．西門子TELEPERM XP分散控制系統(tǒng)在臺山電廠的設計應用【J】．廣東電力，2006，（4）．
[2J西門子發(fā)布分散控制系統(tǒng)SPPA T-300qZ]．中國電力，2006，（1O）
（轉(zhuǎn)載）
