本文針對某電廠#3機組DCS系統出現畫面無回應的異常現象， 分析了具體原因， 提出了對系統組態優化建議、日常操作注意事項及故障出現時採取的措施。
某廠#3機組容量為300MW機組、“W”火焰的燃煤機組， 該機組DCS控制系統採用了和利時公司 Smartpro3.2.0系統。
某天， 該廠#3機組操作員站突然出現畫面無回應， 接著所有操作員站都出現同樣的現象， 致使整個DCS系統處於癱瘓狀態。 檢查發現， 歷史站上運行的工程於兩小時前自動退出運行， 視窗上彈出兩個錯誤對話方塊， 此時歷史站也出現畫面無回應的現象， 看不清錯誤對話方塊上的提示。
在故障之後進行了類比試驗， 發現歷史站的記憶體在不斷的上漲而且不回落， 在FacView內核調試功能表中用page trendqueues命令檢查系統網路繁忙程度， 發現也一直在不斷上漲。
檢查歷史站的趨勢設定檔發現， 趨勢配置點共9345個， 採樣週期都為1S， 歷史趨勢保存時間三個月， 檔保存採用一天保存一個檔的方式。 按照和利時公司的要求， 開始減少歷史趨勢的配置點來觀察歷史站的記憶體使用情況， 發現在趨勢點配置在6000點左右時記憶體的使用穩定在70M至80M之間變化。
可見和利時Smartpro3.2.0 DCS系統能承受的歷史趨勢點配置數就在6000點左右， 超過這個數系統就不穩定且會出現不正常的現象。
該廠DCS單元機組配置只有一台歷史伺服器， 沒有按常規進行冗餘配置， 而且該歷史伺服器還兼作報警及報表伺服器用。
當歷史站運行的工程出現不正常退出時， 操作員不能接收到報警資料， 但操作員站還能檢測到報警伺服器的存在而向其不斷的請求報警資料， 從而造成網路堵塞， 使上層網路癱瘓， 出現畫面無回應的異常現象。
導致畫面無回應的可能原因根據現場的調試及運行經驗， 通常有以下幾種情況會導致和利時Smartpro3.2.0 DCS系統畫面出現無回應的異常現象：
1、各台操作員站、伺服器、介面站等電腦上運行的工程不統一。 對於和利時DCS系統來說， 保證各台電腦上組態工程的一致性，
2、報警伺服器、歷史伺服器運行是否穩定， 也是保證系統穩定運行的關鍵。 當報警、歷史伺服器出現故障時， 會導致各台操作員站不斷的向報警伺服器請求報警資訊， 網路會變得繁忙， 造成網路堵塞現象。
3、歷史站上的歷史趨勢點配置數量不合適， 也會導致系統不穩定。 當歷史趨勢點配置過多歷史站負荷過重， 會導致運行緩慢或歷史站上運行的工程不正常的退出。
4、各台工程師站、操作員站、歷史站、介面站及伺服器上運行的工程設定檔參數
設置不正確， 或各台電腦參數設置不能很好配合， 從而導致畫面無回應或畫面回應速度慢。
5、埠使用衝突， 也會導致所有操作員站畫面無回應。 為了與協力廠商軟體進行通訊， DCS系統根據實際需要定義了一些埠， 但是埠相互衝突， 會導致畫面死機、無法操作。
6、代碼函數錯誤。 代碼函數出現錯誤， 特別是用於報警、趨勢用的代碼函數， 可能導致報警伺服器、趨勢伺服器上運行的工程不正常退出， 導致操作畫面無法操作， 使整個上層網路癱瘓。
7、電腦網卡出現故障， 特別是一些歷史、報警、報表及IO伺服器的網卡出現故障會導致整個上層網路癱瘓。
保證系統穩定運行的建議為避免在DCS系統今後的運行中出現諸如畫面無法操作及死機的現象， 特提出如下建議：
1、在機組正常運行過程中不要修改各種資料庫檔（variable.dbf檔、趨勢、報警、通訊及其它設定檔）， 不要去修改畫面的精靈、超級精靈、畫面範本等，如確實需要修改，則按照和利時公司DCS說明書的要求恢復各台電腦上的工程。如修改了畫面要及時將各站的工程進行恢復。
2、即使在機組停運時修改代碼函數也應慎重，未進行測試不要隨意使用修改後的代碼函數。
3、在調試通訊程式時，用協力廠商軟體進行檢測通訊過來的點是否正確，一定要注意查看已經使用過的埠號，避免設置埠相互衝突。
4、各台電腦上各設定檔應設置正確，能保持一致的項目儘量保持一致。
5、在今後的工程中應將歷史站冗餘配置，這樣當主歷史站出現故障時，另一台歷史站也能夠正常工作。同時歷史站冗餘配置可以使歷史趨勢的點適當的增加，也便於今後事故分析。
6、儘量單獨配置報警伺服器，這樣可以避免在報警伺服器與歷史伺服器同配一台電腦時歷史站出現故障，從而導致網路堵塞畫面無響應的現象。
7、電腦網卡是否正常工作也是保證畫面能正常操作的關鍵。因此除了要選用品質好的網卡外，還要注意防塵以免由於積灰導致網卡不能正常工作。
總結從和利時DCS系統設計上看，操作站上發生的畫面操作無回應現象與控制器是否正常運行沒有很緊密的關係。只要資料沒有顯示為#com,則很可能是網路原因，也有可能是IO伺服器運行出現異常，或歷史站出現異常。所以對於操作無回應的現象始終要注意歷史站有無異常，IO伺服器有無異常。
如果出現一個全英文的對話方塊，則需要立即關閉該對話方塊；如果IO伺服器沒有出現異常，則最大可能就是歷史站因點數過多而造成的存儲困難，引起其它電腦資料相應緩慢。
根據筆者經驗，減少歷史站點數，減少對外介面的通信點數，是保證系統穩定運行的很好措施。合理地考慮對外介面點數和歷史站點數（參考已經實施成功的系統），可以大大減少故障出現的幾率。
（摘編自《電氣技術》，原文標題為“和利時DCS系統畫面無回應原因分析”，作者為彭小強、王冬敏。）
不要去修改畫面的精靈、超級精靈、畫面範本等，如確實需要修改，則按照和利時公司DCS說明書的要求恢復各台電腦上的工程。如修改了畫面要及時將各站的工程進行恢復。2、即使在機組停運時修改代碼函數也應慎重，未進行測試不要隨意使用修改後的代碼函數。
3、在調試通訊程式時，用協力廠商軟體進行檢測通訊過來的點是否正確，一定要注意查看已經使用過的埠號，避免設置埠相互衝突。
4、各台電腦上各設定檔應設置正確，能保持一致的項目儘量保持一致。
5、在今後的工程中應將歷史站冗餘配置，這樣當主歷史站出現故障時，另一台歷史站也能夠正常工作。同時歷史站冗餘配置可以使歷史趨勢的點適當的增加，也便於今後事故分析。
6、儘量單獨配置報警伺服器，這樣可以避免在報警伺服器與歷史伺服器同配一台電腦時歷史站出現故障，從而導致網路堵塞畫面無響應的現象。
7、電腦網卡是否正常工作也是保證畫面能正常操作的關鍵。因此除了要選用品質好的網卡外，還要注意防塵以免由於積灰導致網卡不能正常工作。
總結從和利時DCS系統設計上看，操作站上發生的畫面操作無回應現象與控制器是否正常運行沒有很緊密的關係。只要資料沒有顯示為#com,則很可能是網路原因，也有可能是IO伺服器運行出現異常，或歷史站出現異常。所以對於操作無回應的現象始終要注意歷史站有無異常，IO伺服器有無異常。
如果出現一個全英文的對話方塊，則需要立即關閉該對話方塊；如果IO伺服器沒有出現異常，則最大可能就是歷史站因點數過多而造成的存儲困難，引起其它電腦資料相應緩慢。
根據筆者經驗，減少歷史站點數，減少對外介面的通信點數，是保證系統穩定運行的很好措施。合理地考慮對外介面點數和歷史站點數（參考已經實施成功的系統），可以大大減少故障出現的幾率。
（摘編自《電氣技術》，原文標題為“和利時DCS系統畫面無回應原因分析”，作者為彭小強、王冬敏。）