RR壓縮機(jī)組控制系統(tǒng)冗余切換故障淺析

崔勝濤

（國家管網(wǎng)集團(tuán)西部管道有限責(zé)任公司 新疆輸油氣分公司，烏魯木齊 830000）

0 引言

西氣東輸一線大部分站場使用的壓縮機(jī)為RR壓縮機(jī)組，機(jī)組PLC控制系統(tǒng)主要由5部分構(gòu)成：一是機(jī)組冗余控制系統(tǒng)（UCP）；二是發(fā)動機(jī)控制系統(tǒng)（ECS）；三是安全保護(hù)控制系統(tǒng)（UPP）；四是振動監(jiān)控系統(tǒng)；五是可燃?xì)怏w和火災(zāi)檢測及二氧化碳滅火系統(tǒng)（EQP火氣系統(tǒng)）。UCP、UPP、ECS 3個系統(tǒng)采用的均是Rockwell公司生產(chǎn)的Controllogix PLC，它將順序控制、過程控制、傳動控制及運(yùn)動控制、通訊、I/O技術(shù)集成在一個平臺上，Controllogix系統(tǒng)所有模塊都是可以熱插拔的，這意味著可以在不停機(jī)的情況下進(jìn)行更換和修理[1]。該控制器有冗余功能，兩個控制器框架采用完全相同的配置，與ControlNet網(wǎng)絡(luò)連接的所有模塊一般有兩個獨(dú)立的ControlNet通道A和B，可連接兩個獨(dú)立的鏈路，在通信和控制時冗余的兩個鏈路同時起相同的作用，當(dāng)A鏈路出現(xiàn)故障時，B鏈路仍起通信和控制作用[2]，這樣大大提高了控制器運(yùn)行的可靠性。RR機(jī)組UCP控制器即采用了熱備冗余模式，在日常運(yùn)行中機(jī)組控制系統(tǒng)UCP程序多次在執(zhí)行中出現(xiàn)看門狗超時，導(dǎo)致UCP產(chǎn)生Majors報警；在切換備機(jī)架過程中，又因備機(jī)架SRM冗余模塊故障造成冗余切換失敗，導(dǎo)致跳機(jī)，給天然氣輸送生產(chǎn)帶來嚴(yán)重地影響，故分析上述問題原因，加以解決此類問題。

1 RR壓縮機(jī)組控制系統(tǒng)的組成

1.1 RR機(jī)組PLC控制系統(tǒng)

RR機(jī)組PLC控制系統(tǒng)主要由5部分構(gòu)成：一是UCP，簡稱機(jī)組控制盤，負(fù)責(zé)機(jī)組工藝流程控制；二是ECS，簡稱發(fā)動機(jī)控制系統(tǒng)，負(fù)責(zé)燃?xì)廨啓C(jī)關(guān)鍵控制[3]；三是UPP，安全保護(hù)控制系統(tǒng)負(fù)責(zé)超速等控制；四是振動監(jiān)控系統(tǒng)；五是可燃?xì)怏w和火災(zāi)檢測及二氧化碳滅火系統(tǒng)。

1.2 RR機(jī)組監(jiān)控系統(tǒng)FT210

FT210是RR壓縮機(jī)機(jī)組利用Intouch軟件開發(fā)的機(jī)組監(jiān)控界面。Wonderware Intouch是一款備受贊譽(yù)的HMI可視化軟件，可以幫助用戶實現(xiàn)遠(yuǎn)程操作。Intouch主要由兩個部分組成：WindowMaker應(yīng)用開發(fā)環(huán)境，使用建立圖形窗口顯示，并設(shè)置與控制器、I/O系統(tǒng)地連接；WindowMaker實時運(yùn)行環(huán)境[4]。FT210系統(tǒng)將兩臺機(jī)組的監(jiān)控界面統(tǒng)一為一個程序文件，設(shè)定了兩級權(quán)限：操作員權(quán)限登錄和管理員權(quán)限登錄。在操作員權(quán)限下，只能進(jìn)行界面的切換，查看和部分功能使用；在管理員權(quán)限下，可以關(guān)閉最小化監(jiān)控界面，可以使用所有的功能按鈕。需要注意的是Intouch軟件安裝后，必須要安裝有效期內(nèi)的注冊文件才能正常使用。

1.3 RR壓縮機(jī)組編程系統(tǒng)FT310

RR公司為每座壓氣站的RR機(jī)組都配備了一臺筆記本電腦，用于聯(lián)機(jī)調(diào)試PLC程序，被稱為FT310。在FT310系統(tǒng)中，安裝的主要應(yīng)用軟件有Controllogix PLC的編程軟件Rslogix5000，通訊軟件RSLinx、ControlNet網(wǎng)絡(luò)組態(tài)和診斷軟件RSNetWork，可燃?xì)怏w和火災(zāi)監(jiān)控系統(tǒng)S3等。需要注意的是Rslogix5000、RSLinx、RSNetWork軟件都配置有各自的軟件狗，即KEY。目前軟件保護(hù)方法大致可分為兩類：軟加密和硬加密[5]，而S3系統(tǒng)則配置了硬加密，只有將硬狗安裝在FT310工程本電腦的接口后，S3系統(tǒng)才可以聯(lián)機(jī)使用。

1.4 RR機(jī)組現(xiàn)場控制設(shè)備子系統(tǒng)

RR機(jī)組現(xiàn)場控制設(shè)備子系統(tǒng)主要是GG燃料氣控制系統(tǒng)、GG液壓啟動系統(tǒng)、GG滑油系統(tǒng)、GG進(jìn)口空氣系統(tǒng)、壓縮機(jī)、PT潤滑系統(tǒng)、壓縮機(jī)干氣密封系統(tǒng)、防喘控制系統(tǒng)（防喘閥）、CO2系統(tǒng)（可燃?xì)怏w和火災(zāi)監(jiān)控）、閥門控制（壓縮機(jī)加載、進(jìn)口、出口、放空閥）、溫度（TC/RTD）、速度、振動監(jiān)控、馬達(dá)控制中心。

2 RR壓縮機(jī)組控制系統(tǒng)冗余切換故障分析

2.1 故障現(xiàn)象

壓縮機(jī)組在運(yùn)行中出現(xiàn)“ALM UCP 3 Fuel Control Loss of Communication ComStatusFC_UCP3 ALM”和“ALM UCP 3 Sequence Loss of Communication ComStatusSeq_UCP3 ALM”報警，造成機(jī)組停機(jī)。通過檢查發(fā)現(xiàn)機(jī)組控制系統(tǒng)UCP控制系統(tǒng)冗余機(jī)架均出現(xiàn)故障報警，上機(jī)架（A機(jī)架）CPU各狀態(tài)燈均不正常：OK燈為紅色常亮，RUN燈未亮，IO燈未亮，兩塊CNBR模塊A/B通道顯示紅色閃爍，SRM模塊上Com燈熄滅，LED顯示DISQ。下機(jī)架（B機(jī)架）SRM模塊上OK為紅色長亮，CPU模塊上OK燈狀態(tài)正常，RUN、IO等均未亮。

2.2 故障原因分析

故障發(fā)生后，由于UCP與HMI的通信中斷，只有HMI與ECS控制器和UCP控制器通信中斷報警，無其他任何報警記錄。在線UCP程序中存在A機(jī)架的主CPU產(chǎn)生看門狗超時major fault。在產(chǎn)品手冊上對此故障代碼進(jìn)行查找，看門狗超時原因為用戶任務(wù)未在制定時間內(nèi)完成，程序錯誤產(chǎn)生無限循環(huán)或程序過于復(fù)雜而無法按指定要求快速完成，或者有一個更高優(yōu)先級的任務(wù)使該任務(wù)不能完成。圖1為UCP Watchdog Fault報警記錄。

圖1 UCP Watchdog Fault報警記錄Fig.1 UCP Watchdog Fault alarm record

通過檢查UCP程序中任務(wù)的掃描時間和看門狗時間設(shè)置值，發(fā)現(xiàn)UCP程序中TASK1和TASK2的看門狗時間設(shè)置較短，Task1掃描周期50ms，看門狗時間為60ms；Task2掃描周期為100ms，看門狗時間為120ms。通過查找資料得出看門狗時間≥（2×掃描周期最大值）+100ms。經(jīng)過觀察，UCP的TASK1程序掃描時間在15ms～17.5ms之間跳變，按照最大執(zhí)行時間17.5ms計劃，程序的看門狗應(yīng)設(shè)置為135ms。因此，判斷程序設(shè)置的看門狗時間不合理。

檢查機(jī)組UCP的ControlNet網(wǎng)負(fù)荷，發(fā)現(xiàn)1#節(jié)點(diǎn)和2#節(jié)點(diǎn)ControlNet網(wǎng)絡(luò)CPU負(fù)荷均為100%。冗余系統(tǒng)配置要求ControlNet模塊CPU負(fù)荷不能大于75%[6]，所以，UCP ControlNet網(wǎng)負(fù)荷過高也會對程序任務(wù)的掃描時間造成一定影響。

檢查機(jī)組控制系統(tǒng)中CNBR模塊版本信息，發(fā)現(xiàn)機(jī)組實際使用的硬件信號為1756-CNBR/E，版本為11.3版，而程序中組態(tài)的模板型號為1756-CNBR/D，版本為5.1。所以，硬件實際版本與程序組態(tài)版本不匹配也會對C網(wǎng)負(fù)荷造成一定影響。

進(jìn)一步排查冗余模塊事件記錄，通過RSLinx軟件導(dǎo)出A、B機(jī)架冗余模塊SRM事件記錄，分析發(fā)現(xiàn)A機(jī)架與發(fā)生major fault系統(tǒng)進(jìn)行主備切換。B機(jī)架接到主備切換指令后進(jìn)行嘗試，但由于通訊錯誤未能切換成功，600ms后B機(jī)架冗余模塊自動重啟，1700ms左右B機(jī)架冗余模塊檢測到A機(jī)架，此切換時間已遠(yuǎn)超過各周期任務(wù)看門狗設(shè)定值。針對SRM模塊的Port1故障查找廠家資料，廠家資料中關(guān)于此故障的處理方法為檢查模塊背板的接口插針，把冗余模塊移到其他槽位，更換新的機(jī)架，更換冗余模塊。

3 優(yōu)化解決措施

造成故障停機(jī)的主要原因為機(jī)組程序看門狗時間設(shè)置不合理和C網(wǎng)負(fù)荷過高。同時，B機(jī)架SRM模塊故障也是此次故障發(fā)生的次要原因。為解決以上問題，主要從以下幾方面進(jìn)行優(yōu)化：

3.1 優(yōu)化UCP程序看門狗時間設(shè)定值

對UCP程序中TASK1和TASK2的執(zhí)行時間進(jìn)行觀察，經(jīng)過一段時間觀察后，發(fā)現(xiàn)TASK1的最大掃描時間為17.57ms。為預(yù)留一定的余量將TASK1最大掃描時間取20ms，則通過計算TASK1的看門狗時間=2×20+100=140（ms）。因此，將TASK1的看門狗時間修改為140ms。經(jīng)過觀察后，發(fā)現(xiàn)TASK2的最大掃描時間為43.44ms，為預(yù)留一定的余量將TASK2最大掃描時間取50ms，則通過計算TASK2的看門狗時間=2×50+100=200（ms），因此將TASK2的看門狗時間修改為200ms。

3.2 降低C網(wǎng)負(fù)荷

降低C網(wǎng)負(fù)荷主要是減少M(fèi)SG指令數(shù)，和每個冗余機(jī)架添加一個CNBR模塊。這兩條措施不適合在目前機(jī)組控制系統(tǒng)程序中實施。因此，降低C網(wǎng)負(fù)荷主要從改變ControlNet網(wǎng)絡(luò)刷新時間，提高用戶連接的請求信息包間隔RPI和減少通過CNBR模塊的連接數(shù)等三方面進(jìn)行優(yōu)化。

對UCP、UPP和ECS程序中組態(tài)的IO模塊的RPI時間進(jìn)行優(yōu)化，將所有模塊PRI為5ms的時間優(yōu)化為10ms。將UCP R2_S02遠(yuǎn)程機(jī)架的第2槽1794-OB16/A模塊的RPI時間，由5ms修改為10ms。將UCP、UPP和ECS程序中所有RPI時間為5ms的模塊組態(tài)均修改為10ms后，則對程序編譯，并下裝到控制器中。由于IO模塊組態(tài)信息的變化，需重新對C網(wǎng)進(jìn)行組態(tài)。C網(wǎng)組網(wǎng)優(yōu)化時，將C網(wǎng)的NUT時間修改為10ms后，出現(xiàn)尖峰網(wǎng)絡(luò)負(fù)荷規(guī)劃為121%報錯信息，保存優(yōu)化配置后，下載C網(wǎng)優(yōu)化組網(wǎng)信息。下載后，重新上載C網(wǎng)組態(tài)信息，顯示修改10msNUT時間，仍然為5ms，因報錯未實際被下裝到C網(wǎng)中，而且經(jīng)此方法優(yōu)化后網(wǎng)絡(luò)負(fù)荷仍然為100%。因此，將原程序和原C網(wǎng)備份下載到控制器和C網(wǎng)中，此項措施未能降低C網(wǎng)負(fù)荷。

由于原C網(wǎng)組態(tài)的規(guī)劃節(jié)點(diǎn)地址為16，非規(guī)劃節(jié)點(diǎn)地址為20，而實際C網(wǎng)中總在用的節(jié)點(diǎn)數(shù)為15個。因此，為避免C網(wǎng)掃描時因掃描實際并不存在的節(jié)點(diǎn)而增加掃描時間和負(fù)荷，將規(guī)劃節(jié)點(diǎn)地址為15，非規(guī)劃節(jié)點(diǎn)地址為16，并重新組網(wǎng)，組網(wǎng)文件無報錯，順利下載完成。

3.3 減少對CNBR模塊的網(wǎng)絡(luò)連接數(shù)

通過分析，連接到機(jī)組控制系統(tǒng)PLC的設(shè)備有7個，如圖2所示，分別為機(jī)組站控HMI、1#機(jī)組機(jī)柜HMI、2#機(jī)組機(jī)柜HMI、機(jī)組機(jī)柜HMI、工程師站、SCADA RCI主和SCADA RCI備。其中，SCADA RCI主和SCADA RCI備只和UCP通信，且通信數(shù)據(jù)量較小。機(jī)組各臺HMI和維護(hù)工程師，除與UCP通信外，還與UPP和ECS通信，且通信數(shù)據(jù)較大。為減少連接數(shù)，可將與機(jī)組通信的1#機(jī)組機(jī)柜HMI和2#機(jī)組機(jī)柜HMI連接斷開。斷開1#和2#機(jī)組HMI采集機(jī)組的連接前，先將兩臺HMI上RSLink中組態(tài)文件使用RSLink Backup/Restore軟件進(jìn)行備份，然后將RSLink中與機(jī)組ECS、UCP和UPP通信的DDE TOPIC組態(tài)刪除，同時重新啟動機(jī)組站控HMI和機(jī)組HMI，對無效的通信連接進(jìn)行釋放。優(yōu)化后，C網(wǎng)負(fù)荷下降至77%～81.3%之間波動，負(fù)荷下降較為明顯。

圖2 機(jī)組控制系統(tǒng)對外數(shù)據(jù)通信連接示意圖Fig.2 External data communication connection diagram of unit control system

3.4 優(yōu)化HMI與控制器的數(shù)據(jù)通信連接路徑，均衡CNBR模塊負(fù)荷

RSLink軟件是AB公司開發(fā)的，它為AB的可編程控制器與各種RockellSoftware及AB應(yīng)用軟件之間建立起通信聯(lián)系，從而實現(xiàn)操作站和PLC數(shù)據(jù)庫之間的連接[7]。通過檢查各HMI RSLink中組態(tài)與控制器的通信路徑，發(fā)現(xiàn)HMI和ESC的通信，全部通過UCP主CPU機(jī)架的2#節(jié)點(diǎn)CNBR模塊進(jìn)行通信，而且UCP主CPU機(jī)架的4#節(jié)點(diǎn)CNBR模塊未連接任何外部設(shè)備，如圖5。且HMI從備UCP機(jī)架的IP地址為111.111.111.14的以太網(wǎng)模塊與UPP通信，此路徑存在冗余切換時通信恢復(fù)時間過長的問題，以及備機(jī)架故障時主機(jī)架單獨(dú)運(yùn)行時，UPP與HMI數(shù)據(jù)通信中斷的風(fēng)險。針對該問題，可將HMI與ECS控制器通信的路徑改到由UCP主機(jī)架的上2槽位的4#節(jié)點(diǎn)CNBR模塊上，這樣可以將負(fù)荷過高的2#節(jié)點(diǎn)CNBR的一部分外部訪問負(fù)荷分配給負(fù)荷相對較低的4#CNBR模塊承擔(dān)，達(dá)到負(fù)荷均衡的效果。同時將HMI與UPP通信的路徑改到由UCP主機(jī)架上的IP地址為111.111.111.43的以太網(wǎng)模塊通信，HMI采集各控制器的通信路徑優(yōu)化示意圖如圖6。對站控室HMI和機(jī)組機(jī)柜間HMI與各控制器的通信路徑優(yōu)化后，2#節(jié)點(diǎn)的連接數(shù)由39個減少到32個，且2#CNBR模塊的整體波動范圍有所減小，負(fù)荷波動基本在72.1%～79.2%之間。4#節(jié)點(diǎn)連接數(shù)由原31個上升至37個，但模塊負(fù)荷并未出現(xiàn)明顯增加，在69%～72%之間波動。

3.5 更換發(fā)生故障的SRM冗余模塊

機(jī)組備機(jī)架上SRM模塊3次出現(xiàn)PORT1錯誤，根據(jù)廠家手冊建議需要檢查和更換SRM模塊和與其PORT1連接的背板。更換故障SRM模塊和7槽位機(jī)架，更換后經(jīng)過測試冗余功能正常。

3.6 將6塊1756-CNBR/E模塊全部更換為1756-CNBR/D

將6塊1756-CNBR/E模塊全部更換為1756-CNBR/D，并重新進(jìn)行C網(wǎng)組網(wǎng)，機(jī)組運(yùn)行正常。

4 結(jié)果及驗證

通過進(jìn)行程序分析、報警信息分析、系統(tǒng)運(yùn)行狀態(tài)診斷、系統(tǒng)網(wǎng)絡(luò)優(yōu)化等方法和手段，判斷此次導(dǎo)致故障停機(jī)的原因為A機(jī)架CPU看門狗時間超時，及B機(jī)架冗余模塊Port1通訊錯誤所致。通過優(yōu)化看門狗時間，優(yōu)化C網(wǎng)組態(tài)，精簡通信連接數(shù)，優(yōu)化數(shù)據(jù)通信連接路徑，更換故障SRM模塊等多項措施，機(jī)組C網(wǎng)負(fù)荷有明顯下降，更換SRM模塊后冗余功能正常，對避免類似故障再次發(fā)生具有重要作用。

5 結(jié)束語

本文主要介紹了RR壓縮機(jī)組控制系統(tǒng)冗余切換故障的處理，目前很多站場所使用的1756-L55及所配套的C網(wǎng)模塊、冗余模塊、以太網(wǎng)模塊等大部分備件已停產(chǎn)，各板卡硬件版本低，且存在模塊實際硬件版本與程序組態(tài)的硬件版本不一致，C網(wǎng)使用率高導(dǎo)致冗余切換存在失敗風(fēng)險。建議對RR壓縮機(jī)組的控制系統(tǒng)ControlNet網(wǎng)絡(luò)負(fù)荷進(jìn)行檢查，對存在的類似C網(wǎng)負(fù)荷超高問題及時處理優(yōu)化，一方面減少對機(jī)組控制系統(tǒng)的外部訪問連接數(shù)，另一方面定期重啟機(jī)組HMI釋放無效連接。為了更好地提升壓縮機(jī)控制系統(tǒng)的整體運(yùn)行性能，建議使用處理性能更強(qiáng)，可靠性更高的L73、CN2R、EN2T、RM2等新版本模塊。