梁胤程,杜 翠,劉 杰,楊超宇,3,楊 峰
(1.中國礦業大學(北京) 機電與信息工程學院,北京 100083; 2.中國鐵道科學研究院 鐵道建筑研究所,北京 100081; 3.安徽理工大學 經濟與管理學院,安徽 淮南 232001)
鐵路路基狀態檢測評價是既有鐵路養護維修的關鍵環節。從目前的檢測評價技術手段來看,要實現快速、無損和高精度的檢測和評價鐵路路基狀態,探地雷達尤其是車載探地雷達是一種最為理想的檢測方法[1-2]。鐵路路基狀態周期性檢測是未來發展的必然趨勢,探地雷達數據將呈幾何級數增長。但目前對探地雷達數據的處理和解釋工作主要依靠單機處理,使得海量的探地雷達數據處理時間相對較長,大大降低了檢測的時效性,而且鐵路路基狀態檢測評價數據及結果管理沒有統一規定,不同時間檢測的數據以及不同檢測方法檢測的數據無法進行比對分析,嚴重阻礙路基檢測數據的統計分析和再利用[3-4]。
隨著計算機領域并行處理技術以及大數據處理技術的迅猛發展[5-7],使得通過集群計算實現對海量探地雷達數據的高效處理及智能化的信息提取成為可能。當前國內外學者利用大數據及云計算技術進行探地雷達數據處理分析的研究工作比較少,也不是很成熟。本文采用并行計算技術對鐵路路基狀態檢測中大規模探地雷達數據的處理進行研究,以實現雷達數據的快速處理;通過大量鐵路路基的雷達數據對路基狀態進行動態監測,將鐵路路基狀態檢測中探地雷達的應用由檢測技術向監測技術轉化,預測鐵路路基狀態的變化趨勢,為管理部門決策提供依據。
當前主流大數據并行處理平臺Hadoop和Spark等多用于互聯網行業的數據挖掘和推薦[8],在傳統行業中應用較少。Hadoop和Spark應用于探地雷達數據并行處理時主要存在幾個問題:①編程模型具有局限性,對迭代算法支持較弱,并不適用于部分探地雷達數據的處理,而且處理探地雷達數據的效率過低;②探地雷達數據解析技術已經穩定、成熟,因此對探地雷達數據進行并行處理涉及數據處理算法的移植和重寫,需要較大的工作量,如何快速進行技術遷移也是探地雷達數據并行處理時需要重點考慮的問題。本文基于當前主流大數據并行處理平臺,進行適用于探地雷達數據并行處理的設計和研究。
鐵路路基狀態檢測雷達數據并行處理平臺由鐵路路基狀態監控軟件、探地雷達數據并行處理平臺中心服務器和數據處理集群子服務器構成。探地雷達數據并行處理平臺系統架構如圖1所示。

圖1 探地雷達數據并行處理平臺系統架構圖
鐵路路基狀態監控軟件。雷達數據處理任務的提交及處理算法參數的選擇由鐵路路基狀態監控軟件實現,在客戶端上能夠查看、下載原始文件,將文件提交到服務器集群上執行處理任務,處理完成后能夠查看下載處理的結果。針對服務器集群的運行狀態及任務提交執行情況,建立Web監控端,實時查看服務器集群上的資源利用情況及雷達數據處理情況。
探地雷達數據并行處理平臺中心服務器。中心服務器是整個平臺的核心,相當于整個平臺的“管理者”,負責整個集群的作業控制和資源管理。中心服務器節點負責平臺作業的狀態監控,及時發現集群服務器節點的異常并啟動相應的容錯機制。保存作業的運行信息,用于作業調度時進行任務選擇。不斷接收各個子服務器發來的子服務器資源量和任務執行結果,綜合考慮整個集群的負載情況進行資源管理。
數據處理集群子服務器。負責接收中心服務器發來的任務并進行解析,主要包括任務的屬性信息和處理相關的參數信息。調用移植到處理集群的雷達數據處理程序,對探地雷達數據進行解析處理,主要處理操作包括小波變化、背景去噪、二維濾波、卷積、自動增益等。
本節以作業的生命周期為軸線介紹探地雷達數據并行處理平臺的實現原理,分析1個作業的提交和執行過程。該過程涉及并行處理平臺的各個組件,其中,探地雷達并行處理初始化過程比較簡單,為執行后續作業準備數據、參數及環境等。從用戶提交作業到作業執行的主要過程分為6個步驟,如圖2所示。

圖2 探地雷達數據處理作業提交過程時序圖
步驟1用戶通過鐵路路基狀態監控軟件的客戶端設置雷達數據處理參數并提交初始化任務至并行處理平臺中心服務器。
步驟2雷達數據處理中心服務器根據提交的任務,生成任務配置參數XML文件,轉存至數據存儲陣列相應目錄下保存。
步驟3雷達數據中心服務器根據選用的調度算法將數據處理任務分發到集群中相應的子服務器。
步驟4雷達數據并行處理子服務器根據任務請求,從磁盤存儲陣列中讀取任務參數配置文件并讀取相應的雷達數據文件到本地子服務器。
步驟5子服務器調用探地雷達數據處理算法執行數據解析,將結果返回至中心服務器。
步驟6中心服務器對各子服務器任務處理結果匯總并返回至鐵路路基狀態監控軟件客戶端。
探地雷達數據并行處理平臺采用總分式的架構。中心服務器的并發能力將決定整個平臺的效率,所以中心服務器軟件的開發使用了多種提高并發處理能力的計算機技術,主要包括線程池、事件驅動和Reactor設計模式。Reactor是并發編程中的一種基于事件驅動的設計模式[9]。它具有以下2個特點:通過派發/分離IO操作事件提高系統的并發性能;提供粗粒度的并發控制,采用單線程實現,避免了復雜的同步處理。
探地雷達數據處理任務在平臺中心服務器的處理流程如圖3所示。中心服務器接到用戶請求后,中心服務器端有1個監聽程序(listener),監聽客戶端的任務請求。一旦有新的任務到達,它從輪詢的線程池中選擇1個監聽線程(Reader)進行處理。將所有任務請求封裝成實體請求(Request)存放到共享隊列中,通過共享隊列提高系統處理能力。多線程技術為每個用戶建1個處理線程(Handler),在處理線程中封裝該用戶的請求。考慮到當函數返回結果過大或者網絡速度過慢時難以將結果一次性發送給客戶端,處理線程將嘗試把后續的任務交給集群子服務器任務處理結果匯總線程。此過程中每個任務更新1個狀態列表,記錄當前任務的狀態。任務狀態分為3種:準備,運行和完成。當從共享隊列中取得任務時,任務初始狀態為準備,當中心服務器向子服務器發送執行請求時,進入運行狀態。當子服務器返回任務完成信息時,任務狀態置為完成。共享隊列中當任務狀態為完成時,將任務從隊列中移除,寫文件保存執行狀態。處理線程(Handler)為隊列中的每個任務維護1個服務器任務列表,只有當所有子任務都返回成功,該任務才置完成狀態。

圖3 探地雷達數據并行處理平臺中心服務器數據處理流程
鐵路路基狀態檢測雷達數據并行處理平臺采用Master/Slave架構,中心服務器負責平臺所有任務的分發和調度,而任務分配算法的好壞直接影響探地雷達數據并行處理平臺的執行效率。因此本文的并行處理平臺采用基于服務器的負載的動態調度方法,通過心跳包實時返回子服務器負載情況,設置負載閾值,當子服務器負載達到該閾值時則停止分配新的雷達數據處理任務給該服務器。集群服務器的負載均衡算法主要分為靜態算法和動態算法[10]。靜態分配算法簡單,設置方便,但是在實際應用中,各節點計算機的配置、用戶連接數及用戶請求信息不確定,很難通過靜態負載均衡方案達到負載均衡。采用動態調度算法較靜態算法優越,常用的動態調度算法為加權最小連接法。設N臺服務器的處理能力分別為C1,C2,…,Cn,各服務器的任務請求連接個數為R1,R2,…,Rn,服務器處理能力與當前連接數比值為Wi=Ci/Ri,把當前作業分配給Wi值最大的服務器。
根據探地雷達數據處理算法對服務節點性能的需求,綜合考慮服務器的性能參數(主要有CPU頻率P、內存容量M及網絡速率N)計算服務器的處理能力,以保證各服務器能充分發揮其性能。計算式為
Ci=k1C(P)+k2C(M)+k3C(N)
(1)
式中:ki為各參數的加權系數,根據探地雷達數據處理算法對各參數指標的需求進行設置。
各服務器的當前真實負載Li按照式(2)計算。
Li=k1Li(P)+k2Li(M)+k3Li(N)
(2)
式中:Li(P)為服務器i的CPU占用率;Li(M)為服務器i的內存使用率;Li(N)為服務器i的網絡帶寬占用率。
本文中加權系數k1=0.5,k2=0.3,k3=0.2。
服務器集群在初始化時,設置1個服務器負載閾值Lmax;各服務器的處理能力Ci在加入集群時根據式(1)求得,當前負載Li從開始每隔時間片T由式(2)求得并向中心服務器提交。當有新的請求到達時,根據Ci及Li計算服務器的權值Vi=Ci/Li;選取權值Vi最大的服務器分配任務請求。
探地雷達數據處理就是在強干擾背景下提取微弱有效反射信號的過程[11]。鐵路路基狀態檢測探地雷達數據并行處理平臺的主要目標就是提高這些雷達數據處理算法的解析效率。高頻電磁波在均勻介質傳播過程中呈指數規律衰減,衰減系數與介質的電性參數和波的頻率有關。探地雷達數據處理算法的功能是抑制隨機的和規則的干擾,用最大可能的分辨率在探地雷達圖像剖面上顯示反射波,提取反射波中的有用信息幫助解釋病害信息。本節重點介紹卷積和自動增益算法在探地雷達并行處理平臺中的實現。
地層是由不同巖性和物理性質的巖石組成,不同的物性介質具有不同的波阻抗特性,在相鄰巖石之間的波阻抗差產生電磁波的反射,反射信號被接收天線所接收。這樣,所記錄的雷達信號可表示為1個卷積模型,即地層波阻抗差產生的脈沖響應與雷達子波的卷積。
可以針對雷達記錄提出1個卷積模型。假定1個雷達子波向下垂直傳播,在4 ns雙程時碰見1個界面,此界面的反射系數為R1,反射的雷達子波被接收天線接收到,接收能量的大小由反射系數所決定。如果在多個雙程時都碰見界面,則雷達子波被多次反射。如果反射系數是負值,則子波反射相位與入射信號相位差π。
利用疊合原理,可以建立如下的雷達模型為
x(t)=w(t)*e(t)+n(t)
(3)
式中:x(t)表示雷達記錄;w(t)為雷達子波;e(t)為地層脈沖響應,即為反射系數序列;n(t)為隨機環境噪聲;*為卷積運算。
自動增益的目的是使雷達剖面上各有效波的能量均衡,這種處理便于對有效波的追蹤,也利于弱信號的對比。自動增益依靠雷達記錄乘以隨時間變化的增益權函數實現,即

(4)

對于能量大的反射信號,所乘的權因子應該小;對于能量小的反射信號,所乘的權因子應該大。為了使反射波的記錄不會發生失真,權函數因子隨時間的變化應該比較緩慢。為了計算增益權函數P(t),首先將整個時間窗分割成若干個等時間的小窗口,利用小窗口的能量大小確定控制點的增益大小。
由參數控制點數確定時間窗的數量,在計算平均振幅時,每2個相鄰時間窗之間要重疊半個時間窗。因此,根據控制點數,需要計算的參數有時間窗長、時間窗的起始時間和終止時間。因此,第i個時間窗內的平均振幅計算公式為
(5)
式中:z(t)為要處理的雷達采集的單道信號;Ti-1為第i個時窗的起始時間;Ti+1為第i個時窗的終止時間;Ny為第i個時窗的樣點數;Ai為第i個時窗的平均振幅。
最后,把每個時窗的平均振幅對應于各自的時窗中心作為控制點的增益參數存放起來。
加權函數為
(6)
式中:Pi為第i個時窗中心對應的加權因子;S為用于調整處理后有效振幅大小的平衡系數。
對于那些非時窗中心各點的加權因子,可以利用相鄰2個時窗中心的加權因子線性內插得到。
探地雷達數據并行處理平臺以并行方式運行同一個探地雷達數據處理程序,它把1批任務分解成不連續的單元,保證任務在可用的處理單元之間進行分配。傳統單機版雷達數據處理程序多為用VC++編寫的windows程序,本文平臺盡可能在原有雷達數據處理程序基礎上做較小改動,以減少雷達數據處理算法在并行處理過程中代碼移植的工作量。傳統的圖形化界面的處理程序被分割成2部分,一部分為圖形界面的參數設定,另一部分為集群子服務器的探地雷達數據處理程序。將傳統圖形界面程序的參數設定等操作移植到并行處理平臺的客戶端上。圖4展示了并行處理平臺客戶端自動增益處理的參數設置界面。用戶通過客戶端完成參數的設定,并將形成的XML配置文件提交給并行處理平臺的中心服務器。通過少量修改傳統單機版探地雷達數據處理程序,將代碼編寫成命令行調用程序,子服務器將參數配置文件的參數傳遞給命令行調用的雷達處理程序,并啟動探地雷達處理程序進行探地雷達數據的解析。

圖4 探地雷達數據并行處理客戶端的參數設置界面
鐵路路基狀態檢測探地雷達數據并行處理平臺的實驗環境為由9臺PowerEdge R720計算機組成的集群。計算機的CPU為Xeon E5-2620,內存為16GB DDR3,硬盤大小為1 TB。實驗數據為實地采集的10 GB鐵路路基狀態檢測雷達數據。探地雷達數據在采樣時進行了切分,每個數據塊大小為100 MB左右。
為了比較本文介紹的探地雷達數據并行處理平臺與現有大數據處理平臺在處理探地雷達數據時效率上的差別,實驗測試了本文并行處理平臺和基于Hadoop的探地雷達處理程序對探地雷達數據進行處理時的運行時間、加速比[12]和可擴展性。平臺分別對1 GB和10 GB的鐵路路基狀態檢測探地雷達數據進行處理,探地雷達數據的處理時間為平臺環境和單機環境下5次實驗用時的平均值。探地雷達數據的處理時間對比結果見表1。由表1可見:探地雷達數據并行處理平臺執行卷積操作和增益操作時隨著集群處理節點(服務器)的增加,雷達數據處理時間相應的減少;10 GB雷達數據用8節點的探地雷達數據并行處理平臺處理的效率比單機版軟件的處理效率提高553%,比Hadoop平臺縮短用時50%以上。

表1 不同數量計算機處理雷達數據的用時對比 s
加速比表示在任務量不變的情況下,依次增加計算節點數量后系統運行時間的對比度變化。圖5為探地雷達數據并行處理平臺和Hadoop平臺處理雷達數據的加速比對比。由圖5可見,探地雷達數據并行處理平臺的處理效率和集群中計算機節點數目的關系密切。隨著計算機節點數目的增加,系統加速比不斷變大,處理效率也越高,有較理想的加速曲線;但隨著節點數目和任務數增加,計算節點間數據通信負擔也越大,并行處理平臺的加速比增速逐漸變緩。由于實驗條件限制,未對通信負擔瓶頸進行峰值評估。基于Hadoop的探地雷達數據處理方法隨著計算機節點數的增加也可以獲得較好的加速比,但其加速比低于探地雷達數據并行處理平臺,尤其是當計算機節點數較少時其數據處理速度反而低于單機的處理速度,其主要原因是Hadoop平臺的通訊代價遠大于探地雷達數據并行處理平臺。根據實驗結果,探地雷達數據并行處理平臺能有效解決單機處理雷達數據時隨著數據量的增加執行效率呈指數衰減的問題,相比傳統的探地雷達數據處理方法極大提高了鐵路路基狀態檢測探地雷達數據的處理效率。

圖5 探地雷達數據并行處理平臺的加速比對比
可擴展性是系統可處理更大規模業務的性能指標。可擴展性L被定義為給定程序的系統效率E與忽略了并行通信開銷的系統效率E′的比值,即
(7)
式中:T0為系統通信的時間開銷;T1為串行時的時間開銷;Tn為n個節點并行時的時間開銷。
系統的可擴展性由系統通信的時間開銷和并行計算時間的比值決定。當系統通信時間相對于總執行時間較小時,則說明該并行系統的可擴展性較強。由于系統通信時間是并行系統可擴展性的重要參數,因此通過系統通信時間和總執行時間測試并行系統的可擴展性。
表2給出了對10 GB的探地雷達數據進行各種數據處理操作時的總執行時間和數據通信時間。由表2可見,進行一維濾波、二維濾波和小波變換等雷達數據處理操作時,通信時間和總執行時間的比值低于1%。進行背景去噪和增益變換等操作時,通信時間和總執行時間的比值偏高,這是由于背景去噪和增益變換操作復雜度低,總執行時間過短造成的。隨著并行度的增加,系統通信時間有所增大,增加的通信時間為新增節點的通信時間。本文提出的探地雷達數據處理平臺計算機節點間的通信交互采用第3節中介紹的定制參數傳輸格式,以減少平臺節點間的通信時間。平臺的通信時間主要為雷達數據在節點間傳輸所消耗的時間,相比Hadoop等已有并行系統,通信時間消耗增幅小[13]。平臺數據處理總執行時間在并行度增加時降幅大于已有并行系統,所以本文探地雷達并行處理平臺具有更好的可擴展性。

表2 不同并行度的系統可擴展性測試結果
為了測試探地雷達數據并行處理平臺的數據處理結果的準確性,將并行處理平臺對雷達數據進行二維濾波處理后的數據經過Matlab仿真軟件進行成圖顯示,如圖6所示。二維濾波器選擇切餅式濾波器,視速度1選為1,視速度2選為80,頻率選800 MHz。通過圖6中(b)和(c)的對比分析可知,由并行處理平臺得到的雷達數據處理結果和傳統單機版軟件的處理結果基本一致,二維濾波將有效信號和干擾信號在頻率和視速度上進行區分,抑制了圖中橫向的道間水平信號,增強了視速度小的傾斜信號。經過并行處理平臺濾波處理后的雷達波曲線同樣比較平滑,而且對有效雷達波進行了增強顯示。

圖6 探地雷達數據經二維濾波處理圖
圖7為探地雷達數據先經過并行卷積處理后再進行并行增益處理的實驗效果圖。增益因子為線性增益at+bect,參數a取6.1,b取0.006,c取0.055。雷達波每條數據的采樣時間窗為200 ns,實驗中增益控制點數選為10個。通過圖7中(a)和(b)的對比分析可知,采用本文的并行處理平臺對原始雷達波的干擾信號進行有效去除的同時,還對低頻漂移具有良好的抑制效果,有效提高了信號的分辨率。圖7(c)為平衡雷達有效波時能量均衡的增益效果。對能量大的反射信號乘以較小的權因子,對能量弱的反射信號乘以較大的權因子。進行并行處理增益操作時,通過對增益控制點的合理選擇,放大探地雷達波中的弱小信號,從而提高了雷達信號對不同介質反射波的分辨能力。

圖7 雷達波先卷積后增益仿真示意圖
圖8為雷達數據并行處理平臺成像顯示的鐵路路基檢測雷達數據二維剖面圖,橫坐標對應測線位置,縱坐標代表探測深度。圖中圓形標注區域表示該區域鐵路路基局部含水量大,正方形標注區域表示該區域鐵路路基基床下沉。局部含水量大在剖面圖中表現為低頻強振幅高能量反射,有時會出現多次反射現象,含水量越高,反射能量越強。基床下沉在圖中表現為基床表層反射的同相軸發生明顯彎曲下沉或同相軸中斷不連續,如砟土混合較嚴重,其同相軸有缺失。
從圖8中可以看出,探地雷達數據經過并行處理后其圖像較好地表現了不同介質的回波反射數據,成像邊界清晰,便于對鐵路路基病害的發現和標識。

圖8 雷達數據解析剖面圖
(1)探地雷達數據并行處理平臺能高效濾波解析雷達數據。處理時間、并行化加速比和系統可擴展性等性能指標較傳統方法都有明顯的改善,其中8節點的探地雷達數據并行處理平臺的處理效率比平臺單機版數據處理軟件提高553%,探地雷達數據處理時間比基于Hadoop的平臺縮短50%以上,同時減少了大量的代碼移植工作,實現了鐵路路基狀態檢測中探地雷達的應用由檢測技術向監測技術轉變。
(2)探地雷達數據并行處理平臺可對雷達干擾信號進行有效去除,放大探地雷達波中的弱小信號,提高了雷達信號對不同介質反射波的分辨能力。探地雷達數據經過并行處理后圖像較好地表現了不同介質的雷達回波反射數據,成像邊界清晰,便于鐵路路基病害的發現和標識。
[1]劉杰. 鐵路路基含水狀態的探地雷達檢測方法研究[D]. 北京:中國礦業大學(北京), 2015.
(LIU Jie. Research of Ground Penetrating Radar Detection Method in Railway Subgrade Water Content Condition[D]. Beijing:China University of Mining & Technology,2015. in Chinese)
[2]郭秀軍, 韓宇, 孟慶生,等. 鐵路路基病害無損檢測車載探地雷達系統研制及應用[J]. 中國鐵道科學, 2006, 27(5):139-144.
(GUO Xiujun, HAN Yu, MENG Qingsheng, et al.Manufacture and Application of the On-Board Ground Penetrating Radar for Non-Invasive Inspection of Railway Subgrade Defects[J]. China Railway Science,2006,27(5):139-144. in Chinese)
[3]聶如松, 冷伍明, 楊奇. 既有重載鐵路路基檢測試驗與狀態評估[J]. 鐵道工程學報, 2014, 31(11):20-24.
(NIE Rusong, LENG Wuming, YANG Qi. Detection Test and Condition Assessment on Existing Heavy Haul Railway Subgrade[J]. Journal of Railway Engineering Society, 2014, 31(11):20-24. in Chinese)
[4]許獻磊. 車載探地雷達系統的開發及其應用實驗研究[D]. 北京:中國礦業大學(北京), 2013.
(XU Xianlei. Development of the Vehicle-Borne Ground Penetrating Radar System and Application Experimental Study [D]. Beijing:China University of Mining & Technology (Beijing), 2013. in Chinese)
[5]GHEMAWAT S, GOBIOFF H, LEUNG S T. The Google File System[C]//19th ACM Symposium on Operating Systems Review.New York: ACM, 2003: 29-43.
[6]DEAN J, GHEMAWAT S. MapReduce: Simplified Data Processing on Large Clusters[C]// 6th Symposium on Opearting Systems Design & Implementation. San Francisco:DBLP, 2004:137-150.
[7]CHANG F, DEAN J, GHEMAWAT S, et al. Bigtable: a Distributed Storage System for Structured Data[C]// 7th Usenix Symposium on Operating Systems Design & Implementation. Seattle:DBLP, 2006:205-218.
[8]趙彥榮, 王偉平, 孟丹,等. 基于Hadoop的高效連接查詢處理算法CHMJ[J]. 軟件學報, 2012, 23(8):2032-2041.
(ZHAO Yanrong, WANG Weiping, MENG Dan,et al. Efficient Join Query Processing Algorithm CHMJ Based on Hadoop[J].Journal of Software,2012, 23(8):2032-2041. in Chinese)
[9]董西成. Hadoop技術內幕:深入解析MapReduce架構設計與實現原理[M]. 北京:機械工業出版社, 2013.
(DONG Xicheng. Hadoop Internals: In-Depth Study of MapReduce[M]. Beijing:China Machine Press, 2013. in Chinese)
[10]楊際祥, 譚國真, 王榮生. 并行與分布式計算動態負載均衡策略綜述[J]. 電子學報, 2010, 38(5): 1122-1130.
(YANG Jixiang, TAN Guozhen, WANG Rongsheng. A Survey of Dynamic Load Balancing Strategies for Parallel and Distributed Computing[J]. Chinese Journal of Electronics,2010, 38(5): 1122-1130. in Chinese)
[11]楊峰,彭蘇萍. 地質雷達探測原理與方法研究[M]. 北京:科學出版社, 2010.
[12]李文石, 姚宗寶. 基于阿姆達爾定律和蘭特法則計算多核架構的加速比[J]. 電子學報, 2012, 40(2):230-234.
(LI Wenshi, YAO Zongbao. Multicore Architecture Speed up Computation Based on Amdahl’s Law and Rent’s Rule[J]. Chinese Journal of Electronics,2012, 40(2):230-234. in Chinese)
[13]周敏奇. Hadoop 權威指南[M]. 北京:清華大學出版社, 2011.
(ZHOU Minqi. Hadoop the Definitive Guide[M]. Beijing: Tsinghua University Press,2011.in Chinese)