一種用于列車運行監控系統的設備故障智能診斷及處理銷號的方法與流程

本發明涉及列車運行監控系統(以下簡稱lkj)的信息化管理領域，尤其涉及機車lkj設備故障分析及處理的方法。

背景技術：

列車運行監控系統(lkj)為機車的行車安全提供了重要保障，lkj設備運用質量是行車安全的基礎，路局各級管理人員和使用人員對lkj設備故障的檢測分析、維修處理、運用質量高度重視。

目前，路局主要采用地面處理軟件解析lkj運行記錄文件，將機車的運行記錄文件按協議解析后通過軟件打開查看，由人工查詢機車運行記錄信息分析機車設備故障，分析發現故障信息后通知檢修人員進行設備更換、維修，維修后的設備再次裝車運用。

然而，人工分析lkj設備故障準確率不高、不及時，分析發現的故障信息無法自動流轉為檢修任務，維修后的設備裝車的運用質量難于跟蹤。

綜上所述，為解決目前lkj設備故障分析及處理存在的弊端，確保lkj設備的運用質量，利用網絡技術、數據分析、流程引擎、消息推送等技術，亟需一種機車lkj設備故障智能診斷及處理銷號的方法，保證lkj設備故障分析、處理銷號的準確、及時、可靠、可控。

技術實現要素：

為了確保鐵路安全運輸，列車運行監控系統(lkj)發揮了至關重要的作用。目前，我國鐵路正處在跨越式發展的特殊時期，各級管理人員及作業人員對機車lkj設備的故障檢測、維修測試都高度重視，投入大量的人力對lkj設備質量進行卡控，但由于lkj設備復雜、故障類型和發生條件的多樣性和時變性等特點，通過人工查閱全程記錄進行分析lkj設備故障，效率不高，并且分析結果完全依賴以分析人員的業務水平和經驗，無法準確判斷設備故障或者故障趨勢。另外，對于lkj設備的維修質量，主要由人工把控，難于跟蹤維修后的設備安裝到機車上運行故障是否已消除。

因此，本發明要解決的技術問題在于：

(1)目前lkj設備的故障分析主要通過人工查閱lkj運行記錄文件中的全程記錄進行分析，人工分析效率不高，還容易出現誤看、漏看，嚴重依賴以分析人員的專業水平。缺乏一種智能檢測、分析設備故障的手段；

(2)lkj設備的檢修主要依賴以故障修和定期修，無法智能分析設備的故障規律和趨勢，并對設備的潛在故障進行預警；

(3)目前lkj設備的維修質量主要由人工把控，維修后設備運用情況主要通過人工盯控，難于跟蹤設備在維修后的運用過程中故障是否消除，存在質量安全隱患。缺乏一種故障處理銷號的卡控手段；

(4)設備的故障分析、故障處理等作業由不同部門協同完成，目前故障信息、故障處理信息沒能做到信息共享、數據流通，分析人員和檢修人員之間無法實現故障信息的自動流轉和檢修任務的自動派送，可能導致故障處理不及時等問題；

(5)故障分析—>機車設備更換—>送修—>故障維修—>修后裝車—>首趟分析銷號等作業環節，沒有實現信息化的流程協作管理，管理人員難于跟蹤故障處理的進度、執行詳情和完成質量等；

(6)各種故障統計、維修記錄采用人工的方式，結果準確性不高，臺帳記錄查詢困難，不利于設備質量的跟蹤管理。

綜上，為滿足鐵路lkj設備故障檢測、故障處理銷號的信息化發展要求，本發明提供了一種機車lkj設備故障智能診斷及處理銷號的方法，通過系統智能分析lkj運行文件、設備運行狀態信息，判斷lkj設備的故障信息或故障趨勢，實現機車lkj設備從故障修到預警修；lkj設備維修裝車后，自動分析機車首趟運行產生的lkj運行文件(以下簡稱首趟文件)，判斷機車lkj設備故障是否已消除，實現故障處理的閉環卡控。

在一個實施例中，本發明提供了一種用于列車運行監控系統(lkj)的設備故障智能診斷及處理銷號的方法，其特征在于，所述方法包括：

a:設置一故障條件配置文件；

b:讀取并解析所述故障條件配置文件，將各種故障類型的判斷依據解析并寫入一故障條件對象數組；

c:機車運行入庫后，上車轉儲lkj運行文件并上傳至地面服務器的指定目錄；

d:讀取并按協議解析所述lkj運行文件，將所述lkj運行文件中的每一條記錄信息解析寫入內存數據表中，每一條記錄至少包括發生時間、事件、狀態值；

e:根據所述故障條件對象數組中的故障判斷條件，對所述內存數據表中的記錄信息進行遍歷和統計分析，判斷是否滿足故障條件，如果滿足，則執行故障處理流程，如果分析未發現故障，則執行步驟f；

f:提取所述lkj運行文件中的機車型號、機車號信息，查詢所述lkj運行文件中提取的機車在數據庫的機車故障信息表中是否存在未銷號的故障信息，如果查詢到未銷號記錄信息，則將故障處理狀態置為“已銷號”，并結束流程；如果未查詢到滿足條件的記錄信息，結束流程。

所述步驟e中的執行故障處理流程包括：

g:將步驟d中檢測到的故障信息寫入數據庫的機車故障信息表中，處理狀態置為“待處理”；

h：利用流程引擎技術自動啟動故障處理流程，利用消息推送技術將故障信息推送給相關檢測、檢修作業人員，進行故障處理提醒；

i：收到故障處理任務后，執行機車故障設備更換和送修流程；

j：收到故障設備后，執行故障維修流程，維修后的設備交由檢測人員進行裝車運用；

k：機車lkj設備更換后運行入庫，再次啟動步驟c。

所述步驟a包括：

在配置文件中按約定格式配置各種故障類型的判斷條件，或者潛在發生故障的條件，以生成“故障條件”配置文件。

所述發生故障的條件至少包括事件、時間段(周期)、次數、閥值。配置格式為：“故障類型＝[事件代號][周期][次數][閥值]”。

某類故障的判斷條件可以是多種場景的組合，采用“&&”符號將“[事件代號][周期][次數][閥值]”進行組合。

當所述故障判斷條件發生變化時，只需修改所述故障條件配置文件。

本發明自動分析lkj運行文件、車載實時狀態數據，利用大數據分析及檢索技術實現lkj設備故障的診斷和預警，通過對檢修機車首趟文件進行分析，實現機車lkj設備檢修質量的閉環卡控。具體創新點和有益效果如下：

(1)上述方案流程步驟201、202中通過配置文件配置故障條件，程序動態加載和解析配置文件的方法，當故障判斷條件發生變化時，只需修改配置文件即可，而不用修改系統(方法)的判斷邏輯，避免了故障判斷條件的變化導致系統(方法)的頻繁修改，大大減輕了系統的維護工作量，增強了系統的實用性；

(2)上述方案流程步驟205中根據故障條件，利用大數據分析技術對記錄信息進行統計、分析、檢索，實現了設備故障的智能診斷和預警，將人工分析變為智能分析，減輕了分析人員工作量，并解決了人工分析存在的不足，大大提高了作業效率和作業質量；

(3)上述方案步驟206中，通過自動分析lkj運行文件實現機車故障的銷號，將人工盯控變為機控，解決了人工跟蹤機車故障處理情況存在的弊端和安全隱患；

(4)上述方案步驟208至210中，利用流程引擎技術，實現了多個部門協同作業，信息共享，解決了管理人員難于跟蹤故障處理的進度、執行詳情和完成質量等難題，提高了設備質量管控水平。

附圖說明

本發明的以上發明內容以及下面的具體實施方式在結合附圖閱讀時會得到更好的理解。需要說明的是，附圖僅作為所請求保護的發明的示例。在附圖中，相同的附圖標記代表相同或類似的元素。

圖1示出了根據本發明一實施例的機車lkj設備故障智能診斷及處理銷號的業務流程圖；

圖2示出了根據本發明一實施例的機車lkj設備故障智能診斷及處理銷號的方法流程圖。

具體實施方式

以下在具體實施方式中詳細敘述本發明的詳細特征以及優點，其內容足以使任何本領域技術人員了解本發明的技術內容并據以實施，且根據本說明書所揭露的說明書、權利要求及附圖，本領域技術人員可輕易地理解本發明相關的目的及優點。

術語定義：

lkj：列車運行監控系統；

lkj運行文件：機車上的lkj設備運行產生的文件，文件中記錄lkj設備在運行中的各種狀態信息和發生的事件信息；

地面處理：一種將lkj運行文件按協議解析為文本文件并打開查看的軟件；

首趟文件：機車發生故障并故障處理后，首趟運行入庫轉儲的lkj運行文件，簡稱為首趟文件或首趟運行文件；

車載實時狀態數據：機車在運行過程中的實時狀態信息，包括速度、各板件狀態、管壓、缸壓等信息；

機車運行入庫：機車完成一趟運輸任務后，需要到指定地點(機務段)進行檢測、檢修和交接工作，完成運行任務后到機務段進行測試、交接工作這一過程成為機車運行入庫；

轉儲lkj運行文件：通過ic卡、手持終端等設備，將lkj設備上的形成的lkj運行文件轉儲(拷貝)至服務器的操作，成為轉儲lkj運行文件；

圖1示出了根據本發明一實施例的機車lkj設備故障智能診斷及處理銷號方法的業務流程圖。

根據設定的故障條件自動檢索、分析lkj運行文件和車載實時狀態數據，判斷lkj設備質量狀態和故障趨勢，利用消息推送技術將故障信息自動轉化為設備更換、檢修任務下達給相關檢測、檢修人員，利用流程引擎技術實現故障分析—>機車設備更換—>故障設備送修—>故障設備維修—>修后裝車—>首趟分析銷號等作業流程的自動路由和閉環，實現了故障分析、故障處理作業的全程盯控；設備維修(更換)上車后，系統自動分析機車的首趟文件，檢測設備故障是否消除，如果已消除，則自動閉環機車設備故障，將機車的故障處理和設備的檢修質量由人控變為機控。

圖2示出了根據本發明一實施例的機車lkj設備故障智能診斷及處理銷號的方法流程圖。

步驟201:在配置文件中按約定格式配置各種故障類型的判斷條件，或者潛在發生該故障的條件，以生成“故障條件”配置文件。故障發生的條件包括事件、時間段(周期)、次數、閥值等信息。配置格式如下：“故障類型＝[事件代號][周期][次數][閥值]”，如果某類故障的判斷條件是多種場景的組合，可以用“&&”符號將“[事件代號][周期][次數][閥值]”進行組合，例如，某一故障類型的發生條件為兩種事件的組合，配置格式為“故障類型＝[事件代號1][周期1][次數1][閥值1]&&[事件代號2][周期2][次數2][閥值2]”。

步驟202:讀取并解析“故障條件”配置文件，將各種故障類型的判斷依據解析并寫入“故障條件對象數組”。

步驟203:機車運行入庫后，上車轉儲lkj運行文件并上傳至地面服務器的指定目錄。

步驟204:讀取并按協議解析步驟203中上傳的lkj運行文件，將lkj運行文件中的每一條記錄信息解析寫入內存數據表中，每一條記錄包括發生時間、事件、狀態值等信息。

步驟205:根據步驟202中描述的“故障條件對象數組”中的故障判斷條件，對內存數據表中的記錄信息進行遍歷和統計分析，判斷是否滿足故障條件，如果滿足，則執行步驟207—210，如果分析未發現故障，則執行步驟206。

步驟206:提取lkj運行文件中的機車型號、機車號信息，查詢lkj運行文件中提取的機車在數據庫“機車故障信息表”中是否存在未銷號的故障信息，如果查詢到未銷號記錄信息，則將故障處理狀態置為“已銷號”，并結束流程；如果未查詢到滿足條件的記錄信息，結束流程。

步驟207:將步驟204中檢測到的故障信息寫入數據庫“機車故障信息表”中，處理狀態置為“待處理”。

步驟208：利用流程引擎技術自動啟動故障處理流程，利用消息推送技術將故障信息推送給相關檢測、檢修作業人員，進行故障處理提醒。

步驟209：收到故障處理任務后，執行機車故障設備更換和送修流程。

步驟210：收到故障設備后，執行故障維修流程，維修后的設備交由檢測人員進行裝車運用。

步驟211：機車lkj設備更換后運行入庫，再次啟動步驟203。

本發明自動分析lkj運行文件、車載實時狀態數據，利用大數據分析及檢索技術實現lkj設備故障的診斷和預警，通過對檢修機車首趟文件進行分析，實現機車lkj設備檢修質量的閉環卡控。具體創新點和有益效果如下：

(1)上述方案流程步驟201、202中通過配置文件配置故障條件，程序動態加載和解析配置文件的方法，當故障判斷條件發生變化時，只需修改配置文件即可，而不用修改系統(方法)的判斷邏輯，避免了故障判斷條件的變化導致系統(方法)的頻繁修改，大大減輕了系統的維護工作量，增強了系統的實用性；

(2)上述方案流程步驟205中根據故障條件，利用大數據分析技術對記錄信息進行統計、分析、檢索，實現了設備故障的智能診斷和預警，將人工分析變為智能分析，減輕了分析人員工作量，并解決了人工分析存在的不足，大大提高了作業效率和作業質量；

(3)上述方案步驟206中，通過自動分析lkj運行文件實現機車故障的銷號，將人工盯控變為機控，解決了人工跟蹤機車故障處理情況存在的弊端和安全隱患；

(4)上述方案步驟208至210中，利用流程引擎技術，實現了多個部門協同作業，信息共享，解決了管理人員難于跟蹤故障處理的進度、執行詳情和完成質量等難題，提高了設備質量管控水平。

上文已對基本概念做了描述，顯然，對于本領域技術人員來說，上述發明披露僅僅作為示例，而并不構成對本申請的限定。雖然此處并沒有明確說明，本領域技術人員可能會對本申請進行各種修改、改進和修正。該類修改、改進和修正在本申請中被建議，所以該類修改、改進、修正仍屬于本申請示范實施例的精神和范圍。

同時，本申請使用了特定詞語來描述本申請的實施例。如“一個實施例”、“一實施例”、和/或“一些實施例”意指與本申請至少一個實施例相關的某一特征、結構或特點。因此，應強調并注意的是，本說明書中在不同位置兩次或多次提及的“一實施例”或“一個實施例”或“一替代性實施例”并不一定是指同一實施例。此外，本申請的一個或多個實施例中的某些特征、結構或特點可以進行適當的組合。

此外，本領域技術人員可以理解，本發明的各方面可以通過若干具有可專利性的種類或情況進行說明和描述，包括任何新的和有用的工序、機器、產品或物質的組合，或對他們的任何新的和有用的改進。相應地，本申請的各個方面可以完全由硬件執行、可以完全由軟件(包括固件、常駐軟件、微碼等)執行、也可以由硬件和軟件組合執行。以上硬件或軟件均可被稱為“數據塊”、“模塊”、“引擎”、“單元”、“組件”或“系統”。此外，本發明的各方面可能表現為位于一個或多個計算機可讀介質中的計算機產品，該產品包括計算機可讀程序編碼。

計算機可讀信號介質可能包含一個內含有計算機程序編碼的傳播數據信號，例如在基帶上或作為載波的一部分。該傳播信號可能有多種表現形式，包括電磁形式、光形式等等、或合適的組合形式。計算機可讀信號介質可以是除計算機可讀存儲介質之外的任何計算機可讀介質，該介質可以通過連接至一個指令執行系統、裝置或設備以實現通訊、傳播或傳輸供使用的程序。位于計算機可讀信號介質上的程序編碼可以通過任何合適的介質進行傳播，包括無線電、電纜、光纖電纜、rf、或類似介質、或任何上述介質的組合。

本申請各部分操作所需的計算機程序編碼可以用任意一種或多種程序語言編寫，包括面向對象編程語言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常規程序化編程語言如c語言、visualbasic、fortran2003、perl、cobol2002、php、abap，動態編程語言如python、ruby和groovy，或其他編程語言等。該程序編碼可以完全在用戶計算機上運行、或作為獨立的軟件包在用戶計算機上運行、或部分在用戶計算機上運行部分在遠程計算機運行、或完全在遠程計算機或服務器上運行。在后種情況下，遠程計算機可以通過任何網絡形式與用戶計算機連接，比如局域網(lan)或廣域網(wan)，或連接至外部計算機(例如通過因特網)，或在云計算環境中，或作為服務使用如軟件即服務(saas)。

此外，除非權利要求中明確說明，本申請所述處理元素和序列的順序、數字字母的使用、或其他名稱的使用，并非用于限定本申請流程和方法的順序。盡管上述披露中通過各種示例討論了一些目前認為有用的發明實施例，但應當理解的是，該類細節僅起到說明的目的，附加的權利要求并不僅限于披露的實施例，相反，權利要求旨在覆蓋所有符合本申請實施例實質和范圍的修正和等價組合。例如，雖然以上所描述的系統組件可以通過硬件設備實現，但是也可以只通過軟件的解決方案得以實現，如在現有的服務器或移動設備上安裝所描述的系統。

同理，應當注意的是，為了簡化本申請披露的表述，從而幫助對一個或多個發明實施例的理解，前文對本申請實施例的描述中，有時會將多種特征歸并至一個實施例、附圖或對其的描述中。但是，這種披露方法并不意味著本申請對象所需要的特征比權利要求中提及的特征多。實際上，實施例的特征要少于上述披露的單個實施例的全部特征。

一些實施例中使用了描述成分、屬性數量的數字，應當理解的是，此類用于實施例描述的數字，在一些示例中使用了修飾詞“大約”、“近似”或“大體上”來修飾。除非另外說明，“大約”、“近似”或“大體上”表明所述數字允許有±20％的變化。相應地，在一些實施例中，說明書和權利要求中使用的數值參數均為近似值，該近似值根據個別實施例所需特點可以發生改變。在一些實施例中，數值參數應考慮規定的有效數位并采用一般位數保留的方法。盡管本申請一些實施例中用于確認其范圍廣度的數值域和參數為近似值，在具體實施例中，此類數值的設定在可行范圍內盡可能精確。

針對本申請引用的每個專利、專利申請、專利申請公開物和其他材料，如文章、書籍、說明書、出版物、文檔、物件等，特此將其全部內容并入本申請作為參考。與本申請內容不一致或產生沖突的申請歷史文件除外，對本申請權利要求最廣范圍有限制的文件(當前或之后附加于本申請中的)也除外。需要說明的是，如果本申請附屬材料中的描述、定義、和/或術語的使用與本申請所述內容有不一致或沖突的地方，以本申請的描述、定義和/或術語的使用為準。

最后，應當理解的是，本申請中所述實施例僅用以說明本申請實施例的原則。其他的變形也可能屬于本申請的范圍。因此，作為示例而非限制，本申請實施例的替代配置可視為與本申請的教導一致。相應地，本申請的實施例不僅限于本申請明確介紹和描述的實施例。