鐵路信號集中監測智能分析與故障診斷測試腳本系統設計與實現

張雯柏，彭翠云，張立都，胡愛云

（上海鐵大電信科技股份有限公司 研究發展中心, 上海 200070）

鐵路信號智能分析與故障診斷系統（簡稱：智能分析）在信號集中監測（CSM，Centralized Signaling Monitoring）的基礎上，對安全隱患預先識別與實時處理，給出穩定有效的故障解決方案。電務設備檢修、故障定位、隱患處理不再只依靠維護人員的業務水平和經驗積累程度[1]。現有CSM系統主要有 CSM–HH、 CSM–TD、 CSM–TH、CSM–KA、CSM–YH、 CSM–JS、 CSM–JD、CSM–WD、 CSM–LT、 CSM–CL等。唐匯東應用蟻群算法生成腳本全局串接測試RBC[2]。崔巖使用正向最大匹算法生成腳本測試TCC[3]。叢向超提出覆蓋全場景編制腳本測試TSRS[4]。白鴻鈞等人研究腳本語言測試LKJ[5]。在上述研究基礎上，本文著重研究以數據驅動方式把自動化腳本系統引入CSM智能分析系統測試。

對智能分析系統的漸增式集成測試是上站之前必備的工作步驟，實際站場中信號設備類型多樣、故障邏輯多變、測試腳本數量大，直接依靠手工編寫需要較長時間，且在接口協議轉換、經驗值讀取、數值計算等編寫過程中容易出錯。因此，設計一套以數據驅動讀取站場數據、程序化業務邏輯、序列化故障腳本數目，面向CSM智能分析的測試腳本生成系統具有一定的實用意義。

1 智能分析測試系統結構與故障腳本分類

1.1 測試系統結構與腳本入口

搭建的智能分析測試系統，如圖1所示，分為腳本入口層、模擬轉換層以及傳輸層。腳本入口層是模擬采集工具TestServer；模擬轉換層包括相應數據格式轉換模塊；傳輸層主要是綜合信息通信采集板卡，能夠接收RS485、CAN、RS232和TCP/IP格式的數據；環境監測、列控中心、TDCS/CTC、UPS和集中監測等信息直接從TCP/IP通信網輸入站機[6]。

圖1 CSM智能分析系統的測試結構圖

（1）將測試腳本輸入到TestServer，把腳本分割為單個模擬采集數據包；（2）數據包通過腳本入口網傳輸至模擬轉換層，模擬工具接收對應的數據解析歸類，分別打包為RS485、TCP/IP、CAN以及Moxa卡等監測格式的數據；（3）傳輸至監測站機，經拆解分析后保留有用信息作為監測采集數據，并轉發到智能分析系統處理，得到報警和預警結果。

1.2 信號設備的故障腳本分類

測試故障按安全級別分為報警和預警腳本。鐵路信號設備類型分為信號機、道岔、軌道電路、站內電碼化、電源屏、外電網、環境監測、聯鎖系統、列控中心、TDCS/CTC、UPS等，其中，信號機、道岔、軌道電路、電源屏與外電網需要通過測試腳本進行邏輯分析。如圖2所示，按設備類型依次展開各自對應的報警和預警項目。

1.3 區間軌道電路的故障分類

同一報警或預警對應不同的原因，如表1中區間軌道電路包括4個報警項目，其中，“區間紅光帶”的故障原因包括“發送功出電壓低”等6類[7]，如果要驗證該報警項目，則需編寫上述6類故障原因腳本。

智能分析系統以單個設備為最小的處理單元，站場信號設備配置數量增加，測試腳本成倍數增長，同類單元的監測點與采集種類相同，因此設計時按照故障類型分類，對設備統一編號，統計并編寫該類故障下所有設備的獨立腳本，文章以區間軌道電路為例，圖3所示是一個區間軌道電路單元包含的11個故障區域，需要配套編寫相應的11類邏輯腳本[8]。

2 故障測試腳本的邏輯設計與程序實現

2.1 測試腳本的模擬通信協議設計

模擬轉換層的模塊要按照一定的通信協議解析腳本，因此編寫腳本前，需要設計腳本中各類采集通信協議，按照現場實際采集方式設計以下幾類通信協議，如圖4所示。

以區間軌道電路通信協議為例，區間軌道電路走網絡通信時，模擬量通信協議以“區間軌道電路（網絡）=區段名稱，模擬量標志位，設定值”格式設計，按ZPW2000A監測通信協議，模擬量標志位設置在0到27范圍，分別表示區段各監測點采集量，如“04=28810AG，3，2 000”， 其中“3”表示“功出載頻”。區間軌道電路開關量通信協議以“區間軌道電路（網絡）=區段名稱，開關量標志位，狀態位”格式設計，開關量標志位，0表示主軌，1表示小軌；狀態位，0表示空閑，1表示占用，2表示無效。如“09=28810AG，0，1”。區間軌道電路走串口通信時，以“區間軌道電路（串口）=區段名稱，模擬量標志位，模擬量類型”格式設計，模擬量類型中，1表示區間軌道電路，2表示電碼化。

圖2 CSM智能分析系統處理報警與預警分類

表1 區間軌道電路報警項目與原因

圖3 區間軌道電路單元故障定位區域與監測采集點

2.2 測試腳本邏輯分析與編寫設計

自動化測試腳本分為5個層次：線性化，結構化，共享化，數據驅動化與關鍵字驅動化腳本。考慮到站場數據配置多，儲存格式多樣，不能隨意修改，因此采用數據與腳本分離的數據驅動化設計方式，腳本只編寫邏輯控制信息，通過讀取站場配置文檔，經邏輯計算配置模擬量大小。該設計方式優點是可以快速添加相似測試，不同類別腳本讀取同一數據時互不影響。編寫時程序成本大，有多少類腳本就要寫多少類邏輯，但后期維護成本小。

信號設備的報警可以按照業務邏輯逐層分析定位，因此編寫腳本遵從相應的邏輯推導規則，能夠降低誤寫率，避免內容重復的編寫。如圖5所示，圖5 a是對應的數據驅動化編寫腳本程序流程圖；圖5 b是區間軌道紅光帶的業務邏輯分析流程圖。

圖4 測試系統模擬通信協議分類

2.2.1 編寫初始化腳本

在腳本運行之前，需要對測試站場信號設備的開關量和模擬量進行初始化設置，保證測試站場處于正常工作狀態。

（1）初始化站場信號設備開關量。通過站場配置文件讀取所有信號設備的開關量，查找對應的ID號并設置，有道岔的1DQJ、2DQJ、定反表繼電器開關量；站內軌道電路GJ、FBJD等相關開關量；聯鎖、外電網、電源屏相關開關量；控制臺接發車與閉塞按鈕相關開關量；各模塊與采集板卡通信狀態等相關開關量等。程序對應讀取StationCFG.ini站場圖信息，讀取FrankCFG.ini連接的通信地址與分機號，讀取Digit.ini中所有配置開關量的名稱和ID號。

（2）初始化站場信號設備模擬量。查找所有模擬量ID號并設置對應模擬量等于正常狀態下的經驗值。有電源屏、外電網、站內軌道、道岔、信號機、電纜絕緣、電源漏流、電碼化、區間軌道電路與監測、計軸、環境監測、UPS等相關的電壓、電流、阻抗、功率、載頻、相位角模擬量。編寫程序對應讀取 Power、ModBus、TrackCircuit、Turnout、TrackTestDa、TrackOnSit、Signal、SetOther等文擋中的模擬量名稱與ID。

（3）根據讀取的實驗室經驗值文檔TrackTestDa和現場經驗值TrackOnSit文檔設置站場開關量和模擬量初始值。初始化后，所有主電源點亮，軌道處于出清狀態，信號機點紅燈，道岔處于定位狀態。

2.2.2 編寫發送功出電壓低腳本

（1）編寫初始化語句，調初始化腳本，使所有設備處于初始狀態。

（2）取站場管轄區間內一段非盡頭區段，在Digit開關量表中查找對應ID號。

（3）通過該區段名稱和ID，在Analog模擬量表中查找對應的功出電壓和電流、電纜側發送電壓和電流、受端電纜側主軌電壓、主軌入和小軌入電壓、主軌出和小軌出電壓模擬量ID號，初始化該區段所有設備的電壓、電流、載頻處于正常經驗值。

（4）通過該區段名稱和ID，在SecRelation軌道關聯表中查找該區段前后相鄰區段名稱與ID，讀取相關數據表，設置相鄰區段GJ吸起。

（5）設置該區段功出電壓和電流模擬量低于邏輯閾值，延時默認20 s。

應用上述（2）的方法編寫剩余區間軌道紅光帶的5類腳本，根據邏輯依次編寫，對邏輯結構不同的地方做相應調整。

3 實驗結果分析

3.1 界面設計

在VS平臺下引用MFC與DEV編寫測試系統的圖形用戶界面（GUI），如圖6所示，在菜單行添加了一系列Ribbon控件，表示各類信號設備腳本獨立控制生成功能區，如軌道電路功能區中包含正常接車發車、合并過車報警、站內報警等邏輯控制選項，可以通過點擊按鈕觸發腳本生成，保存至當前程序運行路徑下。在點擊生成腳本之前需要先選擇“經驗值設置”，確定初始化與邏輯對比的經驗值來源，可以選擇站場數據庫讀取或默認初始值；在“通信設置”中根據需求設置聯鎖、Modbus、Can通信接口號；根據業務邏輯，在“延時設置”中設置4類延時。

3.2 實用分析

在系統設計完成之后，通過配置相應的站場設備文檔對多個站進行應用。以丹霞山、滕州和南昌西等3個站為例，進行應用說明，3個站的信號設備數量依次由少到多，其中，丹霞山屬于小型信號集中站，滕州站屬于中型，南昌西屬于大型。分別統計各站的電源屏、外電網、站內軌道、道岔、信號機、電碼化和區間軌道的測試腳本數量，如圖7表示各個站內信號設備種類與對應測試腳本數量的分布情況，軌道電路、信號機和道岔測試腳本最多，是電務部門維護和關注的重點，大型站的測試腳本數量要遠多于中小型站。

圖5 區間軌道邏輯流程與對應的編寫流程

表2中統計了3個站的信號設備總數、生成測試腳本總數、手動編寫平均時間和系統自動生成時間，其中，南昌西站的測試腳本11 590個，是丹霞山站的12倍多，測試腳本生成數量最多，自動生成時間最長（165 s），是丹霞山站生成時間的14倍，而平均編寫一個腳本的時間是6 min，該系統縮小了編寫時間，提升了編寫效率。

圖6 腳本生成系統軌道電路控制界面

圖7 應用站場信號設備與測試腳本分布關系

按照技術規范[9-10]，在監測點數目一定、采集數據一致的前提下，信號設備故障的業務邏輯流程是一致的，腳本控制程序一般不需要修改，因此系統生成的腳本邏輯性較高；數據讀取過程與轉換算法流程明確，可追蹤錯誤，經過多個站場測試應用，腳本準確性較高。

表2 腳本生成系統站場腳本總數與生成時間

4 結束語

綜上所述，為減少測試腳本編寫工作量，降低測試腳本誤寫率，縮短測試上線周期，設計并實現了面向CSM智能分析的測試腳本生成系統。在數據驅動設計思路下，分析了智能分析系統需處理的故障項目與原因，以面向對象的程序集變更業務數據來源、接口協議與控制流程中的變量，便于調整邏輯流程和測試環境，控制腳本的輸出。設計的腳本系統對鐵路信號設備故障測試具有一定的實用意義，不足之處是還未實現腳本預期報警與實際報警結果自動對比功能，今后研究方向是從智能分析系統中提取報警結果，與輸入的腳本預期報警對比，自動生成測試結果報告。