云仿真驅動的列車動力學協同可視化分析

王力霆 唐 兆 黎 榮 辜 錚 胡玉煒 李岳洪 張繼業(yè)

1.西南交通大學牽引動力國家重點實驗室,成都, 6100312.西南交通大學機械工程學院,成都, 610031

0 引言

在高速列車動力學研究中,數值仿真發(fā)揮著關鍵作用,研究如何對列車動力學仿真方案進行有效分析對中國鐵路穩(wěn)健發(fā)展具有重要意義[1-2]。隨著網絡信息技術的發(fā)展,軌道交通裝備研發(fā)與云計算、人工智能等新興技術融合,逐漸走向數字化、智能化的發(fā)展道路[3]。然而,車輛運行速度、載重量、路網規(guī)模等指標的逐年提高導致了列車產品設計過程中需考慮的要素日益復雜,部門協同更頻繁,多學科知識交叉更深入,計算規(guī)模擴大等現象。這些現象對傳統列車動力學仿真分析流程提出了諸多挑戰(zhàn),主要表現為可視化手段單一且動態(tài)交互低效、異地協作困難、客戶端硬件設備昂貴、人為因素多、分析時效性差等[4-5]。為了更好地應對上述困難,列車動力學仿真分析環(huán)境亟需向著集成化、平臺化的方向演進。

云仿真概念是在2009年由李伯虎等[6]提出,并被認為是仿真工程領域特別值得關注的方向之一[7],在技術上深度融合了網絡通信、虛擬化、生命周期管理、仿真分析、云計算等技術,通過仿真資源虛擬化以及服務云池的構建為用戶提供可靠靈活的云端仿真服務。

近年來,國內外研究人員已逐漸將云仿真技術運用于復雜產品研發(fā),如何越等[8]在既有核電仿真系統基礎上構建云仿真平臺,實現了高效、敏捷的仿真服務以及系統的模塊化部署;張彬橋[9]將水電站復雜大系統仿真與云計算、消息隊列、鯰魚粒子群算法結合實現了“互聯網+水電仿真”的服務模式并滿足了大規(guī)模仿真的需求;TAYLOR等[10]針對計算流體動力學(CFD)的遠程高性能計算需求構建了PaaS平臺,實現了工作流高效管理與跨平臺資源調度。云端仿真技術允許用戶通過互聯網遠程訪問高性能計算機和數據存儲資源進行各種類型的仿真模擬,從而在無需購買昂貴硬件設備的情況下進行大規(guī)模和高性能仿真計算,還可以實現多用戶共享和協作[11]。

在列車動力學仿真可視化分析領域,仿真分析相關研究工作還是以單機軟件系統為主導,如SIMPACK[12]、UM[13]、Vampire[14]、TTISIM[15]等軟件,云仿真相關應用案例較少。因此,本文從可視化與模塊集成化角度出發(fā),結合列車動力學仿真、云渲染、云計算等技術構建了云仿真驅動的列車動力學協同可視化分析框架,并對可視化分析場景搭建、多用戶協同的遠程可視化交互、求解器集成等關鍵技術進行研究,然后依據該框架搭建軟件系統,最后對系統進行功能、精度、性能方面的驗證。

1 框架結構

列車動力學協同可視化分析框架及應用系統在云仿真理論及方法指導下,在網絡通信及虛擬化技術支持下,以列車動力學性能分析需求作為牽引,為多角色構成的研究人員群體提供一體化、開放協同的可視化仿真分析環(huán)境?？蚣茏裱謱蛹墶⒛K化思想進行設計,從下到上分為四層(基礎設施層、服務支撐層、云仿真服務層與應用交互層),如圖1所示。

圖1 云仿真驅動的列車動力學協同可視化分析框架層級Fig.1 Hierarchy of cloud simulation-driven train dynamics collaborative visualization analysis framework

基礎設施層為云仿真平臺提供運行環(huán)境以及基礎仿真能力,主要包括經虛擬化技術封裝的物理資源(存儲資源、計算資源等),形成多元的虛擬資源池,屏蔽異地、異質性因素,向上具備虛擬資源管理接口,具有提供資源申請、資源釋放等能力。

服務支撐層由基礎設施層驅動,在內部數據平面的支持下通過多個模塊對上層的列車動力學仿真分析業(yè)務起支撐作用。該層包含的三種支撐模塊分別對應仿真建模、云端渲染、仿真求解三個方面。其中仿真建模支撐模塊為模型參數可視化配置功能提供支持,如模型預處理、仿真元數據管理等;云端渲染支撐模塊則是為多用戶協同可視化分析提供基礎能力,包括復雜信令邏輯處理、網絡穿透、媒體數據中轉等;仿真求解支撐模塊從求解器集成角度出發(fā),通過求解器通信組件打通參數配置、結果采集與上傳、異步并發(fā)求解調用等流程,并提供異步消息隊列、負載均衡等功能為任務執(zhí)行增效。

云仿真服務層在服務支撐層的通信、集成、增效功能基礎上構建覆蓋仿真全生命周期的核心服務,包括方案管理、方案配置、資源組合、任務監(jiān)控與管理、可視化分析與驗證等完整流程,為多角色研究人員提供高效能仿真分析服務。

應用交互層則提供列車動力學仿真建模平臺與列車動力學實時可視化分析平臺,包含項目管理、任務監(jiān)控、仿真建模、可視化分析等服務界面與功能接口,支持多組多角色用戶通過多終端、跨平臺的方式進行列車動力學協同可視化分析。

2 關鍵技術研究

2.1 列車動力學仿真可視化分析場景搭建

為了更好地將列車動力學仿真數據三維映射服務化,設計列車動力學仿真分析場景搭建框架如圖2所示,包含如下4個部分:①基礎場景模型是動力學研究主體的“承載體”,承擔著軌道參數等仿真方案參數的三維實體映射任務,由松耦合的異構模型生成器以及基礎模型資源構成;②研究主體模型是研究人員在仿真分析中的主要觀測體,包括車輛參數等仿真方案參數、三維仿真模型(輪對、構架、車廂等)及其動態(tài)信息,其中動態(tài)信息由時間序列主導,與其他關鍵性能指標相互映射,并預留控制接口實現細粒度場景回溯;③分析方法集是研究人員與研究主體間的“橋梁”,聯通人機交互流程,具有多維度、高自由度、直觀等特點;④驅動數據是框架運轉的“發(fā)動器”,承擔著驅動可視化場景構建、研究主體模型引入、仿真分析流程運轉等任務,分為仿真結果數據與仿真參數數據。

圖2 列車動力學仿真分析場景搭建框架Fig.2 Framework for train dynamics simulation analysis scene building

在基礎場景模型特別是鐵路線路構建過程中,以“點線面體”順序按層次建模,提供參數化建模方案與關鍵建模算法并輔以網絡通信技術構建在線基礎場景建模服務。算法模塊獲取曲線長度、曲線半徑、坡道長度、坡度角等參數生成特征點,并以三階貝塞爾插值得到線路曲線,再通過掃掠與離散單元生成獲得初步模型,最后進行線路超高的映射以及軌道連接處不連貫問題的修正。

在研究主體模型的驅動方面,為平衡映射完成度與計算精度,對列車自由度進行簡化。保留了車體、轉向架、車鉤、輪對等部件自由度以模擬浮沉運動、搖頭運動以及部件的旋轉或偏移情況,最終每節(jié)車廂包含24個自由度,可以較準確地對仿真結果進行三維映射。

另外,為減少插值算法對線路模型精確度的影響,軌道的底層設計為多段短軌道拼接而成的長軌道。該情況下,簡單使用車輛定距計算轉向架及輪對的位置,會出現轉向架與車體不處于一條軌道上的時刻,從而造成兩者在沿線路方向上分離的現象。因此,在驅動研究主體模型的過程中,需對列車模型各部件的位姿進行狀態(tài)分類與修正。

輸入:

Tw=Ti∥初始化車廂軌道為Ti

While(列車開始運行)

Tw=Ti∥更新車體軌道

Tb=Ti-1∥更新后轉向架軌道

Else

Tb=Tw∥更新后轉向架軌道

End if

Tw=Ti

Tf=Ti+1

Else

Tf=Tw

End while

圖3為多節(jié)編組高速列車在控制腳本作用下的運行模擬示意圖,其中圖3a、圖3b、圖3c分別為直線、曲線、隧道工況下的運行場景。

(a)直線工況

分析方法集包括二維數據展示方法集、三維數據映射方法集及細粒度場景回溯方法。在傳統后處理模塊中,通常以多層級列表的形式對各項指標進行索引,過多的數據從屬關系造成了用戶較重的認知負擔,因此,本文構建了二維數據展示方法集,為輪對、車廂、轉向架、車鉤、減振器等列車部件級模型綁定相應動力學性能指標面板,由點擊事件觸發(fā)彈窗,實現了輪軸橫向力、輪對橫移、輪軌接觸力、車體加速度、輪重減載率、脫軌系數等指標的靈活、直觀展示,從而將可視化場景與仿真數據實時聯系起來,使得用戶能夠更容易地挖掘列車動力學響應規(guī)律。

三維數據映射方法集包含云仿真結果驅動的輪對位移、車體點頭角、車鉤位移、車鉤垂向擺角等映射動畫,同時采用自適應的三向箭頭模型對輪軌接觸力、車體加速度等有向指標進行表征。自適應指可以自動通過控制算法保證不同的數值區(qū)間與波動幅度都能夠合理地映射到三維箭頭上,保證三維箭頭不超出畫面且能夠反映微小的數值波動。

細粒度場景回溯是針對時間維度的分析方法。列車動力學性能指標在時間屬性上具有連續(xù)性,無躍遷現象,因此以時間序列作為主導設計細粒度場景回溯功能,建立虛擬三維空間中時間與動力學指標結果映射關系,可以滿足跨時空評估列車運行情況的需求。時序數據通?？擅枋鰹?/p>

Data.T={(t1,ST1,SA1,RQ1),(t2,ST2,SA2,RQ2),…,(tn,STn,SAn,RQn)}

(1)

式中,t代表數據對象的時間屬性;ST代表穩(wěn)定性指標結果數據;SA代表安全性指標結果數據;RQ代表平穩(wěn)性指標結果數據。

研究人員可通過拖拽進度條觸發(fā)事件回調從而操作Data.T控制接口,對t進行復雜查詢,再通過映射算法實現細粒度的場景回溯功能,從而在時間尺度上對動力學性能進行三維可視化分析。其中時間粒度的粗細通過方案中的采樣頻率確定。某次場景回溯案例如圖4所示,其中圖4a、圖4b、圖4c分別代表運行時間在2.52 s、9.15 s、12.42 s下的駕駛室視景。

(a)t=2.52 s (b)t=9.15 s (c)t=12.42 s圖4 場景回溯案例Fig.4 The case of scene retraction

2.2 基于云渲染的遠程三維可視化交互

云渲染將“云應用”與渲染結合,實現了在線三維可視化,廣泛適用于在線視頻游戲領域[16]。在傳統列車運行可視化中,由于場景復雜度高、三維模型精細、交互頻繁等原因,系統對客戶端硬件要求苛刻,因此借助云渲染思路,針對跨平臺、“瘦客戶端”等需求,將渲染資源中心化并按需提供,避免了研究人員在動力學分析過程中受到時空、終端類型、硬件水平等限制。WebRTC(web real-time communication)是一項開源實時通信技術,可基于瀏覽器建立對等實時通信,具有低延遲、高質量、跨平臺等特點[17],因此框架選用WebRTC作為云渲染支撐技術。

為建立靈活分組、多角色混合、高效實時、可交互的列車動力學分析在線可視化服務,提出遠程可視化交互框架如圖5所示,分為以下4個部分:

圖5 遠程可視化交互框架Fig.5 Framework for remote visual interaction

(1)混合角色驅動的邏輯組接入。一次仿真前后處理流程可能需要多種角色參與,分別在不同任務流程發(fā)揮相應關鍵作用。角色職責上分為設計、分析、建模、管理四類,組群混合時可靈活形成多元能力分布的邏輯組,在資源組合模塊中根據能力分布按需分配仿真資源,提高集群資源利用率。例如可視化分析過程中,為分析人員分配更高帶寬以滿足實時交互需求,而其他人員則分配較少的帶寬,只傳輸媒體信息。

(2)信令邏輯處理。作為遠程交互可視化的樞紐,向下對Web接入請求進行認證、檢驗、分配等處理,向上為各Web頁面配對渲染源實例。消息轉發(fā)模塊負責WebRTC對等連接建立之前的媒體協商、Candidate收集等流程;邏輯組管理模塊則為組業(yè)務提供支持,包括組成員管理、組異常分析與處理、交互權轉移等。

(3)渲染源數據準備。渲染源在后臺邏輯、渲染池管理中間件的加持下實現池化,按需取用,滿足不同類型的可視化分析需求。基于面向對象技術在WebRTC原始接口上建立CamSender、AudioSender類,對Unity3D場景中的音視頻數據進行采集、加工、編碼等處理完成數據準備。另外,建立InputReceiver類并通過基于SCTP(stream control transmission protocol)的RTCDataChannel接收數據,依據表1中交互協議解析數據,再按需構建遠程虛擬設備集合,最終實現實時交互數據在渲染實例中的精確映射。

表1 交互協議

(4)對等連接建立與數據傳輸?；赪ebRTC 會話層實現雙端的媒體協商、Candidate收集任務后,建立對等連接,通過MediaStream、RTCDataChannel模塊實現流傳輸。由于某些情況下對稱型NAT(symmetric NAT)策略的存在,基于公有云建立STUN/TURN(session traversal utilities for NAT/traversal using relays around NAT) Server并搭建中轉鏈路,最終為研究人員提供穩(wěn)定、靈敏、實時的遠程交互可視化功能。

2.3 面向列車動力學實時分析的求解器集成模型

由于研究人員需通過可視化場景實時觀測指標結果并即時定位仿真方案缺陷,因此可視化分析功能在時效性上需達到秒級響應,即指標結果分片映射至可視化系統的時間跨度應處于秒級。然而列車動力學仿真求解器因缺失模塊間通信功能而無法獨立進行任務狀態(tài)感知、結果數據采集、驅動數據配置等工作,因此亟需設計一種求解器集成模型以在實現求解器模塊通信的基礎上充分降低數據在系統各模塊間的流通耗時。

仿真任務到達計算中心時刻Tsubmit至第一份指標結果數據分片被可視化映射的時刻Tfirst形成的區(qū)段Psubmit→first構成可表達為

Psubmit→first=Pconfig→Psolve→Pcollect→Ptransfer→Pmapping

(2)

式中,Pconfig為驅動數據配置流程;Psolve為仿真求解流程;Pcollect為數據采集流程;Ptransfer為數據傳輸流程;Pmapping為可視化映射流程;→為流程銜接符。

針對求解器Pconfig與Ptransfer的缺失,本文基于Golang語言開發(fā)了求解服務中間件。Golang通過原生特性Goroutine及Channel實現基于通信順序過程(communicating sequential process,CSP)模型的松耦合、安全的并發(fā)編程,符合多用戶并發(fā)模型特點[18]。中間件實現過程中針對Pconfig中并發(fā)驅動數據寫入時鎖粒度大的缺點,借鑒Linux RCU(read copy, update)思想,通過復制并更新驅動數據原件后再進行原子覆蓋的方式降低鎖粒度,在驅動數據配置并發(fā)量為20的情況下使得并發(fā)參數配置效率提高了42.1%。針對Pcollect采集不及時的問題,基于生產者-消費者模型建立接口Collecter、Consumer分別完成結果監(jiān)聽與上傳,并通過具有動態(tài)緩沖區(qū)的數據通道進行高性能線程間通信,實現指標結果封裝、映射與交換流程異步,避免串行帶來的時間損耗。完整集成模型示意如圖6所示。

圖6 求解器集成模型Fig.6 Integrated model of solver

列車動力學仿真任務為CPU密集型任務,訪問量突增對動力學分析時效性產生的消極影響會很嚴重。針對此問題,采用了基于Docker的虛擬化技術將中間件與算法程序封裝為具備一定隔離性的容器,并通過Kubernetes進行統一編排和管理。部署好集群后,Kubernetes中默認調度器會將新創(chuàng)建的Pod通過Predicates以及Priorities兩個調度算法自動調度到最合適的節(jié)點上,初步實現集群的負載均衡及彈性擴展。

3 應用驗證

3.1 驗證準備

依據上述研究成果,分布式系統基于B/S架構設計,后臺基礎服務基于ABP Framework開發(fā),并以PostgreSQL作為結構化數據庫系統,Redis作為緩存系統,列車動力學分析可視化場景由Unity3D驅動,云渲染模塊基于Node.js、Render Streaming、Unity WebRTC搭建,物理架構如圖7所示,具體硬件配置如表2所示。

表2 硬件配置

圖7 系統物理架構Fig.7 Physical architecture of the system

圖8為一次協同分析案例的運行過程示意圖,邏輯組由四個不同角色(設計、建模、分析、管理)的用戶組成,分別主導總體方案設計、仿真建模、可視化分析、邏輯組管理四種工作,多組之間可以共享可視化內容。然而,并非每項工作都只由一個用戶完成,比如在可視化分析過程中,所有用戶皆可獲取云渲染畫面,但是只有分析人員具有交互權,其他角色的用戶只做輔助分析,若需進行交互需先向管理人員申請交互權。

圖8 系統運行案例Fig.8 Cases of system operation

3.2 精度驗證

云仿真系統與商業(yè)動力學軟件SIMPACK按以下工況進行計算:列車時速為80 km/h,曲線半徑為2000 m,曲線長度為340 m,緩和曲線長度為25 m,超高0.1 m。選取脫軌系數、輪軸橫向力、輪重減載率三個性能指標的最大值進行對比。由表3可知,兩個軟件系統的求解結果具有良好的一致性。

表3 指標對比結果

在另一工況(曲線半徑為1000 m,緩和曲線長度為45 m,超高為0.075 m)下以輪軌橫向力、輪軌垂向力兩個性能指標作為對象進行對比驗證,結果如圖9所示。兩者在量值以及變化趨勢上總體吻合,但存在一定差異,差異來自于兩者動力學建模過程中輪軌接觸、線路平縱斷面、軌道結構等細節(jié)。

圖9 輪軌力指標對比結果Fig.9 Results of wheel-track force index comparison

總的來說,云仿真系統在關鍵動力學性能指標結果上能與SIMPACK取得較好的一致性,在平穩(wěn)性、安全性分析中能夠部分替代商業(yè)動力學軟件。

3.3 性能分析

在系統實現前期,可視化模塊采用Unity WebGL技術進行發(fā)布,導致運行時大量渲染工作在客戶端進行。為體現云渲染技術在列車動力學實時可視化分析應用中的優(yōu)勢,將基于WebRTC的云渲染技術與項目前期使用的Unity WebGL技術進行性能對比。對比采用的三維場景信息如下:軌道全長1340 m,包含扣件5360個(間隔0.5 m),支柱54個(間隔50 m),場景總體三角面片數為1143萬。具體指標為平均加載時間、平均交互時間、平均畫面幀率,分別代表了時效性性能、交互靈敏性與畫面流暢度。根據圖10結果,云渲染方案在交互靈敏性與畫面流暢度方面略低,但仍然滿足高質量可視化交互需求。在時效性方面,由于云渲染方案中用戶無需加載大量靜態(tài)資源,平均加載時間為7.2 s,遠遠低于WebGL方案的平均加載時間356.8 s,且不會隨場景復雜度變化,滿足后續(xù)可視化場景擴展需求。

圖10 可視化性能分析結果Fig.10 Results of the visualization performance analysis

為了對比本系統求解器與SIMPACK在單節(jié)點上的并發(fā)求解能力,本文以相同計算節(jié)點上的最大并發(fā)量為指標,用兩個軟件分別執(zhí)行相同參數的單節(jié)列車動力學仿真任務。當CPU利用率達到100%時認為節(jié)點已達性能極限,記錄達到性能極限時的運行軟件數量。經過多組試驗,SIMPACK平均最大并發(fā)量為7.31,本系統求解器平均最大并發(fā)量為11.23,比SIMPACK平均最大并發(fā)量約高出53.7%。造成該結果的主要原因是本系統中求解器與前后處理模塊的解耦,軟件資源粒度更小,而SIMPACK架構耦合性更強。

4 結論

(1)本文針對傳統列車動力學仿真流程中多用戶協同不便、硬件要求苛刻、自動化水平不足等問題,將列車動力學仿真分析技術與云計算、云渲染、求解器集成技術相結合,提出了一種云仿真驅動的列車動力學協同可視化分析框架。

(2)本文細化了列車動力學可視化分析場景搭建流程,并設計了一種相應框架。通過基礎場景構建、研究主體模型驅動、分析方法集構建三個步驟實現對列車動力學分析可視化場景的搭建自動化與服務化。

(3)本文在云渲染架構的基礎上進一步基于WebRTC提出了一種多組多角色協同的遠程可視化交互框架,提高了仿真的協作性和分析效率,同時減少了傳統渲染架構中大量的客戶端渲染工作。

(4)本文提出了一種面向列車動力學實時分析的求解器集成模型,將原本緊密關聯的模塊解耦,結合Linux RCU思路、容器編排等技術實現了模塊間高效通信以及彈性擴容。

(5)本文在實際項目中對框架及系統進行了精度與系統性能的驗證,結果表明:該框架及系統可滿足研究團隊在列車動力學仿真分析中的需求,同時對其他復雜系統的云端可視化分析模塊構建具有借鑒意義。未來的工作中將構建云渲染服務質量評估模型,從多維度進行遠程實時可視化交互優(yōu)化,提高列車動力學仿真分析效率。