ATP 車載設(shè)備智能檢修管理關(guān)鍵技術(shù)及應(yīng)用

戴 博，康仁偉，李 科，王 彧，衣沛然

ATP 車載設(shè)備是保障動(dòng)車組運(yùn)行安全的關(guān)鍵設(shè)備，其日常檢修是支撐設(shè)備正常運(yùn)轉(zhuǎn)的必要手段。目前各鐵路局集團(tuán)公司主要采用傳統(tǒng)的檢修方式，人工編制檢修計(jì)劃，攜帶檢修記錄單和攝像手電等上車作業(yè)，作業(yè)完成后再手動(dòng)填寫檢修記錄，檢修效率低下，過(guò)程監(jiān)控缺失，信息統(tǒng)計(jì)困難，嚴(yán)重制約了ATP的檢修效率和安全保障能力。

按照工業(yè)4.0 戰(zhàn)略部署和技術(shù)引領(lǐng)，傳統(tǒng)的鐵路行業(yè)急需數(shù)字化升級(jí)改造［1］，并逐步向智能化發(fā)展。文獻(xiàn)［2］從建設(shè)、裝備、運(yùn)營(yíng)三大業(yè)務(wù)主線出發(fā)，搭建了集業(yè)務(wù)、應(yīng)用、數(shù)據(jù)、技術(shù)、評(píng)價(jià)和標(biāo)準(zhǔn)為一體的我國(guó)智能高鐵體系架構(gòu)；文獻(xiàn)［3］將高鐵作為一個(gè)復(fù)雜系統(tǒng)，從系統(tǒng)論的角度，構(gòu)建了高鐵建設(shè)、運(yùn)營(yíng)、管理的系統(tǒng)模型。這2 個(gè)文獻(xiàn)從宏觀的角度，頂層設(shè)計(jì)了智能高鐵未來(lái)發(fā)展的藍(lán)圖和技術(shù)發(fā)展方向。在鐵路信號(hào)領(lǐng)域，自動(dòng)駕駛、智能調(diào)度指揮和智能運(yùn)維被認(rèn)為是高速鐵路信號(hào)系統(tǒng)的3 大典型智能技術(shù)［4-5］。由此可見，ATP日常檢修的全程信息化管理是實(shí)現(xiàn)智能運(yùn)維的必然要求，也是實(shí)現(xiàn)從預(yù)防修到狀態(tài)修轉(zhuǎn)變的必然途徑［6-8］。文獻(xiàn)［9］提出了一種ATP 車載設(shè)備全路通用的唯一標(biāo)識(shí)編碼方案，以二維碼的形式粘貼在設(shè)備固定位置，為檢修管理快速精準(zhǔn)地識(shí)別特定設(shè)備提供了技術(shù)保障；文獻(xiàn)［10］設(shè)計(jì)了一種基于手持終端的ATP 作業(yè)檢修系統(tǒng)，重點(diǎn)說(shuō)明手持終端在檢修作業(yè)中的功能，但是缺少整體的架構(gòu)設(shè)計(jì)和流程規(guī)劃。

綜上所述，本文研究ATP 車載設(shè)備智能檢修管理系統(tǒng)，實(shí)現(xiàn)設(shè)備從檢修計(jì)劃到檢修過(guò)程，從檢修結(jié)果到統(tǒng)計(jì)分析的全程信息化和智能化，具有重要的現(xiàn)實(shí)意義。

1 ATP設(shè)備智能檢修管理需求分析

從2008年京津城際開始，全路ATP 車載設(shè)備在將近10年的時(shí)間內(nèi)統(tǒng)一采用固定周期、固定項(xiàng)目的檢修方式，設(shè)備一級(jí)修平均每天做一次，二級(jí)修平均每個(gè)月做一次。隨著ATP 設(shè)備數(shù)量逐年遞增，檢修任務(wù)量越來(lái)越大，迫切需要提質(zhì)增效，減輕現(xiàn)場(chǎng)職工的作業(yè)負(fù)擔(dān)。此外，設(shè)備運(yùn)用趨于穩(wěn)定，故障率逐年下降，說(shuō)明固定周期的檢修必要性降低。因此，從2016年開始，上海局集團(tuán)公司率先開始ATP 車載設(shè)備修程修制的改革探索，適時(shí)延長(zhǎng)檢修周期并調(diào)整檢修項(xiàng)目。

為進(jìn)行差異化檢修，提出了“檢修包”的概念，即用戶可以根據(jù)實(shí)際需求，集合若干條檢修項(xiàng)目構(gòu)成一個(gè)檢修包。例如所有一級(jí)修的無(wú)電項(xiàng)目組成一個(gè)檢修包，當(dāng)本次列車入庫(kù)時(shí)，可以只按照該檢修包的條目和要求作業(yè)。除了靈活定義檢修包的內(nèi)容之外，每個(gè)檢修包的周期也可以靈活配置。由此，形成了以檢修包為核心的檢修方案。

在既有檢修模式的基礎(chǔ)上，ATP 車載設(shè)備智能檢修管理系統(tǒng)整體需求如下。

1）靈活配置檢修周期和項(xiàng)目。全路ATP修程修制改革鼓勵(lì)檢修單位根據(jù)實(shí)際情況制定檢修項(xiàng)目和周期，因此，各路局每個(gè)電務(wù)段的檢修項(xiàng)目和周期都不盡相同，需要提供用戶自定義檢修項(xiàng)目和周期的平臺(tái)，各基層單位可按照實(shí)際情況制定不同的檢修策略，并設(shè)置失修漏檢的報(bào)警條件。

2）自動(dòng)生成檢修計(jì)劃。目前，ATP 車載設(shè)備的檢修計(jì)劃是先由人工手動(dòng)編制，交由車間審核，再由工區(qū)具體實(shí)施。而智能檢修管理系統(tǒng)是根據(jù)動(dòng)車組的檢修計(jì)劃及電務(wù)段自定義的檢修周期，自動(dòng)生成ATP 的當(dāng)日入庫(kù)檢修計(jì)劃，并在系統(tǒng)中完成檢修計(jì)劃的審核和下派等卡控流程。

3）作業(yè)過(guò)程閉環(huán)控制。實(shí)現(xiàn)檢修作業(yè)過(guò)程留痕和卡控，自動(dòng)記錄用戶實(shí)施的作業(yè)流程和作業(yè)規(guī)范，從任務(wù)發(fā)起到任務(wù)結(jié)束全流程閉環(huán)控制，自動(dòng)生成檢修記錄和異常情況記錄，并將數(shù)據(jù)自動(dòng)上傳至服務(wù)器，由調(diào)度分析人員即時(shí)調(diào)閱。

4）失修漏檢實(shí)時(shí)預(yù)警。由于不同電務(wù)段設(shè)置不同的檢修周期，同一等級(jí)的檢修任務(wù)又包括不同的檢修包，因此，需要對(duì)即將到期或者已經(jīng)超期的設(shè)備分級(jí)預(yù)警，及時(shí)提醒現(xiàn)場(chǎng)作業(yè)人員ATP 設(shè)備的檢修狀態(tài)，盡量做到既不失修，也不過(guò)剩修。

2 智能檢修管理系統(tǒng)設(shè)計(jì)

2.1 檢修作業(yè)閉環(huán)控制流程

ATP 智能檢修業(yè)務(wù)主要從檢修計(jì)劃、檢修任務(wù)、作業(yè)過(guò)程、作業(yè)結(jié)果、失修漏檢預(yù)警等方面進(jìn)行約束和控制。整個(gè)閉環(huán)控制流程見圖1。

圖1 ATP車載設(shè)備檢修作業(yè)閉環(huán)控制流程

1）檢修計(jì)劃。ATP 車載設(shè)備需要伴隨動(dòng)車組的檢修而檢修，只有動(dòng)車組入庫(kù)之后才具備檢修條件。通常，車輛專業(yè)有明確的檢修計(jì)劃，包括動(dòng)車組的計(jì)劃出入庫(kù)時(shí)間、?？抗傻馈⒂须娮鳂I(yè)時(shí)間段、無(wú)電作業(yè)時(shí)間段、作業(yè)項(xiàng)目等，這些信息由動(dòng)車組管理信息系統(tǒng)負(fù)責(zé)存儲(chǔ)和更新。ATP 車載設(shè)備日常檢修計(jì)劃來(lái)源于兩方面：一是通過(guò)ATP 智能檢修系統(tǒng)與動(dòng)車組管理信息系統(tǒng)的接口獲??；二是用戶新建的ATP 檢修計(jì)劃。前者通常會(huì)根據(jù)車輛和電務(wù)的作業(yè)重疊關(guān)系，在車輛計(jì)劃基礎(chǔ)上，結(jié)合ATP 設(shè)備修程，自動(dòng)生成ATP 檢修計(jì)劃；后者則可根據(jù)臨時(shí)性、突發(fā)性的情況，由用戶再次新建檢修計(jì)劃。2 個(gè)方面相互補(bǔ)充、靈活運(yùn)用，共同服務(wù)ATP設(shè)備日常檢修計(jì)劃。

2）檢修任務(wù)。ATP 設(shè)備檢修是一項(xiàng)相當(dāng)嚴(yán)肅的業(yè)務(wù)，對(duì)于生成的檢修計(jì)劃，需要更高級(jí)別的權(quán)限進(jìn)行審核。高權(quán)限用戶對(duì)初始計(jì)劃可以編輯、刪除等，最后形成規(guī)范的、有效的、有約束力的檢修計(jì)劃，以此計(jì)劃作為每天檢修任務(wù)的基準(zhǔn)。

3）作業(yè)過(guò)程。為實(shí)現(xiàn)作業(yè)過(guò)程控制，設(shè)計(jì)研發(fā)移動(dòng)終端。PC 端生成的檢修計(jì)劃傳輸至移動(dòng)終端［10］，用戶攜帶移動(dòng)終端上車作業(yè)。提供2 種方式將PC 端的計(jì)劃分派至移動(dòng)終端：一種是高權(quán)限用戶將計(jì)劃分派給特定用戶，由上車作業(yè)的用戶被動(dòng)接收；另一種是已經(jīng)核實(shí)確認(rèn)的任務(wù)以廣播的形式擴(kuò)散至同一部門所有用戶，需要上車作業(yè)的用戶主動(dòng)領(lǐng)取。移動(dòng)終端APP 界面顯示需要檢修的車組號(hào)、端位、ATP 類型、檢修包等信息，用戶按照提示，對(duì)關(guān)鍵項(xiàng)點(diǎn)逐一進(jìn)行確認(rèn)。對(duì)特定的設(shè)備，例如軌道電路接收（TCR）天線、應(yīng)答器傳輸模塊（BTM）天線等進(jìn)行拍照（或者錄視頻），以記錄設(shè)備表面是否完好。作業(yè)過(guò)程中若發(fā)現(xiàn)設(shè)備異常，可以通過(guò)移動(dòng)終端掃描二維碼，快速獲取該設(shè)備的上道日期、版本信息、檢修歷史、配件更換歷史等。同時(shí)，移動(dòng)終端提供對(duì)講功能，實(shí)時(shí)與相關(guān)專業(yè)人員聯(lián)絡(luò)。

4）作業(yè)結(jié)果。用戶完成作業(yè)之后，移動(dòng)終端自動(dòng)生成作業(yè)結(jié)果，包括作業(yè)人員、時(shí)間、地點(diǎn)、項(xiàng)目、多媒體等信息，自動(dòng)上傳至路局集團(tuán)公司服務(wù)器，便于后期作業(yè)分析、作業(yè)查詢等。

5）失修漏檢預(yù)警。作業(yè)結(jié)果一經(jīng)上傳成功，系統(tǒng)便自動(dòng)更新失修漏檢庫(kù)，重新計(jì)算每臺(tái)ATP某個(gè)檢修包的預(yù)警時(shí)機(jī)。對(duì)于即將到期的設(shè)備檢修包，自動(dòng)納入下一次的檢修計(jì)劃，如果該動(dòng)車組入庫(kù)，則優(yōu)先安排ATP特定檢修包的作業(yè)。

2.2 系統(tǒng)架構(gòu)

ATP 車載設(shè)備智能檢修系統(tǒng)由支撐層、應(yīng)用層構(gòu)成，其系統(tǒng)架構(gòu)見圖2。

圖2 ATP車載設(shè)備智能檢修系統(tǒng)架構(gòu)

1）支撐層在服務(wù)器、存儲(chǔ)設(shè)備、網(wǎng)絡(luò)設(shè)備等硬件資源的基礎(chǔ)上，部署Windows Server 2019 操作系統(tǒng)、Oracle 19c 數(shù)據(jù)庫(kù)、.NET 7 開發(fā)平臺(tái)等應(yīng)用運(yùn)行環(huán)境，具有輕量、跨平臺(tái)、高性能、支持云原生等優(yōu)勢(shì)。

2）應(yīng)用層采用前后端分離的架構(gòu)模式，適用于以用戶需求和體驗(yàn)為導(dǎo)向的智能檢修作業(yè)場(chǎng)景，不僅大大提高開發(fā)效率，而且系統(tǒng)性能增強(qiáng)，用戶體驗(yàn)感提升。前端分為瀏覽器端和移動(dòng)終端，瀏覽器端以固定PC 的方式進(jìn)行人機(jī)交互，移動(dòng)終端用于車上設(shè)備檢修作業(yè)；后端采用“倉(cāng)儲(chǔ)層+服務(wù)層+控制層+基礎(chǔ)設(shè)施層”的Restful 風(fēng)格的WebAPI 框架［11］，其中基礎(chǔ)設(shè)施層封裝各種功能組件供其他3個(gè)層級(jí)使用。Restful風(fēng)格的最大特點(diǎn)是系統(tǒng)中所有的事務(wù)都被抽象為資源，所有的資源操作都是統(tǒng)一接口，這種格式設(shè)計(jì)的軟件更簡(jiǎn)潔、更有層次、更易于實(shí)現(xiàn)緩存。

2.3 軟件設(shè)計(jì)

系統(tǒng)軟件設(shè)計(jì)采用前后端分離架構(gòu)，見圖3。前端以React 18為基礎(chǔ)搭建框架，服務(wù)于瀏覽器端和移動(dòng)終端，包含用戶界面（User Interface，UI）、數(shù)據(jù)管理、應(yīng)用程序接口（Application Programming Interface，API）請(qǐng)求、工具、路由管理等模塊；后端是以.NET 7 為平臺(tái)的WebAPI 框架，包括用戶認(rèn)證、API接口、業(yè)務(wù)處理、數(shù)據(jù)持久化等模塊。

圖3 ATP車載設(shè)備智能檢修管理軟件架構(gòu)

1）UI模塊。根據(jù)功能需求進(jìn)行頁(yè)面布局、樣式、動(dòng)態(tài)效果的設(shè)計(jì)。頁(yè)面設(shè)計(jì)使用Ant Design 4.0 技術(shù)，風(fēng)格簡(jiǎn)潔大方。圖片等動(dòng)態(tài)效果展示基于Echart 5.0 技術(shù)，例如以餅狀圖的方式展示檢修任務(wù)完成進(jìn)度。每一個(gè)UI 對(duì)應(yīng)后端的一個(gè)API，用于人機(jī)交互和數(shù)據(jù)傳輸。

2）數(shù)據(jù)管理模塊。包括數(shù)據(jù)模型、數(shù)據(jù)緩存、數(shù)據(jù)校驗(yàn)等。前端應(yīng)用中最基本的數(shù)據(jù)模型是JavaScript 對(duì)象，根據(jù)業(yè)務(wù)需求對(duì)數(shù)據(jù)進(jìn)行適當(dāng)?shù)霓D(zhuǎn)換。對(duì)于查詢量大但是短時(shí)間內(nèi)不改變的數(shù)據(jù)，例如失修漏檢預(yù)警信息，通過(guò)本地存儲(chǔ)LocalStorage 或者會(huì)話存儲(chǔ)SessionStorage 技術(shù)實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)和校驗(yàn)。

3）API 請(qǐng)求模塊。用于與后端通信，基于Axios 技術(shù)實(shí)現(xiàn)前端請(qǐng)求，調(diào)用后端API 接口獲取數(shù)據(jù)。

4）工具模塊。提供常用的工具函數(shù)或工具類，例如日期格式化、字符串處理等，有其他類似需求的業(yè)務(wù)可直接復(fù)用該模塊。

5）路由管理模塊。基于React Router 路由庫(kù)技術(shù)，實(shí)現(xiàn)不同頁(yè)面之間的跳轉(zhuǎn)，以及與后端API接口的映射，主要適用于瀏覽器端。

6）用戶認(rèn)證模塊。負(fù)責(zé)用戶身份認(rèn)證、權(quán)限管理、登錄驗(yàn)證等。該模塊基于JWT（Json Web Token）協(xié)議，保證數(shù)據(jù)傳輸?shù)陌踩涂刂朴脩魴?quán)限。

7）API 接口模塊。提供Restful API 接口供前端調(diào)用，實(shí)現(xiàn)客戶端與服務(wù)器端的解耦，使得前后端可以各自獨(dú)立進(jìn)行迭代和升級(jí)。

8）業(yè)務(wù)處理模塊。負(fù)責(zé)處理后端接收到的業(yè)務(wù)數(shù)據(jù)，包括數(shù)據(jù)檢索、數(shù)據(jù)校驗(yàn)等。

9）數(shù)據(jù)持久化模塊。負(fù)責(zé)讀寫數(shù)據(jù)庫(kù)及文件系統(tǒng)操作，將檢修計(jì)劃和任務(wù)結(jié)果最終持久化到數(shù)據(jù)庫(kù)，將作業(yè)過(guò)程中的視頻和照片等多媒體文件持久化到文件系統(tǒng)中。

3 關(guān)鍵技術(shù)

3.1 ATP車載設(shè)備編碼唯一

ATP 車載設(shè)備的編碼需要保證全路唯一性，并且要簡(jiǎn)潔明確。為此，在國(guó)家標(biāo)準(zhǔn)和鐵路標(biāo)準(zhǔn)的基礎(chǔ)上，針對(duì)ATP 車載設(shè)備隨動(dòng)車組頻繁調(diào)配的特點(diǎn)，設(shè)計(jì)專用的ATP 車載設(shè)備編碼，由12 位數(shù)字組成，包括11位序列碼和1位校驗(yàn)碼［9］。

采用Oracle 數(shù)據(jù)庫(kù)存儲(chǔ)和管理唯一標(biāo)識(shí)編碼，數(shù)據(jù)庫(kù)自帶唯一的約束判斷功能，若編碼出現(xiàn)重復(fù)，則無(wú)法寫入數(shù)據(jù)庫(kù)。此外，數(shù)據(jù)庫(kù)的容災(zāi)備份機(jī)制保證了唯一標(biāo)識(shí)全生命周期的穩(wěn)定性。數(shù)據(jù)容災(zāi)是基于連續(xù)數(shù)據(jù)保護(hù)技術(shù)實(shí)時(shí)監(jiān)測(cè)數(shù)據(jù)的變化，自動(dòng)保存記錄每一次編碼數(shù)據(jù)讀寫的變化，如遇服務(wù)器故障、軟件錯(cuò)誤、病毒等突發(fā)情況，可快速恢復(fù)至任意時(shí)間點(diǎn)的數(shù)據(jù)。數(shù)據(jù)備份是按固定的時(shí)間間隔，可以每天將某一時(shí)刻全路所有的編碼數(shù)據(jù)備份到磁盤上，然后再傳遞至異地保存。

3.2 基于工作流組件的檢修作業(yè)過(guò)程閉環(huán)管理

ATP 設(shè)備入庫(kù)檢修作業(yè)從檢修計(jì)劃開始，到任務(wù)派發(fā)、作業(yè)設(shè)備人機(jī)校對(duì)、上車作業(yè)、生成作業(yè)結(jié)果、結(jié)果評(píng)價(jià)等多個(gè)環(huán)節(jié)，環(huán)環(huán)相扣，在時(shí)間維度上建立工作流模型。工作流組件是以ATP 檢修作業(yè)各模塊獨(dú)立升級(jí)及減少各模塊之間不必要的交互為基本原則，通過(guò)將檢修作業(yè)分解為定義良好的任務(wù)（如檢修計(jì)劃生成、檢修任務(wù)校核、檢修記錄上傳等）、角色（如計(jì)劃編輯、任務(wù)審核、結(jié)果查看等），按照現(xiàn)場(chǎng)慣用的作業(yè)規(guī)則和過(guò)程來(lái)執(zhí)行，并監(jiān)控每一個(gè)任務(wù)的執(zhí)行結(jié)果。

工作流組件的核心是工作流引擎。首先設(shè)計(jì)規(guī)則引擎將檢修流程中的業(yè)務(wù)邏輯分離，業(yè)務(wù)邏輯成為一個(gè)共用體在多個(gè)流程中調(diào)用，例如車組號(hào)的識(shí)別和解析，可復(fù)用于多個(gè)模塊，避免大量重復(fù)性的編碼工作。其次設(shè)計(jì)安全引擎對(duì)系統(tǒng)操作進(jìn)行監(jiān)控，并實(shí)時(shí)將用戶角色和操作權(quán)限相互匹配，發(fā)現(xiàn)異常及時(shí)預(yù)警。基本流程是工作流組件接收來(lái)自外部接口有關(guān)過(guò)程控制的請(qǐng)求（如過(guò)程初始化、獲取活動(dòng)及結(jié)束活動(dòng)等），根據(jù)不同的請(qǐng)求類型調(diào)用相應(yīng)的處理模塊，完成與本次請(qǐng)求相關(guān)的操作，并將結(jié)果返回。對(duì)外部請(qǐng)求的處理涉及工作流組件相關(guān)數(shù)據(jù)的讀寫和更改操作，同時(shí)通過(guò)工作流控制數(shù)據(jù)辨別每個(gè)過(guò)程或活動(dòng)實(shí)例的狀態(tài)，并推動(dòng)工作流過(guò)程的執(zhí)行。由此約束檢修作業(yè)過(guò)程的流程和邏輯，實(shí)現(xiàn)全程作業(yè)閉環(huán)控制和痕跡管理。

3.3 服務(wù)器端與移動(dòng)終端間數(shù)據(jù)安全傳輸

移動(dòng)終端用戶繁多，為了對(duì)用戶身份進(jìn)行驗(yàn)證，采用基于令牌（Token）的用戶認(rèn)證技術(shù)。基于JWT 統(tǒng)一標(biāo)準(zhǔn)，用戶使用賬號(hào)/密碼等憑據(jù)登錄到應(yīng)用程序，由服務(wù)器端驗(yàn)證憑據(jù)，生成令牌并使用密鑰對(duì)其進(jìn)行簽名；然后服務(wù)器端發(fā)送加密的Token，移動(dòng)終端收到Token存儲(chǔ)在本地、會(huì)話存儲(chǔ)或小型文本文件中。此后，該Token被添加到后續(xù)請(qǐng)求的授權(quán)頭中，與服務(wù)器端請(qǐng)求交互數(shù)據(jù)時(shí)，無(wú)需再次輸入賬號(hào)和密碼。

為防止用戶篡改數(shù)據(jù)，服務(wù)器在生成Token時(shí)添加一個(gè)簽名來(lái)保證移動(dòng)終端的安全接入。服務(wù)器端和移動(dòng)終端數(shù)據(jù)傳輸時(shí)，基于超文本傳輸安全協(xié)議，通過(guò)數(shù)字簽名和非對(duì)稱加密技術(shù)，保證數(shù)據(jù)傳輸?shù)陌踩院屯暾?。此外，根?jù)ATP 檢修作業(yè)的實(shí)際場(chǎng)景，設(shè)置令牌的有效期。一旦Token過(guò)期即反饋給前端，前端使用更新令牌（RefreshToken）申請(qǐng)一個(gè)全新Token 繼續(xù)使用。該方案中，服務(wù)器端只需要在移動(dòng)終端請(qǐng)求更新Token 時(shí)對(duì)RefreshToken的有效性進(jìn)行一次檢查，避免頻繁讀寫。令牌機(jī)制正是通過(guò)其隨機(jī)性、不可預(yù)測(cè)性、時(shí)效性、無(wú)狀態(tài)等特點(diǎn)，保證服務(wù)器端和移動(dòng)終端數(shù)據(jù)傳輸?shù)陌踩浴?/p>

3.4 檢修多媒體數(shù)據(jù)壓縮和傳輸

移動(dòng)終端內(nèi)部集成了H.264 硬件編解碼模塊，采集到的視頻信號(hào)可以實(shí)時(shí)進(jìn)行編碼壓縮。H.264的核心是采用更高效的視頻壓縮算法，在獲得有效壓縮效果的同時(shí)，由壓縮引起的失真最小。H.264在視頻編碼層和網(wǎng)絡(luò)抽象層的框架上，定義了3 類幀：I 幀、B 幀和P 幀。I 幀指的是完整的圖像幀，B 幀和P 幀是指不對(duì)全部圖像進(jìn)行編碼的幀。不同之處是B 幀是參考前后的圖像幀生成，P 幀是參考I 幀生成。H.264 的壓縮算法分為幀內(nèi)壓縮和幀間壓縮，前者用于生成I 幀，后者用于生成B 幀和P幀。幀內(nèi)壓縮指當(dāng)壓縮一幀圖像時(shí)，僅考慮本幀的數(shù)據(jù)而忽略相鄰幀之間的冗余信息；幀間壓縮指根據(jù)相鄰幀數(shù)據(jù)的相關(guān)性，壓縮相鄰幀之間的冗余量，僅僅記錄本幀與相鄰幀的差值，從而大大減少數(shù)據(jù)量。

此外，移動(dòng)終端與中心服務(wù)器之間采用斷點(diǎn)續(xù)傳技術(shù)保證文件傳輸?shù)姆€(wěn)定性。移動(dòng)終端獲取到相應(yīng)的文件，按照指定的分割方式將大文件分段，然后通過(guò)HTML 協(xié)議分段傳給后端服務(wù)程序，由后端服務(wù)程序再按順序?qū)⑽募M(jìn)行拼接。這樣即使傳輸文件中斷，也可以迅速定位，并重新進(jìn)行傳輸。

4 系統(tǒng)實(shí)施和運(yùn)用效果

系統(tǒng)現(xiàn)場(chǎng)部署方案示意見圖4，主要由服務(wù)器組、網(wǎng)絡(luò)設(shè)備、移動(dòng)終端等組成。通過(guò)搭建服務(wù)器組實(shí)現(xiàn)數(shù)據(jù)的收發(fā)、存儲(chǔ)和運(yùn)算，設(shè)置防火墻實(shí)現(xiàn)網(wǎng)絡(luò)安全防護(hù)，移動(dòng)終端用于車上檢修作業(yè)。所有設(shè)備通過(guò)鐵路內(nèi)網(wǎng)互聯(lián)，鐵路局、電務(wù)段、車間工區(qū)等用戶通過(guò)鐵路內(nèi)網(wǎng)訪問(wèn)系統(tǒng)。

圖4 ATP車載設(shè)備檢修管理系統(tǒng)現(xiàn)場(chǎng)部署方案

作業(yè)前，將待檢修ATP設(shè)備的履歷信息、配件更換歷史等數(shù)據(jù)提前下載至移動(dòng)終端。作業(yè)過(guò)程中產(chǎn)生的數(shù)據(jù)，包括ATP各子設(shè)備狀態(tài)信息、設(shè)備外觀圖片、檢修異常記錄等，均暫時(shí)存儲(chǔ)在移動(dòng)終端。作業(yè)完畢，移動(dòng)終端進(jìn)入工區(qū)有網(wǎng)絡(luò)的環(huán)境時(shí)，所有數(shù)據(jù)自動(dòng)上傳至中心服務(wù)器。通常作業(yè)地點(diǎn)在動(dòng)車所檢修庫(kù)中，根據(jù)各動(dòng)車所的網(wǎng)絡(luò)環(huán)境（若網(wǎng)絡(luò)資源充裕，服務(wù)器端與移動(dòng)終端可實(shí)時(shí)交互數(shù)據(jù)），數(shù)據(jù)由移動(dòng)終端暫存是現(xiàn)場(chǎng)運(yùn)用的主要模式。

目前該系統(tǒng)已陸續(xù)在鄭州鐵路局、上海鐵路局集團(tuán)公司等部署實(shí)施，服務(wù)于路局所有ATP 設(shè)備的日常檢修和管理。據(jù)統(tǒng)計(jì)，使用該系統(tǒng)之前，ATP 車載設(shè)備一級(jí)檢修作業(yè)平均用時(shí)48.2 min，主要消耗在檢修計(jì)劃編制、作業(yè)記錄填報(bào)等方面；而使用該系統(tǒng)之后，平均用時(shí)降至25.6 min，下降46.9%。在作業(yè)過(guò)程管控方面，檢修項(xiàng)目失修漏檢率由0.3%下降至0.1%，檢修管理效果顯著，所有信息均有跡可循，促進(jìn)了鐵路信號(hào)設(shè)備運(yùn)維精細(xì)化和智能化的進(jìn)程。

5 結(jié)論

通過(guò)分析ATP 車載設(shè)備既有檢修模式的改進(jìn)需求，設(shè)計(jì)了一種智能檢修管理系統(tǒng)，從檢修計(jì)劃開始到失修漏檢預(yù)警，全程實(shí)現(xiàn)了自動(dòng)化及檢修過(guò)程的閉環(huán)管理。經(jīng)在鄭州局、上海局集團(tuán)公司等部署運(yùn)用，檢修效率明顯提升，具有極大推廣價(jià)值，為設(shè)備精準(zhǔn)檢修和智能檢修奠定基礎(chǔ)。