1. 如何減少鐵路基礎設施安全自動化系統的鑒定時間

每天乘客運輸量高達1000萬人次的RATP，一直在投資交通現代化以應對交通的持續增長，響應乘客的需求，并優化經濟和環境性能。作為巴黎地鐵現代化項目的一部分，RATP選擇開發一種名為OCTYS的新型地鐵管理系統。利用基于通信的列車控制，交通運營商可以在完全安全的情況下減少兩列火車之間的間隔時間，這樣在高峰時段有更多列車可供乘客使用。這樣的系統變得越來越復雜，也越來越難以集成和鑒定。本文將介紹用于減少現場測試的時間和成本的具體工具和方法。

2. 介紹

其中最大的困難在于安全系統（分布在網絡上的電子控制單元）與原有的安全信號系統的連接和集成，這些系統響應時間和輸入數據都不同。

圖1 巴黎地鐵，已有110多年歷史

傳統的測試通常在夜間交通關閉時進行。要完成現場測試，需要大量的時間（大約1000個晚上）和人力資源（測試工程師、司機和交通操作員）。RATP考慮可交換性，將其定位為通用OCTYS項目。該策略要求靈活性，確保系統支持多個供應商，考慮成本效率。

因此，可用于規范定義、驗證和培訓的基于新的“虛擬化”概念的方法和工具變得非常重要。

為了符合OCTYS系統的要求，RATP啟動了“系統集成和鑒定測試平臺”(BIQS)項目。該項目采用特定方法和工具，應用到OCTYS等復雜系統，使系統集成和鑒定階段更加高效。

2.1 OCTYS硬件架構

關鍵問題是如何將OCTYS系統與現有的線路中的設備、本地控制站和中央控制連接起來。

圖2 場景下的OCTYS

OCTYS是由多個計算機組成的分布式體系結構，通過通信系統（一個專用的現場網絡和一個列車無線電網絡）相互連接。

OCTYS由五個模塊組成:

· PAE: 列車嵌入自動駕駛儀 (一個列車電子計算機單元),

· MES: 與線路設備有接口的遠程I / O模塊 (鐵路、信號、開關),

· PAS: 地面自動駕駛儀 (每個管理物理線路上的一部分),

· FRONTAM: OCTYS和線路中央控制之間的接口,

· STD: 智能通信系統管理。

2.2 集成和鑒定需要

BIQS平臺的主要目標是:

· 改善集成階段工作, 在實驗平臺上使用測試管理搭建和驗證新的線路,

· 在其生命周期內監控OCTYS系統（操作和維護活動），支持查找和協助診斷,

· 測試和驗證系統的未來的改進和更改,

· 支持可交換性

系統鑒定平臺的目標和任務:

· 考慮實時約束和典型行為，仿真整線的能力，

· 集成不同模型并執行聯合仿真 (火車、線路、交通、信號、安全規則,自動駕駛儀…)的能力,

· 不需要繁重的重新配置工作，就能與實際目標機交換目標模型的能力,

· 模擬數據傳輸系統能力,

· 通過故障引入獲得系統功能退化模式的能力,

· 在自動模式及交互模式下集成測試用例的能力,

· 配置線路具有靈活性和擴展性的能力,

· 提供HMIs便于分析的能力,

· 重放記錄的事件的能力。

所有這些能力合在一起體現了RATP項目的一個重大創新。

由于OCTYS有很多制造商參與，每個制造商只看到了整個系統的一部分，而且接口不標準只支持其服務部分?；诂F場的實際線路情況，系統部件的最終集成仍然是需要在現場測試階段完成。

此外，實現這樣的集成和鑒定平臺需要匯集來自不同參與者的知識，這些參與者包括控制系統專家、仿真專家、能夠處理復雜組織和系統的管理人員等。

因此,這測試臺的主要需求分為三類:

· 支持集成和驗證

· 支持系統維護

· 鑒定新供應商資格，符合OCTYS可交換性的要求

2.2.1 支持集成和確認

目的是通過離線驗證系統，減少現場鑒定時間，避免操作中斷。

2.2.2   支持系統維護

一個主要目的是維護系統的運行，并利用記錄的數據(黑箱)來查找在開發過程中出現異常的根本原因。其目的是剝離事故，分析記錄的事件，并使用友好的HMIs和工具來可視化/檢查它們。此類服務可以自動創建場景(測試向量)，以便在測試臺上回放實時情況。

2.2.3 鑒定新的供應商，符合OCTYS可交換需求

在將其添加到兼容的OCTYS設備的參考列表之前，BIQS 平臺幫助鑒定新制造商目標產品。經過標準測試集測試，最終和預期結果都應相互匹配: 對新目標產品應用標準測試過程，測試結果自動與預期結果進行比較。

2.2.3.1 BIQS硬件架構

為了滿足集成和驗證的需要，BIQS 平臺鑒定系統需要模擬完整的OCTYS系統環境，以容納整個系統的電子控制單元，并允許運行測試用例。

這個完整的環境，包括信號、線路和火車，以及所有的OCTYS安全和控制功能，這些都是用ControlBuild進行建模和仿真。在線路模型上添加了自動測試腳本(交通和故障模式)，提供了快速、全面的分析結果。

BIQS平臺的獨特之處在于，支持半實物仿真，為滿足OCTYS系統而開發的真實ECUs可以任意連接到試驗臺上，進行聯合仿真。此外，通過仿真模型，供應商a提供的設備可以替換為供應商B制造的另一個ECU。

圖3 系統集成和鑒定測試臺

2.2.3.2 軟件架構

RATP在巴黎的第8地鐵線上的 “Porte de Charenton” 車站設一測試基地。第一個實現的目標是創建一個虛擬的線路模型，從電子設備的角度來看，它的行為將與真實的線完全相同。

圖4 “Porte de Charention”車站測試線路圖

鑒定平臺由仿真模型（線路的物理環境、機車(火車)和虛擬控制器）、測試場景和所有設備之間的通信(I/Os接口配置和網絡通信)組成。

2.3 仿真模型

模型不僅取代了真實環境，也取代了被測試的目標本身 （因為這些目標在測試平臺中并不總是可用的）。所有這些模型:

· 可以連接到I / O或數據網絡與其他模型通信的接口,

· 代表模型行為或其參數 (運動時間,平臺長度,開門時間,需要速度…)的狀態變量,

· 依賴預期行為的簡單或復雜的傳輸函數,

· 用來修改模型正常行為 (機械,電氣或通信故障) 的特定參數。

BIQS平臺集成了不同類型的模型:

· 環境 (線路、信號、車輛和本地控制板模型)

· 電子設備模型 (自動駕駛)

2.3.1 環境模型

支持自動駕駛的環境模型是經驗證過的。它們描述并模擬了線路、信號、電力分配、現場或中央控制室和列車(車廂、牽引、車門、本地化傳感器以及虛擬司機)的行為。

線路模型: 線路模型中包含了引導列車運動的所有對象。線模型包括軌道、開關、信號和檢測器、站臺、隧道……）。每個對象都參考一個行為模型。每個對象都有一個圖形動畫，并設置為3軸維度。線路模型可以從ControlBuild下的庫里模型自動構建出來，只需要填寫模型里的地理位置參數。

圖5 帶交通狀態的實際線路

信號模型:目前巴黎地鐵的信號系統主要是通過電氣硬件實現安全控制。所以這個系統需要與新的電子控制系統共存。因此，鑒定平臺需要開發信號硬件的模型。

圖 6 信號原理圖

原始的電氣原理圖印在紙上, 通過半手動方式將其捕獲翻譯到ControlBuild中。在代碼評審驗證階段，將原始圖與模型進行比較。最后的驗收階段由安全工程師通過仿真和測試來驗證模型。

本地站控制模型:當線路與中央控制系統斷開連接時，RATP就有一個本地的交通控制來管理車站內的列車。本地站控制由一個顯示信號、開關位置和占用軌道的面板組成。一個面板允許管理站點設備以建立預期的線路。在ControlBuild里開發“Charenton Porte de Charenton”車站控制模型，并將其集成到鑒定平臺中。

圖7 車站可視化面板

圖8 車站控制面板

機車車輛模型: 根據我們的需要，列車模型包含了司機室、簡化的車輛 (門、鐵路線、配電…受電弓) 和牽引設備等模型。牽引模型的動態特性與實際列車的動態特性非常接近，從而可獲得整線的特性。

簡化列車模型是為了提供必要的接口，由一“執行者”驅動列車模型。該駕駛面板已被通用模型化，無論何種類型的車輛，都可以用同一駕駛模型。

圖9駕駛艙面板

列車和線路之間的交互: ControlBuild有一個功能，可以不需要編程在三維坐標空間中移動列車。因此，列車可以沿著鐵軌行駛，檢測開關岔道的位置，對傳感器做出響應，捕獲帶受電弓接觸網功率……該模塊與牽引模型交互，根據要求的加速情況計算列車的速度。

2.3.2 自動駕駛模型

物理電子處理單元(自動飛行員)在測試臺上可有也可用虛擬模型替代。根據實際設備的存在情況，開發的虛擬模型可以被動態地啟用或禁用。

圖10 顯示自動駕駛接口狀態

使用虛擬電子設備開發了“Porte de Charenton”站，自動駕駛儀功能需要基于該虛擬車站執行一系列測試:

· 重新配置禁用區域

· CBTC激活

· 彌補錯誤的軌道電路

· 幫助自動取消路線

· 幫助緊急取消路線

· 安全方法鎖定

· 發現和釋放超限鎖定

· 遵守信號指示

· 設置方向

· 設置列車保護

· 檢測軌道電路故障

· 處理乘客保護

· 線路控制安全

· 制動時授權重新發電（再生能源）

· 禁止駕駛模式

· 授權進入車站

· 操作支持監督

2.4 測試腳本

鑒定平臺可支持手動操作或自動操作模式。在手動模式下，仿真模型的用戶圖形界面GUI (線路、信號艙、機車……)支持測試人員沿著線路 (路線開發) 駕駛列車，驗證真實(和仿真)設備的正確操作，并模擬故障以驗證安全功能和故障模式。

ControlBuild允許測試工程師搭建測試腳本, 以觸發正常操作模式相關的動作 (如定位一列列車, 啟動列車, 改變駕駛模式, 加速或制動) 或產生異常情況 (例如, 強制系統或設備的一部分產生故障) 。測試用例是提供輸入事件和輸出測量的操作序列。這些測試腳本也可以在測試臺上自動執行。

圖11 測試腳本編輯器和生成的測試報告

主測試腳本加載當前測試的初始條件 (模擬設備和環境的固定狀態)，然后順序執行所有代碼指令。與此同時，其他場景可能會模擬故障、觸發事件(不管預期與否)并強制某些設備模型的狀態。

測試腳本為測試臺和實際硬件ECUs之間的輸入/輸出和通信接口的配置提供代碼指令。這些指令允許測試工程師在所有接口和通信上引入故障。

2.5 測試臺物理接口

測試臺的目標是在硬件目標集成到站點(或列車內部)之前對其進行驗證鑒定。為此，有必要將目標機連接到工作臺; BIQS測試平臺提供輸入/輸出和通信子系統。

2.5.1 子系統輸入/輸出

該采集子系統用于仿真物理目標的輸入，測量設備的輸出值，并為實際目標提供功率。對于每個信號，子系統保證了電路的適應性、模擬傳感器電平的數字化和事件的時間戳。BIQS測試臺硬件子系統還能夠支持標準或特定的通信網絡。

配置編輯器允許在測試平臺上輸入/輸出卡和通信協議進行配置。

圖12 I/O和網絡配置

2.5.2  通訊子系統

在OCTYS系統中，通信是基于UDP的。所有的交互所都由一個叫做STD(數據傳輸系統)的電子設備管理。它的主要功能是在OCTYS系統的設備(物理目標或模擬目標)之間路由消息。

該通信設備的行為模型是在ControlBuild下搭建的。它有特定的模塊來存儲交換的幀，并實時地中斷通信數據。

圖13 監視，數據登錄及通訊監控

通過對通信系統故障的模擬，測試和安全工程師可以驗證真實設備的能力，檢測故障行為，并做出正確的決策(繼續、停止、保護、警報……)。

3. 總結

這個系統集成和鑒定平臺項目展示了使用已驗證的仿真技術處理安全自動化問題的關鍵優勢。成功的關鍵因素在于所使用的仿真工具的通用性，例如，ControlBuild，特別適合于運輸部門，以及所使用的方法和過程的靈活性(從模型到HIL)。

這個解決方案減少了現場測試時的故障停機和對實際設備操作成本。

“一天的模擬測試可以抵10個晚上的現場測試!”

這種基于模型的測試技術在系統開發之前驗證規范很有幫助。

ControlBuild提供的高級語言允許設計人員輕松地描述線路的不同環境模型(信號、功率分配)、重用車輛模型和原型新的自動化需求(不管是否安全控制)。這些用例可以由不同的項目利益相關方(工程、安全部門、交通操作工程師…)驗證。

由于該模型代表系統，因此一旦系統投入使用，集成和驗證工作臺可支持進一步驗證測試仿真分析。在實際操作中檢測到的所有事件都可以引入到測試臺中進行分析。

模型也可以用于培訓當與中央控制室斷開通信時，RATP工人如何管理車站交通?？梢詣摻ㄕ：头钦顩r、事件和事故:目標是讓辦公室人員增加可能發生的事件了解,使他們能夠在緊張的情況下做出正確的決定。

文章來源：默識沙龍