淺談城市軌道交通信號ATS系統與主控牽引供電的接口

陳 微 吳應攀 辛 驥

陳 微:廣州地鐵通號中心 工程師 510000 廣州

吳應攀:廣州地鐵通號中心 助理工程師 510000 廣州

辛 驥:廣州地鐵通號中心 工程師 510000 廣州

城市軌道交通信號系統的專業接口多而復雜，特別是與牽引供電的接口，一旦設備出現故障，在人機交互界面 (HMI)上就會顯示錯誤的供電信息，給線路的正常運營造成不便。本文在介紹信號與主控牽引供電接口原理的基礎上，詳細講述了廣州地鐵3號線處理牽引供電信息系統故障的方法及步驟。

1 信號系統與主控系統接口

信號系統與主控系統的接口在車站控制室和控制中心。在車站控制室，為車站行車值班員進行“緊急停車/扣車/放行”操作提供接口;在控制中心，ATS子系統通過以太網接入主控系統的中心交換機，接口類型一般為IEEE802.3 10/100BASE-TX以太網 (一主一備)，協議類型為TCP/IP。高層協議由主控系統統一提出。廣州地鐵3號線采用MODBUS協議，信號系統負責進行通信規約和接口的轉換，以滿足數據傳輸的要求。

信號系統為主控提供:運行時刻表、實時的列車位置及識別號、列車實際的區間運行時間或阻塞、旅客向導等信息。主控為信號系統提供:牽引供電、火災報警、實際客流及客流統計報告、對信號與主控之間的通道檢測等信息。

控制中心信號系統與主控系統接口為各種信息的傳輸提供了通道，即各種信息的硬件傳輸通道是相同的。對于非事件觸發且傳輸不頻繁的數據，采用FEP協議，而對于有事件觸發或者傳輸比較頻繁的數據，采用MODBUS TCP/IP協議。同時，由同一種協議傳輸不同類型的數據，采用不同的功能碼加以區分。

2 MODBUS TCP/IP協議

主控系統的FEP配置為主機，信號系統的DL工作站配置為從機，主機每500 ms向從機發送一次輪詢報文。MODBUS TCP/IP協議的報文格式包括報頭、功能碼和數據3個部分，如圖1所示。其中報頭包括:①2個字節的報文序列號，例如0X0B 0X40表示第0X0B40=2880條報文;②2個字節的協議標志，恒為0X00 0X00;③2個字節的長度標志，以字節計，表示自單元標志開始的數據長度，例如0X02 0X53表示其后有0X0253=595字節數據;④1個字節的單元標志，恒為0XFF。

圖1 MODBUS TCP/IP協議的報文格式

從機報文的報文序列號、協議標志和單元標志是從主機拷貝的。功能碼為1個字節:0X04表示讀輸入寄存器，即主控FEP讀取信號相應寄存器的數據;0X10表示預置可寫寄存器，即主控FEP向信號相應寄存器寫入數據，寫入的數據其實就是牽引供電信息。每一個寄存器有16位。主控FEP向信號發送報文功能碼后，跟隨有2個字節的讀寫寄存器起始地址和2個字節的讀寫寄存器數量，從而確定了讀寫寄存器的范圍。

3 牽引供電信息的傳輸原理

牽引供電信息通過接口，從主控的FEP傳輸到信號系統的DL工作站，再經過信號系統SRS的處理，最終在HMI上顯示出來。牽引供電信息的傳輸采用MODBUS TCP/IP協議，其信息傳輸的流程如圖2所示。

圖2 牽引供電信息傳輸流程

若信號與主控的鏈接中斷 (一般是信號重啟SRS和DL工作站)，主控會以5 s的周期不斷地發送狀態檢測報文，檢測信號設備的狀態，直到設備狀態正常。該報文請求讀取以寄存器01開始的寄存器數據，即讀取寄存器01的數據。

信號可讀寄存器01的低2位表示信號設備的狀態:01表示數據無效，10表示信號有效。當信號系統接收到該報文之后，如果信號設備準備就緒，將會發送表示信號設備有效的報文，否則發送無效的報文。

當主控系統檢測到信號設備可用之后，將會以500 ms的周期不斷地發送輪詢報文，從信號設備獲取運營信息。典型報文:0X00 0X05 0X00 0X00 0X00 0X06 0XFF 0X04 0X00 0X01 0X01 0XD7表示讀取以寄存器01開始的0X01D7=471個寄存器的數據。

信號系統接收到該報文之后，將會返回主控需要的線路運營信息。如果是第一次接收到該輪詢報文，信號系統會將寄存器02的最低一位置為1，表示請求牽引供電信息，如0X00 0X05 0X00 0X00 0X03 0XB1 0XFF 0X04 0X00 0X00……(功能碼0X04之后的0X00表示字節個數，在此無效，恒為00);否則，該位為0。

主控系統在接收到牽引供電請求之后，將會發送牽引供電信息。該報文將以寄存器0X01F5=501開始的8個可寫寄存器數據預置。

信號可寫寄存器501—508共8個寄存器128個位，每2個位表示一個牽引供電區段的狀態:00和11表示不確定、01表示帶電、10表示掉電。牽引供電區段與寄存器位的對應關系如表1所示。信號系統收到牽引供電信息之后，保存該信息，并在HMI上顯示。如果某一牽引供電區段帶電，相應軌道上不會有顯示;否側，將顯示2條綠色的直線。

信號系統接收到牽引供電信息之后，將返回主控確認報文。

主控系統接收到信號系統返回的確認報文之后，將會立即發送牽引請求復位的報文，復位信號對牽引供電的請求。信號系統接收到該報文之后，將牽引供電請求位置0，不再請求牽引供電信息，牽引供電信息保持不變，直到再次重新連接，或者主控檢測到牽引供電信息改變。

主控系統檢測到牽引供電信息出現更新時，會主動再次向信號系統發送可寫寄存器的報文，將更新的牽引供電信息寫入可寫寄存器。信號系統接收到該報文之后，更新并存儲更新之后的牽引供電信息，同時更新HMI的顯示。

4 牽引供電信息故障的處理

牽引供電信息故障主要是HMI顯示的牽引供電信息與現場情況不一致，包括2種情況:HMI顯示牽引掉電而現場為牽引供電，HMI顯示牽引供電而現場顯示牽引掉電。

表1 牽引供電區段與寄存器位的對應關系

4.1 牽引供電信息報文的閱讀

在處理牽引供電信息故障的時候，需要閱讀牽引供電信息報文。在報文中搜索內容“0X10 0X01 0XF5 0X00 0X08 0X00 0X10”，將其后16個字節的數據轉換為二進制之后，從左到右自上而下依次填入表1所示的牽引供電信息與寄存器位的對應表中，即可得出結論。

4.2 牽引供電信息故障的處理流程

3號線信號維護人員處理牽引供電信息故障的流程及方法如圖3所示。

當出現HMI顯示牽引供電信息與現場不一致時，立即查看MODBUS報文，找到最新的由主控發向信號系統的牽引供電信息 (寫入可寫寄存器)報文。需要注意的是一定要找到最新的供電信息報文，因為HMI是根據最新的牽引供電報文顯示牽引供電信息的。為此，可從文件最底端向上搜索，若未找到，繼續查看上一個文件，依次類推。

軌道區段與寄存器位的映射關系:軌道區段→供電區段編號→寄存器位。

1．牽引供電區段與軌道區段的對應關系可查看相關工程圖紙，以便得到故障區段的牽引供電區段編號。

2．找到最新的牽引供電信息報文之后，依據該供電區段編號，按照上述方法閱讀報文得到故障牽引供電區段的牽引供電信息 (00、01、10、11)。

圖3 3號線信號維護人員處理牽引供電信息故障的流程及方法

3．將報文的信息與HMI顯示對比即可判斷報文信息與HMI顯示是否一致。如果報文信息與HMI顯示不一致，則證明是SRS或者DL工作站軟件出錯，可待運營結束之后，重啟SRS和DL工作站。若未恢復則重裝SRS和DL工作站軟件。若還未恢復則證明故障原因為軟件缺陷，需聯系供貨商升級軟件。如果報文信息與HMI顯示一致，則故障原因可能是信號與主控連接中斷或者主控專業問題。此時可以分別在2個DL工作站上ping主控FEP的 2個 IP地址 192.168.70.11和192.168.70.12。若能夠ping通 (有一條鏈路ping通就行)，則證明信號與主控鏈接正常，故障原因在主控一方，通知主控人員檢查其設備;若不能ping通，則證明信號DL工作站到主控FEP的鏈接中斷，聯系主控人員一起檢查并恢復鏈路。

5 結束語

本文從系統需求、軟硬件的設計和實現方面，詳細講述了廣州地鐵3號線ATS與主控關于牽引供電信息的接口，以及信號方面關于牽引供電信息故障的處理流程和方法，可為城市軌道交通信號關于接口的設計、施工和維護提供參考。

［1］ 王長林，林穎.列車運行控制技術［M］.成都:西南交通大學出版社，2006.