趙 強
(中車長春軌道客車股份有限公司,吉林 長春 130062)
列車網絡控制系統(TCMS)是動車組、城市軌道車輛的重要系統之一,對全車的關鍵設備進行控制、監視、故障診斷,其可靠性是保證車輛安全運行的決定性因素。作為涵蓋固有化硬件(如中央控制單元、網關、顯示器、中繼器及輸入輸出模塊等)及關鍵性軟件(如系統軟件、應用軟件、調試測試軟件及PC機工具軟件等)的復雜網絡信息傳輸系統,其系統故障可能是由于任何軟件、硬件或傳輸介質故障所造成的,因此其可靠性分析應綜合考慮所有軟件和硬件故障模式的影響,通過一個統一的數學模型進行綜合計算。
蒙特卡羅算法以概率論及數理統計為理論基礎,利用重復的抽樣、統計試驗直接或間接針對數學模型進行大量統計模擬試驗,用以有效解決很多用傳統數理統計或物理試驗難以處理的問題[1]。本文以北京地鐵6號線列車網絡控制系統為例,在說明其系統組成、規定條件及任務的基礎上,建立了系統可靠性綜合模型,說明了應用VB語言開發TCMS可靠性數字仿真程序的使用方法,采用蒙特卡羅仿真法計算了TCMS的可靠性指標,對于進行復雜網絡系統(涵蓋硬件、軟件及網絡通信)的可靠性預計分析具有借鑒意義。
北京地鐵6號線TCMS的設計符合IEC 61375-1:1999《鐵路電氣設備列車總線國際標準》的要求,TCMS主要通過中央控制單元(CCU)與各子系統的控制單元間的信息傳輸實現對車輛子系統設備的控制、監視及故障診斷功能。圖1為北京地鐵6號線列車網絡拓撲圖,該圖說明了TCMS系統與各子系統控制單元之間的信息傳輸關系。

ERM.列車數據記錄儀;RIOM.遠程輸入/輸出模塊;HMI.人機接口單元;BCU.制動控制單元;PA.列車廣播系統;FAS.煙火報警系統; ATC.列車自動控制系統;HUB.集線器;RPT.中繼器;HVAC.空調系統;TCU.牽引控制單元;DCU.門控單元; ACU.輔助控制單元;MC.主控器;EMD.電氣中距離。
從可靠性冗余設計角度考慮,在列車網絡控制系統中,CCU是主要的控制部件,其主要功能是完成底層MVB通信數據的收發和控制邏輯的運算[2]。因此,TCMS設有2個CCU,這2個CCU在運行中互為熱備份,如果主CCU故障,另一個CCU會接替主CCU進行工作。RPT和RIOM都采用冗余的技術方案,任何一個單點故障都不會影響列車的正常運行。HMI用于在施加列車運行控制指令的同時進行各子系統故障狀態信息的顯示,顯示屏通過MVB總線、以太網總線與CCU接口,對于實時性要求高的控制指令、狀態數據通過MVB總線進行傳輸,其他數據通過以太網總線進行傳輸,可有效減輕網絡負載率。為防止車輛在運行過程中因車間線纜斷裂引起列車網絡故障,在車間增加了車間分線器,提高了車輛運行的安全可靠性。
TCMS可靠性任務要求由地鐵運營商與TCMS供應商在設計階段進行確認,并在車輛交付后進行驗證。對TCMS故障按照其對列車營運的影響進行分類及定義,即在列車正常運行期間,對由于TCMS故障直接或間接導致的列車故障(包括運營服務故障、晚點故障及維護故障)進行分類及定義。北京地鐵6號線TCMS可靠性的任務要求是服務故障平均無故障時間為48 400 h,晚點故障和維護故障時間分別為22 400 h和1 000 h。
TCMS的可靠性綜合模型是綜合考慮系統的軟硬件故障給出的系統可靠性模型,體現為系統構件層和拓撲層可靠性模型的融合。建模過程中考慮到融合的復雜程度,采用將軟件拓撲可靠性模型融入到硬件拓撲可靠性模型中的方式,即在硬件的故障樹模型中加入軟件的故障。硬件拓撲可靠性模型根據底層設備的失效分布抽取故障時間;而在軟件拓撲模型中,構件的故障判據根據概率抽樣得出首次故障時軟件模塊執行周期數的正態分布參數,然后根據軟件模塊的執行周期轉化為軟件模塊首次故障的時間,最后綜合軟件與硬件的故障時間進行故障樹的蒙特卡羅仿真,給出TCMS整體的可靠性指標值。
復雜系統可靠性分析應符合其自身的特點,越復雜的系統和結構越會導致多種失效模式共存,多種失效模式之間相互作用、彼此影響,往往存在競爭失效問題[3]。TCMS軟件和硬件的故障模式多樣,單純建立系統常規的可靠性框圖,僅應用串聯、并聯等邏輯關系難以全部包容軟件和硬件故障模式的影響,因此考慮從功能結構角度進行故障模式影響分析(FMEA)。FMEA分析過程中,由于受系統軟件應用開放性限制,除CCU以外的軟件系統(如HMI,RIOM)在建模過程中均作為黑盒處理,而對于TCMS重要設備RIOM的軟件故障在明確其軟件構成的前提下,可以采用與CCU同樣的方式進行軟件故障建模分析,最終通過FMEA找出所有軟件和硬件故障模式對TCMS功能的直接影響。利用故障樹的邏輯關系(包括時序關系的影響)建立TCMS可靠性綜合模型,如圖2所示。

A.MVB2 A/B路故障;B.MVB1 A/B路故障;C.RPT1 A/B路故障;D.任意A/B路故障;E1.MVB4 A路故障;E2.MVB4 B路故障;F1.MVB5 A路故障;F2.MVB5 B路故障;G1.RPT2 A路故障;G2.RPT2 B路故障;H1.RPT3 A路故障;H2.RPT3 B路故障;I.MVB3 A/B路故障;J.RPT4 A/B路故障;K1.HMI1故障;K2.HMI2故障;L1.CCU1軟件故障;L2.CCU1硬件故障;M1.CCU2軟件故障;M2.CCU2硬件故障;N1.RIOM1硬件故障;N2.RIOM1軟件故障;>N3.RIOM2硬件故障;N4.RIOM2軟件故障;N15.RIOM8硬件故障;N16.RIOM8軟件故障。
常規的故障樹定量計算中,無法對邏輯時序關系、非指數分布情況及維修情況等進行解析計算[4],因此本項目采用蒙特卡羅方法對上述故障樹邏輯模型進行仿真分析和計算。根據蒙特卡羅仿真思想,TCMS可靠性仿真的邏輯設計圖如圖3所示。TCMS系統可靠性數字仿真采用離散事件驅動的模擬方法,仿真核心是對一個事件隊列的處理,該隊列按照事件發生的時間先后進行排序,每一個事件將會產生一個中斷等待處理,隨著仿真時鐘推進,設備故障及設備維修等不同事件會進入隊列中驅動仿真推進。

圖3 TCMS可靠性仿真邏輯設計圖
為實現對上述模型的計算,項目采用VB語言開發了一個可靠性數字仿真程序,其界面設計如圖4所示,該程序對應蒙特卡羅可靠性仿真的邏輯,在故障樹的基礎上同時考慮了部件的維修問題。通過仿真軟件在TCMS可靠性模型上建立節點設備及節點間的連線物理連接關系,完成TCMS的拓撲結構,對TCMS組成單元的屬性進行設置,包括設備信息、可靠性參數和維修性參數,也包括TCMS相應單元中的軟件模塊的可靠性參數。

圖4 TCMS可靠性數字仿真程序
在仿真過程中各種事件可以實時顯示,故障設備的狀態同時會在TCMS拓撲圖中顯示出來,對于喪失功能的設備用紅色標示,對于只有1個通道故障時用黃色標示,主CCU故障以粉色標示;仿真結果顯示框顯示的數據是本次仿真的結果,多次仿真結束后,仿真結果顯示框中顯示的信息是多次仿真的平均值。
TCMS可靠性數字仿真程序采用離散事件驅動的模擬機理(“事件”是指TCMS狀態的變化),仿真過程中仿真核心維護著1個故障事件隊列,該隊列按照事件發生的時間先后進行排序,隊列的第1個事件將產生1個中斷,處理完該故障事件后該事件被刪除,隨著仿真時鐘的推進,不斷有設備故障,故障設備維修后又會有新的故障事件插入到故障事件隊列中形成仿真推進的動力,當滿足退出條件時則仿真終止[5]。
數字仿真程序應用的輸出結果包括列車的平均運行時間、運行期間發生的平均故障次數、發生的平均掉線故障次數、平均檢修故障間隔時間、平均掉線故障間隔時間和TCMS系統使用可用度,之后的應用中可以根據需求統計其他需要的可靠性、維修性和可信性等參數。
列車的平均運行時間TOP是多次TCMS仿真中列車運行時間的平均值,列車運行期間發生的平均故障次數FN是多次TCMS仿真中列車發生的所有故障次數之和的平均值,發生的平均掉線故障次數CFN是多次TCMS仿真中列車發生的所有掉線故障次數之和的平均值。
單次TCMS仿真和多次TCMS仿真后的平均檢修故障間隔時間分別為MTBFi和MTBF,計算公式為:
(1)
(2)
式中:TOPi——每次TCMS仿真時的列車運行時間;
N——仿真次數。
單次TCMS仿真和多次TCMS仿真后的平均掉線故障間隔時間分別為MTBCFi和MTBCF,計算公式為:
(3)
(4)
系統的使用可用度Ao是指系統當需要時能夠正常工作的程度,其計算公式為:
(5)
式中:TT——TCMS的任務時間;
DT——TCMS不能工作的時間。
仿真數據輸入包括對列車運行任務剖面數據的設置以及TCMS組成單元參數的設置。
3.4.1 仿真任務設置
假設列車的任務時間為6年,每月有1天的時間需對列車進行檢查,檢查當天列車不運行,每年按365天計算,則6年內列車總的任務時間為(365-12)×6=2 118(天),其余任務參數設置如下:每日出車時間為5:00 a.m.,每日返回時間為11:00 p.m.,單程運行時間為90 min,仿真運行次數為20次。
3.4.2 設備參數設置
依據可靠性理論和大量工程實踐,復雜系統故障規律一般服從指數分布[6]。列車各系統及其子系統均屬于復雜系統,且在正常運行期間的故障率是基本恒定的,其基本部件的故障規律基本服從指數分布。考慮到項目設計階段無法確定TCMS組成單元的可靠性和維修性參數,硬件的可靠性參數按照可靠性分配的結果取值,軟件的可靠性和設備的維修性參數則初步給一個參考值,軟件可靠度和維修時間分布參數分別設為0.99和1 h計算分析中采用的設定仿真輸入數據如表1所示。

表1 仿真輸入數據設置
在數字仿真程序開發完成的基礎上,對TCMS的硬件組成可靠性以及TCMS軟硬件綜合的可靠性水平進行仿真分析,仿真運行在假設條件下進行,獲得更詳細車輛實際運營數據后進行仿真時仿真結果會更加準確。
3.5.1 TCMS硬件可靠性仿真結果
將含有軟件單元的軟件可靠度數值設為1,即認為軟件不發生故障,其他參數按表1中所列數值進行設置。TCMS硬件組成可靠性仿真結果如表2所示。

表2 TCMS硬件組成可靠性仿真結果
3.5.2 TCMS軟硬件綜合可靠性仿真結果
在TCMS可靠性數字仿真程序中輸入表1中參數,在綜合考慮軟硬件故障的情況下,TCMS軟硬件綜合可靠性仿真結果如表3所示。

表3 TCMS軟硬件綜合可靠性仿真結果
3.5.3 仿真結果對比分析
將TCMS硬件組成可靠性仿真結果及軟硬件綜合可靠性仿真結果進行對比分析,可以得到以下結論:
(1) 不考慮軟件故障的情況下,列車運行2 118天平均發生的故障次數為36.2次(不考慮硬線)和37.2次(考慮硬線)。TCMS硬件的平均故障間隔時間為1 052.39 h(不考慮硬線)和1 024.20 h(考慮硬線),與可靠性分配的指標(1 000 h)基本相符。
對于TCMS的硬件組成,考慮硬線備份后,列車運行2 118天平均發生的掉線次數由22.6次降為17.07次,列車的平均掉線故障間隔時間由1 685.69 h提高到2 232.43 h,提高了32.43%。
(2) 綜合考慮軟件和硬件故障,列車運行2 118天平均發生的故障次數為1 440次左右,通過與硬件組成的仿真結果進行對比可知,其中軟件故障有1 400次左右。TCMS的平均故障間隔時間為26.4 h 左右,由于軟件故障后可恢復的特性,由TCMS故障導致的列車掉線次數較少,但是比硬件組成多9次左右。
(3) 綜合考慮軟件和硬件故障,在加入硬線備份后,TCMS的平均掉線故障間隔時間由1 220.58 h 提高到1 426.52 h,提高了近16.87%。由于硬線只是對MVB網絡(MVB總線、中繼器、分線器)連通性的備份,對軟件故障沒有備份功能,硬線備份后TCMS的平均掉線故障間隔時間的提高主要是硬線設計對網絡連通可靠性的提升。
國產化列車網絡控制系統開發及應用對硬件、軟件及系統集成可靠性指標要求不斷提高,產品開發過程中如何針對具有硬件、軟件、網絡通信的復雜系統進行可靠性指標預計并進行工程化應用一直是車輛系統集成需要面對和解決的問題。本文以列車網絡控制系統這一復雜網絡系統為分析對象,建立了基于蒙特卡羅算法的可靠性仿真預計分析模型,應用開發的數字仿真程序進行了仿真預計分析,根據仿真分析結果協調設計參數進行方案比較,以發現系統設計的薄弱環節,對復雜網絡系統的可靠性及維修性設計工程化具有一定的借鑒意義。