關(guān)鍵詞：軌道車輛；修程優(yōu)化；RCM系統(tǒng)；可靠性分析

中圖分類號：TH17; U279.3+23 文獻標識碼：A

文章編號：1009-3044（2024）25-0097-04

0 引言

RCM分析方法以可靠性為中心開展維修分析，在軌道車輛研制過程中，通常采用RCM確定車輛預防性維修需求、優(yōu)化維修策略[1]。通過對系統(tǒng)進行功能與故障分析，明確系統(tǒng)故障發(fā)生的后果，用規(guī)范的邏輯決斷方法，確定各類故障后果的預防性對策[2]，通過現(xiàn)場故障統(tǒng)計、專家評估和定量化建模等手段，在保證安全性和可用性的前提下，以維修停機損失量最小為目標，優(yōu)化系統(tǒng)的維修策略[3]。

深化軌道車輛檢修技術(shù)體系建設(shè)，推進RCM分析在軌道車輛檢修規(guī)程開發(fā)及優(yōu)化上的推廣應(yīng)用，搭建適用的RCM分析與管理平臺，真正實現(xiàn)RCM分析在軌道車輛檢修規(guī)程開發(fā)及優(yōu)化上的應(yīng)用落地，本文研究了一種軌道車輛全壽命周期RCM分析系統(tǒng)，加強全壽命可靠性經(jīng)濟性分析能力。

1 關(guān)鍵技術(shù)研究

為實現(xiàn)軌道車輛檢修規(guī)程優(yōu)化的目標，首先考慮車輛運行環(huán)境、車輛規(guī)模、服役年限等因素，選取一定規(guī)模的車輛作為樣本，收集車輛運維數(shù)據(jù)，包括潛在故障與真實故障，其中潛在故障按照“檢修目的相關(guān)性”與“故障影響重要性”進行數(shù)據(jù)分類，制定檢修規(guī)程的優(yōu)化策略[4]；其次，基于制定的優(yōu)化策略，分別對潛在故障進行數(shù)據(jù)分析，依據(jù)趨勢分析與統(tǒng)計分析結(jié)果，增加或刪除檢修任務(wù)，通過假設(shè)檢驗與詳細分析延長或縮短檢修間隔，并考慮故障的風險，基于可靠性統(tǒng)計分析，采集車輛的服務(wù)可靠性數(shù)據(jù)，監(jiān)控檢修規(guī)程實施前后車輛服役可靠性變化，完善檢修規(guī)程[5]。

針對RCM系統(tǒng)分析，主要內(nèi)容包括對系統(tǒng)部件進行MSI確認和RCM分析流程，包括基本信息維護、可靠性數(shù)據(jù)維護、系統(tǒng)分析、檢查任務(wù)以及RCM轉(zhuǎn)移等功能。RCM分析與管理平臺在設(shè)計之初，就確定了MSI判別的功能。將安全、秩序、法規(guī)、使用及故障是否隱蔽作為MSI選擇的依據(jù)或原則，考慮到車輛實際情況，經(jīng)濟性不作為MSI選擇的考慮因素。這樣就可以針對影響安全、秩序的關(guān)鍵系統(tǒng)及設(shè)備篩選出來，更加有針對性。

MSI判別問題具體內(nèi)容如下：

（1） 故障對正常履職的操作人員（司機、乘務(wù)員、機械師）來說是否無法發(fā)現(xiàn)或不易察覺的。

（2） 故障是否會影響安全、秩序、法規(guī)。

（3） 故障是否會影響使用。

根據(jù)以上問題，實現(xiàn)MSI篩選的功能。針對MSI 選擇問題，有一個回答為“是”則為MSI，所有問題回答均為“否”，則非MSI。因通常將產(chǎn)品分解的最高可管理層作為MSI。最終輸出對應(yīng)的MSI 清單，以作為FMEA和后續(xù)系統(tǒng)RCM分析的對象清單，也就是最高可管理層清單。

在確定系統(tǒng)RCM分析對象之后，即可通過RCM 分析與管理平臺開展FMEA、故障影響及故障原因分析工作。故障影響及故障原因分析遵循MSG-3標準的RCM邏輯決斷圖，RCM邏輯決斷如圖1所示。

2 平臺架構(gòu)設(shè)計

2.1 RCM 分析系統(tǒng)架構(gòu)

本文RCM系統(tǒng)架構(gòu)基于SAAS—PAAS—IAAS的設(shè)計方式，采用企業(yè)級SOA的架構(gòu)框架，利用分層模型，在持久層、數(shù)據(jù)層、邏輯層、應(yīng)用層、表現(xiàn)層上實現(xiàn)技術(shù)落地。采用Spring Cloud、Spring Boot、Zoo?keeper、Dubbo、VUE、Python等主流應(yīng)用技術(shù)，預留和外圍系統(tǒng)的對接的擴展性。同時，自身的分層架構(gòu)也為自身的系統(tǒng)提供了擴展性以及治理的便捷性，更好地支持分布式應(yīng)用服務(wù)，最終形成了圖2 所示的技術(shù)架構(gòu)。

系統(tǒng)架構(gòu)進行設(shè)計時遵循以下原則：

（1） 全面解耦原則；（2） 服務(wù)化/組件化原則；（3） 接口隔離及服務(wù)自治原則；（4） 彈性伸縮原則；（5） 安全可靠原則；（6） 用戶體驗和自動化運維原則。

基于以上原則確定了如圖3所示的架構(gòu)設(shè)計圖。

在對拓撲架構(gòu)進行設(shè)計時，本著簡潔、高效的原則，從用戶使用開始到系統(tǒng)反饋送達，盡可能縮短信息、數(shù)據(jù)的鏈路，提高用戶體驗。在前后端交互的節(jié)點上，采用Nginx的應(yīng)用服務(wù)，提供負載均衡、水平擴展和安全過濾等系統(tǒng)擴展性、魯棒性的支持。后端的應(yīng)用集群的統(tǒng)一入口由Java應(yīng)用來提供支持，采用微服務(wù)的部署方式，提高程序的使用效率。在核心計算服務(wù)上使用Python作為服務(wù)節(jié)點，提高計算效率，服務(wù)之間采用單向異步的交互形式，避免計算阻塞引起的系統(tǒng)性風險。同時各級服務(wù)的交互中，采用Java的權(quán)限微服務(wù)進行安全性保障。業(yè)務(wù)數(shù)據(jù)庫的對接也由Java來完成對接，提高數(shù)據(jù)安全性，靈活應(yīng)用多種數(shù)據(jù)存儲引擎，為不同場景提供更好的支持和服務(wù)。

3 系統(tǒng)部署與模塊功能

3.1 系統(tǒng)部署方案

部署過程涉及“軟件包”“IT環(huán)境”以及“部署流程”這三個主要要件。對于這三個主要要件定義相關(guān)的部署規(guī)范，以便讓一個部署過程標準化、自動化并且可復制可預期。因此，基于DevOps的理念，部署規(guī)范的主要內(nèi)容如下：

軟件包規(guī)范：形成軟件包（也稱部署包）作為部署系統(tǒng)的輸入，對其規(guī)范是整個部署過程規(guī)范化的前提。一般來說，軟件包的內(nèi)容需要包含包內(nèi)內(nèi)容項以及其目錄組織方式，該標準需要保障輸入的軟件包內(nèi)容完整，意義明確，相對獨立。

IT環(huán)境規(guī)范：IT環(huán)境是最終提供服務(wù)的載體，同時作為軟件包部署的基礎(chǔ)。在一個軟件研發(fā)流程中常常會涉及不同類型的環(huán)境（如開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境等）。IT環(huán)境規(guī)范需要定義軟件研發(fā)流程中的環(huán)境類型，每個環(huán)境包括的實體等。另外，定義好不同環(huán)境之間的升級和回滾標準也是非常重要的一步。

部署流程規(guī)范：定義一個軟件包在一個軟件環(huán)境里面安裝部署的流程規(guī)范。由于一次部署可能會在一個環(huán)境的多個節(jié)點上部署，所以部署流程規(guī)范需要保證一個軟件包在一個環(huán)境節(jié)點上的完整部署流程，如圖4所示。

3.2 系統(tǒng)功能模塊

系統(tǒng)RCM分析模塊基于RCM分析流程開發(fā)，包含維修重要項目（MSI） 選擇、MSI分析、數(shù)據(jù)處理、數(shù)據(jù)分析、間隔決策功能。模塊界面如圖5所示。

系統(tǒng)可實現(xiàn)部件（LRU） 及其可靠性數(shù)據(jù)的創(chuàng)建、錄入和管理功能，“部件編號”“部件名稱”“供應(yīng)商”等信息可通過人工選擇或自動填充，已實現(xiàn)“相似車型”“MTBUR（非計劃拆卸的平均時間）/MTBF/MDBF/MDBUR”（包括預計值與統(tǒng)計值）“帶故障運行”等屬性信息的錄入與修改。

MSI 功能故障分析時，可將典型車型RCM 分析試運行文件作為樣例或數(shù)據(jù)直接導入或錄入，供RCM 分析人員參考或調(diào)用。功能故障分析如圖7所示。

系統(tǒng)具備MSI故障影響分析邏輯及功能，故障影響分析如圖8所示。

4 結(jié)束語

通過本文研究，分析了軌道交通RCM 分析中MSI 選擇與RCM 邏輯決策流程，建立了適用于國內(nèi)軌道車輛檢修規(guī)程分析的RCM 分析系統(tǒng)技術(shù)架構(gòu)，基于可靠性數(shù)據(jù)分析、系統(tǒng)功能故障分析、故障影響分析等模塊開發(fā)，搭建了可動態(tài)擴展、可實現(xiàn)快速響應(yīng)需求的軌道車輛RCM 分析平臺，可以有效支撐軌道車輛檢修規(guī)程制定及修程優(yōu)化。