壓縮TDCS故障延時的探討

周 曄

（南寧鐵路局南寧電務(wù)段，助理工程師，廣西 南寧 530001）

鐵路列車調(diào)度指揮系統(tǒng)（Train operation Dispatching command System，簡稱TDCS）是實現(xiàn)鐵路各級運輸調(diào)度對列車運行透明指揮、實時調(diào)整、集中控制的現(xiàn)代化信息系統(tǒng)，實現(xiàn)了鐵路運輸組織的科學(xué)化、現(xiàn)代化，且增加運能、提高效率，減輕了調(diào)度人員的勞動強度，改善了調(diào)度指揮的工作環(huán)境。由于TDCS系統(tǒng)發(fā)生故障后對行車調(diào)度影響很大，所以有必要研究如何壓縮TDCS故障延時的措施，以減少故障對行車的影響。

1 故障延時長的主要原因

南寧鐵路局管內(nèi)有湘桂、黔桂、黎湛、焦柳、南昆、南憑、河茂、益湛8條鐵路線，運營里程3 237.4 km，TDCS設(shè)備遍布274個車站的運轉(zhuǎn)室、站調(diào)、外勤及機務(wù)段等機構(gòu)。況且目前維護勞力缺乏，技術(shù)底子薄弱，所以故障延時長一直都是電務(wù)部門難以攻克的難題。壓縮TDCS故障處理延時，最重要的是查找主觀因素方面的原因。

1.1 故障處理流程多故障受理及處理流程主要有3個步驟：1）發(fā)現(xiàn)問題。主要通過現(xiàn)場電務(wù)人員和TDCS中心對設(shè)備的巡視，及使用部門的申告實現(xiàn)。但實際存在巡視不到位、通知不及時、使用部門無暇申告，造成延時。2）查找原因。由于現(xiàn)場作業(yè)人員對設(shè)備不熟悉，需要TDCS中心的電話指導(dǎo)。故障信息和指導(dǎo)信息的頻繁交互，往往會因通訊障礙、表達障礙等因素變得相當?shù)暮臅r。3）故障處理。由于在處理故障時沒有把故障處理的詳細經(jīng)過和經(jīng)驗記錄下來，形成故障處理的規(guī)范，在處理類似故障時仍需邊回憶邊處理。不準確的回憶，必然造成又一次的延時。

1.2 故障信息采集滯后且不準確在故障發(fā)生后，故障實際處理人即現(xiàn)場電務(wù)人員并未在第一時間獲得故障信息，而是由TDCS中心通過電話通知。因此，存在通知障礙和溝通障礙等延時因素。通知障礙包括電話故障、電話長時間占線、電話無人接聽等情況。溝通障礙則包括電話信號不良、采用方言不同及對設(shè)備故障點的理解不同等。這些因素都會造成TDCS中心和故障處理人之間信息傳遞滯后和信息不對稱，出現(xiàn)故障延時。

1.3 故障處理方式落后TDCS系統(tǒng)設(shè)備包括：網(wǎng)絡(luò)處理單元（NPC）、車務(wù)終端（STPC）、應(yīng)用服務(wù)器，調(diào)度指揮終端（GPC）等。目前，針對TDCS故障處理的方式比較落后。

1.3.1 NPC故障 網(wǎng)絡(luò)處理單元（NPC）就是將站場信息以碼位的形式解析，再將相關(guān)數(shù)據(jù)送給其處理，并以網(wǎng)絡(luò)的方式傳遞。整個單元的內(nèi)部芯片采用Linux Redhat的系統(tǒng)平臺，外部配與單網(wǎng)卡來實現(xiàn)網(wǎng)絡(luò)傳輸。把網(wǎng)卡與本站局域網(wǎng)內(nèi)網(wǎng)IP地址捆綁，并采用雙機熱備的方式以實現(xiàn)網(wǎng)絡(luò)傳輸預(yù)處理。但在一些雷害頻發(fā)的地區(qū)，雙套NPC同時被雷擊壞經(jīng)常發(fā)生，這給鐵路系統(tǒng)尤其是電務(wù)部門帶來了極大的困擾和經(jīng)濟損失。而現(xiàn)場電務(wù)人員恰恰缺乏故障處理的技術(shù)能力，必須由相關(guān)的電子綜合部門根據(jù)本站實際情況重新編寫芯片程序，再發(fā)往故障現(xiàn)場。而電子綜合部門只設(shè)在南寧、柳州、桂林三地，如此一去一回，使故障延時長。

1.3.2 STPC故障 現(xiàn)行的車務(wù)終端（STPC）采用傳統(tǒng)的雙機熱備方式。其原理是基于磁盤塊的復(fù)制方式，當某個磁盤塊靜止不動，軟件發(fā)現(xiàn)改動，才進行復(fù)制拷貝，這時候如果磁盤有壞道，損壞的數(shù)據(jù)也隨之覆蓋備機完好的數(shù)據(jù)，這就形成了3種不理想結(jié)果：1）數(shù)據(jù)不能即時同步；2）數(shù)據(jù)容易丟失；3）每次停機都有較長的初始化過程，數(shù)據(jù)再覆蓋一遍。這正是主備機不能正常切換，磁盤無數(shù)據(jù)、數(shù)據(jù)丟失，故障延時長的重要原因。

1.3.3 應(yīng)用服務(wù)器故障 應(yīng)用服務(wù)器是TDCS系統(tǒng)的核心設(shè)備，也采用雙機熱備的方式。在發(fā)生故障時，由人工切換。問題在于當故障發(fā)生突然且嚴重時，應(yīng)用服務(wù)器不能自動切換。比如當網(wǎng)絡(luò)誤碼率大于7%時，程序依然運行，但數(shù)據(jù)已經(jīng)開始丟失；部分車站收不到階段計劃、調(diào)度命令，以及運行線不全等故障癥狀開始慢慢體現(xiàn)。所以，人工切換應(yīng)用服務(wù)器的故障解決方式明顯落后，造成故障延時長。

1.3.4 GPC故障 調(diào)度指揮終端（GPC）是一客戶端，其數(shù)據(jù)要寫入數(shù)據(jù)服務(wù)器中的IBM DB2數(shù)據(jù)庫。如果數(shù)據(jù)服務(wù)器癱瘓，行調(diào)員繪制的運行圖、下發(fā)的調(diào)度命令、記事等諸多數(shù)據(jù)將無法存儲，后果很嚴重。而數(shù)據(jù)服務(wù)器故障點查找難，恢復(fù)慢，影響時間長。針對數(shù)據(jù)服務(wù)器二取一平行的存儲方式，當主、備服務(wù)器同時發(fā)生故障時，不僅僅是故障處理時間延長，甚至難以恢復(fù)原功能。

1.4 軟件缺乏人性化在實際TDCS故障處理中，除了硬件發(fā)生故障以外，也不乏軟件故障。軟件如果缺乏人性化及規(guī)范化，故障延時可能比硬件故障更長。比如TDCS程序?qū)υO(shè)備故障不能自動報警、GPC程序不能自動切換聯(lián)網(wǎng)模式和單機模式、程序配置文件多且沒有封裝等都是軟件缺乏人性化的具體表現(xiàn)。針對這些表現(xiàn)，必須人工巡視設(shè)備、人工切換模式、人工檢查配置。而這些都依賴于人的技術(shù)水平高低和責(zé)任心的強弱，會帶來故障延時，并且這種延時是不可控的。

2 壓縮故障延時的措施

鑒于上述分析，應(yīng)在弄清故障原因的基礎(chǔ)上，通過優(yōu)化處理流程，利用Unix環(huán)境參數(shù)優(yōu)化，數(shù)據(jù)庫間的轉(zhuǎn)換及系統(tǒng)底層緩存攔截和智能識別來達到壓縮故障延時的目的。

2.1 優(yōu)化故障處理流程在信號微機監(jiān)測系統(tǒng)中，故障可以通過采集值直觀地反映出來，并通過網(wǎng)絡(luò)傳輸?shù)竭_監(jiān)測調(diào)閱終端，調(diào)度員發(fā)現(xiàn)聲音報警后，直接通知相關(guān)人員前去處理。針對這一點，TDCS系統(tǒng)是可以借鑒和進一步優(yōu)化。通信前置服務(wù)器就類似監(jiān)測服務(wù)器，可以在通信前置服務(wù)器上加裝一通訊設(shè)備，將TDCS設(shè)備故障信息以手機短信群發(fā)的形式，發(fā)送到相關(guān)負責(zé)人的手機。這樣故障信息可以跨越通知障礙和溝通障礙，在第一時間準確無誤地傳達到故障處理人。這樣既可以節(jié)省故障通知時間，又能彌補機房巡視人員由于工作疏忽而遺漏的設(shè)備隱患。

但僅僅壓縮了故障通知的時間是遠遠不夠的，故障處理事件往往由于TDCS中心人員沒有親眼目睹故障現(xiàn)象和故障位置，以及現(xiàn)場電務(wù)人員不熟悉TDCS設(shè)備的雙重原因，造成故障點誤判以致延時。鑒于此情況，對于一些業(yè)務(wù)不熟悉的現(xiàn)場作業(yè)人員有必要配帶輕便的攝像設(shè)備，以輔助TDCS中心人員指揮其確認故障點并順利排除故障。而故障視頻信息可以通過TDCS網(wǎng)絡(luò)傳遞到TDCS中心并予以保存。

2.2 增強故障處理方式的科學(xué)性因為TDCS系統(tǒng)使用范圍廣，遍布全局管轄所有車站，且電務(wù)人員勞力不足，對TDCS技術(shù)不熟悉，所以改變故障處理方式落后的現(xiàn)狀，對壓縮故障延時，提高行車效率有重要和深遠的意義。

2.2.1 NPC故障處理方式的優(yōu)化 NPC故障處理時間長，是因為NPC只配備了單網(wǎng)卡，且只捆綁了單IP。如果從鄰站調(diào)用一套NPC，其IP地址與路由不在同一子網(wǎng)，無法通信。其實，Unix最多可以支持255個IP別名。如果給單網(wǎng)卡綁定好相應(yīng)鄰站和本站的IP地址，電務(wù)人員在發(fā)生故障時，只需將鄰站事先配置好多IP地址的NPC備機，換到本站安裝好即可。這樣可以省去遠距離來回遞送NPC的時間，可壓縮故障延時80%以上。而這些要通過優(yōu)化Uinx環(huán)境參數(shù)來實現(xiàn)，實現(xiàn)方法如下：

假設(shè)需要綁定多IP的網(wǎng)卡是eth0，則在/etc/sysconfig/network-scripts目錄里面創(chuàng)建一個名為ifcfg-eth0：0的文件，內(nèi)容樣例：

device=“eth0：0”//device為設(shè)備的名稱

ipaddr=198.12.163.5//ipaddr為此設(shè)備的ip地址

netmask=255.255.255.0//netmask為子網(wǎng)掩碼

broadcast=198.12.163.255//onboot表示在系統(tǒng)啟動時自動啟動

onboot=yes//表示在系統(tǒng)啟動時自動啟動

bootproto-none

如果需要再多綁定一個IP地址，只需要把文件名和文件內(nèi)的device中的eth0：x加1，然后把ipconfig eth0：1 198.12.164.5 broadcast 198.12.255.255 netmask 255.255.255.0加在啟動自運行文件（/etc/rc.d/rc.local）里面即可〔1〕。此方法通過優(yōu)化Unix環(huán)境參數(shù)，改變了傳統(tǒng)模式，使故障延時大大降低。

2.2.2 STPC故障處理方式的優(yōu)化 對于目前STPC采用的傳統(tǒng)雙機熱備方式帶來的不理想結(jié)果，建議采用雙機雙軟熱備的方案，從而使用了新的軟件架構(gòu)，改變傳統(tǒng)數(shù)據(jù)同步模式，即使用單程序而后臺運行雙進程的方式，使數(shù)據(jù)在本地磁盤先備份及數(shù)據(jù)識別，然后才進行雙機熱備的數(shù)據(jù)同步工作。其原理是基于系統(tǒng)底層的緩存攔截，加上智能數(shù)據(jù)識別，同步鎖定等功能，數(shù)據(jù)有稍微的改動，經(jīng)過緩存都會在備機及本機其它分區(qū)執(zhí)行相同操作。如果采用此方案，STPC的故障預(yù)防性可得以提高，自我恢復(fù)能力將得到加強。

2.2.3 應(yīng)用服務(wù)器故障處理方式的優(yōu)化 在應(yīng)用服務(wù)器程序中添加對網(wǎng)絡(luò)狀態(tài)自動判斷的語句模塊。當網(wǎng)絡(luò)誤碼率大于7%時，程序自動退出，此時備機程序則自動成為主用。這樣就解決了因網(wǎng)絡(luò)丟包而造成的不經(jīng)意間數(shù)據(jù)丟失。

2.2.4 GPC故障處理方式的優(yōu)化 在調(diào)度指揮終端（GPC）建立一個類似ACCESS，MYSQL的小型數(shù)據(jù)庫。ACCESS的數(shù)據(jù)庫如圖1所示。

圖1ACCESS數(shù)據(jù)庫表

在圖1中，ACCESS數(shù)據(jù)庫表由IBM數(shù)據(jù)服務(wù)器的DB2數(shù)據(jù)庫轉(zhuǎn)換而來。當數(shù)據(jù)服務(wù)器癱瘓時，啟動本地數(shù)據(jù)庫。待數(shù)據(jù)服務(wù)器恢復(fù)正常工作時，再將本地數(shù)據(jù)庫的數(shù)據(jù)回送到數(shù)據(jù)服務(wù)器中，從而即使雙機冗余的數(shù)據(jù)服務(wù)器都出現(xiàn)故障，行調(diào)員依舊可以正常地指揮行車，不存在故障延時。

3 結(jié)束語

TDCS系統(tǒng)自投入使用以來，不僅給行車調(diào)度指揮工作帶來了極大的便利，也為鐵路系統(tǒng)創(chuàng)造了良好的經(jīng)濟效益和社會效益。但與此同時，隨著TDCS系統(tǒng)的不斷升級，也對TDCS設(shè)備維護提出了更高的要求和標準。通過Unix環(huán)境參數(shù)的優(yōu)化，數(shù)據(jù)庫間的轉(zhuǎn)換及系統(tǒng)底層緩存攔截和智能識別，有效地實現(xiàn)了壓縮故障延時的目的。對主要耗時故障，縮短延時達50%以上，提高了行車指揮的工作效率和安全性。

〔1〕尤晉元.UNIX環(huán)境高級編程〔M〕.北京：機械工業(yè)出版社，2002.