基于雙總線的城市軌道交通列車網絡主控設備冗余控制設計

張增一 宋 揚 魯振山

（1.中車大連電力牽引研發中心有限公司，116052，大連；2.動車組和機車牽引與控制國家重點實驗室，116052，大連∥第一作者，工程師）

由于列車運行環境復雜多變，TCMS（列車控制與管理系統）在運行過程中需應對氣壓、溫差、空氣質量以及電磁環境等多重因素瞬時突變造成的影響。因此，除對設備及通信線路進行更高等級的防護，以及執行更嚴苛的試驗測試標準外，通常采用冗余設計以保證系統安全和穩定地實現其通信管理及控制功能。本文利用在研項目的帶高速智能網絡系統的某城市軌道交通車輛配置的兩種車輛控制總線所搭建的數據交互環境，研究網絡主控設備列車中央控制單元（CCU）對于自身及冗余設備運行異常、通信功能異常等狀態進行高速判別，并進行準確應對處理的有效實現方法，提出基于雙總線的雙級熱備冗余控制的設計思路，以實現TCMS 運行安全性能的進一步提升。

1 網絡主控設備

在研項目帶高速智能網絡系統的某城市軌道交通車輛，其列車4 節編組結構為：1 節帶司機室動車+1 節拖車+1 節帶受電弓拖車+1 節帶司機室動車。TCMS 采用編組以太網（ECN）和多功能車輛總線（MVB）兩種車輛總線拓撲結構。列車各設備均通過兩種總線進行數據交互，默認采用高速的ECN 總線作為首選數據信任總線，MVB 為冗余總線，并同時提供相關人機交互接口用于首選控制線設置及切換。

在該項目中，ECN 總線采用TRDP（列車實時數據協議）中的數據協議棧進行實時數據傳輸。2015年7 月出臺機車車輛使用的工業以太網標準IEC 61375-2-3（Edition1.0）［1］，其定義ECN 的4～7 層都將使用專為鐵路用途開發的自主協議TRDP，并通過行業團體TCNOpen 以開源的形式公開。TRDP的協議棧在以太網中所處位置如圖1 所示［2］。

CCU 作為TCMS 核心部件，負責整車網絡管理和車輛運行控制功能。該項目列車裝配2 臺互為冗余的CCU，其中1 臺作為冗余設備（從CCU）處于熱備狀態，實時檢測主CCU 狀態，確保在主CCU發生故障時能夠迅速接管主CCU 全部功能，以持續保證系統功能安全運行。

圖1 TRDP 在ECN 機構中的位置

CCU 的硬件部分采用低功耗嵌入式PC/104 結構的工業計算機104-1645CLDN-（24B）板卡，集成了AMD LX800CPU、256 MB 的DDR、1 個PC/104擴展接口、1 個10/100 Mbit/s 自適應網口、1 個IDE接口、2 個串口、USB2.0 接口等［2］；軟件部分主要包括底層系統軟件和上層應用軟件，前者是后者的操作系統平臺，采用基于x86 硬件平臺的VxWorks 多任務實時操作系統，進行軟件輸入輸出映射管理、內存管理、任務調度等功能，是本研究中實現雙級熱備冗余控制的主要研究對象。

2 雙級熱備冗余控制

所謂雙級熱備冗余控制，即在配置兩種控制總線的列車上通過優化CCU 底層系統軟件設計，使CCU 同時實現數據接收總線間的總線級冗余控制，以及主、從CCU 間的設備級冗余控制功能。通過對總線和設備的雙級冗余處理，分別對通信總線突發的暫時性通信異常以及設備部件功能性故障進行應對處理，使系統運行得到更高效、全面的保護。

2.1 CCU 的總線級冗余控制

本項目采用MVB 和ECN 雙總線數據交互的車輛控制總線配置方式，實現整車設備通信功能。CCU 通過雙總線同時向其他設備發送數據，并將由雙總線接收的數據分別進行緩存處理，默認優先選擇ECN 總線作為數據信任總線，也可通過人機交互界面對數據信任總線進行選擇。CCU 實時監視對比兩個總線接收的緩存數據，判斷總線數據健康狀態，并選擇處于健康狀態的數據作為CCU 邏輯運算輸入結果，實現總線級冗余控制。

2.1.1 總線冗余實現方式

在項目設計階段，為使上層應用軟件對設備接收數據的處理不受數據總線選擇的影響，開發者會對兩種通信接口協議進行統一編制，并分別生成MVB 和TRDP 通信配置文件。

MVB 通信配置了CCU 各端口源宿屬性、端口號、端口大小及特征周期4 種參數，并根據主、從CCU 通信性質分別進行配置。CCU 底層軟件將在啟動后的初始化過程中讀取MVB 通信配置文件，并依據其中的端口號大小自動排列端口順序，再結合端口大小計算出各個端口數據的內存偏移地址。底層軟件在輪詢各端口并讀取端口數據后將按照該內存偏移地址將數據依次映射在分配好的內存空間內，完成MVB 數據緩存。

TRDP 通信配置了CCU 數據通信各數據包相關的數據源設備、源設備IP 地址、宿設備IP 地址、數據包ComId、數據包源宿類型、數據量、偏移位置以及特征周期等8 種參數。CCU 底層軟件將在啟動后的初始化過程中讀取TRDP 通信配置文件，并依據文件內各宿類型數據包偏移位置大小自動排列，同時按順序為每個數據包創建1 個socket（套接字）。底層軟件在輪詢socket 并讀取接收到的數據后，將按數據包規定的內存偏移地址將數據依次映射在分配好的內存空間內，完成TRDP 數據緩存。

由于MVB 和TRDP 均嚴格規定了數據偏移位置，在兩個數據總線通信狀態完全正常時，兩個數據緩存區內數據內容應一致。而在數據信任總線受到干擾時，CCU 按照當前信任總線確定1 個數據集合單元，并以該數據集合單元為單位，對兩個總線數據緩存區內的數據內容進行健康狀態對比，以非信任總線中健康的數據集合單元對信任總線中不健康的數據集合單元進行替換處理，實現更高效的數據總線來源切換。數據接收雙總線冗余的軟件執行邏輯如圖2 所示。

本設計中，CCU 按照不同的信任總線確定用于作為數據冗余單位的數據集合單元，各數據集合單元標定在2 個數據緩存區索引數據的內存偏移地址和數據長度。當MVB 總線為信任總線時，CCU 以MVB 通信配置的數據端口作為數據集合單元，并在緩存區內分別對各端口接收的數據進行健康狀態判斷，對于非健康數據以數據端口對應內存偏移作為索引地址在非信任ECN 總線數據緩存區內進行索引，并進行數據冗余處理；當ECN 總線為信任總線時，CCU 以TRDP 通信配置的各數據包作為數據集合單元，并在緩存區內分別對各數據包對應socket 接收的數據進行健康狀態判斷，對于非健康數據以數據包對應內存偏移作為索引地址在非信任總線MVB數據緩存區內進行索引，并進行數據冗余處理。

總線級冗余功能嵌入在CCU 底層軟件的主應用任務中執行，執行周期為20 ms。

2.1.2 MVB 數據健康狀態判斷

MVB 為信任總線時以數據端口為數據集合單元進行數據冗余處理。CCU 通過對比每個端口刷新時間與其對應的健康判斷時間，進行MVB 端口數據健康判斷。在本設計中每個端口健康判斷時間與其端口特征周期存在對應關系，具體如表1 所示。

圖2 數據接收雙總線冗余

表1 MVB 端口特征周期與健康判斷時間對應表

各端口健康判斷時間以該端口特征周期乘以對應判斷系數N 而得出。當端口刷新時間未超過其對應的健康判斷時間時，視為該端口數據處于健康狀態；反之，則視為該端口數據處于非健康狀態，按照該數據集合單元標定的內存偏移地址和端口大小，在TRDP 數據緩存區索引對應數據，并進行數據替換處理完成數據冗余。

2.1.3 ECN 總線數據健康狀態判斷

ECN 總線為信任總線時以通信配置的各數據包為數據集合單元進行冗余數據處理。在TRDP 通信配置階段，已經將各子設備向CCU 的數據通信配置在不同的socket 進行接收，通過輪詢每個socket實現在同一周期內對全部子設備發送數據進行接收。對于讀取出的數據分別進行解析、校驗，并將數據向TRDP 數據緩存區進行映射，同時判定該數據集合單元健康狀態良好。當讀取socket 無數據時，為保證數據接收在同一運行周期內的運行實時性，將進行循環讀取socket 動作，直至讀取出數據或循環次數超過M 次（本設計中M=10）時停止循環讀取動作。當連續5 個任務運行周期讀取socket 無數據次數超過M 次時，判定該數據集合單元為非健康狀態；將根據該數據集合單元標定的內存偏移地址和數據長度在MVB 數據緩存區內索引對應數據，并進行數據替換處理完成數據冗余。

2.2 CCU 的設備級冗余控制

為了實現更完備、高效的設備冗余切換功能，本研究根據以往項目中CCU 的故障案例，總結了CCU 運行過程中可能突發的各類設備功能性故障，并對這些故障所期望得到的設備冗余功能應對效果進行統計性研究，最終形成有效的設備級冗余控制方法。CCU 功能性故障類型如表2 所述（冗余控制只應對單設備故障）。對表2 中闡述的各類型故障進行總結，形成主、從CCU 故障判斷條件，并以此形成自身及冗余設備故障判斷結果，最終對判斷結果進行相應的應對處理。主、從CCU 設備級冗余控制功能的實現過程分別如圖3、圖4 所示。

在上述邏輯判斷條件中，MVB 宿端口超時判斷及TRDP 數據有效性判斷方法，與總線級冗余控制描述的數據健康狀態判斷方法一致，但設備級冗余控制是針對設備功能性異常進行的，需對全部數據集合單元的健康狀態進行判斷得出判斷結果。為保證邏輯判斷時間充足且不影響冗余切換功能的高效性，本設計中將全部MVB 宿端口超時判斷時間設置為256 ms，全部TRDP 數據失效判斷時間設置為100 ms，即保證設備在300 ms 內完成設備功能性故障狀態判斷。

主、從CCU 通過單獨配置的MVB 內部通信端口和TRDP 單播數據包，實現設備間內部通信。在內部通信數據中，單向包含主或從CCU 設備的MVB 接收功能狀態、TRDP 接收功能狀態、自身故障判斷以及生命信號，利用內部通信中數據信息的傳輸，使主、從設備雙方得到充足的數據依據，了解故障時刻雙方狀態，并以此做出準確的故障判斷及應對動作。本設計中MVB 內部端口特征周期設置為32 ms，TRDP 內部通信周期設置為20 ms。在主CCU 判斷自身故障狀態后，主動進行TRDP 及MVB 的從狀態配置，規避總線上雙主故障情況。

表2 CCU 功能性故障分類

圖3 主CCU 冗余控制判斷邏輯及應對動作

本項目中采用的CCU 設備，TRDP 主從狀態切換可以由軟件瞬間完成；而MVB 主從狀態切換需要主板調度MVB 通信板卡進行主從狀態重新配置過程，實測耗時為295 ms。因而，從CCU 在完成主CCU 故障判斷后，在不中斷應用邏輯運算的前提下，首先進行TRDP 通信主從狀態切換，以TRDP通信數據維持系統正常控制及通信管理功能。同時啟動MVB 主配置加載任務，待到MVB 加載主配置成功后，再恢復數據總線冗余功能。

圖4 從CCU 冗余控制判斷邏輯及應對動作

3 實驗室的模擬驗證測試

雙級熱備冗余控制通過軟件實現后，在實驗室搭建網絡拓撲測試環境（如圖5），對冗余控制功能效果進行模擬驗證測試。其中，陪試設備為可編程的通信模擬設備，可模擬項目中全部網絡子設備數據發送功能，并可通過在線調試模式控制兩種總線的任意數據集合單元數據發送，以此模擬數據異常狀態。

圖5 驗證測試環境的網絡拓撲圖

總線級冗余功能測試中，通過陪試設備模擬2種總線不同數據集合單元的異常狀態，測試結果表明，利用MVB 為信任總線并模擬其故障時，數據總線冗余完成時間與表1 中規定的MVB 端口健康狀態判斷時間一致，各數據端口可在其對應的健康狀態判斷時間（最小160 ms，最大1 024 ms）內利用TRDP 數據完成數據冗余；ECN 總線為信任總線并模擬其故障時，冗余完成時間為5 個主任務執行周期，即5×20 ms=100 ms 完成數據冗余。

設備級冗余功能測試中，通過軟件模擬與線纜通斷操作，對表2 中描述的CCU 故障情況逐一進行模擬。測試結果表明，從CCU 在256 ms 完成對MVB 和TRDP 通信狀態的有效性判斷，并優先進行TRDP 主從切換保證CCU 控制功能順利進行，完成切換時間為256 ms。

在調試過程中，主、從CCU 始終運行具備雙級熱備冗余控制功能的底層系統軟件，并在整個靜調、動調測試過程中，CCU 控制功能完全正常，說明雙級熱備冗余控制的軟件實現在保證冗余功能的同時，沒有對列車網絡控制功能造成任何不良影響。

4 結語

一系列驗證測試結果表明，雙級熱備冗余控制功能具備較高的實時性和可靠性，在充分保證網絡主控設備對列車的穩定控制功能的同時，有力應對了通信瞬時異常及設備功能性故障對于TCMS 安全運行所造成的風險，對軌道交通車輛的安全運行性能的提升具有較現實的參考意義。