核電廠DCS與JDT系統通訊故障診斷及優化

程保華，張合廠（中廣核工程有限公司，廣東深圳，518124）

核電廠DCS與JDT系統通訊故障診斷及優化

程保華，張合廠
（中廣核工程有限公司，廣東深圳，518124）

本文結合在某在建CPR1000核電項目的實際通訊調試中遇到的通訊故障解決處理經驗，分析討論了DCS與JDT系統通訊故障的相關情況、診斷方法、數據分析及優化方案。

通訊；故障診斷；優化

1 DCS與JDT通訊特點

JDT是核電站的火災探測系統，負責核電站火警信號、故障信號、現場煙霧信號和就地手動信號等信息，送給DCS以供實現監視、報警以及對防火閥的控制，此系統對核電廠來說非常重要。某核電項目1#機組DCS與JDT系統通過冗余的串行鏈路連接，連接示意圖如圖1。JDT側采用一塊OMRON系列 PLC15 CPU和兩個SCU31通訊模塊，每個通訊模塊具有兩個串行口，一個使用四線制RS422方式從JDT火災探測器ALTARES獲取現場信號和就地手動信號，另一個以兩線制RS485方式與DCS通訊。兩個通訊模塊收發的數據都由CPU模塊進行處理。DCS側采用兩臺工控機構成冗余的70#通訊站。雙方通訊站出口的電信號通過光電轉換器O/E轉換成光信號，通過光纖進行連接。

圖1　JDT與DCS通訊站的連接

在通訊協議上，采用Modbus-RTU，DCS側通訊站為主站，JDT側通訊模塊為從站。DCS通訊站用Modbus功能碼3周期性地讀取JDT采集的火警信號、故障信號、現場煙霧信號和就地手動信號等信息，送給DCS以實現對防火閥的控制；而對于DCS采集的防火閥開關反饋狀態及噴淋狀態信號，DCS通訊站通過功能碼15發送給JDT側，通訊鏈路速率配置為9600bps，采用無校驗方式，讀串口超時時間500ms、讀串口等待延遲時間100ms、發送幀間隔0ms，最大幀長度為255。

自DCS-JDT通訊投用以來，在KIC上瀏覽日志就會發現JDT 與DCS通訊會頻繁出現單側鏈路通訊故障信息。每次故障持續時間約為3～5秒，故障頻率約每天40～50次。如圖2。

為更好的定位故障原因，我們在JDT通訊側采取總線監聽的方式開展了JDT A側的通訊報文抓取工作。在診斷中我們使用一臺診斷用便攜式PC以及一個RS232/RS485轉換器作為診斷設備。按照下圖所示的方式，使用信號線將RS232/RS485轉換器的RS485 端D+/D-端子并聯的接到JDT A側光電轉換器RS485端的D+/D-端子上，再將RS232/RS485轉換器的RS232端接到PC機的串口上。之后在診斷PC上按照DCS與JDT通訊規定的波特率、起始位、停止位、校驗方式設置好串口參數，運行相應的串口監聽軟件（如PortMon等）抓取報文。另外，并聯接入診斷設備時要斷開鏈路，所以鏈路A上的通訊需短時中斷。（因為通訊雙方各使用兩個通訊站構成冗余鏈路，所以暫時的斷開不會使雙方通訊喪失）。

圖3　在JDT A側串行通訊鏈路上監聽報文

抓取的報文連續地存儲在一個文本文件中，表2給出了其中一段異常的報文及分析。這段異常報文產生在2012年12月21日凌晨3點50分。

表1　 DCS通訊站配置的JDT鏈路參數

圖2　70#通訊站的部分故障日志

表2 對一段異常報文的分析

如上表所示，在主站DCS發出［01 03 00 8C 00 01 45 E1］的請求報文（No.3報文）后，在預先設定的讀串口超時時間500ms 內JDT未給予應答。于是DCS通訊站進行超時重發（No.4報文），但JDT仍未在500ms內應答。DCS網關根據預先設定的超時重發次數（2次）進行最后一次超時重發（No.5報文）。然而，最后一次超時重發仍未及時得到JDT的應答。至此，DCS根據預先確定的故障判斷機制，認為該通訊已經故障，并向DCS系統發送通訊鏈路故障信息，引發KIC報警（在KIC上查到的故障報警時間也和這一時刻的時間吻合）。隨即，DCS通訊站初始化了該通訊，即從一個完整數據刷新周期的第一個數據開始依次發送請求報文給JDT。No.6報文［01 03 00 80 00 02 C5 E3］即為通訊重新初始化后發出的第一條請求報文。但是對于這條報文，JDT仍然未在500ms內給予應答。DCS通訊站針對該報文，進行第一次超時重發（No.7報文）。在500ms內，JDT給出了一條應答（No.8報文），即［01 03 02 00 00 B8 44］?？墒峭ㄟ^對該報文內容進行分析可知，該報文實際上是對早前No.3～5報文中某一條的應答，而不是對No.7報文的應答。根據Modbus協議規范，JDT給出的應答是 “答非所問”。因此，DCS通訊站再次判斷該通訊故障，并重新初始化該通訊，并發送一個數據刷新周期中的第一條請求報文（No.9報文）。隨即，JDT給出一條正確的應答，此后通訊才恢復正常。從時間上分析，從DCS發出No.3條報文開始到No.8條JDT回復報文，期間JDT有2.1s的時間沒有任何響應。

根據分析多次抓取的故障報文，均為類似現象，只是發生異常的具體報文不同，而且DCS使用功能碼15向JDT寫數據時也出現過此種異常。因此，初步可判斷認為故障原因是由于JDT沒有及時響應DCS通訊站的請求，導致DCS通訊站超時定時器動作觸發報警。但是，對于JDT為何會出現這種間歇性的不能響應DCS請求的情況，需要JDT側進行深入的調查和分析。報文，而實際上計算機處理報文的速度是以微秒計算的。根據國家標準GB/T 19582.2-2008對Modbus-RTU幀的規定：“在RTU模式中，時長至少為3.5個字符時間的空閑間隔將報文幀區分開”，即t3.5的約定。因此過短的發送幀間隔在串行鏈路上會帶來一個潛在的故障風險，即如果DCS收到第三方的報文后在過于短的時間內（小于t3.5）就處理完收到的報文并開始發出下一條報文，可能會引發對方無法識別DCS發出的報文。而且在較低的波特率下t3.5時間更長，更容易產生問題（9600bps波特率下的t3.5時間為4ms），這種問題曾在DCS與KRT通訊調試中出現過。

2 進一步分析及優化

因我方介入解決此問題是在2012年末，此核電項目是CPR1000擴建項目的首臺商運機組，開展的相關工作都將為后續項目樹立標桿，且項目1#機鄰近商運，時間非常緊迫，JDT側供應商來不及立即進行分析和優化。我們一方面讓JDT廠家加緊分析故障原因，另一方面在DCS側開展了深入的分析和優化嘗試，試圖緩解或消除故障。2013年2月初，DCS實施了相關的改造和升級。

圖4　國家標準對t3.5時間的規定

另外一方面，適當增加幀間隔時間，可以適當減輕通訊負荷，在發生JDT側無響應的情況時給予更長的等待時間。對于減少通訊中斷的幾率是有利的。

2.3增加寫指令重試次數

2.1減少報文數目

在對報文的深入分析中，我們發現因DCS通訊站的通訊點配置文件ComPoints.csv中的通訊地址不連續，使得DCS發出的大部分單次請求的數據量一般只有一到兩個字節，造成請求報文數達到42條，一個通訊周期數據的刷新時間約7s，通訊效率較低。而根據消防聯動控制系統國家標準GB 16806-2006，消防系統從檢測到火警到防火設備的動作時間應＜3s，現有的周期是不能滿足這一要求的。鑒于此，我們采取將70#站通訊點配置文件中的空偏移地址盡量補全的方式，使DCS通訊站的通訊接口程序在每個完整的數據刷新周期中發送更少條數的請求報文。經過優化，DCS側總發送報文條數從42條減少到6條，周期數據刷新時間減少到約1.5s，大大提高了數據傳輸的實時性。

在報文中我們發現因為DCS在發出Modbus讀指令后未收到響應時會重試兩次，而寫指令未得到JDT側響應時不會重試，為了在這種情況下給JDT更多的等待時間，我們推動供應商將寫指令超時重試次數也修改為3次，以期減少通訊中斷幾率。另外，經我方要求，DCS供應商將通訊站讀指令重試次數、寫指令重試次數增加為可配置參數（見下表）。這樣，就使后續項目的通訊組態配置上更加靈活，也方便了今后各CPR1000項目通訊調試時的測試、修改和優化。

3 問題的解決和分析

表3　報文連續性優化前后對比

2.2增加發送幀間隔

增加發送幀間隔是考慮到兩個方面的因素。其一，DCS與JDT建立通訊時，鏈路參數中的“發送幀間隔”初始設置為0ms，即DCS一旦解析完第三方系統發來的報文就會立即發出下一條

在實施了優化方案后，通訊鏈路故障率有明顯下降，從之前的平均每天接近40次降低至每周1~2次。最終，JDT廠家到項目現場調整了通訊模塊鏈路分配，將兩條與DCS通訊的串行鏈路配置到同一塊PLC通訊模塊上，而兩條與火災探測器通訊的鏈路配置到另一塊通訊模塊上，徹底解決了通訊鏈路故障的問題。后續推動供應商后續項目的JDT控制系統也做了同樣配置。

然而，對單模塊帶兩條到DCS的通訊鏈路是否滿足冗余通訊的要求還值得探討，因為修改后每個通訊模塊需要同時在與火災探測器和DCS通訊，而與火災探測器通訊的負荷較重時，是否會能引起通訊模塊對DCS的請求暫時無應答的情況，還進一步分析

表4　DCS通訊站平臺升版增加了可配置的鏈路參數

和后續關注。

［1］GB/T 19582-2008， 基于Modbus協議的工業自動化網絡規范［2］Doyle，J，Carroll，J.D， TCP/IP路 由 技 術 ，夏 俊 杰（譯），2009-06-01，人民郵電出版社

Fault diagnose and optimization of DCS and JDT communication fault in Nuclear Power Plant

Cheng Baohua，Zhang Hechang
（China Nuclear Power Engineering Co. Ltd.， Guangdong Shenzhen，518124）

This paper based on encountered nuclear power projects communication debugging troubleshooting experience in handling，analyzed and discussed the DCS and RGL system communication failure matter，and its diagnostic methods，data analysis and optimization measure.

communication；troubleshooting；optimization

程保華（1982—），男，工程師。2008 年畢業于西安交通大學熱能與動力工程專業，獲碩士學位?，F主要從事核電廠DCS系統相關工作。