尹 青， 上官偉， 張軍政， 胡妙春， 臧一佩

(1.中國鐵道科學(xué)研究院集團有限公司，北京 100044； 2.北京交通大學(xué) 電子信息工程學(xué)院，北京 100044)

隨著我國高鐵線路的大規(guī)模發(fā)展，對鐵路運輸安全提出了更高的要求，列控中心(Train Control Center,TCC)系統(tǒng)作為高鐵技術(shù)核心之一，在保障高鐵安全運行方面起著重要作用。列控中心系統(tǒng)由安全主機子系統(tǒng)、驅(qū)采子系統(tǒng)、通信接口子系統(tǒng)、維護子系統(tǒng)和電源子系統(tǒng)5個部分組成。該系統(tǒng)根據(jù)管轄范圍內(nèi)各列車位置、聯(lián)鎖進路和線路臨時限速狀態(tài)等信息，控制軌道電路編碼和有源應(yīng)答器信息，向列車提供運行許可。

現(xiàn)有的C2級列控中心仿真工程測試主要依靠人工完成，即按照測試案例逐條進行手動測試，包括案例的編寫也主要依靠人工，帶有較大的盲目性和不確定性，同時測試人員的行為傾向使得他們選擇的測試用例往往僅能測出所熟悉或印象較深的錯誤，且在工程項目較多、工期較為緊張的情況下，測試人員對系統(tǒng)的熟悉程度和自身疲勞程度對測試質(zhì)量和效率都有較大影響。因此需要開發(fā)更為高效智能的自動化測試產(chǎn)品以減少對人工的依賴，提高測試質(zhì)量和效率。

針對以上問題，在數(shù)據(jù)配置及軟件功能測試方面，筆者探討了將機器學(xué)習(xí)應(yīng)用在C2列控中心室內(nèi)仿真測試案例的生成中，實現(xiàn)通過智能分析站場數(shù)據(jù)，生成有針對性的測試案例，結(jié)合分析以往的測試數(shù)據(jù)，優(yōu)化測試結(jié)構(gòu)，并研究自動測試框架，自動執(zhí)行并對被測對象的輸出進行驗證和評判，能夠減少大量重復(fù)煩瑣的人工測試工作，從而降低人為因素造成的錯誤率，提高測試效率。

1 列控中心仿真測試平臺架構(gòu)

1.1 室內(nèi)仿真測試需求

在C2級系統(tǒng)中，列控中心軟件主要完成以下功能：

① 根據(jù)列車進路和軌道區(qū)段狀態(tài)等信息，實現(xiàn)站內(nèi)和區(qū)間軌道電路的編碼；

② 通過安全數(shù)據(jù)網(wǎng)接收臨時限速信息，實現(xiàn)應(yīng)答器報文的實時組幀、編碼并發(fā)送給地面電子單元(Lineside Electronic Unit,LEU);

③ 實現(xiàn)區(qū)間運行方向與閉塞的控制；

④ 實現(xiàn)信號機的點燈控制；

⑤ 實現(xiàn)TCC間、聯(lián)鎖系統(tǒng)(Computer Based Interlocking,CBI)、調(diào)度集中系統(tǒng)(Centralized Traffic Control,CTC)信息的傳輸；

⑥ 實現(xiàn)區(qū)間閉塞分區(qū)的占用邏輯檢查等。

針對以上功能，測試內(nèi)容主要包括站內(nèi)、區(qū)間載頻校驗；站內(nèi)進路編碼測試；區(qū)間編碼及點燈測試；改方測試；異物防護配置測試；無限速報文測試；大號碼道岔應(yīng)答器報文發(fā)送測試；進路限速及信號降級測試；正線及區(qū)間限速測試；接口配置測試[1]；長短鏈限速測試等[2]。

測試環(huán)境由TCC真機、仿真鄰站TCC、仿真CBI、仿真臨時限速服務(wù)器(Temporary Speed Restriction Server,TSRS)、仿真CTC、仿真LEU、仿真繼電器驅(qū)采(IO)、仿真軌道電路和維護終端組成。TCC室內(nèi)仿真測試設(shè)備連接如圖1所示。

圖1 TCC室內(nèi)仿真測試設(shè)備連接圖

現(xiàn)有TCC仿真測試主要由人工進行，在驗證軌道電路編碼正確性時需要人工排列進路，根據(jù)碼序圖和信號顯示關(guān)系圖等資料數(shù)據(jù)驗證編碼、邊界和改方等信息。在測試報文時需要人工驗證有源應(yīng)答器的所有場景報文[3]，包括無限速時和有限速時、接車報文、發(fā)車報文、預(yù)告報文等，工作量較大。

1.2 系統(tǒng)架構(gòu)設(shè)計

C2級智能列控中心仿真測試平臺架構(gòu)如圖2所示，主要包括3個模塊：通信接口模塊、驗證服務(wù)模塊、AI案例生成及執(zhí)行模塊。通過AI驅(qū)動的案例選擇引擎生成有針對性的測試案例，再對外部輸入驅(qū)動數(shù)據(jù)進行解析，對數(shù)據(jù)進行關(guān)鍵字特征提取，自動執(zhí)行測試案例序列，并通過通信接口模塊接收被測TCC系統(tǒng)的輸出數(shù)據(jù)，將輸出數(shù)據(jù)交由驗證服務(wù)模塊進行評判驗證，同時給出測試結(jié)果。

圖2 C2級智能列控中心仿真測試平臺架構(gòu)圖

1.2.1 基于vSphere的通信接口模塊

試驗開始前，首先需要人工創(chuàng)建測試環(huán)境，目前主要是在多個物理設(shè)備上進行人工部署，傳統(tǒng)物理結(jié)構(gòu)如圖3所示。

圖3 傳統(tǒng)物理結(jié)構(gòu)

本測試平臺的一個創(chuàng)新點在于整合管理多臺物理服務(wù)器的計算、網(wǎng)絡(luò)和存儲，形成集中的資源庫，在資源庫中為不同的測試環(huán)境分配虛擬機和劃分虛擬局域網(wǎng)(Virtual Local Area Network,VLAN)，為仿真CTC、仿真TCC、仿真TSRS、仿真CBI和接口仿真等提供基礎(chǔ)運行環(huán)境，在很大程度上減少了物理接口，提高了運行的穩(wěn)定性，并可以將部署時間大幅縮短。通過多個操作系統(tǒng)的整合，只需采用一臺高性能服務(wù)器，即可構(gòu)建資源集中和共享的新服務(wù)器模式，滿足日益擴大的應(yīng)用需求。

創(chuàng)建方法是在物理服務(wù)器中分布式安裝vSphere，完成ESXi服務(wù)器配置，然后通過安裝vCenter，將ESXi服務(wù)器連入vCenter服務(wù)器進行集中管理[4]。同時，將存儲接入ESXi服務(wù)器，并按網(wǎng)卡分配規(guī)則，將網(wǎng)卡指定給不同的虛擬交換機，并配置不同的端口組，同時指定不同的VLAN，安裝相應(yīng)虛擬機后，配置不同的端口組，從而實現(xiàn)虛擬機間網(wǎng)絡(luò)互聯(lián)。不同于傳統(tǒng)的測試環(huán)境，vSphere虛擬化環(huán)境實現(xiàn)了物理資源的池化和計算資源的共享，省去了互聯(lián)機器間的線纜，提高了機器之間可靠性和可管理性[5]。串口通信設(shè)備均為仿真時，可采用虛擬串口工具實現(xiàn)。

在配置完vSphere和vCenter的整體環(huán)境后，該平臺可提供虛擬機生成和網(wǎng)絡(luò)服務(wù)，其中，網(wǎng)絡(luò)服務(wù)主要由虛擬化環(huán)境中的虛擬交換機和虛擬端口組提供，基本滿足了列控設(shè)備的集成測試環(huán)境需求。

根據(jù)實際通信需求將通信接口設(shè)計為3種通信方式。以太網(wǎng)通信模塊主要實現(xiàn)集成測試平臺中集成封裝的仿真CBI、仿真TSRS、仿真鄰站TCC、仿真LEU(以太網(wǎng))與被測TCC系統(tǒng)之間的數(shù)據(jù)交互。

RS422串口通信模塊主要實現(xiàn)集成測試平臺中集成封裝的仿真CTC、仿真LEU(串口)與被測TCC系統(tǒng)之間的數(shù)據(jù)交互。

CAN總線通信模塊主要實現(xiàn)集成測試平臺中集成封裝的仿真IO與被測TCC系統(tǒng)之間的數(shù)據(jù)交互。

1.2.2 案例生成及執(zhí)行模塊

案例生成模塊主要包含數(shù)據(jù)解析、案例生成和案例執(zhí)行3個部分。首先應(yīng)對輸入源文件進行數(shù)據(jù)解析、信息提取和結(jié)構(gòu)重組。案例生成工具根據(jù)重組后的數(shù)據(jù)預(yù)測生成車站所需測試案例，再通過Robot Framework 測試框架自動遍歷執(zhí)行測試案例。輸入源文件包括與其他系統(tǒng)的接口文件、設(shè)計數(shù)據(jù)、LEU端口表、TSRS管轄范圍表等。

1.2.3 驗證服務(wù)模塊

驗證服務(wù)模塊采用Robot Framework測試驅(qū)動框架，解析不同測試案例對應(yīng)腳本的指令，根據(jù)腳本信息向仿真測試系統(tǒng)下發(fā)相應(yīng)的指令，并實時獲取列控中心所反饋的狀態(tài)信息，從而對結(jié)果做出判斷。

① 報文驗證。測試平臺下發(fā)報文測試序列后，接收由TCC回傳的報文數(shù)據(jù)并進行驗證。標(biāo)準(zhǔn)站場示意圖如圖4所示，其中BX即X發(fā)車口的進站應(yīng)答器，以此類推。

圖4 標(biāo)準(zhǔn)站場示意圖

例如X→XI這條進路，由測試平臺下發(fā)聯(lián)鎖進路命令，列控中心執(zhí)行后，回傳該進路所需要核對的有源應(yīng)答器報文，平臺接收后，對該應(yīng)答器報文數(shù)據(jù)進行解析驗證，并生成報告，若不一致通過紅色高亮顯示，再由人工進行確認。

② 碼序驗證。碼序驗證測試流程如圖5所示。碼序驗證模塊根據(jù)設(shè)計提供的碼序表、編碼規(guī)范、聯(lián)鎖進路排列和信號開放情況，生成預(yù)期碼序輸出表，將其與被測TCC輸出的碼序進行驗證評判。測試平臺自動執(zhí)行碼序測試案例，判斷實際值與預(yù)期值是否一致。

圖5 碼序驗證測試流程

③ 限速驗證。限速驗證模塊包括2個部分：驗證信號機限速降級信息、驗證邊界和進站應(yīng)答器配置。主要驗證包括平臺下發(fā)給被測TCC的限速命令，被測TCC系統(tǒng)是否正確執(zhí)行，限速線路號、起始公里標(biāo)、終點公里標(biāo)以及應(yīng)答器限速報文是否正確。

2 關(guān)鍵技術(shù)

2.1 決策樹算法驅(qū)動的案例選擇器

仿真測試的一個關(guān)鍵點是測試案例的生成，針對不同站型，重點研究如何生成適合的測試案例。案例選擇器根據(jù)決策樹算法，學(xué)習(xí)以往的案例生成方式，結(jié)合歷史數(shù)據(jù)和問題庫，通過大數(shù)據(jù)加上機器學(xué)習(xí)，針對不同站型選擇出該車站的適用案例。目標(biāo)測試案例為工程測試案例，軟件的功能測試案例不作為本次研究的重點。

案例選擇器基于決策樹算法設(shè)計，決策樹算法是一種非常有效的數(shù)據(jù)分類技術(shù)，有著與流程圖相似的樹結(jié)構(gòu)[6]。特定站型和所有案例有直接相關(guān)性，例如標(biāo)準(zhǔn)站都有A類案例，非標(biāo)站沒有B類案例，C類案例只在某種站型中出現(xiàn)等。前述相關(guān)性不太好描述，所以根據(jù)歷史積累的數(shù)據(jù)，基于決策樹算法進行訓(xùn)練，最終實現(xiàn)了AI驅(qū)動的案例選擇器。決策樹有多種算法，例如ID3算法、C4.5算法和CART算法[7]等。 ID3中根據(jù)屬性值分割數(shù)據(jù)，之后該特征不再起作用，這種快速切割的方式會影響算法的準(zhǔn)確率。而CART是一棵二叉樹，采用二元切分法，每次把數(shù)據(jù)切成2份，分別進入左子樹和右子樹，葉子節(jié)點比非葉子多1。相比ID3和C4.5，CART應(yīng)用要多一些，既可以用于分類也可以用于回歸。CART分類時，使用基尼(Gini)指數(shù)來選擇最好的數(shù)據(jù)分割的特征，Gini指數(shù)描述的是純度，與信息熵的含義相似。CART中每一次迭代都會降低Gini指數(shù)。因此本研究選取CART算法。

以一個標(biāo)準(zhǔn)車站為例，從數(shù)據(jù)中獲取最終案例生成所需要的各個特征點，包括股道數(shù)量、發(fā)車口類型、軌道電路制式、站內(nèi)及區(qū)間編碼方式、區(qū)間信號控制方式、異物侵限配置、大號碼道岔配置、站臺門配置和區(qū)間占用邏輯檢查配置等。通過決策樹算法，根據(jù)特征點與數(shù)據(jù)的匹配一致性來判斷出是否生成該特征點對應(yīng)的測試案例。案例選擇器決策樹結(jié)構(gòu)如圖6所示。

圖6 案例選擇器決策樹結(jié)構(gòu)

實際工作中，測試人員對報錯的報告進行檢查，確認該錯誤。對于正確的報告，考慮到AI引擎可能漏選，故需進行有針對性的補充測試。將每次的結(jié)果再次輸入給選擇器進行訓(xùn)練，不斷地提高準(zhǔn)確性，并豐富測試案例庫。

測試案例庫的管理使用SQL數(shù)據(jù)庫進行。模型服務(wù)流程如圖7所示。把數(shù)據(jù)引入到系統(tǒng)后，先用 SQL算子對數(shù)據(jù)做了拼接，然后清洗一些無效數(shù)據(jù)； 再把數(shù)據(jù)拆分為訓(xùn)練集和測試集，分別對2個數(shù)據(jù)集做特征抽?。恢笥?xùn)練集傳遞給機器學(xué)習(xí)算法進行訓(xùn)練，訓(xùn)練后使用測試集來測試模型的效果。由近年來已測工程車站的數(shù)據(jù)訓(xùn)練結(jié)果可知，該模型是有效的。

圖7 模型服務(wù)流程

通過歷史測試案例訓(xùn)練出決策樹模型后，發(fā)布一個預(yù)測服務(wù)，然后輸入新的數(shù)據(jù)后可根據(jù)模型算出一個預(yù)測值，即針對該站的測試案例。當(dāng)然，擁有的數(shù)據(jù)越多、越豐富、越真實，訓(xùn)練出的模型效果越好。

2.2 關(guān)鍵字驅(qū)動測試模型

Robot Framework是基于Python 語言編寫開發(fā)的，是支持關(guān)鍵字驅(qū)動的自動化測試框架，多個測試案例可以通過同一關(guān)鍵字的調(diào)用實現(xiàn)測試的功能，腳本復(fù)用度較高。Robot Framework內(nèi)置全局日志管理模塊，包含多種案例庫管理與測試報告生成工具[8-10]，支持多設(shè)備通信，包括Telnet、SSH、XML-RPC等。

以關(guān)鍵字驅(qū)動的自動化測試由關(guān)鍵字構(gòu)成測試案例對應(yīng)的腳本[11]，通過改變關(guān)鍵字來驅(qū)動自動化測試的執(zhí)行，最終引起測試結(jié)果的變化。關(guān)鍵字即對測試操作的抽象與封裝，其執(zhí)行順序代表著系統(tǒng)的業(yè)務(wù)邏輯[12]。在關(guān)鍵字驅(qū)動模式下，測試數(shù)據(jù)存儲于數(shù)據(jù)文件中，與關(guān)鍵字相獨立，通過Robot Framework的開源圖形界面開發(fā)工具RIDE實現(xiàn)測試案例的管理和執(zhí)行，如圖8所示。采用基于Internet過程調(diào)用實現(xiàn)的XML-RPC通信協(xié)議，將執(zhí)行模塊作為客戶端，TCC接口適配仿真作為服務(wù)端，完成測試指令的解析和執(zhí)行，從而實現(xiàn)非侵入式閉環(huán)的黑盒自動測試。

圖8 基于RIDE開發(fā)工具的測試案例管理界面圖

碼序測試或報文測試都是在排列進路的基礎(chǔ)上完成的，TCC與聯(lián)鎖、相鄰TCC等系統(tǒng)的交互會影響軌道電路碼序的改變以及有源應(yīng)答器報文的選擇[13]。因此本測試平臺將測試案例中的進路相關(guān)操作封裝于關(guān)鍵字中，將進路的始端與終端信號按鈕寫入數(shù)據(jù)文件。執(zhí)行測試案例時，Robot Framework根據(jù)測試案例中的步驟，加載相應(yīng)的數(shù)據(jù)文件并調(diào)用關(guān)鍵字對應(yīng)的底層代碼，完成對聯(lián)鎖進路的操作，以便進行之后的測試。

3 仿真平臺測試結(jié)果驗證

以連鎮(zhèn)線寶應(yīng)站數(shù)據(jù)為測試輸入來驗證筆者提出的測試方法的可行性。寶應(yīng)站為4股道標(biāo)準(zhǔn)車站，將該站數(shù)據(jù)引入AI驅(qū)動的案例選擇器后，生成目標(biāo)測試案例種類包括站內(nèi)區(qū)間編碼測試、改方測試、報文測試、限速及區(qū)間邏輯占用檢查測試和站臺門測試案例，站場部分特征篩選如表1所示。將案例選擇器生成結(jié)果與手動編寫案例進行對比，結(jié)果如表2所示。由表2可知，案例選擇器生成的案例種類等于手動編寫案例，而數(shù)量則等于或多于手動編寫案例。應(yīng)用于多個車站后，結(jié)果表明基于決策樹算法驅(qū)動的案例選擇器生成的案例覆蓋率更高。

表1 站場部分特征篩選表

表2 寶應(yīng)站兩種案例生成方式生成種類及數(shù)量對比

以發(fā)碼自動化測試為例，選擇X→X1→SF發(fā)碼測試案例，碼序測試的測試案例大致步驟如表3所示。單擊“運行”按鈕，執(zhí)行該測試案例，能夠生成簡單易讀的測試報告和碼序驗證結(jié)果，測試報告中案例測試若執(zhí)行失敗，背景顯示紅色，反之則顯示綠色，如圖9所示。

表3 測試案例步驟一覽表

圖9 碼序驗證結(jié)果

測試報告記錄了本次案例自動執(zhí)行的結(jié)果，包括場景執(zhí)行的成功與失敗的次數(shù)以及執(zhí)行完該案例的耗時,測試執(zhí)行結(jié)果報告如圖10所示。該進路的碼序遍歷測試在 5 s 內(nèi)完成，擴展到全站時不超過10 min，用時遠小于人工測試，結(jié)果表明采用所提出的自動測試方案在案例生成和測試用時方面均遠小于人工測試，測試效率有顯著提高，驗證了該方案的可行性和有效性。

圖10 測試執(zhí)行結(jié)果報告

4 結(jié)束語

本文提出了一種列控系統(tǒng)室內(nèi)仿真自動測試平臺的設(shè)計方法，該仿真測試平臺實現(xiàn)列控中心系統(tǒng)數(shù)據(jù)配置的自動化測試，并提供直觀的測試結(jié)果，縮短了項目工程周期，通過計算機的自動計算代替人工計算，有效減少了人為失誤并節(jié)省了人力資源的投入，提高了效率。同時，積累了測試經(jīng)驗數(shù)據(jù)，通過逐步優(yōu)化測試案例算法，可挖掘測試盲區(qū)，保證測試質(zhì)量，有較高的工程應(yīng)用價值，減少了人工成本，提高了生產(chǎn)率。