杜麗霞，曹 巖

(蘭州交通大學 電子與信息工程學院，甘肅 蘭州730070)

0 引 言

在客專鐵路運營中，CTCS 系統(tǒng)實現(xiàn)對列車運行速度的控制，CTC 系統(tǒng)實現(xiàn)遠程排路、設置、取消臨時限速這樣的工作模式，使列車在高速運行的同時，列車運行安全也有了保障。

1 CTC 與CTCS2 交互流程

通 過 CTC［1-4］與 技 術 咨 詢 中 心(Technology Consultancy Center，TCC)的通信數(shù)據(jù)分析［5-7］可以看出，雙方傳輸?shù)摹芭R時限速數(shù)據(jù)塊”為核心內(nèi)容。通過接口協(xié)議［8-9］，可以看出，CTC 向TCC 發(fā)送一條臨時限速命令中，核心部分如下，如表1 所示。

表1 CTC 發(fā)送的核心數(shù)據(jù)

發(fā)往列控中心的一個完整的限速命令中，“限速命令號”、“執(zhí)行標記”、“線路號”均是發(fā)令者(或車站執(zhí)行者)較為容易理解，而“起點覆蓋標志”、“終點覆蓋標志”字段則需要CTC 進行計算，即CTC 需要對公里標進行歸檔，當限速區(qū)域超出該列控中心管轄范圍時，CTC 需要增加左右覆蓋標志，用以告知列控中心，這部分計算對CTC 來說較為復雜，若CTC 歸檔將此標志左右搞反后，則會造成列控中心限速區(qū)域出錯。

下面舉例說明CTC 的左右覆蓋標志計算方式，一般而言車站列控中心的限速范圍［10-15］如圖1 所示。

圖1 限速范圍示意圖

圖1 中，B 站列控中心管轄范圍為K603 +772-K654 +336 ，而C 站列控中心管轄范圍為K619 +780-K679 +667，如果限速區(qū)域如上圖所示，限速公里標為:K619 +100-K656 +600，此時CTC 需要對此限速公里標歸檔計算，輸入的參數(shù)包括:線路號(下行線);起點里程標系符(K);起點公里標(619 +100);結(jié)束里程標系符(K);結(jié)束公里標(656 + 600);限速速度值(120 km/h)。

通過輸入?yún)?shù)，需要計算該限速命令對每一個列控中心(B、C)的分解命令對應的覆蓋標志。根據(jù)下行線，公里標范圍為遞增趨勢，比較輸入的開始和結(jié)束公里標，對比每個列控中心的管轄范圍，計算如下。

發(fā)往B 站列控中心的限速數(shù)據(jù)需要為:開始公里標K619 +100，覆蓋標志0，結(jié)束公里標K656 +600，覆蓋標志01。

發(fā)往C 站列控中心的限速數(shù)據(jù)需要為:開始公里標K619 +100，覆蓋標志2，結(jié)束公里標K656 +600，覆蓋標志0。

計算流程大致如圖2 所示。

圖2 計算流程圖

以上為簡單的公里標覆蓋標志說明，當一條線路存在多種里程標系時，計算尤為復雜。以成都局達成線實際為例，如圖3 所示。

圖3 成都局達成線公里標示意圖

正常情況中，下行線路公里標均為由小至大，上行線路由大至小。但是在實際特殊的樞紐線路區(qū)、疏解線路區(qū)，就會存在不同的里程標系，比如上述成都局達成線中。其中K1 +809-K129 +521 的下行線為普通的“達成下行線路”，公里標由小至大，但在“石板灘”車站則存在里程標系切換點，為IIK 里程標系(成渝線里程標系)，范圍為IIK18 +762-IIK12 +215，此里程標系雖然為下行線路，公里標卻由大至小。同樣，K129+476-K2 +143 里程為普通的“達成線上行線”里程標系，而從“龍?zhí)端隆敝痢笆鍨倍?，公里標范圍為IK0+210-IK6 +640，在“石板灘”存在里程切換點，IK 里程標系為“成渝疏解線”里程，雖然為上行線路，公里標卻為遞增。在下達限速時，整條線路從“遂寧”-“龍?zhí)端隆睘槔ň€路，即允許下達“下行線”K128 +100-IIK13 +200 這樣的臨時限速命令。

通過上述實際應用，在復雜線路中，計算覆蓋標志時需要將整個線路拉通，對不同的里程標系拉通計算轉(zhuǎn)換［16］。

2 實際中覆蓋標志出現(xiàn)的問題

通過上述描述，CTC 通過對限速公里標、每個列控管轄范圍進行計算，得出對每個列控中心的左右覆蓋標志。這意味著CTC 必須計算正確。也意味著CTC要配置整條線路的列控數(shù)據(jù)。實際的工程實施中，由于每條線路可能存在諸多特殊性，以及整條線路中，CTC 需要配置的列控數(shù)據(jù)相當龐大且繁雜，一旦配置錯誤，可能會導致計算錯誤。

下面以實際工程應用中出現(xiàn)的問題為例，主要分析覆蓋標志單方面計算時出現(xiàn)的問題，最后給出對策。

2.1 試驗出現(xiàn)問題

客運專線甬臺溫在線路拉通試驗時，需要下達限速命令測試。試驗的限速區(qū)段為上行線路K654 +300-K654 +400 區(qū)域。而此限速范圍跨越了福鼎站和鰲江站的TCC 管轄范圍邊界，既然跨了2 個TCC 列控中心管轄范圍，則CTC 向列控發(fā)送的限速命令具體數(shù)據(jù)中會有覆蓋標志，而CTC 系統(tǒng)因為覆蓋標志計算不正確，下達給列控中心后，列控中心將原信息反饋給CTC 并通知執(zhí)行成功，CTC 系統(tǒng)內(nèi)部界面顯示的限速與實際列控執(zhí)行的限速區(qū)域不一致。此時在CTC 終端中的界面顯示表征找不到任何問題。限速初始示意圖如圖4 所示。

圖4 測試限速示意圖

在圖4 中，黃色區(qū)域即為“預期限速區(qū)域”，公里標范圍為K654 +300-K654 +400。通過上面，也知道初始的列控中心管轄范圍為:福鼎站上行管轄范圍為K654 + 336----K709 + 824;蒼南站上行管轄范圍為K619 + 780----K679 + 667;鰲江站上行管轄范圍為K603 +772----K654 +336。

以上數(shù)據(jù)為每個列控中心的初始數(shù)據(jù)。此時CTC下達限速命令，輸入的參數(shù)為:開始公里標K654 +400，結(jié)束公里標K654 +300，限速120 km/h。在實際應用中，部分列控中心可能需要歸檔，但是實際CTCS2中一般不需要CTC 對此公里標歸檔，為此本文對歸檔不作詳細說明。通過上面的圖示可以看出目標限速區(qū)域跨越了鰲江站TCC 的反響管轄邊界和福鼎站TCC的正向管轄邊界，而對蒼南站TCC 而言，目標限速區(qū)域在蒼南站TCC 的管轄范圍之內(nèi)。在當時試驗時，CTC 系統(tǒng)經(jīng)過計算后發(fā)給各個列控中心的限速命令數(shù)據(jù)核心部分如下。

福鼎站列控中心:開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志2。

蒼南站列控中心:開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志0。

鰲江站列控中心:開始公里標K654 +400，覆蓋標志1，結(jié)束公里標K654 +300，覆蓋標志0。

根據(jù)上面的通信協(xié)議，覆蓋標志位為1 時表示其對應公里標在該列控中心TCC 正向管轄范圍之外，覆蓋標志位為2 表示其對應公里標在該列控中心TCC的反向管轄范圍之外。所以上述的核心數(shù)據(jù)部分有錯誤，正確的應該為:

福鼎站列控中心:開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志1。

蒼南站列控中心:開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志0。

鰲江站列控中心:開始公里標K654 +400，覆蓋標志2，結(jié)束公里標K654 +300，覆蓋標志0。

在發(fā)生了錯誤數(shù)據(jù)之后，各個列控中心對接收到的限速命令中的公里標數(shù)據(jù)進行執(zhí)行，執(zhí)行結(jié)果如下:

福鼎站列控中心開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志2 的命令執(zhí)行如圖5 所示。

福鼎站的開始公里標K654 +400 的覆蓋標志為0，該福鼎站列控中心認為該公里標在其管轄范圍之內(nèi)(實際也的確在其管轄范圍)。而結(jié)束公里標K654 +300 的覆蓋標志為2，列控此時不校驗該覆蓋標志2 是否與結(jié)束公里標的方向一致，而直接認定反向覆蓋，即列控中心直接對從公里標K654 +400 開始到反向(上行方向為正向)管轄范圍邊界的區(qū)域進行限速，如上圖的黑色框部分即為實際執(zhí)行限速。

福鼎站的正確公里標數(shù)據(jù)開始公里標K654 +400，覆蓋標志0，結(jié)束公里標K654 +300，覆蓋標志1，正確執(zhí)行的限速圖例應該如圖6 所示。

蒼南站收到的數(shù)據(jù)開始和結(jié)束公里標均沒有覆蓋標志，而且目標限速預期完全在蒼南站的管轄范圍之內(nèi)，所以蒼南站的實際執(zhí)行區(qū)域與欲執(zhí)行區(qū)間完全一致。即如圖7 所示。

圖5 福鼎實際示意圖

圖6 福鼎站正確圖例

圖7 蒼南站執(zhí)行限速圖示

鰲江站列控中心對開始公里標K654 +400，覆蓋標志1，結(jié)束公里標K654 +300，覆蓋標志0 的限速命令執(zhí)行如圖8 所示。

這是因為鰲江站對接收的數(shù)據(jù)中，結(jié)束公里標K654 +300 的覆蓋標志為0，列控認為其在鰲江列控中心的管轄范圍之內(nèi)(實際該公里標同樣也的確在其管轄范圍)。而開始公里標K654 +400 的覆蓋標志為1，列控中心沒有校驗覆蓋標志1 是否與開始公里標的方向一致，而直接對從正向管轄范圍到結(jié)束公里標的K654 +300 的區(qū)域直接限速，如圖8 所示。

而鰲江的正確公里標數(shù)據(jù)應該為開始公里標K654 +400，覆蓋標志2，結(jié)束公里標K654 +300，覆蓋標志0 ，對應的限速區(qū)域應該如圖9 所示。

各個列控中心對各自接收到的限速執(zhí)行成功后，將CTC 系統(tǒng)發(fā)送給TCC 的限速數(shù)據(jù)(起始公里標、結(jié)束公里標、覆蓋標志)反饋給CTC，CTC 根據(jù)該執(zhí)行范圍計算在各個終端應該顯示的限速黃色帶區(qū)域。

圖8 正確的示意圖

圖9 實際執(zhí)行范圍圖

通過上圖可以看出，CTC 端看不出任何問題，CTC從TCC 接收到的數(shù)據(jù)認為限速區(qū)域即為原預期要限速的區(qū)域，而3 站列控中心的限速區(qū)域卻將限速執(zhí)行范圍遠遠擴大，將原只100 m 的限速范圍，執(zhí)行為限速了幾十公里，同時由于3 個列控中心發(fā)送的限速范圍不一致，向?qū)膽鹌靼l(fā)送限速數(shù)據(jù)包內(nèi)容不一致，導致機車緊急制動。

2.2 問題處理

實際中出現(xiàn)問題的原因即因為CTC 系統(tǒng)雖然給出了正確的公里標，但沒有給出正確的公里標覆蓋標志，而列控中心TCC 不校驗公里標及覆蓋標志，直接將CTC 系統(tǒng)計算的覆蓋標志用來限速，導致了上述出現(xiàn)的問題，即列控實際限速與CTC 不一致。

CTC 系統(tǒng)這種計算錯誤經(jīng)查即為工程數(shù)據(jù)的配置中出現(xiàn)錯誤，導致了系統(tǒng)計算出現(xiàn)問題。CTC 系統(tǒng)的覆蓋標志的錯誤影響的是整個列控中心管轄的整條線路范圍，而不僅僅是限速輸入的目標限速區(qū)域，一旦出現(xiàn)錯誤，所有公里標覆蓋跨越的TCC 的限速均會不正確執(zhí)行，而非預期效果。

由于CTC 系統(tǒng)需要對整條線路的區(qū)間數(shù)據(jù)進行配置，數(shù)據(jù)量非常龐大，且沒有自動工具，只能人工錄入，可能導致配置錯誤。此類似問題在成都局的達成線CTC 中同樣出現(xiàn)過，在其他鐵路局中同樣也出現(xiàn)過。為了防止這類問題的發(fā)生，CTC 系統(tǒng)必須配合列控，對所有的列控中心至少進行跨越管轄范圍的限速測試，每個列控中心至少試驗2 條限速，分別有一個公里標不在該列控的管轄范圍之內(nèi)。即對某列控中心A，2 條限速公里標起止應該測試。

(1)起始公里標在A 的管轄范圍內(nèi)，結(jié)束公里標在A 的正向管轄范圍外。

(2)起始公里標在A 的管轄范圍內(nèi)，結(jié)束公里標在A 的反向管轄范圍外。

3 結(jié) 語

上述的試驗方案在新建線路時，可以有充裕的時間對列控中心及各種公里標進行測試試驗，而在已經(jīng)上線使用的線路中，尤其是在改造的車站中，施工時間點緊迫，沒有充裕的時間進行測試，就會出現(xiàn)問題。成都局達成線在改造某一CTC 車站的列控中心時，由于只給了1 個小時的施工點，測試沒有完全，仍然發(fā)生了類似上述的問題。要從根本上解決此類問題，分析后可以有如下方案:

CTC 系統(tǒng)在每一次改動后同列控配置對各種情況的限速進行完全遍歷性測試試驗，然后再上線使用，如果工程施工時間不夠，則雙方在試驗環(huán)境中進行模擬測試。目前，由于鐵路應用的特殊性，各個鐵路局一直沿用此方案，由各個廠家負責對數(shù)據(jù)的完整測試。

［1］ DU Lixia，CAO Yan. Drug Utilization Knowledge Discovery Using Self-organizing Map and Rough Set Theory ［J］. Journal of Computational Information Systems，2008，4(2):553-558.

［2］ DU Lixia，CAO Yan. The application of A Markov Chain Model of Algorithmic Efficiency in termination time of TV shows［J］.Proceedings IEEE，2008(3):1580-1582.

［3］ ALSTOM. FSFB/2 Safety Protocol Requirements Specification［S］.1999，Version B.2.

［4］ CENELEC. EN 50129 Railway applications--- Communication，signalling and processingsystems ---Safety related electronic systems for signaling［S］.2003(2).

［5］ IEC 61850. Communication Networks and Systems in Substations［S］.2004.

［6］ 李長林，高 潔.Visual C + + 串口通信技術與典型實例［M］.北京:清華大學出版社，2006.

［7］ 科技運［2008］127 號. 中國列車控制系統(tǒng)CTCS 名詞術語(V1.0)［M］.北京:中國鐵道出版社，2008.

［8］ 科技運［2008］151 號. 客運專線列控系統(tǒng)臨時限速技術規(guī)范(V1.0)［M］.北京:中國鐵道出版社，2009.

［9］ 科技運［2004］15 號.分散自律調(diào)度集中(CTC)技術條件(暫行修訂稿)［M］.北京:中國鐵道出版社，2004.

［10］ 許 誠，王安平. 繁忙鐵路干線調(diào)度集中調(diào)試開通方案的研究［J］.鐵道通信信號，2007(6):56-60.

［11］ 張宏林.精通Visual C+ +串口通信技術與工程實踐［M］.3 版.北京:人民郵電出版社，2008.

［12］ ALSTOM. FSFB/2 Safety Protocol Requirements Specification［S］.1999，Version B.2.

［13］ CENELEC. EN 50129 Railway applications --- Communication，signalling and processingsystems ---Safety related electronic systems for signaling［S］.2003(2).

［14］ ALSTOM. 000-801-S-01-SW001-B-002-088 FSFB/2 safety protocol requirements specification［S］.France:ALSTOM，2002.

［15］ 吳文麒. 國外鐵路信號新技術［M］. 北京:中國鐵道出版社，2000.

［16］ 岳朝鵬. 40.10_08.04.25_客專列控中心接口協(xié)議_V037［S］.2008.