電客車維修組織管理智能化平臺的開發

張興寶 王向娜 逯偉軍

(1.西安市地下鐵道有限責任公司運營分公司 陜西 西安 710018；2.蘭州交通大學 甘肅 蘭州 710600; 3.中國鐵路西安局集團公司安康東站 陜西 安康 725000)

對于地鐵車輛的維修部門而言， “供好車， 供足車”是其核心任務。 為此， 除了制定適合自己車輛的維修模式(計劃修、 狀態修)外， 還需要實時結合車輛的狀態， 有針對性地對其開展相關專項作業以及臨時性作業等。 如何將車輛的專項作業、 臨時性作業和車輛的修程有機結合起來， 確保各項作業順利開展是地鐵車輛維修部門實現“供好車， 供足車”的必要條件。 這些工作都是由車間調度(DCC)根據當天情況進行綜合考慮安排， 難免出現部分項目漏安排、 漏統計以及未按照規定節點完成等情況， 尤其是場段維修基地(“場段維修基地”對應地鐵設計規范中的“車輛段、停車場”)運作后， 類似問題就更加突出(場段調度相關信息不能共享)[1]。

基于以上問題，著手搭建一個信息共享平臺，建立數學模型，相關人員僅在此平臺輸入相關限定條件，然后系統根據這些條件自動生成每日派工單(班組當日生產任務清單)，這樣既可以解放DCC人員，又可以確?，F場生產按照相關要求完成，最主要的是改變了傳統的紙質記錄臺賬繁瑣、相關臺賬存檔混亂以及事后追溯困難等問題。

1 電客車維修組織概況

電客車維修按照其種類分，主要包括計劃性檢修作業、專項修作業和臨時性檢修作業，其維修組織流程如圖1所示。

圖1 現場生產組織流程圖

場段維修基地運作后，場段生產組織和僅車輛段運作時的流程基本一致，但由于多個基地共同完成所有電客車的維修任務，所以場段生產檢修調度需要溝通協調，這樣場段就需要明確一方為主檢調度。主檢調度除負責本場段作業外，還需要綜合協調維修基地(車輛段、停車場)之間的生產任務。此時對場段生產信息的共享和場段相關信息的同步性就提出了更高的要求。場段運作后電客車維修管理具體流程如圖2所示。

圖2 場段運作后現場生產組織流程圖

2 傳統電客車維修組織存在的問題

(1)由于生產任務零散，檢修調度(以下簡稱“檢調”)在編制派工單時，可能出現作業項目遺漏的情況，導致相關工作未能在規定時間內完成。

(2)班組當日專項作業完成后未及時、如實地在項目進度表處登記，導致現場登記的專項維修進度和檢修調度處掌握的進度不一致，兩處信息出現矛盾。

(3)檢修調度跟進專項工作進度是以傳統的Excel形式記錄，容易出現手誤(誤刪或登記信息錯誤等)，這樣檢調處登記的專項進度和現場班組員工的專項工作進度表不一致，產生矛盾。

(4)副調度未及時、準確將本場段的生產完成情況告知主檢調，導致主檢調度未準確掌握電客車各專項作業進度，出現部分列車部分項目遺漏或重復安排作業等情況。

(5)由于現場專項作業進度表單獨記錄，導致在安排第三方人員檢查專項作業的開展情況時相關問題不容易被發現，他控環節的功能衰弱。

(6)關于相關信息，檢調可根據電話、辦公軟件等進行溝通、共享，但場段相關臺賬的整理存檔極為困難，容易出現臺賬存檔不及時以及臺賬丟失等異常情況。

3 電客車維修組織智能化平臺搭建框架

3.1 平臺搭建初衷及實現功能

專項工作技術人員不用向各班組下發紙質生產通知單，僅在此平臺輸入相關要求即可。每日各班組的派工單不是完全由檢調編寫，派工單系統可自動生成。作業結束后不用班組在項目進度表處登記，僅將當日派工單在此平臺上回填即可。專項作業在規定的期限內未完成，不用安排專人檢查，系統可自動提醒。在當天班組交車時，檢調不用查閱檢修記錄單及詢問班組此車是否具備上線條件，僅在此平臺查看即可。專項作業完成后，在后續倒查此專項作業細節內容時，不用在海量的檔案庫內查找相關記錄單，僅在此平臺內輸入相關信息，平臺自動檢索出所需要的資料。

3.2 平臺內相關模塊之間的邏輯關系及平臺運作

圖3所示為此智能平臺運作流程及相關信息的邏輯框架圖。從功能角度考慮，此平臺主要包括三大部分。

圖3 智能平臺邏輯框圖

3.2.1生產任務的閉環管理模塊

(1)發起人在平臺輸入相關信息。技術人員下發的生產通知，不再通過紙質形式下發各班組，僅在此平臺上按照要求填寫相關內容，具體項目如表1所示，填寫完成提交后自動進入校核、審批環節，審核手續流程完成后，平臺將此項內容設為合法任務，并進入執行環節(檢調崗位可看到此項內容)。

表1 生產通知單填寫項目

(2)DCC輸入信息。每日檢調在安排當日生產計劃時，新建派工單，然后輸入作業班組、作業時間、修程和對應列車即可，系統自動篩選出此車符合此條件的所有專項作業，并形成當日對應班組派工單。此時檢調根據外界條件對部分內容進行增刪，最終形成派工單終稿。

(3)班組查派工單，并開展工作。各班組在此平臺僅選擇班組及日期，則系統自動彈出當日派工單(檢調提交的派工單)，派工單內容如表2所示。

(4)派工單回填。班組作業完成后，對當日派工單進行回填，項目內容如表3所示。

表2 x月x日x班派工單

表3 x月x日x班派工單回填單

(5)檢調查看派工單，判斷此車是否具備上線條件。檢調根據派工單的回填信息，確認此車是否具備上線條件，并安排后續工作。

3.2.2信息的儲存和檢索模塊

各專項作業進行中以及結束后，均可根據輸入的不同查詢條件，系統自動檢索輸出不同的結果，例如：輸入專項作業名稱，則查詢結果為此專項作業的進度表(見表4)。

表4 xx專項作業跟蹤進度表

通過此表可了解此專項作業的完成進度，也可追溯某一項歷史作業任務的作業人員等信息，還可以掌握此次專項作業統計發現問題情況等。

3.2.3和其他相關平臺的接口模塊

此部分是為此系統后續實現高級智能化，系統升級所備，是和其他電客車維修相關平臺實現關聯準備的，例如電客車故障錄入系統、電客車履歷管理系統、物資管理系統等。

3.3 平臺解決傳統維修組織存在的問題

(1)此平臺投入后，相關專項作業的生產通知單不再下發紙質版，技術人員僅在此平臺輸入專項作業的相關條件即可，既節省紙張，也方便操作，簡化了流程，提高了效率。

(2)場段班組作業結束后均在此平臺填寫回執單，班組不用再填寫專項作業進度表，并且班組填寫的回執單檢調需要審核，避免了傳統生產組織中出現的班組登記的項目進度表和檢調記錄的項目進度表進度不一致的情況。

(3)場段檢調共用同一個平臺，場段調度在安排專項作業時均以此平臺記錄為依據，避免了傳統生產組織中出現的副調度未將當日專項作業告知主檢調，或雖將生產完成項目告知主檢調，但主檢調未記錄或記錄錯等導致相關工作遺漏的情況。

4 電客車維修組織平臺實現深入智能化規劃

如上設計出的平臺，雖然較傳統的電客車生產組織有了很大的改善，也從一定程度上實現了智能化，但部分內容仍舊需要人工參與。若想繼續減少人工參與，實現高級智能化，則需要利用此平臺預留的擴展接口，增加相關的邏輯判斷以及將此平臺和已有的電客車維修相關平臺進行關聯，具體項目及實現功能如下：

(1)平臺根據電客車修程修制確定原則，智能生成其年、月、周計劃和日計劃。將電客車各修程修制確定原則(各修程維修周期、走行公里數以及允許偏差)寫入后臺，然后此平臺可根據這些條件及各電客車最近修程時間，自動生成年、月、周生產計劃及日計劃，最大化實現電客車不過度修、不失修。

(2)平臺根據電客車大架修公里數要求，智能生成每日各電客車擔當的任務。具體做法是提前給系統設定大架修的時間和公里數要求以及電客車公里數梯隊的梯度，然后系統通過從電客車信息系統中調取各電客車的首次運營時間，走行公里數等，每日動態計算，并智能安排各列車當日擔當任務，方可實現列車走行公里數拉開梯隊，最大程度地實現了電客車大架修作業“不失修、不過修”。

(3)電客車各專項工作的安排及推進計劃實現智能化。各專職人員在此平臺填寫專項作業生產通知單時，需要明確此專項的范圍(列車)、作業時機(在什么情況下作業)、開始時間和結束時間，這樣系統可根據輸入的這些條件判斷輸入條件之間是否有沖突，及時對專職人員進行提醒。同時在任務執行中，當因為某些原因，專項作業耽誤，導致部分電客車可能出現超修時，系統可智能預警，提醒調度盡快安排此項作業，避免超修[2-4]。

(4)維修發現故障和現有電客車故障錄入系統之間實現智能化。電客車維修及專項修發現的問題錄入故障庫后，員工在作業結束后填寫派工單回執單時，此智能平臺自動在此回執單中發現故障數、已處理故障數和未處理故障數等。這樣，同一個問題員工不用重復錄入及統計，同時檢調也可根據回執單確認和把控此車是否具備上線條件。

(5)電客車專項作業和電客車履歷管理系統實現智能化。此平臺和電客車履歷管理系統關聯。對于日常維護變動了履歷項目中的設備，可對作業人員智能提醒，防止員工未及時更新履歷，導致現車和履歷不符合的情況。

(6)此平臺和物資管理系統關聯，備件更替后其規格型號、物資編碼實現智能化。日常維護中部分部件由于質量問題、設計問題或部件停產等問題，選擇替代品在所難免。此時就需要將這些替代品的規格型號/物資編碼及時在物資管理系統中更新，為后續購買備件提供便捷[5]。

(7)此平臺和員工信息管理系統關聯，實現作業任務和員工技能等級之間的智能化。隨著班組員工技能水平的提高及公司對各作業員工技能等級的逐漸規范，需要對電客車各修程各作業的人員技能等級進行明確。各技術人員在下發生產通知時，需要明確此專項作業需要幾個人，各人員需要什么技能等級等，然后平臺和已有的員工信息管理系統進行關聯，班組上班后在平臺輸入到崗人員，然后系統可根據班組員工到崗人員數及各人員的技能等級，自動篩選出當日生產任務，這樣就可避免現場員工無證上崗或“低能高用”等的情況，卡控住了現場生產質量及安全的第一道關口。

5 結語

此平臺已完成了各子模塊的搭建，例如電客車故障錄入系統、電客車履歷管理系統、電客車磨耗部件智能預判系統以及員工信息管理系統等，目前單獨運行良好，已投入應用。整體框架目前還在進行中，待整體框架編程完成后和各子系統進行關聯，測試成功后方可投入現場應用。同時，組織對此平臺的搭建，也總結出如下經驗：

(1)在搭建平臺前，首先做好定位，確認此平臺近期需要實現哪些功能，遠期需要擴展哪些功能，在編程中預留好充分的接口；

(2)參與項目的編程人員較多，必須制定相關的規范，確保后期軟件在關聯調試時，軟件之間可兼容，避免出現返工；

(3)在編寫軟件時，盡可能使用本公司的對軟件有一定基礎的員工。因為本單位員工了解單位基本情況及一線需求，編程出的軟件與IT行業專業人員編程出的軟件相比更貼近實際情況，使用起來更加順手。