基于蒙特卡羅算法的列車網(wǎng)絡(luò)控制系統(tǒng)可靠性仿真分析

趙 強

(中車長春軌道客車股份有限公司，吉林 長春 130062)

列車網(wǎng)絡(luò)控制系統(tǒng)(TCMS)是動車組、城市軌道車輛的重要系統(tǒng)之一，對全車的關(guān)鍵設(shè)備進行控制、監(jiān)視、故障診斷，其可靠性是保證車輛安全運行的決定性因素。作為涵蓋固有化硬件(如中央控制單元、網(wǎng)關(guān)、顯示器、中繼器及輸入輸出模塊等)及關(guān)鍵性軟件(如系統(tǒng)軟件、應(yīng)用軟件、調(diào)試測試軟件及PC機工具軟件等)的復(fù)雜網(wǎng)絡(luò)信息傳輸系統(tǒng)，其系統(tǒng)故障可能是由于任何軟件、硬件或傳輸介質(zhì)故障所造成的，因此其可靠性分析應(yīng)綜合考慮所有軟件和硬件故障模式的影響，通過一個統(tǒng)一的數(shù)學模型進行綜合計算。

蒙特卡羅算法以概率論及數(shù)理統(tǒng)計為理論基礎(chǔ)，利用重復(fù)的抽樣、統(tǒng)計試驗直接或間接針對數(shù)學模型進行大量統(tǒng)計模擬試驗，用以有效解決很多用傳統(tǒng)數(shù)理統(tǒng)計或物理試驗難以處理的問題[1]。本文以北京地鐵6號線列車網(wǎng)絡(luò)控制系統(tǒng)為例，在說明其系統(tǒng)組成、規(guī)定條件及任務(wù)的基礎(chǔ)上，建立了系統(tǒng)可靠性綜合模型，說明了應(yīng)用VB語言開發(fā)TCMS可靠性數(shù)字仿真程序的使用方法，采用蒙特卡羅仿真法計算了TCMS的可靠性指標，對于進行復(fù)雜網(wǎng)絡(luò)系統(tǒng)(涵蓋硬件、軟件及網(wǎng)絡(luò)通信)的可靠性預(yù)計分析具有借鑒意義。

1 TCMS規(guī)定條件和任務(wù)要求

北京地鐵6號線TCMS的設(shè)計符合IEC 61375-1：1999《鐵路電氣設(shè)備列車總線國際標準》的要求，TCMS主要通過中央控制單元(CCU)與各子系統(tǒng)的控制單元間的信息傳輸實現(xiàn)對車輛子系統(tǒng)設(shè)備的控制、監(jiān)視及故障診斷功能。圖1為北京地鐵6號線列車網(wǎng)絡(luò)拓撲圖，該圖說明了TCMS系統(tǒng)與各子系統(tǒng)控制單元之間的信息傳輸關(guān)系。

ERM.列車數(shù)據(jù)記錄儀；RIOM.遠程輸入/輸出模塊；HMI.人機接口單元；BCU.制動控制單元；PA.列車廣播系統(tǒng)；FAS.煙火報警系統(tǒng)； ATC.列車自動控制系統(tǒng)；HUB.集線器；RPT.中繼器；HVAC.空調(diào)系統(tǒng)；TCU.牽引控制單元；DCU.門控單元； ACU.輔助控制單元；MC.主控器；EMD.電氣中距離。

從可靠性冗余設(shè)計角度考慮，在列車網(wǎng)絡(luò)控制系統(tǒng)中，CCU是主要的控制部件，其主要功能是完成底層MVB通信數(shù)據(jù)的收發(fā)和控制邏輯的運算[2]。因此，TCMS設(shè)有2個CCU，這2個CCU在運行中互為熱備份，如果主CCU故障，另一個CCU會接替主CCU進行工作。RPT和RIOM都采用冗余的技術(shù)方案，任何一個單點故障都不會影響列車的正常運行。HMI用于在施加列車運行控制指令的同時進行各子系統(tǒng)故障狀態(tài)信息的顯示，顯示屏通過MVB總線、以太網(wǎng)總線與CCU接口，對于實時性要求高的控制指令、狀態(tài)數(shù)據(jù)通過MVB總線進行傳輸，其他數(shù)據(jù)通過以太網(wǎng)總線進行傳輸，可有效減輕網(wǎng)絡(luò)負載率。為防止車輛在運行過程中因車間線纜斷裂引起列車網(wǎng)絡(luò)故障，在車間增加了車間分線器，提高了車輛運行的安全可靠性。

TCMS可靠性任務(wù)要求由地鐵運營商與TCMS供應(yīng)商在設(shè)計階段進行確認，并在車輛交付后進行驗證。對TCMS故障按照其對列車營運的影響進行分類及定義，即在列車正常運行期間，對由于TCMS故障直接或間接導致的列車故障(包括運營服務(wù)故障、晚點故障及維護故障)進行分類及定義。北京地鐵6號線TCMS可靠性的任務(wù)要求是服務(wù)故障平均無故障時間為48 400 h，晚點故障和維護故障時間分別為22 400 h和1 000 h。

2 TCMS的可靠性綜合模型

TCMS的可靠性綜合模型是綜合考慮系統(tǒng)的軟硬件故障給出的系統(tǒng)可靠性模型，體現(xiàn)為系統(tǒng)構(gòu)件層和拓撲層可靠性模型的融合。建模過程中考慮到融合的復(fù)雜程度，采用將軟件拓撲可靠性模型融入到硬件拓撲可靠性模型中的方式，即在硬件的故障樹模型中加入軟件的故障。硬件拓撲可靠性模型根據(jù)底層設(shè)備的失效分布抽取故障時間；而在軟件拓撲模型中，構(gòu)件的故障判據(jù)根據(jù)概率抽樣得出首次故障時軟件模塊執(zhí)行周期數(shù)的正態(tài)分布參數(shù)，然后根據(jù)軟件模塊的執(zhí)行周期轉(zhuǎn)化為軟件模塊首次故障的時間，最后綜合軟件與硬件的故障時間進行故障樹的蒙特卡羅仿真，給出TCMS整體的可靠性指標值。

復(fù)雜系統(tǒng)可靠性分析應(yīng)符合其自身的特點，越復(fù)雜的系統(tǒng)和結(jié)構(gòu)越會導致多種失效模式共存，多種失效模式之間相互作用、彼此影響，往往存在競爭失效問題[3]。TCMS軟件和硬件的故障模式多樣，單純建立系統(tǒng)常規(guī)的可靠性框圖，僅應(yīng)用串聯(lián)、并聯(lián)等邏輯關(guān)系難以全部包容軟件和硬件故障模式的影響，因此考慮從功能結(jié)構(gòu)角度進行故障模式影響分析(FMEA)。FMEA分析過程中，由于受系統(tǒng)軟件應(yīng)用開放性限制，除CCU以外的軟件系統(tǒng)(如HMI,RIOM)在建模過程中均作為黑盒處理，而對于TCMS重要設(shè)備RIOM的軟件故障在明確其軟件構(gòu)成的前提下，可以采用與CCU同樣的方式進行軟件故障建模分析，最終通過FMEA找出所有軟件和硬件故障模式對TCMS功能的直接影響。利用故障樹的邏輯關(guān)系(包括時序關(guān)系的影響)建立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軟件故障。

3 TCMS可靠性蒙特卡羅仿真

3.1 仿真邏輯設(shè)計

常規(guī)的故障樹定量計算中，無法對邏輯時序關(guān)系、非指數(shù)分布情況及維修情況等進行解析計算[4]，因此本項目采用蒙特卡羅方法對上述故障樹邏輯模型進行仿真分析和計算。根據(jù)蒙特卡羅仿真思想，TCMS可靠性仿真的邏輯設(shè)計圖如圖3所示。TCMS系統(tǒng)可靠性數(shù)字仿真采用離散事件驅(qū)動的模擬方法，仿真核心是對一個事件隊列的處理，該隊列按照事件發(fā)生的時間先后進行排序，每一個事件將會產(chǎn)生一個中斷等待處理，隨著仿真時鐘推進，設(shè)備故障及設(shè)備維修等不同事件會進入隊列中驅(qū)動仿真推進。

圖3 TCMS可靠性仿真邏輯設(shè)計圖

3.2 數(shù)字仿真程序

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

圖4 TCMS可靠性數(shù)字仿真程序

在仿真過程中各種事件可以實時顯示，故障設(shè)備的狀態(tài)同時會在TCMS拓撲圖中顯示出來，對于喪失功能的設(shè)備用紅色標示，對于只有1個通道故障時用黃色標示，主CCU故障以粉色標示；仿真結(jié)果顯示框顯示的數(shù)據(jù)是本次仿真的結(jié)果，多次仿真結(jié)束后，仿真結(jié)果顯示框中顯示的信息是多次仿真的平均值。

TCMS可靠性數(shù)字仿真程序采用離散事件驅(qū)動的模擬機理(“事件”是指TCMS狀態(tài)的變化)，仿真過程中仿真核心維護著1個故障事件隊列，該隊列按照事件發(fā)生的時間先后進行排序，隊列的第1個事件將產(chǎn)生1個中斷，處理完該故障事件后該事件被刪除，隨著仿真時鐘的推進，不斷有設(shè)備故障，故障設(shè)備維修后又會有新的故障事件插入到故障事件隊列中形成仿真推進的動力，當滿足退出條件時則仿真終止[5]。

3.3 仿真分析計算

數(shù)字仿真程序應(yīng)用的輸出結(jié)果包括列車的平均運行時間、運行期間發(fā)生的平均故障次數(shù)、發(fā)生的平均掉線故障次數(shù)、平均檢修故障間隔時間、平均掉線故障間隔時間和TCMS系統(tǒng)使用可用度，之后的應(yīng)用中可以根據(jù)需求統(tǒng)計其他需要的可靠性、維修性和可信性等參數(shù)。

列車的平均運行時間TOP是多次TCMS仿真中列車運行時間的平均值，列車運行期間發(fā)生的平均故障次數(shù)FN是多次TCMS仿真中列車發(fā)生的所有故障次數(shù)之和的平均值，發(fā)生的平均掉線故障次數(shù)CFN是多次TCMS仿真中列車發(fā)生的所有掉線故障次數(shù)之和的平均值。

單次TCMS仿真和多次TCMS仿真后的平均檢修故障間隔時間分別為MTBFi和MTBF，計算公式為：

(1)

(2)

式中：TOPi——每次TCMS仿真時的列車運行時間；

N——仿真次數(shù)。

單次TCMS仿真和多次TCMS仿真后的平均掉線故障間隔時間分別為MTBCFi和MTBCF，計算公式為:

(3)

(4)

系統(tǒng)的使用可用度Ao是指系統(tǒng)當需要時能夠正常工作的程度，其計算公式為:

(5)

式中：TT——TCMS的任務(wù)時間；

DT——TCMS不能工作的時間。

3.4 仿真數(shù)據(jù)輸入

仿真數(shù)據(jù)輸入包括對列車運行任務(wù)剖面數(shù)據(jù)的設(shè)置以及TCMS組成單元參數(shù)的設(shè)置。

3.4.1 仿真任務(wù)設(shè)置

假設(shè)列車的任務(wù)時間為6年，每月有1天的時間需對列車進行檢查，檢查當天列車不運行，每年按365天計算，則6年內(nèi)列車總的任務(wù)時間為(365-12)×6=2 118(天)，其余任務(wù)參數(shù)設(shè)置如下：每日出車時間為5:00 a.m.，每日返回時間為11:00 p.m.，單程運行時間為90 min，仿真運行次數(shù)為20次。

3.4.2 設(shè)備參數(shù)設(shè)置

依據(jù)可靠性理論和大量工程實踐，復(fù)雜系統(tǒng)故障規(guī)律一般服從指數(shù)分布[6]。列車各系統(tǒng)及其子系統(tǒng)均屬于復(fù)雜系統(tǒng)，且在正常運行期間的故障率是基本恒定的，其基本部件的故障規(guī)律基本服從指數(shù)分布。考慮到項目設(shè)計階段無法確定TCMS組成單元的可靠性和維修性參數(shù)，硬件的可靠性參數(shù)按照可靠性分配的結(jié)果取值，軟件的可靠性和設(shè)備的維修性參數(shù)則初步給一個參考值，軟件可靠度和維修時間分布參數(shù)分別設(shè)為0.99和1 h計算分析中采用的設(shè)定仿真輸入數(shù)據(jù)如表1所示。

表1 仿真輸入數(shù)據(jù)設(shè)置

3.5 仿真運行及結(jié)果分析

在數(shù)字仿真程序開發(fā)完成的基礎(chǔ)上，對TCMS的硬件組成可靠性以及TCMS軟硬件綜合的可靠性水平進行仿真分析，仿真運行在假設(shè)條件下進行，獲得更詳細車輛實際運營數(shù)據(jù)后進行仿真時仿真結(jié)果會更加準確。

3.5.1 TCMS硬件可靠性仿真結(jié)果

將含有軟件單元的軟件可靠度數(shù)值設(shè)為1，即認為軟件不發(fā)生故障，其他參數(shù)按表1中所列數(shù)值進行設(shè)置。TCMS硬件組成可靠性仿真結(jié)果如表2所示。

表2 TCMS硬件組成可靠性仿真結(jié)果

3.5.2 TCMS軟硬件綜合可靠性仿真結(jié)果

在TCMS可靠性數(shù)字仿真程序中輸入表1中參數(shù)，在綜合考慮軟硬件故障的情況下，TCMS軟硬件綜合可靠性仿真結(jié)果如表3所示。

表3 TCMS軟硬件綜合可靠性仿真結(jié)果

3.5.3 仿真結(jié)果對比分析

將TCMS硬件組成可靠性仿真結(jié)果及軟硬件綜合可靠性仿真結(jié)果進行對比分析，可以得到以下結(jié)論：

(1) 不考慮軟件故障的情況下，列車運行2 118天平均發(fā)生的故障次數(shù)為36.2次(不考慮硬線)和37.2次(考慮硬線)。TCMS硬件的平均故障間隔時間為1 052.39 h(不考慮硬線)和1 024.20 h(考慮硬線)，與可靠性分配的指標(1 000 h)基本相符。

對于TCMS的硬件組成，考慮硬線備份后，列車運行2 118天平均發(fā)生的掉線次數(shù)由22.6次降為17.07次，列車的平均掉線故障間隔時間由1 685.69 h提高到2 232.43 h，提高了32.43%。

(2) 綜合考慮軟件和硬件故障，列車運行2 118天平均發(fā)生的故障次數(shù)為1 440次左右，通過與硬件組成的仿真結(jié)果進行對比可知，其中軟件故障有1 400次左右。TCMS的平均故障間隔時間為26.4 h 左右，由于軟件故障后可恢復(fù)的特性，由TCMS故障導致的列車掉線次數(shù)較少，但是比硬件組成多9次左右。

(3) 綜合考慮軟件和硬件故障，在加入硬線備份后，TCMS的平均掉線故障間隔時間由1 220.58 h 提高到1 426.52 h，提高了近16.87%。由于硬線只是對MVB網(wǎng)絡(luò)(MVB總線、中繼器、分線器)連通性的備份，對軟件故障沒有備份功能，硬線備份后TCMS的平均掉線故障間隔時間的提高主要是硬線設(shè)計對網(wǎng)絡(luò)連通可靠性的提升。

4 結(jié)束語

國產(chǎn)化列車網(wǎng)絡(luò)控制系統(tǒng)開發(fā)及應(yīng)用對硬件、軟件及系統(tǒng)集成可靠性指標要求不斷提高，產(chǎn)品開發(fā)過程中如何針對具有硬件、軟件、網(wǎng)絡(luò)通信的復(fù)雜系統(tǒng)進行可靠性指標預(yù)計并進行工程化應(yīng)用一直是車輛系統(tǒng)集成需要面對和解決的問題。本文以列車網(wǎng)絡(luò)控制系統(tǒng)這一復(fù)雜網(wǎng)絡(luò)系統(tǒng)為分析對象，建立了基于蒙特卡羅算法的可靠性仿真預(yù)計分析模型，應(yīng)用開發(fā)的數(shù)字仿真程序進行了仿真預(yù)計分析，根據(jù)仿真分析結(jié)果協(xié)調(diào)設(shè)計參數(shù)進行方案比較，以發(fā)現(xiàn)系統(tǒng)設(shè)計的薄弱環(huán)節(jié)，對復(fù)雜網(wǎng)絡(luò)系統(tǒng)的可靠性及維修性設(shè)計工程化具有一定的借鑒意義。