ControlLogix控制器冗余故障診斷與分析①

馬彥寶

(中石油西部管道公司)

ControlLogix控制器冗余故障診斷與分析①

馬彥寶

(中石油西部管道公司)

介紹ControlLogix冗余系統的組成與工作原理，針對系統控制器冗余故障進行了分析，通過對冗余系統軟、硬件的排查，分析了冗余故障產生的原因，并應用軟件優化方法解決了系統冗余故障，提高了控制系統的可靠性和安全性。

故障診斷 天然氣管道 ControlLogix冗余系統 CNBR模塊 SRM模塊

ControlLogix系列PLC是應用最廣泛的工業PLC之一。PLC控制器是系統的控制中心，負責采集現場設備的工況信號、實時控制設備動作、監視生產過程參數和設備運行狀態，當出現報警工況時，上位機界面能夠及時發出報警提示；當出現危險工況時，可以聯鎖保護設備，以保障設備和生產過程的安全。ControlLogix冗余系統中設置了一對相同的CPU機架，當其中一個機架的硬件出現問題時，能夠保障設備或生產過程保持運行狀態，避免了因單CPU故障引起的生產中斷或安全事故，是一種滿足連續生產要求、提高控制系統可靠性的有效手段。

天然氣長輸管道部分壓氣站場采用ControlLogix系列冗余PLC作為壓縮機組核心控制系統和啟停順序控制系統的控制器，筆者以控制器冗余故障排查過程為實例，對冗余故障診斷與處理方法進行分析。

1 冗余系統的工作原理

ControlLogix冗余系統硬件結構由兩個尺寸、模塊和插放位置、控制器程序均相同的控制器框架組成，每個冗余系統框架中包括控制器模塊、通信模塊和SRM冗余模塊。冗余系統使用SRM冗余模塊來保持一對冗余機架之間的通信，兩個控制器框架不需要額外的編程，完全依靠系統SRM冗余模塊來完成同步和數據交換。

進入同步狀態的主控制器能夠自動傳送備份數據到從控制器，無需篩選和編程，只要在主控制器程序運行時刷新過的數據，都會通過交叉裝載傳送到從控制器。兩個控制器的同步運行和大量數據的復制，保證了輸出的無擾動切換。

在成對的冗余框架中，首先上電的框架為主機架，從機架在通電之后與主機架進行同步。當出現主控制器框架掉電、控制器發生主要故障、主機架移除或插入模塊、主機架任一模塊失效、斷開CNBR模塊或ENBT模塊的通信電纜、主控制器發出切換命令、RSLinx軟件發出切換命令等情況，都會導致冗余切換。

圖1為某壓氣站ControlLogix 5561冗余機架網絡拓撲圖，其中ControlNet1與其他控制器通信，ControlNet2與遠程IO機架通信。

系統運行期間會不定期出現冗余切換故障，進而導致從機架離線。此時，查看CPU屬性提示，發現存在周期性任務執行時間超過Watchdog時間這一主要故障報警。而任一單機架運行時則無CPU故障報警。

2 冗余系統檢查

通常，冗余系統為了追求最短的響應時間，會將所有參數都設置為默認值或最小值。但這樣會存在控制器沒有足夠時間完成非預定性通信、內存分配比例不合理、連續任務Watchdog時間短、冗余框架中CNBR模塊CPU運用效率超過75%等一系列隱性故障。

圖1 ControlLogix 5561冗余機架網絡拓撲

2.1 控制器檢查

冗余系統配置要求控制器具有足夠存儲雙倍所有數據的存儲空間。因此，控制器需要檢查存儲空間和非預定性通信時間設置。

非預定性通信是不在控制器IO組態文件里組態的任意類型通信，包括與RSLogix 5000編程軟件通信、與HMI設備通信、執行信息指令、對來自其他控制器的信息做出響應、同步冗余系統的從控制器、重新建立并監視IO連接(如帶電熱拔插模塊)、通過背板在控制器串口與其他設備建立通信等，這些都是在任務邏輯程序執行以外的時間進行。如果控制器組態了連續任務，則由控制器屬性中的System Overhead Time Slice設定值決定非預定性通信時間百分比；如果控制器僅包含周期性任務，則非預定性通信會在周期性任務不運行時進行。

非預定性通信時間設置時需滿足：優先級最高的任務的執行時間明顯比其周期短，所有任務的總執行時間明顯比優先級最低的任務的周期短。可根據需要調整任務周期，以在執行邏輯和非預定性通信之間達到最佳平衡，為非預定性通信留出足夠時間。通常，默認設定值為20%，修改設定值不應超過50%。

現場檢查CPU Memory存儲空間使用率為30.5%，未使用空間為69.5%，滿足控制器存儲空間的要求。CPU Advance屬性中，非預定性通信設定值是50%，滿足設置要求。

2.2 ControlNet模塊檢查

冗余系統配置要求ControlNet模塊CPU利用率不大于75%。使用RSLinx軟件，展開網絡，直到顯示出相應的CNBR模塊，右鍵單擊該模塊依次選擇“模塊統計”、“連接管理器”，檢查CNBR模塊CPU使用率。

如圖1所示，冗余系統中每個獨立的機架中0槽是CPU模塊、1槽和2槽是CNBR模塊、3槽和4槽是ENBT模塊，RACK 1、RACK 2分別為主、從機架。CNBR模塊節點號分別設置為2、4和3、5。現場檢查不同控制器工作情況下CNBR模塊的CPU使用率，結果見表1。

表1 CNBR模塊CPU使用率 %

主、從機架冗余工作時，持續檢查CPU使用率，發現使用率存在超過75%的現象。當CPU使用率超過75%，主、從控制器進行數據同步時，會延長同步時間；當超過Watchdog設定值后，會產生主要報警甚至導致控制器離線。

2.3 Watchdog時間和掃描時間

任務最小Watchdog時間t=2×maximum_scan_time+150(ms)，其中maximum_scan_time為控制器同步后整個任務的最長掃描時間。任務掃描時間是指程序邏輯執行時間和非邏輯協議消費時間的總和。如果Watchdog定時器沒有足夠的時間完整地重新掃描該程序，則將出現主要故障。控制器運行時右鍵單擊任務，通過選擇屬性中的“Monitor”查看任務掃描真實時間和上次運行時的掃描時間，通過屬性中的“Configuration”修改和設置任務的Watchdog估計時間。

現場檢查周期性任務程序掃描時間，程序中周期性任務按照優先等級可分為timeclass1、timeclass2、timeclass3，這3種周期性任務的Watchdog時間初始設定值分別為140、200、600ms，故障處理過程中經過多次修改后的Watchdog時間設定值分別為310、390、1 150ms，任務最大掃描時間分別為310.021、390.017、1 150.101ms。可見，雖然經過多次修改增大Watchdog時間設定值，但任務最大掃描時間仍超過Watchdog設定時間。

3 故障分析與處理

冗余系統中CNBR模塊在進行峰值操作(如同步操作)時，需要額外占用CNBR模塊CPU的8%左右。CNBR模塊需要充足的額外處理時間進行冗余操作，冗余機架中的各個CNBR模塊必須確保CPU利用率保持在75%以下，否則會使從機架在切換后無法同步。因此，解決冗余故障首先應考慮降低CNBR模塊的CPU利用率，可采取的措施如下：

a. 更改ControlNet網絡的網絡更新時間(Network Update Time，NUT)；

b. 增加用戶連接的請求信息包間隔(Requested Packet Interval，RPI)；

c. 減少CNBR模塊上的連接數量；

d. 減少執行信息指令的數量；

e. 為各冗余機架再添置一個CNBR模塊。

前兩項措施可通過C網優化實施，且便于實施和驗證，后3項措施需更改C網硬件配置或修改程序。

3.1 優化NUT時間

ControlNet的NUT為通過ControlNet網絡發送數據的重復時間間隔，用于估算在機架掉電或模塊出現故障的情況下，CNBR模塊無法與其他節點通信時系統切換所需的時間。通常情況下，延長NUT可降低CNBR模塊的CPU利用率，但如果使用過長的NUT，則控制器可能會在切換時與模塊斷開連接。

使用RSNetWorx工具上載、查看當前C網配置。通過運行RSNetWorx for ControlNet，在線upload網絡配置，編輯使能后依次通過選擇菜單Network Properties/Network Paramerters修改NUT設定值。

當前系統配置NUT值為系統默認值5ms，可修改值不大于90ms。嘗試將系統NUT值增大為當前值的兩倍，即10ms，系統提示“exceeded 100% of scheduled network bandwidth”，表示帶寬使用率已到達100%而無法修改。將NUT設置為6ms也無法完成優化。

3.2 修改RPI時間

冗余系統中的每個模塊需確保RPI不大于375ms。如果使用過大的RPI，則控制器切換時可能會產生擾動。設定值根據計算式RPI=NUT×2n(n=0，1，…，6)進行修改。通過Logix5000在線連接控制器，檢查當前系統配置C網NUT值是5ms，在IO Configuration展開已經組態的模塊，右鍵點擊適配器選擇Properties/Connection，修改RPI設定值，如圖2所示。

圖2 IO模塊RPI設定界面

使用RSNetWorx工具上載機架C網配置，通過NETWORK HEALTH MONITOR掃描系統機架中的IO模塊，在線查看當前C網下各IO模塊的通信“健康狀況”。通過掃描檢查發現，C網中的10號節點下3槽1794-OW8模塊和11號節點下5槽1794-OW8模塊，兩個模塊通過遠程機架的背板與C網的通信連接不穩定。檢查兩個模塊的RPI都是20ms，通過公式修改RPI為40ms。RPI修改后，掃描IO模塊通信恢復正常，冗余故障消除。

4 結束語

冗余系統故障是由軟、硬件多方面原因造成的，因此在故障分析、處理過程中需要排除主、從控制器的主要故障，觀察同步過程中主、從機架CNBR模塊和SRM模塊的面板信息和指示燈，解析SRM事件日志，針對不同報警信息和故障現象采取相應的故障處理措施。

TH165+.3

B

1000-3932(2017)08-0792-04

2017-01-22，

2017-03-17)

馬彥寶(1983-)，工程師，從事燃氣輪機和壓縮機組的自控工作，mayanbao@sohu.com。