地鐵動應力測試數據管理與數據可視化系統研究

趙光偉 劉志明 陳 羽

1(中國鐵道科學研究院集團有限公司鐵道科學技術研究發展中心 北京 100081) 2(北京交通大學機械與電子控制工程學院 北京 100044)

0 引 言

自1965年北京建設第一條地鐵至今，我國地鐵建設已有50多年的歷史[1-2]。截至2019年12月，我國地鐵運營總里程已超過6 600公里。然而，隨著運營里程的不斷增長，地鐵轉向架構架的關鍵部位如空氣彈簧附加室、電機吊座、軸箱吊座等部位的焊縫處會產生裂紋[3]，最終導致構架疲勞失效。因此需要對地鐵車輛關鍵部件進行動應力測試，獲取車輛在運行過程中各疲勞薄弱部位的應力變化和損傷情況，并以測試結果為依據進行壽命預測和疲勞評估，最終提出合理的結構改進方案，延長地鐵的運營壽命。動應力測試通常采用SoMat eDAQ動態數據采集系統對構架疲勞薄弱部位的應變[4]、軸箱和構架側梁上方的加速度、列車速度、車體搖頭角速度進行同步采集，測試通道往往多達上百個。為了保證動應力測試數據的可靠性和完整性，測試過程中通常需要在運營線路上進行多個往返的測試，并持續數天，個別情況下需要對構架進行長期跟蹤測試。面對如此大規模的測試數據，僅簡單地將數據按照測試時間存儲在磁盤，可能會存在文件缺失、管理混亂的現象，不利于科研人員將測試結果同歷史數據進行比對分析和數據挖掘。因此，如何合理地管理數據、高效地查詢數據已成為十分重要的研究方向。

近年來，計算機數據庫技術得到飛速發展，并廣泛應用于各個領域。黃挺等[5]針對地鐵車輛現場數據進行了數據庫搭建。陳晴等[6]收集了多個來源的環境氣象數據并搭建了環境氣象數據庫。Plana等[7]建立了面向水質的數據庫，并利用大數據手段開展數據挖掘。數據庫種類繁多，并向多方向發展。伴隨互聯網技術的發展，XML數據庫逐漸成為了一種數據存儲方式[8]。此外為了追求更加完善且符合現實生產的數據模型，研究人員還提出了一種非結構化數據庫，支持重復字段和任意變長數據。這些技術的發展，彌補了關系型數據庫的一些不足，但由于關系型數據庫具備深厚的技術基礎、使用經驗、大量的市場占有額，本文選擇關系型數據庫進行數據管理。

本文首先提出針對動應力測試數據集的存儲方案，并研究了格式轉換的相應工具；其次，提出試驗和測試兩個數據顆粒度，并設計關系型數據庫模型，同時開發相應軟件界面；本文的最后利用AnyCAD控件提供的API處理地鐵車輛轉向架模型，采用以抽樣因子為核心的數據抽樣顯示算法繪制了二維波形，實現了查詢結果的可視化。

1 數據存儲

原始數據采集后，可能存在因信號斷采產生的尖峰信號或是因傳感器溫度上升引起的零點漂移[9]，不能直接用于分析，需要利用數據采集系統的配套軟件進行讀取和處理。然而，當需要深入挖掘信號文件內的信息時，由于不清楚配套軟件生成的文件結構，給研究帶來一定難度。本節對該軟件中的.dac格式文件進行了解析和轉換，提出了便于檢索的測試信號存儲格式并開發了相應的.dac格式轉換工具。

.dac文件是每個采集通道單獨存儲的數據文件，利用二進制文件查看器對.dac文件進行逐字節解析，發現該格式的文件以小端模式存儲，由三部分構成，分別為：文件頭區、數據塊區、文件尾區。表1展示了.dac文件結構中的關鍵信息。其中：m指代數據區結尾的最后一個字節地址；L指代文件總長度。

表1 .dac文件內部結構

在解析的基礎上，本文抽取.dac文件中的數據塊區，以小端模式、單精度浮點類型、單通道獨立存儲的方式保存在后綴名為.mdta的二進制文件中，以此作為信號文件的存儲格式。為了保證.dac文件中重要的元數據信息(如：最大值、采樣頻率等)不丟失，將單次測試的所有通道文件的重要元數據信息抽取并以.xml格式聚合在后綴名為.meta的文本文件中。其中，單通道文件的.xml格式為：

E:channel1.mdta

478350

601195

478350

可以看到，通過將數據區與元數據分離，不僅使得數據信號文件體積得到了壓縮，文件結構變得十分簡單，而且元數據信息也保留了。

多通道的.dac文件在轉換過程中需要進行大量的磁盤IO操作，若全部運行在UI線程，則將阻塞UI界面直至崩潰，為了提升轉換效率，基于.Net Frame-work 4.5并行任務框架設計了.dac文件轉換工具。該工具的核心算法如算法1所示。

算法1文件格式轉換算法

1. var lists=new List();

//變量初始化

var scheduler=new LimitedConcurrencyLevelTaskScheduler(16);

2. for(int i=0;i

//創建任務

{

Task t=new Task(()=>

{

Read_Header();

//讀文件頭

If(Header_Over)

{

Write_Data();

//寫數據

If(Data_Over)

{

Read_Foot();

//讀文件尾

Write_Xml();

//寫xml

}

}

},cts.token,TaskCreation.LongRunning);

t.Start(scheduler);

lists.Add(t);

}

3. Task.WhenAll(lists).ContinueWith(_=>{

Report_Finish();

//報告UI線程任務結束

})

在算法1中創建了任務調度者，控制同時并發的最大線程數為16，每個任務轉換一個.dac文件。當并發任務數量大于16時，多個工作線程搶占調度隊列空間。調度隊列中的任務執行完畢，按照FIFO的順序退出隊列，剩余線程繼續搶占調度空間，直至結束。在與UI界面交互時，由于開啟任務數多于進度條數目，為了避免多個任務共同刷新一個進度條，按照多任務搶占控件的設計思路進行設計：搶占成功的工作者線程對控件封送消息，而未搶占成功的線程則阻塞，直至有進度條空閑。進度條控件獲取算法如算法2所示。

算法2進度條控件獲取算法

1. Progressbar pb;

//聲明待返回的進度條

Int check_index=0;

//指示當前進度條索引序號

2. lock(progressbars)

//鎖定進度條組

{

while(true)

{

If(check_index

{

If(progressbars[check_index].Value==0)

{

pb=progressbars[check_index];

check_index++;

return pb;

}

}

else

//超出進度條組界限

{

check_index=0;

}

}

}

為了測試文件格式轉換算法的執行效率，向轉換工具中導入了22個獨立采集通道的.dac數據文件，每通道文件內包含60萬個數據采樣點。連續轉換5次，并與傳統單線程轉換算法的執行效率進行了對比，測試結果如表2所示。

表2 兩種轉換算法執行效率對比 單位:s

文件格式轉換算法較傳統算法的執行效率提升約67.3%。轉換工具界面如圖1所示，界面左側為8個通道并行轉換進度，右側記錄了各通道文件的詳細轉換情況。

圖1 轉換工具界面

2 數據管理

信號文件按照定義的格式存儲后，還需要在磁盤中存儲試驗數據之間的約束關系，以保證數據文件能夠正確、快速地被檢索出來。本節設計了針對動應力測試數據的關系型數據庫并搭建了數據管理的軟件界面。

2.1 關系模型設計

在關系型數據庫中，信息是以二維表格模型的形式存儲，表單中的字段信息是對現實世界的高度抽象和歸納，明確每一張表、每一個字段的實際意義，合理地與應用程序功能對接，這樣設計出的表和字段才是有意義的[10]。除了考慮表與字段的含義，還應充分考慮表格反映的實體之間的對應關系，良好的關系設計能夠降低數據冗余，提高查詢的速度。另外，功能需求并不是一成不變的，當用戶需求發生改變時，關系模型應當具備良好的可擴展性，表與表之間的耦合性要低[11]。

動應力測試數據關系模型設計前，需要提出數據劃分依據，并以該依據為基礎，研究數據間的歸屬關系：

定義1地鐵動應力試驗：自測點位置確定起至車輛布置傳感器全部拆除，其間進行的全部數據采集工作集合。

定義2地鐵動應力測試：自車輛離開車輛段起至再一次回到車輛段，其間進行的所有線路往返測試集合。

由定義1、定義2可以看出，試驗數據共由兩個顆粒度組成，這兩個顆粒度的對應關系為：一次完整的動應力試驗對應多次動應力線路測試，而一次測試對應唯一一個試驗；一次線路測試對應著多個線路往返，每次往返屬于唯一一次線路測試。基于這兩個關系，將試驗中產生的所有數據依次對應。本節基于MySQL 5.5環境搭建了數據庫模型，模型如圖2所示。

圖2 數據庫模型

模型共由19個表單組成，表單名稱與表單含義如表3所示。

表3 數據庫表單名稱及含義

整個模型以測試和試驗兩個表單為核心進行擴展，表與表之間僅通過ID進行約束。ID字段既作為一個表的主鍵，又與其他表格中的相應字段共同構成外鍵約束，在保證信息完整性的同時正確地反映了試驗與測試之間的映射關系。另外，以單獨ID字段作為主鍵便于對數據庫進行擴展，因為只需要研究新增信息所屬數據級別以及相應的對應關系后，在試驗表或測試表中增加能夠表示新表單的ID的字段即可，大大提升了動應力測試數據庫的可維護性和存活周期。

2.2 軟件功能設計

地鐵動應力測試數據管理系統的主要需求包括：數據錄入、數據查詢、數據整理、數據導出、申請新用戶等，針對以上功能需求，本節基于.Net Framework 4.5框架，目標平臺為x86架構搭建了用戶使用界面。

為了保證測試數據的安全性，管理系統利用MySQL中的權限隔離機制，對不同訪客開放不同的功能：數據管理者具備root權限，能夠對數據庫進行CRUD、導出表單信息、創建新用戶操作。所有的普通訪客賬戶均由管理者創建和分發，普通訪問者能夠查詢數據信息、導出表單、下載數據，但禁止寫入和更新操作。所有使用者在進入管理系統前均需要身份驗證，用戶登錄界面如圖3所示。

圖3 用戶登錄界面

登錄成功進入數據管理主界面，主界面如圖4所示。

圖4 數據管理系統主界面

主界面共分為三塊區域：數據庫結構樹、數據庫表單、功能區。數據庫結構樹展示了數據庫中的所有表單，雙擊可以查看表中的所有記錄。數據庫表單是展示區，用于顯示表單中的所有內容，單頁限制顯示1 000條記錄。功能區是軟件的核心部分，按照高內聚、低耦合的設計原則，將相似的功能模塊聚合在同一功能頁內，而模塊之間僅開放少量接口以供調用。在功能頁中：基本功能頁面向數據管理者，主要以錄入信息、維護信息為主；數據檢索面向所有訪客，以檢索和下載數據庫中存儲的文本信息與數字信號文件為主，是最重要的功能模塊之一。結合2.1節中的數據庫模型，以查詢某次試驗中某天測試工況信息為例，介紹查詢流程。具體查詢過程如圖5所示。

圖5 工況信息查詢流程

查詢過程中相鄰環節之間相互嵌套，內層返回的查詢結果作為外層的查詢條件。經過測試，利用該流程能夠快速地查詢出某一次測試中指定站點的工況信息，驗證了此查詢流程具備普適性。以上僅以查詢工況信息為例，對于其他任意顆粒度的信息均可按照類似流程進行嵌套查詢，在滿足準確性的同時避免了大量表連接操作，提升了查詢效率和準確率。

3 數據可視化

3.1 三維模型可視化

地鐵動應力測試的主體之一是轉向架構架，理解構架的結構細節有助于試驗的開展和后期的結構優化設計。數據庫中存儲的構架模型是.stp格式文件，因此如何將.stp格式模型顯示并集成至管理系統中是本節研究的重點。為了使可視化工具內嵌于數據管理系統中，本節基于AnyCAD.Net SDK中開放的API實現了構架模型的可視化。

通過查閱API文檔，解析和顯示.stp文件需要使用多個命名空間、類，其包含關系如圖6所示。

圖6 命名空間、類之間的所屬關系

命名空間AnyCAD共由三個子命名空間組成，分別為：Exchange、Platform、Presentation。其中：Ex-change命名空間主要作用是解析.step、.iges、.dfx格式的模型文件；Platform提供了描述、管理和顯示模型中各種點線面以及拓撲關系的類和方法；Presentation主要作用是管理顯示場景，如設置背景顏色、設置相機視角等。在理解了各個命名空間的主要作用后，引用AnyCAD.Exchange.Net.dll、AnyCAD.Foundation.Net.dll、AnyCAD.Presentation.Net.dll，編寫相應的調用代碼即能夠實現.stp格式模型的可視化。

在三維控件繪圖過程中，核心是獲取SceneNode對象，通過載入模型，將模型轉換為場景節點，并調用RequestDraw方法發出繪制請求，模型才能被繪制出來。模型顯示支持Edge、Surface、Vertex、Realistic共四種顯示模式，可以根據具體需求選擇不同的顯示模式。軟件整體界面如圖7所示。

圖7 三維查看器整體界面

總體來看，模型加載速度快，模型細節表達清晰，且能夠很好地與管理系統集成為一個整體，基本符合設計要求。

3.2 測試信號可視化

前文提到，測試信號文件最終的存儲格式是以小端模式、單精度浮點類型、單通道獨立保存的二進制文件格式，后綴名為.mdta，各通道元數據以.xml格式保存在后綴為.meta的元數據文件中。基于以上存儲格式，本節利用.Net Framework 4.5 Winform框架下的chart控件實現了測試信號文件波形可視化。

在二維波形的顯示算法方面，在各領域均取得了一定的研究成果：何瑞昊[12]采用C#中多線程ManualRestEvent框架實現了實時采集、波形顯示和存儲功能；陳羽[13]研究了基于像素點顯示方案的工程數據快速處理軟件。針對地鐵動應力測試領域，數字信號的顯示方案共分為兩種：一種是基于數據點顯示，即將所有采集點用折線段連接顯示；另一種是基于像素點顯示，即根據窗口像素點數，按照一組固定抽樣率1/m(平均每m點抽取1點)抽樣顯示[14]。第一種方案適用于采樣率低、數據點少的應用場景，比如一些采集時間間隔較大的實時采集系統；第二種方案適用于采樣頻率高、數據點多的應用場景。針對地鐵信號采集，為了保證時域信號信息不丟失，采樣頻率一般設為主頻的10倍以上，通常為1 000 Hz，數據點總量龐大，適宜采用抽樣顯示。然而以固定抽樣率抽樣意味著無論信號長度如何均會削減采樣率，若對一段時域長度較短的信號進行抽樣顯示，波形會失真。故本節結合兩種算法，提出以抽樣因子為核心、動態計算抽樣率的波形顯式算法。波形顯示算法執行流程如圖8所示。

圖8 波形顯示算法

抽樣因子的計算方法為：

factor=2×total/width

(1)

式中：factor指抽樣因子；total指數據文件的總點數；width指當前窗口寬度的像素值。

抽樣因子的實際含義為：在抽樣過程中將數據文件中的所有數據點構造為一個大數組，將大數組劃分為了width/2個小數組，每個小數組中的容量即抽樣因子。抽樣因子控制著波形的顯示方式，當抽樣因子數值大于2時，采用抽樣顯示，為了保證抽樣過程中盡可能保留原始信息，抽取小數組內的最大值和最小值，讀取的信號長度或窗口寬度的不同都將會影響抽樣因子大小；當數值小于2時，大數組的總點數較少，此時采用數據點顯示方案，將大數組內的數據全部輸出，不再執行抽樣過程，此時抽樣率為零。利用抽樣因子實現了動態計算抽樣率的效果，確保無論數據長度如何，波形均不失真。

由于抽樣過程十分耗時，為了不卡頓主界面，利用C#多線程框架中的BackgroundWorker類構造了一個工作者線程對象，所有抽樣、讀取元數據等操作均安排在工作者線程中進行。波形顯示窗口如圖9所示。

圖9 波形顯示窗口

波形顯示模塊支持數據框選和數據回放功能，數據框選與數據回放共同維護一個字典，字典中記錄著每次框選時波形的起點與終點時刻，并以LIFO的順序進行動態維護。每框選一次波形，向字典末尾添加一條記錄，相反，每回放一次將末尾的記錄彈出，并讀取更新后字典的最后一條記錄。每次框選、回放均調用波形顯示算法重構波形，以確保每一屏的波形光滑、不失真的同時能夠快速響應用戶的各種操作，提升用戶體驗。波形框選后的重構波形如圖10所示。

圖10 數據框選后的重構波形

本節提出動應力測試信號的波形顯示算法，并搭建了相應的軟件界面，經過測試，滿足波形查看的基本要求，實現了測試信號可視化。

4 結 語

針對地鐵動應力測試數據，本文完成了以下工作內容：

(1) 對數據采集系統配套軟件生成的.dac文件格式進行了解析，在解析的基礎上將數據塊區與元數據信息分別存儲，提出便于檢索的數據存儲格式，同時將各通道元數據信息以.xml格式聚合。提出文件格式轉換算法，與傳統轉換方式相比執行效率提升約67.3%。

(2) 提出試驗與測試兩個數據顆粒度的劃分標準，并以該劃分標準為依據設計關系型數據庫，搭建了相應的軟件界面。介紹了數據查詢流程，利用嵌套查詢方式檢索信息，提升查詢效率和準確率。

(3) 研究了地鐵車輛轉向架模型處理方法，搭建了構架模型可視化工具模塊；研究了信號文件波形的顯示算法，提出以抽樣因子為核心的動態計算抽樣率波形顯示算法，搭建了波形顯示模塊。同時，波形顯示模塊支持數據框選與數據回放功能，提升了用戶體驗。

下一階段，在進一步優化管理系統的同時，開發數據挖掘模塊，利用相應的數據挖掘算法模型研究地鐵運行過程中不同工況的識別方法以及工況與構架各部位損傷之間的關聯性，使整個軟件系統功能更加完備。