程保華，朱 雯

（中廣核工程有限公司，廣東深圳 518124）

1 核電DCS結(jié)構(gòu)及其通訊站

中廣核CPR1000核電擴建項目的DCS系統(tǒng)按照不同的安全等級劃分為核安全級（1E）及非安全級（NC）兩部分，DCS系統(tǒng)與第三方的通訊集中在NC-DCS部分實現(xiàn)。NC-DCS系統(tǒng)的一層網(wǎng)絡(luò)SNET主要連接有多個FCS現(xiàn)場控制站以及與通訊站；二層網(wǎng)絡(luò)MNET連接有多個OPS操作員站以及計算服務(wù)器RTDB、歷史服務(wù)器HS等。I/O Server服務(wù)器實現(xiàn)控制數(shù)據(jù)的下行和監(jiān)視數(shù)據(jù)的上傳。工程師站ES實現(xiàn)對一、二層設(shè)備的組態(tài)和下裝。

圖1 NC-DCS系統(tǒng)結(jié)構(gòu)示意

基于HOLLiAS MACS V6 的NC-DCS平臺采用工業(yè)控制計算機作為通訊站與第三方系統(tǒng)通訊，通訊站連接在DCS的一層網(wǎng)絡(luò)SNET上，可與現(xiàn)場控制站（FCS）進行站間通訊并與I/O Server交換數(shù)據(jù)。NC-DCS平臺上的通訊站主要通過串行鏈路或者以太網(wǎng)鏈路與第三方系統(tǒng)網(wǎng)關(guān)連接，與第三方系統(tǒng)進行通訊協(xié)議有三種：基于RS485串行鏈路的Modbus-RTU、基于以太網(wǎng)TCP/IP的Modbus-TCP、基于以太網(wǎng)TCP/IP的IEC-104通訊。

2 DCS與RGL通訊特點

圖2 并行冗余的通訊站鏈路連接

RGL是核電站的反應(yīng)堆棒位控制系統(tǒng)，它通過一對網(wǎng)關(guān)同時與DCS的1E和NC部分DCS通訊，本文只討論與NC-DCS部分的通訊。RGL和DCS側(cè)各使用一對通訊站通過兩條以太網(wǎng)鏈路交換數(shù)據(jù)。DCS側(cè)采用兩臺工控機構(gòu)成冗余的67#通訊站，RGL側(cè)采用國外某品牌PLC通訊模塊實現(xiàn)數(shù)據(jù)通訊。雙方通訊站出口的以太網(wǎng)電信號通過光電轉(zhuǎn)換器O/E轉(zhuǎn)換成光信號，通過光纖進行連接。

下圖為兩個冗余的通訊站與第三方系統(tǒng)做以太網(wǎng)并行冗余通訊時的物理連接示意。A和B兩個通訊站均冗余地接入一層系統(tǒng)網(wǎng)SNET；A站和B站的SNET2B網(wǎng)口相連，構(gòu)成冗余網(wǎng)RNET作為兩個通訊站之間的冗余狀態(tài)監(jiān)視。通訊雙方各自的一對通訊站都同時進行數(shù)據(jù)通訊，但只有作為主站的通訊站才與SNET網(wǎng)絡(luò)交換數(shù)據(jù)。如果其中一個DCS通訊站故障或不能與第三方正常通訊，另一個通訊站就能夠立即變?yōu)橹髡尽?/p>

在通訊協(xié)議上，雙方采用基于TCP/IP的Modbus-TCP協(xié)議，DCS側(cè)通訊站為主站，GRL側(cè)為從站。DCS使用Modbus功能碼1讀取RGL的棒控狀態(tài)反饋、用功能碼3讀取棒位、功能碼5寫控制指令、使用功能碼16向RGL側(cè)寫棒控設(shè)定值。DCS通訊站配置的鏈路參數(shù)中，超時時間設(shè)定為500ms，TCP端口號為502。

3 通訊故障及診斷分析

在某次運行人員檢查操作員站事件日志時，發(fā)現(xiàn)日志中長期存在67#通訊站A/B機與RGL通訊鏈路故障。經(jīng)檢查，故障發(fā)生頻率為每天十幾次，而且故障后幾秒鐘后又自動恢復正常。在檢查了軟件參數(shù)配置和硬件鏈路后都沒有發(fā)現(xiàn)問題所在之后，我們決定采用報文分析的方法查詢故障原因。

報文分析是獲取和分析雙方通訊鏈路上往來的數(shù)據(jù)報文，從而查找和定位故障的診斷方式。報文分析最大優(yōu)點是可直接看到網(wǎng)絡(luò)上通訊的最真實數(shù)據(jù)，通過分析報文數(shù)據(jù)不僅能夠分析出兩方數(shù)據(jù)傳輸是否正常，還能看到雙方傳送的每一個具體數(shù)據(jù)的值是否正確傳輸。因為工程現(xiàn)場不允許在DCS網(wǎng)關(guān)計算機上安裝報文分析軟件，RGL側(cè)PLC模塊也沒有報文抓取功能，我們采取了在以太網(wǎng)鏈路上監(jiān)聽的方式。如下圖，斷開RGL A側(cè)通訊站與相應(yīng)光電轉(zhuǎn)換器的以太網(wǎng)線，接入一臺帶端口鏡像功能的診斷用高性能千兆交換機（雙方為冗余通訊，斷開一條鏈路不會使通訊喪失），再將診斷用便攜PC機接入交換機。通過配置交換機端口映射（如圖所示，將Port1或port2映射到Port3）的方式即可取得雙方往來通訊的報文。在診斷用PC機上使用了Windows平臺下的WinPcap4.1以及dumpcap工具進行抓包，以適應(yīng)計算機穩(wěn)定和長期大數(shù)據(jù)量抓包的性能要求。在報文分析上使用Wireshark軟件進行輔助分析。

圖3 接入設(shè)備監(jiān)聽RGL A側(cè)通訊鏈路上的報文

通過在A/B雙側(cè)長期抓包，我們獲取了大量報文，經(jīng)過整理，發(fā)現(xiàn)故障原因主要可分為兩類，一類是隨機發(fā)生的RGL無響應(yīng)導致通訊中斷的情況；另一種是在DCS用功能碼16寫寄存器后發(fā)生的RGL側(cè)無響應(yīng)導致通訊中斷的情況。

3.1 第一類故障分析

對于每一條TCP報文而言，它有自己的序列號Sequence number、確認號Acknowledge number以及數(shù)據(jù)部分長度Len。每條報文的序列號Seq等于對方發(fā)來上條報文的Ack號；而確認號Ack等于對方發(fā)來上條報文的Seq號+報文攜帶的應(yīng)用層數(shù)據(jù)長度Len。

圖4 Wireshark軟件的報文輔助分析結(jié)果

圖4為Wireshark軟件中對故障部分報文的解讀，圖5為對雙方往來報文的分析示意。如圖所示，當IP地址為192.168.33.4的DCS通訊站發(fā)出一條使用功能碼3讀起始地址為0X6E的61個寄存器值的Modbus請求（圖5的①表示，這條報文在Wireshark中的編號為114267）后，RGL側(cè)未及時給出響應(yīng)。DCS通訊站在等待了200ms后，在既未收到TCP確認也未收到Modbus答復的情況下，重新發(fā)送了這條TCP報文③（TCP Retransmission）。之后RGL側(cè)僅給出了一條不帶任何Modbus應(yīng)答數(shù)據(jù)的TCP確認④。DCS在收到報文④后就會發(fā)現(xiàn)，報文的序列號Seq119462并不等于RGL側(cè)上一條報文的Seq119309+Len22=119331?？梢姡琑GL網(wǎng)關(guān)在發(fā)送報文④的時候，它認為自己先前已經(jīng)將一條序列號Seq =119331、確認號Ack=34157、應(yīng)用層Modbus答復數(shù)據(jù)長度為131（序列號119462-119331）的TCP答復報文②發(fā)給了DCS，但實際上這條報文RGL網(wǎng)關(guān)并未發(fā)出。圖4中的Wireshark軟件也在這條報文上給出了專家診斷信息提示[TCP Previous segment not captured]，表示未捕獲到RGL側(cè)發(fā)出的上一條報文。實際上RGL側(cè)未發(fā)出的這一條報文從數(shù)據(jù)長度131上看正是對DCS請求的答復。接下來，由于DCS通訊站仍未接收到有效的Modbus應(yīng)答數(shù)據(jù)，它以一條新的TCP報文⑤再次發(fā)出與之前內(nèi)容相同的一個Modbus請求。同時，因為DCS通訊站通過收到的報文④已經(jīng)知道RGL有一條報文丟失或未發(fā)出，這時DCS再發(fā)出的報文⑤的ACK確認號復制了其上一條報文③的ACK號119331，即這是一條帶有TCP重復應(yīng)答信息[TCP Dup ACK]的報文，用于告知RGL側(cè)有報文未收到。

對報文⑤的Modbus請求數(shù)據(jù)，RGL網(wǎng)關(guān)給出了一個帶有Modbus響應(yīng)的TCP答復報文⑥，但未糾正報文⑥中的序列號錯亂。DCS隨即發(fā)出了一條單純的TCP重復應(yīng)答報文⑦，再次復制ACK號，告知RGL網(wǎng)關(guān)存在序列號跳躍現(xiàn)象，要求RGL網(wǎng)關(guān)從丟包的序列號119331開始重發(fā)數(shù)據(jù)。Wireshark軟件對報文⑦也給出了專家診斷信息[TCP Dup ACK 114270#1]，提示報文⑦是對報文⑤的TCP重復應(yīng)答。

圖5 故障部分的報文往來分析示意

兩次收到DCS發(fā)來的[TCP Dup ACK]信息后，RGL網(wǎng)關(guān)發(fā)出報文⑧將序列號重置為丟包的序列號119331（也是報文⑦的Ack號），并重發(fā)了丟失的數(shù)據(jù)。但是這條報文⑧卻加載了兩個完全相同的應(yīng)用層Modbus應(yīng)答數(shù)據(jù)（Modbus PDU），使得這條報文長度達到262（內(nèi)容如圖6所示）。因為報文⑧的這種雙Modbus PUD格式不符合通訊雙方之前的約定，DCS是無法解析的，因而在發(fā)出第⑨條確認報文后，DCS通訊站就出現(xiàn)了程序錯誤：DCS在此之后對每個發(fā)出的Modbus請求都會發(fā)送兩次，RGL側(cè)也被迫應(yīng)答兩次（報文No.114275～No.114278），最終DCS在No.114280條報文請求終止了通訊。

圖6 RGL返回的異常報文⑧的詳細內(nèi)容

通過上面的分析可知，引起通訊中斷的最初原因是RGL側(cè)未及時響應(yīng)DCS的請求，然而在DCS的多次請求后RGL其實是給出了正確答復，這本不至于導致通訊中斷。但是由于RGL側(cè)發(fā)出了一條異常報文⑧，以及DCS通訊站對這條報文的容錯處理機制不完善，引起了DCS后續(xù)的請求報文的異常，最終導致了通訊中斷。

3.2 第二類故障分析

對于第二種故障的情況，其現(xiàn)象都是在DCS使用功能碼16向RGL側(cè)寫棒控設(shè)定值后，RGL通訊站長時間沒有響應(yīng)。超過DCS的等待時間500ms之后，DCS認為RGL側(cè)已經(jīng)出現(xiàn)故障，于是申請重新建立TCP連接。但是DCS起初嘗試的幾次TCP SYN同步請求收到的都是RGL網(wǎng)關(guān)返回的帶有[RST，ACK]字段的應(yīng)答，說明RGL網(wǎng)關(guān)內(nèi)部沒有進程在502端口上監(jiān)聽。一段時間后，RGL側(cè)才給予了TCP握手應(yīng)答。這種情況比較簡單，這里就不給出圖文分析。

4 優(yōu)化方案及實施效果

對于上面分析的兩類故障，主要現(xiàn)象都是RGL側(cè)未及時響應(yīng)DCS的請求報文引發(fā)的，這需要RGL廠家進行分析解決。但因為項目現(xiàn)場工期緊張，經(jīng)過內(nèi)部分析和討論，給出了DCS首先能做的優(yōu)化，擬通過優(yōu)化措施減少或消除鏈路中斷的故障。

a）修改DCS對RGL側(cè)異常報文的處理機制。在對第一類故障的分析中提到，DCS通訊站在收到RGL側(cè)發(fā)來的含有兩個重復的應(yīng)用層Modbus協(xié)議數(shù)據(jù)的異常報文⑧之后也出現(xiàn)了故障，最終導致通訊中斷。對此我們認為，DCS雖無力使RGL側(cè)及時應(yīng)答，但DCS通訊站對于通訊中收到的異常報文應(yīng)該據(jù)有一定的容錯能力，只取其中一個應(yīng)用層數(shù)據(jù)，避免引發(fā)通訊中斷。

b）增加發(fā)送幀間隔時間。DCS與RGL從建立通訊開始，報文交換密度就比較高，在DCS不進行RGL棒位操作時（大多數(shù)情況），雙方的通訊數(shù)據(jù)每秒就能刷新約20個周期，約50ms刷新一次，這顯然有些過于頻繁，參數(shù)配置不合理。經(jīng)過分析評估，在完全滿足性能要求的情況下適當增加刷新周期不但能夠減輕雙方通訊站的負擔，也能夠盡量減少因RGL響應(yīng)慢導致的鏈路通訊中斷的發(fā)生。最終DCS通訊站設(shè)定了5ms的幀間隔時間，使數(shù)據(jù)刷新周期增加到100ms，但完全滿足數(shù)據(jù)傳輸實時性的要求。

c）增加寫指令重試次數(shù)。在上文對第二中鏈路故障的分析中提到，DCS在發(fā)出功能碼為16的寫指令而沒有收到RGL側(cè)響應(yīng)，之后DCS通訊站既沒有進行任何重試，也沒有嘗試關(guān)閉連接，而是直接要求重新建立連接，這種機制實際上是不合適的。對此，我們要求供應(yīng)商必須修改通訊驅(qū)動的算法，完善響應(yīng)的機制，并將寫指令重試次數(shù)則增加到三次，增加給RGL做出應(yīng)答的機會和時間，以期減少鏈路故障的發(fā)生率。

在現(xiàn)場實施上述優(yōu)化改造后，一直再未出現(xiàn)過鏈路故障的報警。但是通過檢查報文，RGL側(cè)未及時響應(yīng)的情況還是存在，只不過DCS通過增加容錯和重試次數(shù)，每次都避免了通訊中斷。近期，RGL側(cè)PLC廠商已在工廠復現(xiàn)故障并分析出原因，后續(xù)將進行修改。而本文提出的DCS通訊站的優(yōu)化方案已經(jīng)在多個CPR1000在建核電機組上實施，改善了DCS通訊站的性能。

[1]GB/T 19582-2008，基于Modbus協(xié)議的工業(yè)自動化網(wǎng)絡(luò)規(guī)范

[2]Doyle，J，Carroll，J.D，TCP/IP路由技術(shù)，夏俊杰（譯），2009-06-01，人民郵電出版社