電廠脫硫PLC通訊中斷原因分析及改進(jìn)

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