簡談列控中心仿真驗收測試

王 猛

(北京鐵路信號有限公司，北京 102613)

在新建線路的開通前，為確保高鐵列車安全運行，提高運輸效率，需要對TCC軟件的功能及邏輯關系進行遍歷測試, 旨在及時發現TCC軟件中的缺陷或漏洞，杜絕將存在問題的軟件應用于現場實際運行的高鐵線路上。必要的軟件測試可大大減少現場軟件發生故障的概率，只有經過測試合格的軟件方能用于現場調試或開通，從而確保線路的穩定運行。現場硬件設備復雜、實驗條件受限，因此列控中心軟件的測試以室內仿真平臺測試的方式為主。從平臺規劃、平臺架構、測試流程、常見問題及處理方法等幾個方面來闡述仿真測試的必要性與實際意義。

1 TCC軟件仿真驗收平臺構成

1.1 仿真平臺簡述

TCC設備根據現場實際需求可大致劃分為：大型車站、標準車站、線路所、轉換站、動車所、中繼站等。由于現場設備種類繁多，不同車站的硬件數量不一致、各設備間通信線纜錯綜復雜、現場實驗條件等因素受限，為有效解決上述問題，可通過搭建仿真測試平臺實現對現場真實硬件設備的模擬，其涵蓋了現場全部真實硬件功能，可達到預期的測試效果，成功的將現場環境搬進了實驗室。本文介紹的仿真測試平臺可實現TCC兩大模塊的數據測試，即CTCS-0級和CTCS-2級的仿真測試。CTCS-0功能主要包括：列車進路碼序、低頻信息、載頻信息、邊界碼序傳輸、改方功能等；CTCS-2功能主要包含：臨時限速測試、應答器報文測試等。上述模塊所包含內容均可通過仿真平臺進行驗收測試。TCC產品軟件仿真驗收測試平臺模型如圖1所示。

圖1 TCC產品軟件測試仿真平臺模型Fig.1 TCC product software test simulation platform model

1.2 測試平臺構成

根據1.1仿真驗收測試平臺的建模構成不難看出，在進行TCC軟件驗收測試時，如果對外接口全部為真實設備，會造成實驗室設備數量過多、實驗環境復雜、效率低下。因此，通過使用仿真軟件將列控系統部分模塊與外部接口進行模擬，最大程度優化設備構成，提升驗收測試效率，降低設備成本。仿真測試系統可模擬ZPW-2000A軌道電路系統、計算機聯鎖、調度集中（CTC）、臨時限速服務器（TSRS）、地面電子單元（LEU）、應答器等設備。通過使用仿真平臺軟件，為TCC軟件的邏輯功能及接口測試帶來了極大方便。實驗室仿真驗收測試平臺測試環境如圖2所示。

仿真驗收測試平臺面向列控中心設備。實驗室TCC主機單元及各模塊板卡與現場硬件設備保持一致，所有對外接口設備都可通過仿真軟件進行模擬。如臨時限速服務器（TSRS）、相鄰車站、集中監測(CSM)均通過以太網與待測TCC建立通信；應答器報文信息、ZPW-2000A軌道電路、CTC可通過CAN總線與待測車站建立通信；驅動和采集信息通過仿真機上的專用通信板與待測車站建立數據通信。

根據仿真測試系統環境搭建要求，驗收測試的TCC軟件、工程數據均需要按照現場實際要求執行。例如搭建9套真實的TCC主機單元為被測對象，可以滿足3組驗收測試人員同時進行“三站兩區間”的驗收測試，測試環境如圖3所示。

圖2 仿真驗收測試平臺示意圖Fig.2 Schematic diagram of simulation acceptance test platform

圖3 仿真測試平臺界面Fig.3 Simulation test platform interface

仿真機分別通過光纖通道、以太網通道和CAN通道與待測TCC通信，針對驅動采集單元、ZPW-2000A軌道電路、計算機聯鎖、臨時限速服務器、應答器報文信息等接口設備仿真。相鄰車站通過以太網交換機與被測主機建立數據相連，可實現TCC的改方功能、鄰站邊界碼序的傳輸等功能。臨時限速服務器通過以太網交換機與待測TCC建立通信，其主要功能是為TCC下達初始化命令和臨時限速信息，為接下的報文與臨時限速測試環節提供便利條件。

2 軟件驗收測試過程

2.1 測試前準備工作

1）制定方案

根據各路局電務段所提出驗收需求，梳理出現場工程項目的迫切程度，由技術人員結合實驗室硬件平臺分布及使用情況，制定出詳細、合理、高效的驗收測試方案。合理的驗收方案可提升仿真測試效率，同時，可滿足多家鐵路局電務段人員同步進行此項測試工作，為現場項目的順利開通奠定堅實的基礎。

2）數據調試

測試所需數據包括待測軟件、被測站數據庫信息、工程數據，技術人員在收到這些數據后，需要對軟件版本號、發布日期信息進行核實并記錄，同時創建所需測試環境方案，以保證完整無遺漏。接下來對設計方提供的數據庫文件進行木馬查毒，并通過專用存儲設備將數據庫導入至測試服務器，直至測試環境調試穩定。

2.2 搭建被測軟件仿真平臺

搭建測試環境是軟件測試實現的重要階段，測試環境是否合適將嚴重影響測試結果的真實性和正確性。根據實際測試需求及測試進度計劃，搭建“輔助-待測-輔助”的三站兩區間測試模型。該測試模型覆蓋到中間待測車站列控中心軟件的全部運算邏輯及功能，較好闡述測試的意義及重要性。測試的主體為列控中心軟件，通過仿真機以及外部通信接口等設備實現系統測試平臺。若搭建過程中遇到數據或軟件邏輯問題，由技術支持工程師分析問題原因或將問題反饋至軟件設計方，由其進行確認是否存在缺陷，直至仿真環境搭建完結。

2.3 仿真測試項目

電務段測試人員根據事先準備好的測試記錄表，針對列控中心軟件所包含的全部功能進行遍歷性測試。測試記錄表中的測試項主要包括：改方功能測試、進路碼序測試、應答器報文測試等。下面重點介紹仿真測試所涉及的幾個功能模塊。

改方功能測試：列控中心通過站間安全數據網實現與相鄰車站數據通信，對區間的運行方向協同管理。在雙方列控中心確認可以改變區間運行方向時，才允許聯鎖辦理發車進路。處理機制符合故障-安全的原則，保證相鄰車站不處于敵對運行方向。從而實現車站線路運行方向的改變。

進路碼序測試：列控中心根據列車在區間的走行邏輯，對軌道電路占用、空閑、故障占用、失去分路狀態進行判斷和報警，并采取必要的防護措施。對于站內軌道電路編碼，根據辦理的進路及前方進路狀態，按照軌道電路編碼邏輯，產生對應于各個軌道電路的低頻碼。實驗人員根據對應軌道區段的低頻碼序與測試表格進行核對，從而驗證列控主機軟件邏輯的正確性。

應答器報文測試：根據聯鎖進路狀態選擇與之對應的進路信息報文，通過LEU向對應的進站口應答器傳送，從而向車載設備發送進路參數，包括應答器信息幀、進路軌道區段長度、線路坡度、應答器鏈接、特殊區段、臨時限速、大號碼道岔信息包等。

2.4 問題反饋

在進行仿真測試過程中，當電務段測試人員發現軟件存在疑問或缺陷時，應及時向技術支持人員反饋，由技術支持人員對問題進行初步判斷，確定其是否為軟件缺陷。若軟件確實存在設計缺陷，則應按要求填寫問題反饋單，將反饋單發送至軟件設計方。待設計方修改軟件完畢后，由技術支持人員重新換裝軟件進行仿真測試，直至測試結束，如圖4所示。

圖4 測試流程圖Fig.4 Test flow chart

3 常見測試故障及解決方法

在仿真驗收測試過程中，會反饋一些測試結果與電務驗收人員預期不一致的情況。一般情況下，按照如下順序檢查，可以高效的定位故障：

1) 測試臺硬件設備故障排查；

2) 仿真測試環境版本的確認；

3) 測試輸入文檔的有效性確認；

4) 仿真測試環境的誤操作排查；

5) 被測軟件錯誤排查。

3.1 測試臺硬件設備故障排查

在硬件設備的故障排查時，應先行確認列控中心主機單元的工作狀態。可通過觀察各板卡面板指示燈，輔助判斷硬件板卡的工作狀態；在確認主機單元工作正常后，可調試仿真設備與列控中心的通信狀態，如驅采仿真與列控中心的通信、聯鎖仿真與列控中心的以太網通信、CAN總線仿真設備與列控中心的CAN總線通道狀態。

上述的各類通信狀態，在列控中心的監測機中均有顯示。建議在硬件調試時，搭建相應列控中心的監測機，可以方便硬件設備的故障排查和故障定位；在進行測試過程中，搭建臨時測試環境時會出現重復性的“安裝-拆除”環節。此過程極易造成通信中斷、數據丟失、設備重啟等故障現象。根據設備的通訊方式進行判斷，將故障點定位后，再根據線纜類別進行逐一排查，可以快速恢復仿真測試環境。

軌道電路、LEU、CTC均通過CAN通道與TCC主機建立數據通信，但彼此的傳輸數據內容不一致。由于仿真機CAN卡性能的限制，在測試中可能會出現數據信息不穩定、碼序波動現象。為了避免此類問題出現，可根據實際需要將不同設備的數據通道設置在不同的CAN通道中，從而解決上述測試過程中遇到的問題。

3.2 測試軟件或數據缺陷

仿真測試環境版本確認：仿真測試環境是由列控中心系統硬件平臺、列控中心軟件、仿真測試系統軟件、仿真測試數據組成，其中列控中心軟件為被測對象，其他為測試環境。在確認列控中心系統硬件平臺工作正常后，便需要對仿真測試系統軟件的版本、仿真測試數據確認。

由于在電務驗收前，廠家已經完成了內部測試，故仿真測試系統軟件和仿真測試數據應與廠家內部測試時保持一致。

測試輸入文檔的有效性確認： 在仿真驗收過程中，電務驗收人員以設計出的設計資料為依據、結合鐵路信號技術規范、列控中心相關的技術條件等，形成預期結果，用來評價被測列控中心軟件。但有時由于驗收人員手中的設計文檔與廠家的設計文檔存在差異，導致預期結果的偏離。所以，在測試之前，與驗收人員核實設計文檔的版本顯得極為重要。

仿真測試環境的誤操作排查： 在列控中心系統工作正常、仿真系統軟件版本和數據版本與廠家內部測試所用版本一致時，首先考慮仿真測試環境的誤操作。常見的情況如下：

誤關閉了仿真的某些模塊，導致仿真部分功能缺失；

誤設置了PIO的驅采、IP通信模式（真實IP或虛擬IP），導致列控中心系統與仿真系統交互異常；

誤設置鄰站站間信息，導致改方、碼序追蹤等功能異常；

誤設置保持了一些繼電器的采集狀態，導致列控中心監測該繼電器驅采異常，觸發相應的軟件防護機制；

誤設置了仿真聯鎖始端信號機點燈，導致列控中心無法正常編碼。

當上述情況出現時，可從列控中心軟件的響應結果，來推測可能的誤操作情況，如列控中心無法正常改方，需要檢查IP通信模式、鄰站站間信息、PIO仿真的采集是否到位；列控中心無法正常完成進路編碼，應優先查看聯鎖點燈、進路上各區段的FQJ的采集是否到位。

被測軟件錯誤排查：在上述硬件檢查、環境檢查、設計文檔的一致性檢查都完成后，若被測軟件仍然存在功能異常，可考慮進行軟件錯誤排查。考慮廠家內部測試完成后才進行仿真驗收測試，故軟件自身的缺陷可能性較低，建議先從接口部分入手。常見的兩類問題如下。

1）列控中心進行接口測試時，會出現列控中心與CTC設備無法建立正常通信的情況。由于客專列控中心和CTC協議版本的唯一性，若確認硬件通道無問題后，考慮雙方接口配置不一致性的問題。優先進行雙方軟件通信參數、數據版本的比對，往往可以高效的定位問題。

2）實驗室搭建列控系統仿真平臺后，列控與聯鎖始終無法完成正常通信。優先確認以太網物理通道，通過8K數據區的數據判斷聯鎖與列控之間通道狀態，若物理通道正常、邏輯通道通信中斷，建議使用wireshark等網絡抓包工具，獲取列控傳給聯鎖、聯鎖傳給列控的UDP數據包，檢查RSSP-1協議是否校驗通過、檢查數據版本和協議版本的一致性。

4 結束語

文中介紹的仿真驗收測試環境準備與故障排查方法適用于列控中心仿真驗收測試，提出的測試流程及方案將在今后的實際運用中不斷優化。這一方法還將用于具有自主知識產權的自主化列控產品的仿真測試中，希望能對類似測試有所幫助。