DCS與TCS通訊指令脈沖寬度問題研究

趙東升，黃耀，袁孝松

（中廣核研究院有限公司，廣東 深圳 518124）

1 問題描述

某電廠TCS側有專門用于汽機控制的子組SGC、SLC等，子組由操縱員在DCS側畫面中進行相應的投入與退出操作，以實現對汽機的控制。目前，在1號機65號站DCS與TCS通訊中，DCS送TCS的指令脈沖寬度為2秒，但DCS與TCS的最長通訊周期約為3秒，如此可能導致DCS側發出的脈沖指令丟失，致使TCS側無法準確接收到DCS側發出的脈沖指令。指令丟失嚴重影響通訊的可靠性和準確性，有可能導致TCS側接收不到DCS側的命令而使汽機的運行不受控，影響機組的穩定運行。

2 原因分析

電廠DCS與TCS通訊采用MODBUS通訊協議，其為請求應答機制，雙方中需要一方作為MODBUS通信主站，另一方作為從站，主站向從站讀數據和寫數據的過程為：主站向從站請求讀寫需求，從站響應主站請求[1]。

如圖1所示：TCS與DCS之間的通訊互為冗余,TCS側有兩對CM104通訊網關；DCS側也有兩對COM網關。冗余功能由雙方共同管理，為并行冗余模式，即在兩條通信鏈路上，數據的收發同時進行，DCS-A網關COM65A到TCS-A網關CM6A，DCS-B網關COM65B到TCS-B網關CM6B同時進行數據收發。DCS側網關為主站，TCS側網關為從站。DCS與TCS系統的通訊站各自兼顧各自冗余情況，冗余主站故障時從站自動切換成為主站。

圖1 冗余通訊機制

電廠 DCS 與 TCS 之間的通訊總共使用了 1、3、5、15、16等功能碼，功能碼1用于DCS讀取TCS送過來的開關量，一條報文可以同時讀取多個開關量；功能碼3用于DCS讀取TCS送過來的多個模擬量，也就是一條報文可以包含多個模擬量；功能碼5用于DCS向TCS發送指令，一條指令一條報文，并且沒有發指令的時候，功能碼5的報文不循環發送的；功能碼15用于DCS向TCS發送指令，可以一條報文同時發送多個指令，并且不斷的循環發送；功能碼16用于DCS向TCS發送模擬量指令，可以一條報文同時發送多個指令，并且不斷的循環發送。

通過對3號機組通訊進行抓包分析，得到各報文傳輸時間：A列通訊周期為2.648秒，B列通訊周期為1.307秒。TCS側西門子CM模塊默認以A列為主，B列為輔。CM6A有延遲，但是不直接影響通訊，也不是鏈路等直接影響通訊的故障，所以通訊仍將以A列為主，即通訊周期為2.648秒。由于1號機組與3號機組的通訊機制、通訊設備均相同，3號機組的分析結果可以作為1號機組通訊周期約為3秒的依據。

DCS與TCS之間每一個通信點都有一個固定地址，DCS對TCS發送指令脈沖的過程即為DCS中將相應地址存儲器中的數據寫入TCS中對應地址存儲器的過程。

目前指令脈沖的寬度設置為2秒，以最長通訊周期為3秒計，指令脈沖丟失過程如圖2所示：

圖2 指令丟失示意圖

假設T1為最長通訊周期，即T1為3秒，在通訊周期T1中，DCS側在t0點發送網絡報文，在滯后時間△t內DCS發出了對TCS的指令脈沖，即DCS中將相應的地址存儲器置“1”并維持2秒。在T1周期內指令脈沖是在發出請求報文△t之后才到達，所以在T1周期內TCS中并不能接收到指令脈沖。當0s＜△t＜1s時，由于脈沖寬度為2秒加滯后時間△t小于通訊周期3秒，而T1周期從DCS中發出報文到接收到TCS側的應答時間需要3秒，所以當T1通訊周期結束T2開始時，脈沖指令已經消失，即相應地址存儲器內的值已置“0”，如此導致在T2周期內TCS側依然接收不到DCS側的指令脈沖，致使指令丟失。

3 改進方案

目前通訊周期延遲問題還在分析論證階段，短期無法解決，所以將DCS側指令脈沖寬度設置為2秒有可能造成指令丟失，將DCS側的指令脈沖寬度修改為4秒，如此讓脈沖寬度大于MODBUS的通訊周期，這樣不論指令脈沖在何時出現，都可以保證在兩個通訊周期內TCS側接收到DCS側指令。修改前后的指令脈沖通訊如圖3和圖4所示：

以上圖4所示，將指令脈沖寬度修改為4秒可以確保DCS側指令通訊到TCS側，避免了指令的丟失，提高了通訊可靠性。同時，由于只是修改脈沖寬度，對系統不會造成其他負面影響，需要修改指令脈沖寬度的通訊點如表2所示。

圖3 修改前指令脈沖寬度2S通訊示意圖

圖4 修改后指令脈沖寬度4S通訊示意圖

表1 修改指令脈沖寬度通訊點