基于CTCS標準及規范的系統功能測試評價系統

張毅楠 吳 昊

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

張毅楠，男，碩士畢業于清華大學，助理工程師，軟件開發工程師。主要研究方向包括綜合監測、故障診斷，曾參與十二五國家科技支撐計劃課題：全息化運行環境感知系統，及院科研項目：C3綜合測評系統的研究。

1 概述

目前我國的高速鐵路正處在快速發展的進程中。為保障行車安全，列車控制系統從設計開發至正式運營過程中有多個環節需要進行許多輪次的細致而周密的測試。對于我國高速鐵路上采用的CTCS-3級列車控制系統（以下簡稱C3系統）及其后備的CTCS-2級列控系統（以下簡稱C2系統），在實驗室內需進行系統功能測試（System Function Test，SFT）以驗證其功能是否滿足相關的技術標準及規范。這些技術標準和規范如表1所示。

表1 CTCS-3級列控系統功能測試所依據的標準和規范

表1中，第1到第7項為系統性標準或規范，第8到第11項為各子系統的標準或規范。

C3系統的系統功能測試的傳統流程中，各個測試步驟主要由專業的系統測試人員和子系統的專家來完成。對專業測試人員和專家的培養需要耗費大量的人力和時間，效率較低且不能保證測試人員個體所具備知識的準確性和全面性，所以難以保證通過測試能夠對C3系統的功能進行準確評價;另一方面，由于C3系統功能測試的測試序列數目龐大，操作比較復雜，測試過程中生成的日志數據繁雜多樣，在短時間內依靠人工進行分析和評價，工作強度大而且準確性低，無法及時發現系統潛在的問題。

鑒于傳統的C3系統功能測試的上述弊端，為了節省人力物力資源以及提高測試分析的效率，本文提出了一種將相關的標準和規范形式化描述為計算機能夠理解并處理的規則，并使用推理機系統輔助進行C3系統功能測試的方案，并研究了基于CTCS標準及規范的系統功能測試評價系統需要解決的主要技術難點，包括以下內容。

1）如何將C3級列控系統相關的標準和規范形式化描述為計算機能夠識別和處理的規則；

2）如何將產生于不同子系統、來源于不同監測途徑、格式不統一、數據量巨大的監測數據處理成為能被計算機快速高效處理的數據；

3）如何根據數據進行有效的推理，即如何讓輸入的監測數據驅動推理機內部狀態的更新，最終得到系統期望的輸出結果。

2 標準和規范的形式化表示技術

C3系統的相關標準和規范是C3系統設計和開發的基礎，也是系統測試和驗證的重要依據。表1中的標準和規范是用人的自然語言書寫的，若想讓計算機能夠識別和理解，需要將相關的標準和規范翻譯為計算機能夠理解的語言，即標準和規范的建模和形式化表示。目前已有許多專家學者在列控系統的標準和規范的建模和形式化驗證方面做了有意義工作[1-5]。但這些形式化表示的目的主要在標準和規范本身的檢驗方面，即通過建模驗證標準或規范本身是否完備，并未考慮到形式化表示的標準或規范供推理機使用的可能性，也未能將其應用于對列控系統或其中的子系統的功能評價。為此本文提出了一種新的形式化表示方法。

由于C3系統功能測試主要針對的是各子系統協同工作的情況，要求各子系統在成功建立連接后在規定的時間內向通信對方發送正確的數據，而這個過程中的時間間隔和發送的數據等正是由相關的標準和規范所規定的。所以為了對標準和規范進行建模，可以先把各子系統間發送和接收數據的過程用UML時序圖表示。以C3系統功能測試中的列車自動防護系統（ATP）呼叫無線閉塞中心（RBC）并在RBC中注冊的過程為例，其中參與的對象有列車司機、人機界面（DMI）、ATP和RBC，描述它們之間數據交互的時序圖如圖1所示。

UML時序圖可以很清楚地表示出消息在各對象間是如何發送和接收的，因此可以將標準或規范形式化表示為消息序列，亦即將標準或規范中的規定轉化為消息發送的時間、消息的內容等能夠量化表示的對象屬性，并將不同的消息組織成為序列，從而完成從標準和規范到計算機中對象的轉化。

消息序列中消息的組織也需要根據標準和規范確定。C3系統各子系統間消息的傳遞是有序的。消息的發送和接收在時間上有先后順序，在邏輯上有因果關系。此外在實現一個功能時，有些消息必須出現，有些消息則可有可無，而有些消息不允許出現。為了體現這些消息的不同，在對標準進行形式化的過程中，可將某一過程中涉及的消息分為3類。

1）必須出現的消息（required message）：這類消息在系統完成特定功能時必須在指定的時機出現。

2）可以出現的消息（optional message）：這類消息為可選的消息，可以在完成特定功能的過程中出現，也可以不出現。

3）不允許出現的消息（not allowed message）：這類消息不應在完成特定功能時出現，如果出現了這類的消息，則可判定系統的功能不符合標準和規范。

圖2顯示了required message的組織形式。對于optional類和not allowed類的消息，組織形式和required類的消息類似。

圖2中由若干個消息組成一個消息組（group），各個消息組中的消息是有先后順序要求的。若干個消息組組成一個測試階段（phase），同一個階段中的各個消息組間是沒有先后順序的，亦即是并行的。不同階段之間的消息是有先后順序的，亦即只有前一個階段結束，后一個階段中的消息才允許出現。

將C3系統各子系統間的消息按圖2所示的形式進行組織，即可覆蓋標準和規范中規定的消息之間的時序和邏輯關系，這樣就完成了與系統功能測試有關的標準和規范的形式化表示。

3 監測數據的預處理技術

基于CTCS標準及規范的系統功能測試評價系統面向的是C3系統線路級別的功能測試，測試過程中得到的數據或消息不僅來源多樣，而且數據量巨大。如果將這些數據不加處理地送往推理機進行處理，那么效率將受到很大影響。所以對于得到的監測數據，有必要進行預處理，去除消息中的冗余和不一致，保留有用的信息。

數據預處理的邏輯框圖如圖3所示。根據C3系統監測數據的特征，主要采用數據處理技術有數據集成和數據歸約。

首先將來自不同動態監測機的數據放入接收數據隊列，然后執行圖3中數據預處理操作。

數據集成的目的是解決來自不同監測源的代表同一概念的數據屬性的不一致和冗余。數據不一致包括格式不一致，也包括內容不一致。例如：來自不同監測源的數據所包含的時間戳格式不一致，而且時間會略有偏差。這就需要在數據集成階段將動態監測機發送消息的時間戳轉換成統一格式，并設置時間戳的值為數據預處理機的本地時間。

數據歸約的目的是減小數據規模。通過對周期性發送的重復數據進行歸約，可以避免重復發送大量的冗余數據，減小推理機的處理量，提高推理機的效率。

通過在進行推理之前對數據進行適當的預處理，可以顯著提高測試評價的總體質量，減少所需的時間。數據預處理后的數據將被放入發送隊列，等待發送給推理機，此時所有監測數據都已轉換為統一格式的消息。消息由以下幾部分組成。

1）發送方（sender）

描述消息的發送方。

2）接收方（receiver）

描述消息的接收方。

3）消息類型（type）

描述消息的來源，包括設備的名稱及網絡分層的名稱。如：聯鎖和RBC之間應用層通信的消息類型為：CBI_RBC_APP。

4）消息標識（id）

用于區分同一消息類型中的不同消息。如：ATP和RBC之間的應用層通信的消息類型均為PRI_APP，但不同的消息具有不同的id。如：ATP發送給RBC的列車位置報告消息的id為M136，RBC發送給ATP的行車許可消息的ID為M3。

5）時間戳（timestamp）

描述消息產生的時間。

6）變量（variable）

在消息中使用“變量名—變量值”的有序對描述的一個屬性。

7）信息包（packet）

在消息中表示信息的結構。例如消息類型為PRI_APP的行車許可消息（M3），包含信息包P27（靜態速度曲線）。在信息包P27中，還可以包含變量V_STATIC（線路最大允許列車行駛速度）等變量。

一個消息的示意圖如圖4所示。

4 數據驅動的推理技術

在第2節中介紹了標準和規范的形式化表示方法。在實際操作過程中，為了對C3系統的某一特定功能進行測試，往往把系統的某些基本功能單元編輯成子序列，如圖1中所示的ATP呼叫RBC并在RBC中注冊的過程就可以作為一個基本功能點被編輯成為子序列。編輯完成后的子序列是以消息序列表示的已經形式化的一條規則，該規則中包含有必須出現的消息定義、可能出現的消息定義、不允許出現的消息定義等。

當推理機收到經過預處理的消息時，通過關系運算和邏輯運算判定消息是否匹配，其流程如下。

1）將待評判消息中的消息發送者、消息接收者、消息類型、消息ID與預期結果消息中的相同字段進行逐一比較。如果相同，繼續下一步，如果出現不相同的項，則返回錯誤信息，表示不匹配；

2）以預期消息中所包含的每個變量的名稱作為鍵（key），在待評判消息中查找與該鍵對應的值（value），即變量值。如果能找到，則繼續下一步，否則，返回錯誤信息，表示不匹配；

3）分別取出待評判消息和預期消息中的該變量所對應的值，如果預期消息中的該值以“>”、“<”、“!”、“>=”、“<=”等關系運算符開始，則對這兩個值進行關系計算；否則，判定兩個值是否相同。若關系運算的結果為真或兩個值相同，繼續下一步。否則，返回錯誤信息，表示不匹配；

4）對消息中的信息包依次進行2)～3)步的判定流程；若結果為真，返回匹配，繼續進行評判。否則，返回不匹配。

對于不允許出現的消息的匹配過程，與上述過程類似，只是其中的邏輯相反，即：若值不相同，則進行下一步。否則，返回不匹配的結果。

在推理機對必須出現的消息和不允許出現的消息進行推理匹配的同時，推理機還需要對消息進行老化處理，老化過程從順序性和時效性兩方面對消息的正確性進行評估，用以驗證消息發送的次序和超時時間。

5 討論

基于CTCS標準及規范的系統功能測試評價系統可針對實時監測到的數據進行推理和評判，并對系統的功能表現是否符合標準和規范給出建議。此外，還有許多值得深入研究的方向，比如：C3系統運行狀態數據的集成及記錄技術，數據優化存儲、管理和查詢技術，測試評價結果的集成展現技術等。通過深入研究可以使未來的測試評價系統具備根據歷史運行數據進行評價的功能，并能通過圖形、圖像、表格等豐富的手段直觀化地展示評價的結果。

6 結論

確保列控系統安全穩定地運行關乎人民的生命財產安全和國家交通運輸動脈的暢通。本文所述的基于CTCS標準及規范的系統功能測試評價系統，可以提高系統功能測試階段的故障分析和診斷的效率，能輔助測試人員對列控系統的功能給出科學、綜合的評價，對高速鐵路列控系統的不斷發展完善和應用具有積極的意義。

[1] MCDERMID J. Issues in the Development of Safety-critical Systems[C]. Proceedings of Safety-Critical Systems: Current Issues, Techniques and Standards. Chapman & Hall: 1993: 16-42.

[2] LINDERBERG J F. The Swedish State Railway’s Experience with N-Version Programmed Systems[C]. Proceedings of Directions in Safety-Critical Systems Conference. Springer-Verlag: 1993: 36-42.

[3] HANSEN K M. Validation of A Railway Interlocking Model[C]. Proceedings of FME’94: Industrial Benefit of Formal Methods. Lecture Notes in Computer Science. Barcelona, Spain: Springer-Verlag, 1994: 582-601.

[4] LAERS H E. Specifying Railway Interlocking Requirements for Practical Use[C]. Proceedings of SAFECOMP’96. Vienna, Austria, 1996:74-80.

[5] ERIKSSON L H. Formal Method in Development and Testing of Safety-Critical System: Railway Interlocking System[C]. Proceedings of SAFECOMP ’96. Vienna, Austria: 1999: 35-41.

[6]陳封能, 斯坦巴赫, 庫瑪爾. 數據挖掘導論[M]. 范明, 范宏建，譯. 北京：人民郵電出版社，2011.