基于通信的列車控制系統（CBTC）測試方法研究與設計

孫曉光 侯 磊（北京全路通信信號研究設計院有限公司，北京 100073）

孫曉光，男，碩士畢業于清華大學，助理工程師。主要研究方向包括軟件開發、系統測試，曾參與CBTC項目。

隨著城市軌道交通的飛速發展，基于通信的列車控制系統（CBTC）由于其安全高效和易于維護，已經成為現今城軌交通領域占主導地位的城軌列車控制系統。CBTC系統融合先進的通信技術、列控技術、計算機技術，進行行車控制、指揮和管理，基于高精度高冗余的車地雙向通信實現移動閉塞的列控機制。CBTC列控系統遵循故障導向安全的設計理念，系統安全相關功能須具備SIL4安全完整性等級，因此在系統全生命周期，需進行包括軟件單元測試、子系統測試、系統集成測試、工程測試等多層級全面嚴格的驗證測試工作，其中，系統集成測試是系統驗證的最直接有效手段，系統集成測試質量決定了系統的研發效果，進而影響工程產品的質量安全水平。

本文重點研究CBTC系統仿真測試的特點，分析仿真測試環境的針對性需求和方案特色，提出CBTC系統集成測試理論體系。結合實際CBTC測試項目，具體介紹測試案例的設計策略。

1 CBTC系統簡介

CBTC系統利用無線設備進行雙向車地通信，實現列車的移動閉塞控制，具有追蹤間隔小、列車控制精確、安全性高、易維護等特點。CBTC系統主要由列車自動防護系統（ATP）、區域控制器（ZC）、計算機聯鎖（CBI）、列車自動運行系統（ATO）、列車自動監控系統（ATS）、數據通信網絡組成，其典型系統結構如圖1所示。

ATP、ZC、CBI主要用于列車運行安全防護，防護與撞車、側沖、超速及其他危險源相關的安全事件。ATO在ATP的防護之下，提供自動控車功能。ATS主要用于列車運營調度，并提供系統狀態信息，監控各子系統功能。數據通信網絡用于設備間雙向通信。

2 CBTC系統測試環境

CBTC系統最好的測試驗證環境是理想化的現場環境，但是現實中現場測試存在如下問題：1）現場測試人工、費用成本很高，且時間周期長；2）現場測試不可知因素較多，容易出現事故；3）現場測試不利于監測設備間通信數據和故障模擬；4）現場往往不具備系統功能全面測試所需的所有場景。因此采用實物與仿真相結合的半實物測試環境尤為重要。通過仿真與實物相結合的方式，既在一定程度上模擬了實際場景，又兼顧了系統測試的可行性、全面性。

CBTC系統測試環境主要由半實物仿真測試運行系統、綜合監控系統、綜合測評系統3部分組成。CBTC系統測試環境總體結構如圖2所示。

半實物仿真測試運行系統，通過實物接口平臺將實物設備接入仿真系統，通過數據協議的解析和轉換，實現模型和實物系統的無差異接入，以及虛實互換和虛實互控功能。

綜合監控系統，利用半實物仿真運行系統提供的監控接口實現對系統運行設備及接口的狀態和數據監測，以及操作控制命令的下達。

綜合測評系統，是面向集成測試和故障診斷等實際應用的系統，實時動態顯示實物設備與實物設備、實物設備與仿真系統的連接情況。

結合CBTC系統車地雙向通信量大、移動閉塞、追蹤間隔小、列車控制精確、實時性要求高的特點，CBTC系統測試環境添加較多的數據監測機制和故障注入方式。

數據監測主要包括ATP與ZC通信監測、ZC與CBI通信監測、ZC維護監測、ATP維護監測、ATO維護監測，無線通信監測、安全通信維護監測。數據監測為CBTC系統測試提供了除實物設備動作以外的觀測點。通過數據監測，可以直觀的觀測實物設備間的交互數據。

1）ATP與ZC通信監測用于觀察記錄ATP與ZC之間的通信數據，如ZC向ATP發送的移動授權數據、列車回庫注銷時ATP與ZC的交互數據。

2）ZC與CBI通信監測用于觀察記錄ZC與CBI之間的通信數據，如CBI向ZC發送的計軸區段狀態、ZC向CBI發送的邏輯區段狀態。

3）ZC維護監測用于觀察記錄ZC設備接收發送的所有信息，可通過回放的方式重現測試場景。

4）ATP維護監測、ATO維護監測用于觀察記錄ATP、ATO動作信息及接收發送的數據。

5）安全通信維護監測用于觀察記錄ZC與ATP通信中安全層的連接信息，如列車通信中斷后重新連接ZC時安全連接建立情況。

6）無線通信監測用于觀察記錄無線通信情況，如無線信號強度。

為了便于系統故障模擬，營造故障場景測試條件，CBTC系統仿真測試環境集成了多種故障注入機制。故障注入主要包括故障數據注入、通信故障注入和接口不穩定性故障注入。

1）故障數據注入主要體現在模型的數據輸入不符合設備預期，數據的完整性和準確性出現異常，如應答器數據錯誤。

2）通信故障注入主要體現在各設備模型之間通信連接和通信傳輸的故障，如車-地無線通信故障、設備接口故障等。

3）接口不穩定性故障注入主要體現在設備模型間通信的接口的不穩定給模型功能執行的故障，如ATP速度傳感器斷線等。

故障注入主要通過仿真平臺、無線加擾、設備實物連接等方式實現。仿真平臺，可以模擬部分在現場試驗中無法進行的故障場景，提高系統測試的全面性和可靠性，如列車溜逸、計軸設備故障等。無線加擾可以在實驗室模擬真實線路無線信號強弱變化的特點，根據實際測量的線路信號強弱變化，對無線信號進行了加擾，模擬真實線路的實際無線情況。設備實物連接可以在實驗室模擬實物設備故障、設備間通信中斷等場景，如CBI設備故障、ZC與CBI通信中斷、ATP速度傳感器斷線等。

3 CBTC系統測試理論體系

測試案例生成是系統測試的關鍵問題，本章主要研究了適用于CBTC系統測試的測試案例生成方法，并且給出了應用此方法生成測試案例的實例。

在進行系統測試案例編寫之前，首先需要分析系統需求規范中需求條目的可測性，結合室內仿真測試條件，確認可以通過系統仿真測試進行驗證的系統需求子集，作為后續工作的輸入。

然后，根據CBTC系統需求規范劃分功能實體，提取具體的功能特征點，針對各功能特征點結合CBTC系統測試特點進行細化生成案例描述，進而生成每個功能特征點對應的測試案例。

最后，結合線路數據串聯測試序列，作為系統集成測試執行的依據。

在功能點、測試案例、測試序列的編寫過程中，需進行多級文檔之間的追溯工作，維護多級工作對系統需求規范的追溯，以及彼此的追溯關系，保證所有具備可測性的需求條目真正被測試案例和測試序列覆蓋，并在后續的測試執行中被驗證。

各模塊間追溯關系如圖3所示。

功能特征列表需建立每個功能特征點對需求條目的鏈接追溯關系。每個功能特征中包含的需求條目是其包含的測試案例追溯需求條目的集合，即每個功能特征追溯的需求條目必然被其包含的一個或多個測試案例追溯。

交叉引用表統計需求條目和功能特征列表之間的交叉引用關系（通過功能特征列表到需求條目的鏈接關系得到），用于證明功能特征列表對可測需求子集的完全覆蓋。

測試案例需建立其對系統需求條目的鏈接追溯關系，以及與功能特征列表的追溯歸屬關系。

測試序列需建立其對測試案例的鏈接追溯關系，保證每個測試案例至少被一個測試序列覆蓋，如出現部分測試案例無法被追溯的情況，必須清楚說明該情況，如由于線路數據限制，部分案例可能暫不能進行測試。

3.1 功能特征點

CBTC系統測試立足于系統需求規范，由于需求數量眾多，且部分需求條目較為細致，針對具體功能的描述存在重疊和重復的現象。若針對每條系統需求編寫測試案例，測試案例數量較為龐大，且存在重復工作的可能。另外，部分需求較為概括，需要劃分至具體的功能進行測試。為了解決上述問題，通過功能特征點歸納系統功能，對已篩選確定可測的需求條目進行重新劃分，保證每一條需求至少在一個功能特征點中得到反映。每個功能特征點是一組需求的集合，追溯一條或者多條系統需求條目。

在功能特征點提取過程中，根據CBTC系統結構劃分功能實體，分割各子系統的功能點，逐步細化，形成相對獨立、基礎的功能特征點。CBTC系統測試功能點按照子系統進行歸納，分為車載ATP子系統、ZC子系統、CBI子系統、ATS子系統、ATO子系統，然后根據系統需求逐步細分。

在功能特征點的歸納總結中，還需注意以下幾個地方：1）需為每條功能點均分配一個唯一的功能點編號，方便后續對功能點的追溯統計；2）需明確每條功能點適用的車載設備運行等級和模式；3）需建立對系統需求條目的追溯。

CBTC系統測試功能點的列表格式如表1所示。

表1 CBTC系統測試功能點示例

3.2 測試案例

測試案例根據功能特征點進行編寫。通過分析功能特征點的可能場景，將功能特征點拆分為若干分支流程，然后通過用例圖、狀態圖等輔助措施，從不同角度描述功能特征點對應功能的整個過程，最終結合CBTC系統測試中用于驗證和觀測的可見接口，如ZC-ATP通信等監測數據、CBI控顯、ATS控顯等，形成案例描述。案例描述是對測試案例中測試內容的概括，通過對案例描述進行擴展，可以生成測試案例。生成測試案例的詳細步驟如下：

步驟1：根據功能特征點，分析可能的場景，形成用例圖等；

步驟2：根據可能場景，確定相關設備；

步驟3：根據相關設備，確定可測性及觀測接口；

步驟4：根據可能場景和可測性，形成案例描述；

步驟5：根據案例描述，確定測試案例的詳細步驟、觀測接口、預期結果等。

選取ATP的功能點“ATP接收移動授權”為例，分析ATP接收移動授權的可能場景，可確定該功能點主要與ZC設備有交互。通過ATP與ZC的接口監測數據可以觀測ATP接收移動授權的情況，形成案例描述，部分案例描述如表2所示。

表2 CBTC系統案例描述示例

最后，根據活動圖將案例描述的場景進行細化，按照測試案例模板形成測試案例。測試案例主要包括以下內容：

1）被測對象：本案例測試目的涉及的對象設備（車載或地面子系統）。

2）所屬的功能特征：每一個測試案例都是針對某一個功能特征設計出來的，用于測試其所屬的功能特征。

3）測試的系統需求：每一個測試案例都測試了系統需求規范中的某條需求，必須標明。4）測試方法：包括測試步驟、如何檢驗測試結果。5）易于理解的測試環境：測試包括測試所處的模式等級，各接口的狀態條件。

6）測試執行的結束標準：測試案例執行結束時所處的狀態，產生的影響。

3.3 測試序列

CBTC系統主要包括車載ATP子系統、ATO子系統、ZC子系統、CBI子系統和ATS子系統。測試序列的組織采用先焦點后全面的順序進行。首先依次以車載ATP子系統和ATO子系統為焦點，組織測試序列，并對測試案例進行追蹤統計，此過程將覆蓋所有車載ATP子系統和ATO子系統相關測試案例集，以及大部分ZC、CBI、ATS子系統相關測試案例；接下來，依次針對ZC、CBI、ATS子系統未被覆蓋的測試案例，組織測試序列，對測試案例進行鏈接統計，保證測試序列全面覆蓋測試案例集。

車載ATP子系統和ATO子系統可采用內部狀態串聯方法，組織測試序列。內部狀態串聯方法的要點在于定義子系統內部狀態集，內部狀態集覆蓋所有可能的等級/模式組合。兩個內部狀態之間的轉移稱為一個狀態轉移路線。一旦定義好狀態轉移路線后，通過將模式與（或）等級狀態轉移路線中指定的或者相關的測試案例進行串接，從而形成狀態轉移路線中的測試子序列集。

對測試案例進行串接時，需同時參照測試案例起始和結束的外部接口狀態和其他子系統狀態描述，防止出現CBTC系統設計無法實現的狀態轉移。

內部狀態串聯方法的序列串接過程，需確保所有測試子序列被至少使用一次并且使測試子序列的使用數量達到最少。

完成車載ATP或ATO子系統序列串聯之后，需使用ZC、CBI、ATS子系統等相關子系統的測試案例，對序列測試案例中子系統相關接口測試步驟進行替代，并追蹤鏈接對應測試案例和需求。

針對ZC、CBI、ATS子系統未被覆蓋的測試案例，采用枚舉方式，串聯測試案例，組織測試序列，保證對測試案例和需求集的完全覆蓋追蹤。

此外，串聯測試序列時需考慮線路數據的實際情況，分析確定線路中的特殊位置，如建立定位點、完成頭篩點、列車升級點、站臺區段、折返區段等。

4 結束語

CBTC系統測試對系統的安全運行提供必要的保證。在CBTC系統開發與研制項目中，基于CBTC系統仿真環境和相關測試案例、測試序列，可行性得到驗證，測試效果顯著。

[1] A.Gohler, Eh.Frerichs,E.Fernandez,et al.ERTMS/ETCS SUBSET-076-0 2.2.3, ERTMS/ETCS Class 1 Test Plan[S].2005.

[2] Meyer zu Hoerste,Stefanie schwartz,Jorge lglesias,et al.ERTMS/ETCS SUBSET-076-4-1 1.0.0, ERTMS/ETCS Class 1 Test Sequences Generation：Methodology and Rules[S].2003.