ＣｏｎｔｒｏｌＬｏｇｉｘ系統(tǒng)冗余故障分析及改進(jìn)措施

曾紅波

摘 要：介紹了ControlLogix冗余系統(tǒng)的組成和工作原理。針對(duì)故障現(xiàn)象，通過(guò)對(duì)系統(tǒng)軟件的深入研究和不斷試驗(yàn)、實(shí)踐，提出了合理的改進(jìn)措施并取得了良好的效果，提高了系統(tǒng)的可靠性、排除了因不確定性故障所導(dǎo)致的系統(tǒng)安全。

關(guān)鍵詞：ControlLogix冗余系統(tǒng)；故障；原因分析；改進(jìn)措施和處理方案

中圖分類號(hào)：TP182 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-3198（2009）03-0273-02

1 冗余系統(tǒng)應(yīng)用簡(jiǎn)介

以深圳地鐵一期工程為例：典型車站分為A、B兩端，在A端設(shè)置兩套冗余的控制器（PLC），一套作為整個(gè)車站的主控制器兼作與上位機(jī)的通訊接口，接車站交換機(jī)，另外一套負(fù)責(zé)A端的設(shè)備監(jiān)控；在B端設(shè)置一套冗余的從控制器，負(fù)責(zé)B端的設(shè)備監(jiān)控；在車站的其它地方設(shè)置遠(yuǎn)程I/O設(shè)備。控制器及各遠(yuǎn)程I/O設(shè)備通過(guò)冗余的ControlNet現(xiàn)場(chǎng)總線相連。（系統(tǒng)配置如圖1）

2 冗余系統(tǒng)的設(shè)置和工作原理

ControlLogix冗余系統(tǒng)硬件結(jié)構(gòu)由兩個(gè)完全一樣的控制器框架組成，每個(gè)ControlLogix冗余系統(tǒng)框架中控制器模塊、通信模塊和SRM模塊。兩個(gè)框架尺寸完全相同，模塊一模一樣，插放位置也一模一樣，控制器中的程序也一模一樣。兩個(gè)控制器框架之間，完全靠系統(tǒng)冗余模塊SRM來(lái)完成同步和數(shù)據(jù)的交換。進(jìn)入同步狀態(tài)的主機(jī)控制器，自動(dòng)地傳送備份數(shù)據(jù)到輔機(jī)控制器，這些數(shù)據(jù)無(wú)須用戶挑選和編程，只要在主機(jī)控制器中被程序運(yùn)行時(shí)刷新過(guò)的數(shù)據(jù)，都會(huì)通過(guò)交叉裝載傳送到輔機(jī)控制器，傳送的數(shù)據(jù)量可以非常大?？刂破魍ㄟ^(guò)與SRM的連接，得知自己是主機(jī)控制器還是輔機(jī)控制器，從而決定是傳送數(shù)據(jù)還是接收數(shù)據(jù)。這些完全不需要用戶的介入，系統(tǒng)自動(dòng)獲取、自動(dòng)判斷、自動(dòng)傳送。兩個(gè)控制器的同步運(yùn)行和大量數(shù)據(jù)的復(fù)制，使得輸出得到無(wú)擾切換。

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

3 系統(tǒng)冗余故障顯示及查找

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

最重要一點(diǎn)的是，所有成對(duì)的模塊必須是相同的產(chǎn)品編號(hào)、系列號(hào)和版本號(hào)，并且插放在相同槽內(nèi)。如果輔機(jī)框架的CNBR的Keeper與成對(duì)冗余的主機(jī)框架CNBR的數(shù)字簽名不匹配的話，輔機(jī)框架是不能同步的。需要在RSNetworx組態(tài)軟件中，選擇Keeper Status，檢查輔機(jī)是否為Valid Keeper。如果不是，操作Update Keeper使之恢復(fù)正常。出現(xiàn)這種情況的原因可能是ControlNet網(wǎng)絡(luò)組態(tài)時(shí)，輔機(jī)CNBR模塊是關(guān)閉的或者在別的網(wǎng)絡(luò)中組態(tài)過(guò)。

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

4 改進(jìn)措施和處理方案

4.1 保證非預(yù)定性通信的執(zhí)行時(shí)間

一般說(shuō)來(lái)，非預(yù)定性通信是除了控制器I/O組態(tài)和控制器之間的Produced/Consumed之外的所有的通信——編程設(shè)備的在線、HMI的訪問(wèn)、執(zhí)行MSG指令、響應(yīng)其他控制器的MSG、同步冗余系統(tǒng)的輔機(jī)框架、建立或監(jiān)視I/O的連接（熱拔插模塊）、從控制器的串口通過(guò)背板訪問(wèn)其他設(shè)備等。所有的都是在任務(wù)邏輯程序執(zhí)行以外的時(shí)間進(jìn)行。如果控制器組態(tài)了一個(gè)連續(xù)任務(wù)，由控制器中的System Overhead Time Slice設(shè)定值決定非預(yù)定性通信的時(shí)間；如果控制器沒(méi)有設(shè)定連續(xù)任務(wù)，則在所有周期性任務(wù)執(zhí)行完畢的剩余時(shí)間內(nèi)完成。

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

4.2 合理設(shè)置周期性任務(wù)的時(shí)間參數(shù)

對(duì)于周期性任務(wù)，必須確定最高優(yōu)先權(quán)任務(wù)的執(zhí)行時(shí)間是否遠(yuǎn)遠(yuǎn)小于它的周期時(shí)間，所有任務(wù)執(zhí)行時(shí)間的總和是否遠(yuǎn)遠(yuǎn)小于最低優(yōu)先權(quán)任務(wù)的周期時(shí)間；Watchdog時(shí)間通常為本任務(wù)運(yùn)行時(shí)間的10倍左右。周期時(shí)間、Watchdog時(shí)間可以通過(guò)Logix5000在線連接控制器，在任務(wù)的屬性/組態(tài)中修改（圖3）；任務(wù)執(zhí)行時(shí)間可以通過(guò)Logix5000在線連接控制器，在任務(wù)的屬性/監(jiān)聽(tīng)中查看。（圖4）

4.3 降低冗余框架CNBR模塊的CPU運(yùn)用效率

冗余系統(tǒng)中的CNBR模塊需要足夠的時(shí)間去處理冗余的操作，冗余同步操作將占用CNBR模塊CPU運(yùn)用效率的8個(gè)百分點(diǎn)左右，如果超過(guò)75％，可能會(huì)妨礙冗余切換后的輔機(jī)同步。深圳地鐵一期工程冗余系統(tǒng)CNBR的CPU運(yùn)用效率達(dá)90％以上，部分甚至高達(dá)95％，很容易出現(xiàn)冗余切換后CPU滿負(fù)荷運(yùn)行，導(dǎo)致同步失敗。所以必須想辦法把CNBR模塊的CPU運(yùn)用效率降下來(lái)。

要降低CNBR模塊的CPU運(yùn)用效率，可以從以下幾個(gè)方面著手：增大ControlNet網(wǎng)絡(luò)的NUT（網(wǎng)絡(luò)刷新時(shí)間）、增大I/O模塊連接的RPI（請(qǐng)求數(shù)據(jù)包間隔）、減少通過(guò)CNBR連接的數(shù)量、減少M(fèi)SG的數(shù)量和增加CNBR模塊來(lái)分流信息。由于深圳地鐵一期工程的設(shè)備已經(jīng)定型，增加CNBR模塊涉及到更換機(jī)架成本太高，也沒(méi)有可以減少的MSG指令和通過(guò)CNBR的連接，所以只能從增大ControlNet網(wǎng)絡(luò)的NUT和I/O模塊的RPI兩個(gè)方面入手。

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

RPI設(shè)定可以通過(guò)Logix5000在線連接控制器，在I/O Configuration展開(kāi)所有已經(jīng)組態(tài)的模塊，右鍵點(diǎn)擊適配器選擇Properties/Connection修改Requested Paket Interval為80ms。（圖5）

NUT設(shè)定可以通過(guò)運(yùn)行RSNetWorx for ControlNet，在線upload網(wǎng)絡(luò)配置、編輯使能后通過(guò)菜單Network /Properties/Network Paramerters中修改Network Update Time為20ms。（圖6）

參考文獻(xiàn)

［1］@鄧?yán)?ControlLogix系統(tǒng)實(shí)用手冊(cè)［M］.北京：機(jī)械工業(yè)出版社出版