李超旭,王 輝,李 燕,喬成珍
(中國鐵道科學研究院集團有限公司 電子計算技術研究所,北京 100081)
故障預測與健康管理(PHM,Prognostics and Health Management)技術誕生之初是為了提高航空飛行器的運營維護(簡稱:運維)效率,保障飛行設備的運行安全,通過基于狀態修的維修方式,降低故障率與運維成本[1-2]。隨著PHM技術的不斷發展,其技術理念與應用效果,得到了眾多行業的關注。近年來,軌道交通領域的PHM和大數據技術研究與應用的熱度持續上升[3-5],隨著修程修制改革、狀態修、智能運維等動車組運維目標的設立[6],中國國家鐵路集團有限公司(簡稱:國鐵集團)從2018年開始開展動車組PHM技術研究工作,已取得一定的進展,設計了一套可應用于全國鐵路范圍的開放式動車組PHM系統方案,搭建了動車組PHM系統,并與各鐵路局集團公司開展了試用聯調工作,相關功能研究工作也在穩步進行[7]。
動車組PHM模型是指利用新造、運用、檢修、環境等相關數據,借助算法對動車組系統或其部件進行故障預測、故障診斷、健康評估及運維決策的邏輯組合[8]。動車組PHM模型是動車組PHM的研究重點,是動車組PHM系統實現故障預測與健康管理功能的關鍵。PHM模型的設計與應用,可為提升動車組智能運維水平、提高檢修效率、實現修程修制改革提供技術支撐。
截至2021年11月,國鐵集團研發的動車組PHM系統中已上線部署百余個閾值類PHM模型,適配車型10余種。現場聯調測試結果表明,這些模型的投入使用減少了動車組運維單位的工作量,有效指導了動車組部件的精準維修,可做到及時預防行車過程中的安全隱患,保障運輸安全,同時為延長修提供監測支持。由于動車組PHM技術的研究內容較為寬泛,且全國鐵路范圍的動車組PHM技術研究處于早期發展階段,諸多關鍵技術尚未解決。PHM模型作為動車組PHM技術的重點研究內容,面臨著數據處理和應用等方面的難題。
動車組PHM系統現有的模型數據處理流程如圖1所示,動車組運行監測數據通過動車組車載信息無線傳輸系統(WTDS ,Wireless Transmission Device System)傳輸至中國鐵路主數據中心(簡稱:主數據中心)后,由主數據中心將車載運行監測數據轉發至動車組PHM系統所屬的消息隊列中,再由PHM模型對實時數據進行分析處理。該處理流程與機制可基本滿足實時環境下PHM模型計算所需的條件,但存在較大的局限性,例如,不能較好進行高并發情況下的模型快速響應、存在一定的數據存儲冗余等問題。且該架構只適用于實時數據處理,對批處理模型與多源模型的數據需求缺乏一定的考慮,在一定程度上限制了系統支持的模型種類。

圖1 既有動車組PHM模型數據處理流程
為滿足PHM模型計算對WTDS實時數據與歷史數據的需求,提升數據處理效率,提高數據可用性,在遵循動車組PHM總體技術架構規劃下,本文提出優化的動車組PHM模型數據處理架構。
優化的動車組PHM模型數據處理總體架構在既有的模型數據處理流程基礎上,引入動車組運維信息系統的數據作為新的數據源,滿足模型對多種類源數據的需求;同時,針對WTDS實時數據,設計了分布式存儲、消息隊列、緩存3種數據持久化方式,滿足模型對實時數據和歷史數據的處理需求,提高數據處理效率,總體架構如圖2所示。

圖2 優化的動車組PHM模型數據處理總體架構
優化的動車組PHM模型數據處理技術架構如圖3所示,共分為4層,分別為源數據層、數據匯集層、數據處理層、數據匯總層。

圖3 優化的動車組PHM模型數據處理技術架構
(1)源數據層。包含動車組PHM模型運行所需的數據,來自動車組運用檢修、行車安全檢測等相關的信息系統及相關作業設備。
(2)數據匯集層。主要負責源數據的抽取、匯集工作,根據數據結構特點及業務需求,選擇適合的數據ETL(Extract-Transform-Load)方法進行數據抽取,匯集源數據層的數據并持久化,供數據處理層使用。
(3)數據處理層。主要負責對匯集的數據進行清洗、轉換、融合與分類,借助SparkStreaming實現數據去重、噪點數據過濾、數據標準化、故障合并等處理步驟,將數據加工成可被動車組PHM模型直接利用的數據格式。
(4)數據匯總層。包含數據處理層處理后的數據,根據數據結構及類型對數據進行劃分,并持久化到不同的數據庫中,供模型程序調用。該層數據根據業務劃分后主要包括主題數據、WTDS歷史數據、動車組運用、故障和檢修數據及相關業務緩存數據。
目前,PHM模型的應用大部分基于對WTDS實時數據的處理,以達到實時故障預測或提供維修處理建議的目的。在不考慮模型邏輯的前提下,WTDS數據質量對模型應用效果有較大影響。
WTDS數據可實時刻畫列車在運行過程中各部件、系統的狀態參數[9],包含車組故障信息、運行狀態、地理位置信息等。對WTDS運行狀態參數數據可進行如下抽象。
假設某一時刻某列動車組的WTDS數據集為R;車廂號為n,編組長度為l,n=1,···,l;運行狀態參數為c,集合為C,參數集合數量為m。該車組第n個車廂,第i個時刻的 WTDS數據集合為

其中,cinm為第i個時刻接收到的第n節車廂的第m個參數;vinm為cinm對 應的參數值。令則有,WTDS數據集R為

當前,WTDS數據治理工作尚未全面開展,存在一定的數據質量問題,因此模型計算前的數據處理十分必要[10]。
3.1.1 數據清洗
數據清洗是數據處理過程中的必要環節,通過數據清洗可糾正源數據的各類數據問題,提高數據質量,保障模型輸出的準確度。結合運用經驗,WTDS數據主要存在以下2類問題。
(1)重復數據
數據重復是一種常見的WTDS數據質量問題,具體表現形式可描述為:在第i個時刻,接收到同一列車的數據中存在多個相同的參數集合(cinm,vinm)。該類數據問題會影響模型的計算效率,增加數據處理負擔,降低模型準確率。對此類問題,可將數據抽取到數據匯集層后再進行去重處理。結合WTDS數據特點,單條WTDS數據內去重可采用Hash算法,剔除數據內的重復參數數據;對不同時序上的WTDS數據間去重,可采用Simhash算法,利用“分詞—Hash—加權—合并—降維”處理步驟得到1條WTDS數據的Simhash簽名,通過計算不同WTDS數據Simhash簽名間的漢明距離(Hamming Distance),判斷數據間的相似度,達到去重的目的。
(2)無效數據
無效的WTDS數據主要有噪點數據和干擾數據2種表現形式。噪點數據主要表現為某一時刻接收到的WTDS參數值較該條數據前后時刻的數據參數值變化率超出了正常的數值波動范圍。例如:在某一時間序列上的前后2包數據內的軸溫參數值由50℃跳變為300℃。干擾數據則表現為同一部件、相同位置的運行參數,在同一時間戳i上,存在兩個不同的參數值,即存在多個不同的vinm與同一cinm對應。噪點數據與干擾數據都會對模型邏輯處理產生嚴重干擾,影響模型結果準確性,2類數據清洗工作的開展需要結合業務經驗,針對數據使用場景,研究數據清洗的方式方法,例如,對跳變類的噪點數據可通過對比前后2包數據的最大數值差實現跳變數據的基本過濾;對多值類的干擾數據可結合WTD設備的數據傳輸策略制定數據清洗方法。對作為實時計算模型的源數據,選取的數據處理算法應高效、快速,最小限度地降低數據時效性損失,保障模型輸出的及時性。
3.1.2 參數標準化
WTDS數據落地時需要利用解析協議對數據進行解碼,明確每個車載參數代碼所代表的參數含義。由于解析協議來源于各主機廠,協議規范尚未統一,不同車型對應的數據解析協議也有差異,存在代表相同含義的參數因解析協議不同而編碼不同的情況。因此,需根據WTDS參數的含義與類型,將WTDS數據進行標準化轉換,形成統一規范的數據編碼格式,從而提高模型程序構建效率,降低維護成本。
動車組PHM模型種類多樣,適用范圍覆蓋動車組運維過程的多個階段,模型的輸入數據源包含多個動車組運維類信息系統,數據特點呈現多樣性和異構性。按照數據結構分類,常用的模型輸入數據源可分為以動車組管理信息系統(EMIS,EMU Management Information System)數據為代表的結構化數據和以WTDS數據為代表的非結構化數據。考慮到數據結構的差異性與模型計算所需的數據條件,模型接入的源數據的存儲與獲取方式選擇尤為重要。
3.2.1 實時數據
WTDS數據是實時計算模型的主要實時數據源,為滿足實時計算模型低時延、高時效的特定需求,可采用Kafka消息隊列做為WTDS實時數據的持久化方式,將原始數據與清洗后的數據均存放至Kafka集群,用于實時計算模型消費。由于車組運行過程中,車地數據傳輸可能會存在一定的信號波動,導致數據落地時序亂序。因此,為最大限度地保障模型輸入數據的時序性,原始的WTDS實時數據落地Kafka時可采用輪詢的方式寫入。對于清洗后的WTDS數據,將數據的車組信息作為該條數據的key寫回Kafka,保證同一車組的數據保存在同一分區下,使得模型在實時消費WTDS數據時,可在一定程度上保證數據的時序性。
3.2.2 歷史數據
WTDS數據需長期持久化,以滿足批處理類模型及上層應用的數據需求。選用HBase存儲WTDS歷史數據,既可滿足大體量數據的分布式存儲,又可實現查詢的快速響應。由于WTDS歷史數據體量較大,且存儲周期較長,需考慮數據傾斜問題,避免產生數據熱點,造成集群節點性能下降。上述問題可通過采用設置預分區、結合數據特點為行鍵(Rowkey)添加散列值等方法解決。
模型計算過程中產生的中間結果需臨時存儲,供下一步計算時調用。同時,為提高模型的計算效率,可將計算過程中需頻繁查詢的結構化數據提前抽取到緩存區中,供程序調用。結合模型計算特點及運行環境情況,本文采用公共緩存和特定緩存兩種緩存機制,設計了模型數據處理架構的緩存區及其部署架構,如圖4、圖5所示。

圖4 緩存區設計示意

圖5 緩存區部署架構
3.3.1 公共緩存區
公共緩存區由多臺Redis服務器搭建成Redis集群,用于存儲具有同類計算邏輯的中間結果數據和從其他系統中抽取的結構化數據,該緩存區的數據可被全部模型程序共享,且該區內緩存數據由獨立的程序負責維護和管理。通過設立公共緩存區,可減少同類計算邏輯的重復計算與跨系統的數據交互,提高模型程序的運算效率。
3.3.2 特定緩存區
特定緩存區用于存儲公共緩存區以外的具有特定模型計算需求的中間數據。同時,為提高緩存的讀寫效率,減少由于集群內網絡波動導致的緩存交互時延,特定緩存區需架設在模型計算服務器中。特定緩存區內的緩存數據只可被該節點內的模型共享,其他服務器節點運行的模型程序不可訪問,且緩存數據的維護與管理也只由該節點上的模型程序負責。
WTDS數據的轉發與解析是WTDS數據處理的重要環節,動車組實時回傳的報文數據需要即時解析并傳輸給PHM模型的輸入數據節點及其他有WTDS數據需求的系統,因此,WTDS實時數據抽取的效率是保障PHM系統及模型實時性預警的關鍵。據統計,當前WTDS解析前數據單通道傳輸量平均約為14 100條/min,解析后數據單通道傳輸量平均約為97 020條/min。在測試環境下(測試環境配置如表1所示),采用本文優化的PHM模型數據處理架構,在數據抽取方面實現了單通道29 700條/min解析前數據抽取和119 600條/min解析后數據抽取,如圖6所示。在數據處理方面實現了平均2 561條/s的數據解析、清洗與存儲,如圖7所示。實驗結果表明,該數據處理架構的性能可滿足WTDS數據處理需求。

表1 實驗環境配置

圖6 抽取WTDS數據

圖7 處理WTDS數據
同時,基于動車組PHM模型對EMIS業務數據的需求,結合本文數據處理架構的設計思路,根據EMIS各類業務數據的數據情況與更新頻率,制定EMIS業務數據的抽取、清洗策略,將EMIS業務數據持久化到模型數據處理架構的公共緩存區中,供各模型程序使用。如圖8所示,在測試環境下借助StreamSets構建了EMIS中動車組開行、走行公里、高級修、配屬、車組狀態、構型等多類結構化數據的公共緩存區,同時實現了緩存區數據的動態更新。

圖8 StreamSets構建EMIS數據公共緩存區示意
本文從動車組PHM模型的應用現狀出發,針對模型源數據處理,優化了模型數據處理總體架構和技術架構。同時,對WTDS數據處理技術、數據存儲、數據緩存等關鍵技術進行了探討與研究。經測試驗證,該優化的架構高效可行,解決了動車組PHM模型源數據處理難題,為動車組PHM模型更好地服務于動車組運行安全監控與運維指導提供了保障。