趙光偉 劉志明 陳 羽

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

0 引 言

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

近年來，計(jì)算機(jī)數(shù)據(jù)庫技術(shù)得到飛速發(fā)展，并廣泛應(yīng)用于各個(gè)領(lǐng)域。黃挺等[5]針對(duì)地鐵車輛現(xiàn)場數(shù)據(jù)進(jìn)行了數(shù)據(jù)庫搭建。陳晴等[6]收集了多個(gè)來源的環(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ù)存儲(chǔ)方式[8]。此外為了追求更加完善且符合現(xiàn)實(shí)生產(chǎn)的數(shù)據(jù)模型，研究人員還提出了一種非結(jié)構(gòu)化數(shù)據(jù)庫，支持重復(fù)字段和任意變長數(shù)據(jù)。這些技術(shù)的發(fā)展，彌補(bǔ)了關(guān)系型數(shù)據(jù)庫的一些不足，但由于關(guān)系型數(shù)據(jù)庫具備深厚的技術(shù)基礎(chǔ)、使用經(jīng)驗(yàn)、大量的市場占有額，本文選擇關(guān)系型數(shù)據(jù)庫進(jìn)行數(shù)據(jù)管理。

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

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

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

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

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

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

E:channel1.mdta

478350

601195

478350

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

多通道的.dac文件在轉(zhuǎn)換過程中需要進(jìn)行大量的磁盤IO操作，若全部運(yùn)行在UI線程，則將阻塞UI界面直至崩潰，為了提升轉(zhuǎn)換效率，基于.Net Frame-work 4.5并行任務(wù)框架設(shè)計(jì)了.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();

//報(bào)告UI線程任務(wù)結(jié)束

})

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

算法2進(jìn)度條控件獲取算法

1. Progressbar pb;

//聲明待返回的進(jìn)度條

Int check_index=0;

//指示當(dāng)前進(jìn)度條索引序號(hào)

2. lock(progressbars)

//鎖定進(jìn)度條組

{

while(true)

{

If(check_index

{

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

{

pb=progressbars[check_index];

check_index++;

return pb;

}

}

else

//超出進(jìn)度條組界限

{

check_index=0;

}

}

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

整個(gè)模型以測試和試驗(yàn)兩個(gè)表單為核心進(jìn)行擴(kuò)展，表與表之間僅通過ID進(jìn)行約束。ID字段既作為一個(gè)表的主鍵，又與其他表格中的相應(yīng)字段共同構(gòu)成外鍵約束，在保證信息完整性的同時(shí)正確地反映了試驗(yàn)與測試之間的映射關(guān)系。另外，以單獨(dú)ID字段作為主鍵便于對(duì)數(shù)據(jù)庫進(jìn)行擴(kuò)展，因?yàn)橹恍枰芯啃略鲂畔⑺鶎贁?shù)據(jù)級(jí)別以及相應(yīng)的對(duì)應(yīng)關(guān)系后，在試驗(yàn)表或測試表中增加能夠表示新表單的ID的字段即可，大大提升了動(dòng)應(yīng)力測試數(shù)據(jù)庫的可維護(hù)性和存活周期。

2.2 軟件功能設(shè)計(jì)

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

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

圖3 用戶登錄界面

登錄成功進(jìn)入數(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è)計(jì)原則，將相似的功能模塊聚合在同一功能頁內(nèi)，而模塊之間僅開放少量接口以供調(diào)用。在功能頁中：基本功能頁面向數(shù)據(jù)管理者，主要以錄入信息、維護(hù)信息為主；數(shù)據(jù)檢索面向所有訪客，以檢索和下載數(shù)據(jù)庫中存儲(chǔ)的文本信息與數(shù)字信號(hào)文件為主，是最重要的功能模塊之一。結(jié)合2.1節(jié)中的數(shù)據(jù)庫模型，以查詢某次試驗(yàn)中某天測試工況信息為例，介紹查詢流程。具體查詢過程如圖5所示。

圖5 工況信息查詢流程

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

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

3.1 三維模型可視化

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

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

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

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

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

圖7 三維查看器整體界面

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

3.2 測試信號(hào)可視化

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

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

圖8 波形顯示算法

抽樣因子的計(jì)算方法為：

factor=2×total/width

(1)

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

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

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

圖9 波形顯示窗口

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

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

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

4 結(jié) 語

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

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

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

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

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