地鐵動應(yīng)力測試數(shù)據(jù)管理與數(shù)據(jù)可視化系統(tǒng)研究

趙光偉 劉志明 陳 羽

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

0 引 言

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

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

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

1 數(shù)據(jù)存儲

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

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

表1 .dac文件內(nèi)部結(jié)構(gòu)

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

E:channel1.mdta

478350

601195

478350

可以看到，通過將數(shù)據(jù)區(qū)與元數(shù)據(jù)分離，不僅使得數(shù)據(jù)信號文件體積得到了壓縮，文件結(jié)構(gòu)變得十分簡單，而且元數(shù)據(jù)信息也保留了。

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

算法1文件格式轉(zhuǎn)換算法

1. var lists=new List();

//變量初始化

var scheduler=new LimitedConcurrencyLevelTaskScheduler(16);

2. for(int i=0;i

//創(chuàng)建任務(wù)

{

Task t=new Task(()=>

{

Read_Header();

//讀文件頭

If(Header_Over)

{

Write_Data();

//寫數(shù)據(jù)

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線程任務(wù)結(jié)束

})

在算法1中創(chuàng)建了任務(wù)調(diào)度者，控制同時并發(fā)的最大線程數(shù)為16，每個任務(wù)轉(zhuǎn)換一個.dac文件。當并發(fā)任務(wù)數(shù)量大于16時，多個工作線程搶占調(diào)度隊列空間。調(diào)度隊列中的任務(wù)執(zhí)行完畢，按照FIFO的順序退出隊列，剩余線程繼續(xù)搶占調(diào)度空間，直至結(jié)束。在與UI界面交互時，由于開啟任務(wù)數(shù)多于進度條數(shù)目，為了避免多個任務(wù)共同刷新一個進度條，按照多任務(wù)搶占控件的設(shè)計思路進行設(shè)計：搶占成功的工作者線程對控件封送消息，而未搶占成功的線程則阻塞，直至有進度條空閑。進度條控件獲取算法如算法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;

}

}

}

為了測試文件格式轉(zhuǎn)換算法的執(zhí)行效率，向轉(zhuǎn)換工具中導(dǎo)入了22個獨立采集通道的.dac數(shù)據(jù)文件，每通道文件內(nèi)包含60萬個數(shù)據(jù)采樣點。連續(xù)轉(zhuǎn)換5次，并與傳統(tǒng)單線程轉(zhuǎn)換算法的執(zhí)行效率進行了對比，測試結(jié)果如表2所示。

表2 兩種轉(zhuǎn)換算法執(zhí)行效率對比 單位:s

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

圖1 轉(zhuǎn)換工具界面

2 數(shù)據(jù)管理

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

2.1 關(guān)系模型設(shè)計

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

動應(yīng)力測試數(shù)據(jù)關(guān)系模型設(shè)計前，需要提出數(shù)據(jù)劃分依據(jù)，并以該依據(jù)為基礎(chǔ)，研究數(shù)據(jù)間的歸屬關(guān)系：

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

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

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

圖2 數(shù)據(jù)庫模型

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

表3 數(shù)據(jù)庫表單名稱及含義

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

2.2 軟件功能設(shè)計

地鐵動應(yīng)力測試數(shù)據(jù)管理系統(tǒng)的主要需求包括：數(shù)據(jù)錄入、數(shù)據(jù)查詢、數(shù)據(jù)整理、數(shù)據(jù)導(dǎo)出、申請新用戶等，針對以上功能需求，本節(jié)基于.Net Framework 4.5框架，目標平臺為x86架構(gòu)搭建了用戶使用界面。

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

圖3 用戶登錄界面

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

圖4 數(shù)據(jù)管理系統(tǒng)主界面

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

圖5 工況信息查詢流程

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

3 數(shù)據(jù)可視化

3.1 三維模型可視化

地鐵動應(yīng)力測試的主體之一是轉(zhuǎn)向架構(gòu)架，理解構(gòu)架的結(jié)構(gòu)細節(jié)有助于試驗的開展和后期的結(jié)構(gòu)優(yōu)化設(shè)計。數(shù)據(jù)庫中存儲的構(gòu)架模型是.stp格式文件，因此如何將.stp格式模型顯示并集成至管理系統(tǒng)中是本節(jié)研究的重點。為了使可視化工具內(nèi)嵌于數(shù)據(jù)管理系統(tǒng)中，本節(jié)基于AnyCAD.Net SDK中開放的API實現(xiàn)了構(gòu)架模型的可視化。

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

圖6 命名空間、類之間的所屬關(guān)系

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

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

圖7 三維查看器整體界面

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

3.2 測試信號可視化

前文提到，測試信號文件最終的存儲格式是以小端模式、單精度浮點類型、單通道獨立保存的二進制文件格式，后綴名為.mdta，各通道元數(shù)據(jù)以.xml格式保存在后綴為.meta的元數(shù)據(jù)文件中?；谝陨洗鎯Ω袷?，本節(jié)利用.Net Framework 4.5 Winform框架下的chart控件實現(xiàn)了測試信號文件波形可視化。

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

圖8 波形顯示算法

抽樣因子的計算方法為：

factor=2×total/width

(1)

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

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

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

圖9 波形顯示窗口

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

圖10 數(shù)據(jù)框選后的重構(gòu)波形

本節(jié)提出動應(yīng)力測試信號的波形顯示算法，并搭建了相應(yīng)的軟件界面，經(jīng)過測試，滿足波形查看的基本要求，實現(xiàn)了測試信號可視化。

4 結(jié) 語

針對地鐵動應(yīng)力測試數(shù)據(jù)，本文完成了以下工作內(nèi)容：

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

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

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

下一階段，在進一步優(yōu)化管理系統(tǒng)的同時，開發(fā)數(shù)據(jù)挖掘模塊，利用相應(yīng)的數(shù)據(jù)挖掘算法模型研究地鐵運行過程中不同工況的識別方法以及工況與構(gòu)架各部位損傷之間的關(guān)聯(lián)性，使整個軟件系統(tǒng)功能更加完備。