三星電站監控升級改造通信故障分析

四川明星電力股份有限公司 王賢福

1 引言

三星水電站原名白禪寺電航工程，屬涪江干流開發的第十七級電站，距離遂寧市區約32km，電站于1999年首臺機組發電。2012年初三星電站對上下位機和輔機監控進行了升級改造，上位機軟件升級為南瑞NC2000，下位機取消了工業主機，順控流程直接放入PLC，改造前后其拓撲結構如下。改造過程中問題很多，本文主要討論驅動文件配置錯誤引發的通信問題。

2 故障案例

2.1 南瑞監控與許繼10kV 箱式站保護通信故障

2.1.1 結構情況

10kV 箱式站2010年改造，設備數據通過通信管理機用103規約送后臺計算機。改造前三星站送往調度的主設備數據通過電力貓調制后由載波傳輸，10kV 箱式站數據匯總給RTU 用GSM 信號傳輸。改造后，統一由上位機走SDH 通道發往調度。南瑞遠動機為CDT 主站。

2.1.2 處理過程

通道搭建好后，串口板數據燈不亮，測量通信電壓發現data+、data-間電壓1.03V，電平信號不對。排除硬件原因后檢查許繼通信機配置，發現RTU 目錄下upch6中的channel.cfg

通道配置文件串口模式為1，表示使用232方式發送，而實際接線為485方式，改為485方式輸出后串口數據燈閃爍正常。

查看南瑞數據庫，數據錯亂，但許繼監控數據正常，故可排除通信機或保護裝置發送錯誤。打開通道報文監視：EB 90 EB 90 EB 90 71 61 15 01 00 37 00 14 01 11 01 EE 01 2C 01 5E 07 1F 02 00 4D 07 D7。

從報文可看出發送內容為重要遙測量，共21個信息字，主站地址00，子站地址01。信息字按許繼轉發表定義，第一點為主變高壓側電流，轉換為十進制是276，轉發系數為0.00293，計算公式為：顯示值=實際報文值×轉發系數，即276×0.00293=0.80868（A），由于傳送的是二次測量值，必須乘以變比后才是一次值，所以一次電流值=0.80868×10=8.0868（A）正確。

發送端輸出數據正確，中間接線經檢查正常，繼續檢查接收端驅動文件。打開nari 目錄下txt 文件夾，找到cdt_m 中的cdtdef.h 和cdtdef.c，此二文件一個是預編譯頭文件，一個是驅動源文件。

cdtdef.h 定義了系統庫函數的頭文件（#include 部分）以及數據枚舉（typedef enum部分）和程序預編譯。該頭文件完全遵循CDT 標準編寫。繼續看驅動文件cdtdef.c，文件由許多功能函數構成，主函數通過while（1）不斷調用MsgProcess（ ）函數，處理接收信文，定位到MsgProcess（ ）函數段，CDT 規約信文處理函數段如圖2所示。

圖1 CDT 規約信文處理函數段

圖2 修改后的CDT 驅動文件

圖中藍色背景為模擬量處理字段，該段將P 指針指向的地址值賦給s_val。函數使用雙循環提取出信息字，當i 和j 都為0時，取地址1、2，當j 為1時，取地址3、4，而i=1時分別取7、8和9、10，正好對應信息字段。根據cdt 規約定義，先傳低字節后傳高字節，＊256是為了以區分高低字節。圖中先取出高字節，后取出低字節，順序錯誤，應改為：s_val = （p[i＊CDT_WORD_LEN+1+j＊2] ） +（p[i＊CDT_WORD_LEN+1+j＊2+1] & 0xf）＊256；代碼if （s_val & 0x800）和s_val = -（s_val &0x7ff）為判斷數據是否超過2048，是就取最大值加負號，提示溢出（CDT 數據最大11位，極值 2047，超出會將第11位置1，表示符號位為負）。

if （（s_val & 0x8000）||（s_val & 0×4000））continue 字段是判斷無效時跳出循環。f_val = s_val / 2048是將當前值除以2048賦給f_val，2048為滿量程值，這時f_val 為一比例數，所以不對應改為：f_val = s_val / 1.0， 最后通過drv_AIN1（pAIN, f_val, 0,1）庫函數將實時數據寫入數據庫。修改后的CDT 驅動文件如圖3所示。修改后重新啟動CDT 規約進程查看，數據正確，故障解決。

2.1.3 案例1總結

本例通信問題是因為代碼公式錯誤且高、低字節顛倒，導致數據誤差和溢出，此故障一般出現在調試過程中，維護人員應當防止誤修改，平時要對重要文件進行獨立備份。

2.2 南瑞監控與南瑞輔機通信故障

2.2.1 結構情況

輔機改造范圍包含頂蓋排水、前池加壓、檢修排水、滲漏排水、中壓氣機五大部分。改造前后區別是將常規電氣控制改為了PLC 控制，對大功率設備增加軟啟動裝置，遠控操作由通信實現。

輔機PLC 使用RJ 45接口的串行通信方式與SJ30裝置連接交換數據，送發電機的CPM 模塊或開關站通信管理機，通信協議ModBus_RTU。

通過SJ30B 組態軟件，可對通信點位、參數、地址、協議組態并生成＊.sj 配置文件，實現上傳和下載。MOXA 環境模擬工具可以模擬SJ30裝置運行環境，調試好驅動文件。拷貝該驅動文件到SJ30裝置sbin 目錄下，重啟設備或加載該進程開啟通信。

2.2.2 處理過程

故障點1，串口板發送和接收燈不亮。串口燈不亮意味著雙方沒有握手成功（MODBUS 協議采用主、從站詢問應答方式通信），首先要檢查站地址的問題，根據輔機點表，頂蓋排水配置站地址為5，在SJ30組態軟件中查看信文：

COM5 send:

5 3 0 65 0 1a d4 1e

COM5 recv:COM5 register port driver fail

第二行為主站詢問報文，數字5為對側站地址。第三行從站回復信文報寄存器端口驅動錯誤。聯機查看PLC 配置，發現站地址是1，即輔機站地址配置與SJ30裝置不一致，修改站地址后重啟串口板，串口指示燈RXD 和TXD 連續交替閃爍，通信連接建立，雙方握手成功。

故障點2，查看通信報文發現除最后的校驗位外，模擬量數據全部為零，報文內容為：

DEBUG: COM5 send:

DEBUG: 5 3 0 65 0 1a d4 1e DEBUG: COM5 recv:

DEBUG: 5 3

DEBUG: COM5 recv:

DEBUG: 34

DEBUG: COM5 recv:

DEBUG: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9b f2

數據為零就是沒有接收到數據。打開輔機PLC程序，發現約定的R101-R126字寄存器內僅R101、R102、R109-R126有值且正確，R103-R108段為空，模擬量寄存器沒有數據。

定位程序到通信處理塊COMMON。模擬量上送使用R103開始的8個字寄存器儲存信號，程序處理模塊輸入數據來源為名稱SEND_ALL 的中間變量，搜索SEND_ALL 變量發現沒有任何地方調用，數據無來源所以塊對側從R103開始的寄存器為空。解決方法包括：一是直接取模擬量AI0001開始的8個I/O 點，即修改SEND_AI1為AI0001；二是在模擬量處理部分為SEND_ALL 中間變量定義數據來源。

使用第一種方案修改后查看R103和R104寄存器（頂蓋水位）的值分別為5126和5118，換算后分別是0.70M 和0.69M 與實際一致。

故障點3，查看SJ30接收報文，沒有任何改變，開關量和模擬量都是零值。將驅動頭文件的PLC_REG_ADDR （起始寄存器地址）由101改為100后報文無數據，這就奇怪了，寄存器地址修改后，數據必然有所變化。由于觸摸屏和輔機PLC 通信完全正常，通信協議同樣為MODBUS，可參考觸摸屏的配置。（輔機觸摸屏使用威綸通型號為MT6056 i series 的產品）。

打開觸摸屏組態軟件EB8000，定位到模入信號窗口的頂蓋排水數據顯示部分，通信地址為4x 1277（4x 為類型定義，1277為地址），根據MODBUS 規約定義4x 為讀取保持型寄存器，實現對AQ（模擬量輸出寄存器）、 R（字型寄存器）和從站系統時間的讀取。查看南瑞PLC 編程軟件幫助文檔，寄存器R1～R4096對應的通信地址為1000～5095，起始規約地址為0。換句話說，在南瑞PLC 中真實存放數據的起始地址有1000的偏移量，例如1277對應PLC 中的實際寄存器地址應當為1277-1000=277。R0277處模擬量的取值是AI_BUF1（此值是一個中間寄存器，讀取的是經過品質處理后的AI0001）[1]。

寄存器地址有1000的偏移量，驅動文件中起始地址就必須加上1000。使用UltraEdit 打開頂蓋排水的驅動頭文件，將PLC_REG_ADDR 由101改為1100（因為MODBUS 是從0開始計算，所以地址是1100而不是1101）[2-3]。保存，編譯，拷貝，重啟進程，查看報文，OK！所有數據與實際完全吻合。

最后需要修改PLC 中的INIT 段的變量SI_418_PCNT，把19改為43（增加了24點模擬量，8點實際點，16點虛擬點）；24改為56（增加32點開關量，16點實際、16點虛擬），讓PLC 在初始化時分配足夠的儲存空間。最后修改發送信文箱SEND_LENGTH 寬度，配置數據庫，關聯上位機畫面，上位機終于正確顯示出正確的頂蓋水位。

2.2.3 案例2總結

該故障涉及的點比較多，從硬件到軟件，從輔機PLC 配置到上位機機驅動文件，解決了一個問題又發生新的問題。由于改造時間緊迫，導致設備供貨商南瑞公司對設備的出廠調試倉促，許多調試過程只能在設備到達現場后根據現象逐個消除。

3 結語

通信是實現監控的基礎，沒有通信，就沒有數據流動，也無從談起SCADA。監控的升級中，通信故障是一個比較普遍的問題，往往需要通過逐個功能投入試驗才能發現，一蹴而就的概率極小，而驅動程序引發的問題，也基本出現在開始的調試階段。在水電站的生命周期中，隨著設備的老化，安全性能降低同時伴隨新技術新工藝的出現，升級改造的過程還會不斷出現，也許會有更多稀奇古怪的通信故障出現，牢固掌握基礎和循序漸進的思考是解決通信問題的不可替代方法。