王灘電廠脫硫系統自投運以來，PLC控制系統在雙機熱備情況下經常出現通訊中斷現象，直接影響了運行人員對系統的監控，為此只能采取臨時措施，將雙CPU熱備運行方式退出，改為單CPU運行，減小掃描周期，這極大地降低了PLC控制系統的安全可靠性，給兩臺600MW機組的穩定運行帶來一定的安全隱患。
　　
　　一、脫硫PLC系統的配置情況
　　
　　王灘電廠脫硫PLC控制系統采用樹形網絡，設置兩層控制網絡：上層網為輔助車間集中監控網，下層網為脫硫的車間級控制主干網。全廠輔控網設有4個操作員站、1個歷史站、1個工程師站及2臺相互冗余、相互熱備的服務器、冗余的交換機；車間級控制主干網采用100M冗余光纖以太網，分別設有3臺操作員站、1臺工程師站、1臺歷史站及冗余的交換機，配有#1FGD、#2FGD、#1-2FG、#1-4FGD四套PLC控制系統，配有中央處理單元（CPU）140CPU53414A四套（共8塊）、雙機熱備模塊140CHS11000四套（共8塊），冗余的通訊模件140N0E77101四套（共8塊），輸入輸出模件，連接電纜及連接件和實時操作系統等。PLC系統編程軟件為Concept2.6，監控軟件為Ifix3.5無限點中文開發版。脫硫PLC控制系統通過1000M冗余光纖以太網交換機與全廠輔控網進行通訊，通訊協議TCP/IP，通過通訊接口，脫硫系統的監控納入全廠輔控網，由單元機組集中控制室內的輔助監控站的運行人員完成兩臺爐脫硫系統的監控和管理。操作員站和控制站之間的通訊網絡為雙冗余工業以太網，冗余交換機，通訊協議TCP/IP。I/O站之間的通訊網絡采用冗余的MODICONRIO網絡，即遠程I/O網絡?，F場系統結構示意圖1。　　
　　二、脫硫網通訊中斷原因分析
　　
　　輔控網上有兩臺服務器直接從所有的PLC中采集數據，在脫硫系統中現場有五臺上位機從PLC中采集數據。上位機SCADA軟件采用的是IFix3.5。#1FGD、#2FGD、#1-2FGD、#1-4FGD為Quantum的雙機熱備系統，整個脫硫系統用德國Hirschmann交換機為雙網配置。
　　
　　各站的內存數據分配及上位機數據請求如下表1：　　
　　上位機通訊的性能與CPU的掃描時間、數據請求量及上位機的結構有較大的關系，從上述的表中我們可以得到除了#1-2FGD以外其他站的程序量是比較大的，單機的掃描時間都在50ms以上。另外從3：X類型的數據上看，除#1-2FGD以外其他站的數據量都在50000個字以上。這些因素導致PLC在建立雙機熱備之后所需要的掃描周期在200ms左右，因為每個周期為保證數據的主備機同步，這些數據都需要從主機傳到備機?，F場檢測#1FGD在建立雙機熱備后實際的掃描周期在196ms左右，比單機時擴大了近3倍，從而使得對上位機的響應很慢。另外脫硫系統中有共計有7臺上位機直接從PLC中采集數據，也會導致上位機響應較慢。當出現通訊超時的情況時，SCADA會表現出通訊中斷的現象，但此時PLC對于過程控制的處理是正常運行的。要提高數據的響應速度可以從上述的幾個方面進行分析。
　　
　　三、改進的可行性方案
　　
　　3.1減少直接讀取PLC的上位機數量
　　
　　根據實際操作的需要保留適當數量的上位機，平時不用的站將其IFix3.5關閉可以改善通訊性能?；虿捎每蛻魴C/服務器方式，保留兩臺主機服務器從PLC采集數據，其他操作員站從服務器得到數據。
　　
　　3.2合理配置上位機數據請求以減少數據請求量
　　
　　在IFix中對離散量數據一個請求可以采集2000個點，對字類型數據可以采集125個字。在配置I/O數據請求時盡可能將需要采集的數據放置在同一個請求中采集以減少數據請求數量，如#1FGD、#2FGD、#1-4FGD的0:X類型的數據作優化可都可以減少一個請求。對于7臺上位機來說就可以減少7個請求。但此種變動可能需要對程序作少量修改。另外現場系統采用的雙網絡結構，可以分配上位機從不同的NOE模塊中采集數據。如輔控網從一個NOE采集數據，就地控制從另外一個NOE采集數據，這樣可以有提高SCADA的響應性能。
　　
　　3.3優化程序減小雙機熱備時的掃描周期
　　
　　現場的程序量較大，會導致雙機熱備時所需的熱備字數量較大，從而使得雙機熱備時掃描周期大大增加。可以優化程序如減少非定位變量的應用，減少DFB在雙機熱備系統中的應用可以減少熱備字數量，但此種修改工作量較大。
　　
　　3.4采用的新UnityQuantum雙機熱備CPU模塊
　　
　　以上的幾種方法可以適當地改善目前的通訊性能，但若需要大幅度的提高通訊性能則采用UnityQuantumCPU。主要原因有兩個：新的CPU其程序計算速度及雙機熱備時數據傳輸速度大大提高，從而使得PLC的掃描周期非常短。Unity下的以太網通訊響應請求能力相比于Concept下的Quantum雙機熱備提高了2到4倍。將#1FGD的程序轉換到Unity程序后，根據測試的結果其掃描周期在雙機熱備的情況下可減小到40ms左右。在不變更目前上位機配置下，理論計算可以有30臺上位機同時連接也能滿足性能要求。將Concept程序轉換到UnityPro的程序是比較方便的，程序結構與Concept類似只需作少量的檢查工作。UnityPro操作界面略有不同，但在Concept的基礎上是很容易學習撐握的。系統的硬件及接線除更換CPU和CHS模塊外無需作任何其他的改動。因此，我們選擇了對原控制系統CPU控制器的升級達到減小掃描周期的目的。
　　
　　四、CPU升級及注意事項
　　
　　4.1CPU升級
　　
　　根據以上的分析，zui終確定采用方案4，將原系統中型號為140CPU53414的CPU更換為140CPU67160（要求內存為7M），通過EthernetMTRJ-MTRJ光纖電纜將熱備的兩個CPU相互連接。并且為新更換的CPU增加可擴展的Unityv2PCMCIA存儲卡（SRAM）,型號為TSXMRPC007M，使該控制系統達到可靠的冗余熱備。只需在Unity編程軟件中對新更換的CPU以及槽號進行配置即可。升級后的PLC控制系統#1FGD、#2FGD、#1-2FG、#1-4FGD的掃描周期僅為34ms、37ms、19ms、40ms，*解決了雙機熱備時通訊中斷的問題。
　　
　　4.2CPU升級的注意事項
　　
　　4.2.1工藝系統安全停運
　　
　　CPU升級過程中，工藝系統的運行狀態將無法監視和控制，整個升級過程少則需要一兩個小時，多則可能長達十幾個小時，選擇在機組停運的時候，如不能則一定要做好相應設備的安全措施，無法停運的設備切換到就地運行，如攪拌機和潤滑油泵等。
　　
　　4.2.2CPU型號與NOE版本匹配
　　
　　需要特別強調的是CPU的型號一定要和NOE的版本匹配，否則將無法將程序下載到CPU中。在升級過程中，程序通過MAC地址能連接到CPU，但是通過以太網和USB接口無法將程序下裝，因為本次升級是在原來concept2.6的基礎上進行的，且NOE模塊為2005年采購安裝并使用的，顯然NOE版本和CPU的型號不一致。在升級前一定要在UnityProXL程序下，用OSLOADER功能采用相應的升級文件將NOE模塊升級到Unity下匹配的版本，當系統名稱、系統硬件編號和錯作系統版本顯示無誤后才可完成程序下裝。
　　
　　4.2.3IP地址的配置
　　
　　UnityProXL在用以太網方式連接時，首先將NOE模塊上寫的4組十六進制的數字換算成10進制的4組IP地址，再將本機的IP地址改成同一網段的地址即可。有時候連接不上的話，可以試著配置在以太網模塊上的IP的zui后一位加1，因為加1是帶雙機熱備的IP地址，系統自動加了1。
　　
　　方案實施后取得了較為明顯的效果，實現了脫硫系統的CPU雙機熱備運行，且不再出現通訊中斷的現象。為機組的穩定運行奠定堅實的基礎，全面提高了全廠輔控系統的整體控制水平，為機組安全、穩定、經濟運行奠定了堅實的基礎。