ＣｏｎｔｒｏｌＬｏｇｉｘ系統冗余故障分析及改進措施

曾紅波

摘 要：介紹了ControlLogix冗余系統的組成和工作原理。針對故障現象，通過對系統軟件的深入研究和不斷試驗、實踐，提出了合理的改進措施并取得了良好的效果，提高了系統的可靠性、排除了因不確定性故障所導致的系統安全。

關鍵詞：ControlLogix冗余系統；故障；原因分析；改進措施和處理方案

中圖分類號：TP182 文獻標識碼：A 文章編號：1672-3198（2009）03-0273-02

1 冗余系統應用簡介

以深圳地鐵一期工程為例：典型車站分為A、B兩端，在A端設置兩套冗余的控制器（PLC），一套作為整個車站的主控制器兼作與上位機的通訊接口，接車站交換機，另外一套負責A端的設備監控；在B端設置一套冗余的從控制器，負責B端的設備監控；在車站的其它地方設置遠程I/O設備。控制器及各遠程I/O設備通過冗余的ControlNet現場總線相連。（系統配置如圖1）

2 冗余系統的設置和工作原理

ControlLogix冗余系統硬件結構由兩個完全一樣的控制器框架組成，每個ControlLogix冗余系統框架中控制器模塊、通信模塊和SRM模塊。兩個框架尺寸完全相同，模塊一模一樣，插放位置也一模一樣，控制器中的程序也一模一樣。兩個控制器框架之間，完全靠系統冗余模塊SRM來完成同步和數據的交換。進入同步狀態的主機控制器，自動地傳送備份數據到輔機控制器，這些數據無須用戶挑選和編程，只要在主機控制器中被程序運行時刷新過的數據，都會通過交叉裝載傳送到輔機控制器，傳送的數據量可以非常大。控制器通過與SRM的連接，得知自己是主機控制器還是輔機控制器，從而決定是傳送數據還是接收數據。這些完全不需要用戶的介入，系統自動獲取、自動判斷、自動傳送。兩個控制器的同步運行和大量數據的復制，使得輸出得到無擾切換。

在成對的冗余框架中，首先上電的框架成為主機框架，后上電的框架作為輔機框架，并建立與主機控制器的同步。當出現主機控制器所在框架掉電、拔插主機框架上的任何模塊、控制器程序發生主要故障、斷開CNBR模塊上的ControlNet分接器或電纜、斷開ENBT模塊的EtherNet/IP電纜等情況，或者收到來自主機控制器中用MSG發送的命令、來自Rslinx中SRM模塊組態頁面操作的命令都會發生冗余切換。

3 系統冗余故障顯示及查找

冗余系統不能正常工作，常常表現在輔機不能同步。輔機不能同步的原因有很多，查找的辦法也很多，一般說來，冗余框架中的CNBR模塊都有清楚的提示，SRM模塊的組態界面也存放了詳盡的信息。冗余框架插放的CNBR模塊的面板將顯示系統的狀態，面板是字符式顯示，一般是縮寫的大小字母，它們所表達的意思見表1。

最重要一點的是，所有成對的模塊必須是相同的產品編號、系列號和版本號，并且插放在相同槽內。如果輔機框架的CNBR的Keeper與成對冗余的主機框架CNBR的數字簽名不匹配的話，輔機框架是不能同步的。需要在RSNetworx組態軟件中，選擇Keeper Status，檢查輔機是否為Valid Keeper。如果不是，操作Update Keeper使之恢復正常。出現這種情況的原因可能是ControlNet網絡組態時，輔機CNBR模塊是關閉的或者在別的網絡中組態過。

根據提示檢查硬件的情況，是比較直觀和容易的。但是實際使用過程中，大多數故障不是硬件引起的，而是由于參數設置不合理、通信和連接規劃不好，導致控制器出現主要或者次要故障。在深圳地鐵一期工程的建設過程中，由于承包商是首次使用ControlLogix系列產品，在參數設置方面沒有仔細研究和推敲。為了追求最短的響應時間，將所有參數都設置為最小值。這樣就存在控制器沒有足夠的時間去完成非預定性的通信、內存分配比例不合理、連續任務Watchdog時間太短、周期性任務執行時間大于周期時間、高優先權程序執行時間超過最低優先權程序周期時間、冗余框架中CNBR模塊CPU運用效率遠遠超過75％等一系列隱性故障。

4 改進措施和處理方案

4.1 保證非預定性通信的執行時間

一般說來，非預定性通信是除了控制器I/O組態和控制器之間的Produced/Consumed之外的所有的通信——編程設備的在線、HMI的訪問、執行MSG指令、響應其他控制器的MSG、同步冗余系統的輔機框架、建立或監視I/O的連接（熱拔插模塊）、從控制器的串口通過背板訪問其他設備等。所有的都是在任務邏輯程序執行以外的時間進行。如果控制器組態了一個連續任務，由控制器中的System Overhead Time Slice設定值決定非預定性通信的時間；如果控制器沒有設定連續任務，則在所有周期性任務執行完畢的剩余時間內完成。

深圳地鐵一期工程所有控制器內邏輯程序均為一個連續任務，多個周期性任務的配置。所以，應該適當增大System Overhead Time Slice設定值，保證控制器有足夠的時間完成非預定性通信的執行。具體方法是：通過Logix5000在線連接控制器，在控制器的屬性/高級屬性中設置System Overhead Time Slice。（圖2）

4.2 合理設置周期性任務的時間參數

對于周期性任務，必須確定最高優先權任務的執行時間是否遠遠小于它的周期時間，所有任務執行時間的總和是否遠遠小于最低優先權任務的周期時間；Watchdog時間通常為本任務運行時間的10倍左右。周期時間、Watchdog時間可以通過Logix5000在線連接控制器，在任務的屬性/組態中修改（圖3）；任務執行時間可以通過Logix5000在線連接控制器，在任務的屬性/監聽中查看。（圖4）

4.3 降低冗余框架CNBR模塊的CPU運用效率

冗余系統中的CNBR模塊需要足夠的時間去處理冗余的操作，冗余同步操作將占用CNBR模塊CPU運用效率的8個百分點左右，如果超過75％，可能會妨礙冗余切換后的輔機同步。深圳地鐵一期工程冗余系統CNBR的CPU運用效率達90％以上，部分甚至高達95％，很容易出現冗余切換后CPU滿負荷運行，導致同步失敗。所以必須想辦法把CNBR模塊的CPU運用效率降下來。

要降低CNBR模塊的CPU運用效率，可以從以下幾個方面著手：增大ControlNet網絡的NUT（網絡刷新時間）、增大I/O模塊連接的RPI（請求數據包間隔）、減少通過CNBR連接的數量、減少MSG的數量和增加CNBR模塊來分流信息。由于深圳地鐵一期工程的設備已經定型，增加CNBR模塊涉及到更換機架成本太高，也沒有可以減少的MSG指令和通過CNBR的連接，所以只能從增大ControlNet網絡的NUT和I/O模塊的RPI兩個方面入手。

深圳地鐵一期工程冗余系統的NUT和RPI均設置為系統組態時的默認值，分別為5ms和20ms。也就是說，系統每5ms刷新網絡一次，每20ms更新一次I/O模塊數據。由于系統的監控對象是風機、風閥、溫濕度傳感器、冷水流量傳感器、水系統二通閥執行器等設備，所有的設備均不會發生狀態的高頻變化，也不用控制設備高頻度開關，所以系統默認的NUT和RPI遠遠超過實際應用的需要。這樣就過多的耗用網絡資源，占用ControlNet預定性數據的帶寬。而RPI值一般設為實際需要時間的50％即可，即在一個周期內采樣兩次。在系統沒有高頻動作設備，保證系統實時性的前提下，經過多次測試將RPI由20ms改為80ms，將NUT由5ms改為20ms（RPI=NUT*2n），成功的將冗余系統CNBR的CPU運用效率降到了75％以下。

RPI設定可以通過Logix5000在線連接控制器，在I/O Configuration展開所有已經組態的模塊，右鍵點擊適配器選擇Properties/Connection修改Requested Paket Interval為80ms。（圖5）

NUT設定可以通過運行RSNetWorx for ControlNet，在線upload網絡配置、編輯使能后通過菜單Network /Properties/Network Paramerters中修改Network Update Time為20ms。（圖6）

參考文獻

［1］@鄧李.ControlLogix系統實用手冊［M］.北京：機械工業出版社出版