RR壓縮機組控制系統冗余切換故障淺析

崔勝濤

（國家管網集團西部管道有限責任公司 新疆輸油氣分公司，烏魯木齊 830000）

0 引言

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

1 RR壓縮機組控制系統的組成

1.1 RR機組PLC控制系統

RR機組PLC控制系統主要由5部分構成：一是UCP，簡稱機組控制盤，負責機組工藝流程控制；二是ECS，簡稱發動機控制系統，負責燃氣輪機關鍵控制[3]；三是UPP，安全保護控制系統負責超速等控制；四是振動監控系統；五是可燃氣體和火災檢測及二氧化碳滅火系統。

1.2 RR機組監控系統FT210

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

1.3 RR壓縮機組編程系統FT310

RR公司為每座壓氣站的RR機組都配備了一臺筆記本電腦，用于聯機調試PLC程序，被稱為FT310。在FT310系統中，安裝的主要應用軟件有Controllogix PLC的編程軟件Rslogix5000，通訊軟件RSLinx、ControlNet網絡組態和診斷軟件RSNetWork，可燃氣體和火災監控系統S3等。需要注意的是Rslogix5000、RSLinx、RSNetWork軟件都配置有各自的軟件狗，即KEY。目前軟件保護方法大致可分為兩類：軟加密和硬加密[5]，而S3系統則配置了硬加密，只有將硬狗安裝在FT310工程本電腦的接口后，S3系統才可以聯機使用。

1.4 RR機組現場控制設備子系統

RR機組現場控制設備子系統主要是GG燃料氣控制系統、GG液壓啟動系統、GG滑油系統、GG進口空氣系統、壓縮機、PT潤滑系統、壓縮機干氣密封系統、防喘控制系統（防喘閥）、CO2系統（可燃氣體和火災監控）、閥門控制（壓縮機加載、進口、出口、放空閥）、溫度（TC/RTD）、速度、振動監控、馬達控制中心。

2 RR壓縮機組控制系統冗余切換故障分析

2.1 故障現象

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

2.2 故障原因分析

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

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

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

檢查機組UCP的ControlNet網負荷，發現1#節點和2#節點ControlNet網絡CPU負荷均為100%。冗余系統配置要求ControlNet模塊CPU負荷不能大于75%[6]，所以，UCP ControlNet網負荷過高也會對程序任務的掃描時間造成一定影響。

檢查機組控制系統中CNBR模塊版本信息，發現機組實際使用的硬件信號為1756-CNBR/E，版本為11.3版，而程序中組態的模板型號為1756-CNBR/D，版本為5.1。所以，硬件實際版本與程序組態版本不匹配也會對C網負荷造成一定影響。

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

3 優化解決措施

造成故障停機的主要原因為機組程序看門狗時間設置不合理和C網負荷過高。同時，B機架SRM模塊故障也是此次故障發生的次要原因。為解決以上問題，主要從以下幾方面進行優化：

3.1 優化UCP程序看門狗時間設定值

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

3.2 降低C網負荷

降低C網負荷主要是減少MSG指令數，和每個冗余機架添加一個CNBR模塊。這兩條措施不適合在目前機組控制系統程序中實施。因此，降低C網負荷主要從改變ControlNet網絡刷新時間，提高用戶連接的請求信息包間隔RPI和減少通過CNBR模塊的連接數等三方面進行優化。

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

由于原C網組態的規劃節點地址為16，非規劃節點地址為20，而實際C網中總在用的節點數為15個。因此，為避免C網掃描時因掃描實際并不存在的節點而增加掃描時間和負荷，將規劃節點地址為15，非規劃節點地址為16，并重新組網，組網文件無報錯，順利下載完成。

3.3 減少對CNBR模塊的網絡連接數

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

圖2 機組控制系統對外數據通信連接示意圖Fig.2 External data communication connection diagram of unit control system

3.4 優化HMI與控制器的數據通信連接路徑，均衡CNBR模塊負荷

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

3.5 更換發生故障的SRM冗余模塊

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

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

將6塊1756-CNBR/E模塊全部更換為1756-CNBR/D，并重新進行C網組網，機組運行正常。

4 結果及驗證

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

5 結束語

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