軌道交通中無線調度子系統的問題研究

李石鳳

南京地鐵運營有限責任公司

摘要：無線調度子系統為地鐵無線重要的用戶系統，是行車的關鍵部件，主要由調度服務器和調度臺組成。調度子系統向中心調度員提供功能強大的調度指揮功能，是地鐵運營指揮的主要操作平臺，經過二次開發后，調度子系統除能實現TETRA集群系統標準的調度功能外，還增加根據用戶要求定制的功能。本文重點研究調度子系統的組成及使用過程中出現的疑難問題，為系統維保提供技術支持，為故障提供解決措施。

關鍵詞：原裝調度臺;二次開發調度臺;心跳包;TETRA無線通信系統

一、系統概述

調度子系統包含二次開發部分和無線原裝部分，二次開發主要是調度服務器和調度終端;原裝部分主要調度終端MC7500C和相關配件。

南京地鐵的調度子系統包括互為備份的調度服務器和多個調度臺，根據用戶功能分為總調度臺、行車調度、維修調度、環控（防災）調度和車輛段調度。

調度服務器為高端的機架式服務器，該服務器上配置有windows服務器操作系統和SQLServer專業數據庫及二次開發的調度服務器軟件。

調度臺的硬件包括Motorola的MCC7500原裝調度臺、二次開發調度臺主機（即每個調度臺包括兩臺計算機主機）、1套計算機標準配件（顯示器、鍵盤和鼠標）、1套音頻附件（MIC、揚聲器和腳踏PTT）。每個調度臺配置一套簡易KVM切換設備，用戶通過該設備操作控制二次開發主機和MCC7500主機。每套調度臺的硬件配置都是一致的，但每個調度臺的用戶權限是不一樣，通過用戶名和密碼區分。調度用戶的管理對象（如通話組、電臺、車站等）由系統管理員進行設置，可以根據需要為調度用戶靈活設置管理對象。只有合法的調度用戶才能登錄調度臺軟件，如果用戶輸入錯誤的用戶名和密碼，調度臺軟件將彈出出錯提示框。

調度臺是用戶進行調度運行指揮的主要操作平臺，用戶可以通過它對系統內的列車司機、車站值班員以及手持臺移動用戶發起各種呼叫，或者接收它們的呼叫，以建立與這些用戶之間的語音和數據通信。

二、問題研究

地鐵運營多年，調度子系統發生過多起故障，影響范圍大，故障處理的時間也較長。下面針對調度子系統出現的典型問題故障進行梳理分析。主要有以下兩類問題：

（一）調度臺注冊鑒權失敗

運營初期出現多次二次開發無法啟動的現象，大多為原裝主機沒有正常啟動，重新啟動硬件或軟件即可恢復。但有次問題比較典型，二次開發和原裝臺重啟，重裝都不能正常啟動。

調度臺問題現象為行調1（原裝10.142.116.7加二次開發192.168.11.122）控制臺燈顯黃，顯示調度臺鑒權失敗無法注冊。

排查過程：第一步二次開發主機與原裝主機通過IP進行ping通測試，數據正常，沒有延時，確認兩者網絡通道是正常。第二步使用行調1的xd1用戶名登錄無線調度臺備件（原裝臺10.142.116.2和二次開發192.168.11.127），行調1的用戶名可以正常使用，說明用戶名和密碼是正確有權限的。由此判斷調度大廳行調調度臺軟件系統可能有問題。

使用無線原裝調度臺備機（OP210.142.116.2）替換調度大廳原裝調度臺（OP710.142.116.7）并修改IP地址為（10.142.116.7），復制心跳包“cram.ior”軟件仍無法正常登陸。把有問題的原裝主機（OP710.142.116.7）替換為OP2（10.142.116.2）。重新啟動原裝臺數據庫，開啟四個進程;開啟原裝臺監控軟件，通過用戶名ConUser2和密碼motorola開啟原裝臺調度軟件;發現監控軟件可以監控原裝臺調度軟件的啟動和運行;接著把原裝臺的心跳包拷入二次開發主機;并把二次開發調度臺中windows/Systems/drivers/etc的“host”IP地址改成一對一映射。啟動二次開發的DPH程序后，發現依然登錄不上去，與初始的故障現象一致;但遠程連接原裝臺監控軟件ManagerMonitor上有數據顯示，顯示二次開發調度臺調用的原裝臺的鑒權用戶名為ConUser2和密碼ConUser2，而實際上OP2的原裝臺軟件的鑒權用戶名為ConUser2，密碼為motorola。二次開發數據系統中原裝臺的鑒權用戶名ConUser2的密碼與原裝數據庫中的原裝臺ConUser2的密碼設置不一致，導致原裝臺用戶名ConUser2一直無法被二次開發調度臺調用。在原裝網管UCM軟件中更改用戶名ConUser2鑒權密碼由motorola改為ConUser2，二次開發調度臺重新覆蓋對應的心跳包，二次開發上顯示控制臺鑒權正常，可登錄。

一套調度臺包含一臺二次開發主機和一臺原裝主機，每臺主機都有對應的IP地址，二次開發主機必須得到原裝臺的合理授權，才可以正常使用。此問題的原因有兩方面：一是新增一套調度臺備機，調試過程中把原裝臺ConUser2的密碼更改，二次開發中沒有對應更改，導致二次開發一直沒法調用原裝ConUser2，即原裝系統內密碼被原裝廠家修改，二次開發調度服務器內未改，并且現場維保人員不知道。二是原裝用戶名與原裝主機的IP對應關系可以靈活對應，不是唯一對應。針對此次問題原因，平時設備調試過程中，要關注細節，涉及的用戶名和密碼需做好記錄，并保證各個數據的用戶名和密碼一致，并告知團隊同事，同時要善于利用原裝調度臺的監測軟件，掌握調度臺啟用的步驟。掌握用戶名和IP的對應關系。

（二）調度臺組信息獲取失敗

運營過程出現二次開發調度臺的車組顯示打叉，及無車組信息，導致調度臺無法與行駛列車通話。查看數據庫核心路由等設備都正常，原裝調度臺與二次開發調度臺和中心設備的網絡通信正常。當有部分調度臺出現這類現象，其他調度臺只要重啟就會出現此類現象，不重啟的話可以正常使用。原裝調度臺自檢發現trunkingsystemstatus狀態為“？”;正常狀態為“√”。

通過自檢軟件DiagnosticCentre連接驗證，發現MCC7500componentsVerification（組件驗證）和Upgradereadiness Verification （更新準備驗證）為Failed狀態。

原裝網管UEM反復提示如下告警：

1、ConsoleSiteControlPath_1116.1：zone15DOWN，NOACTIVITYRECEIVEDDIMETRAZcConsoleSCP：3.4.92.1控制臺站點控制路徑處于斷開狀態，沒有收到任何活動。

2、ConsoleSiteControlPath_1116.2：zone15DOWN，TRANSMITRETRYFAILUREDIMETRAZcConsoleSCP：3.4.92.2控制臺站點控制路徑處于斷開狀態，傳輸重試失敗

3、Redundancyattributeoftheentityhaschanged-UNDETERMINED，LINKDOWN實體的冗余屬性發生變化，未確定連接斷開

MCC7500系列一個調度臺站點與區域控制器建立用于刪除調用和設置的控制會話。活動區域控制器到調度臺組的控制路徑由一個稱為LinkOp的調度臺處理，向系統注冊并分配資源的第一個調度臺成為LinkOp，它是與ZC保持通信的唯一活動控制臺。

調度臺組中，總是有一個在用LinkOp調度臺和一個備用的調度臺（在出現故障時準備接管LinkOp調度臺的責任），其他調度臺保持非活動狀態（此處活動是指與ZC的通訊）。所有調度臺通過LinkOp調度臺將其消息發送到ZC，但所有調度臺都能夠通過多播接收ZC消息，除了與ZC通信外，還交換聲音信息，以確認各自的正確操作。當LinkOp調度臺發生故障時，其余的調度臺都知道，備用調度臺變成在用的LinkOp調度臺，轉換時間需要約10秒。

LinkOp即調度臺組與區域核心的邏輯連接，正常有兩個邏輯連接，此模式稱為路徑多樣性。控制路徑是創建的邏輯鏈接，以方便區域控制器與MCC7500系列調度臺組通信。控制路徑為冗余模式：活動路徑和備用路徑。

因之前所有的控制臺都正常注冊和使用，故障時，兩條控制通道處于斷開狀態，導致原裝調度臺注銷之后再登錄，無法獲得ZC全部的資源信息，導致原裝控制臺某些監測不過關。

MCC7500C調度控制臺提供一套應用程序編程接口（API）供二次開發廠家使用。它可供第三方接口通過計算機輔助調度（CAD）系統連接非摩托羅拉其他調度臺，使之與摩托羅拉MSO系統通信。本線路使用的二次開發設備為五十四所的，即通過API接口兩者獲得聯系。

摩托羅拉MCC7500C調度控制臺允許其他軟件應用程序監視和控制其應用軟件。它是通過應用程序接口（API）完成的。API可以支持多個應用程序同時訪問它們的，API可以同時服務調度控制臺用戶界面和第三方應用程序，必須通過CAD系統協助。有三個API可供希望通過調度控制臺訪問無線電系統特性和功能的第三方使用。

控制臺調度接口API

控制臺調度接口API是一組函數或消息，用于全面管理和維護軟件應用程序與調度系統之間的連接。此API中定義的函數和消息：允許應用程序在控制臺系統中注冊和注銷。只有注冊的應用程序才允許與控制臺功能API接口。本故障過程過程，二次開發調度軟件和原裝調度軟件都可以登錄。故控制臺調度接口的API可以正常使用。

資源配置API

資源配置API是一組用于檢索與調度系統相關的配置和別名信息的函數。配置信息包括：系統中資源列表（通話組或通播組）;系統中每個資源上可用的容量及特征列表。別名信息通常指：用戶無線電單元ID（例如，單元6118301=“泰山新村組”）;單元用戶狀態，（例如，狀態7=“現場”）。配置和別名信息是通過系統網絡管理子系統輸入的。本故障現象顯示當時資源配置API出現問題，各通話組的信息二次開發調度臺讀取不到。

控制臺功能API

控制臺功能API是一組功能消息，允許實時監控和控制摩托羅拉調度通信系統。此API中定義的函數和消息用于：1監視系統中的呼叫活動;2向用戶單元發起語音和數據通信。

本次故障時原裝臺和二次開發調度臺的組信息都處于打叉狀態，因原裝臺無法獲得ZC的全部資源，原裝臺信息不全，從而導致二次開發調度臺無法從原裝臺的API獲取組信息，從而導致故障現象，所有的通話組都處于打叉的狀態。即故障點集中在原裝調度臺與ZC之間的通訊。原裝臺與ZC服務器之間的通信是通過核心交換機相連。分析交換機的VLAN配置，發現VLAN16為調度臺的網段。夜間34端口（接的總調調度臺）出現反復離線狀態。最終處理的措施是斷開此局域網段內所有調度臺，重新連接，并重啟調度臺恢復。結合后續故障及資料分析，發現當某個調度臺短時間反復重啟10多次之后，會出現此類組信息打叉的現象，故推測是此類行為被ZC認為有病毒攻擊，激發系統高級行為阻塞，導致LinkOp調度臺至ZC控制的兩條邏輯鏈路處于幾乎斷開狀態，調度用戶可以登錄，但是沒法獲得資源組信息，導致原裝調度臺也沒有資源組的API信息給二次開發。

三、總結

本文重點介紹調度子系統的硬件組成及兩個典型的問題的分析。調度子系統是硬件相對集成簡單的系統，軟件比較復雜，平時維保過程要善于利用監控軟件ManagerMonitor和診斷軟件DiagnosticCentre及原裝的UEM軟件掌握調度后臺軟件所處的狀態，處理故障。平時維保過程中，禁止局部更改調度臺的密碼，導致二次開發和原裝系統的配置不統一;掌握調度臺問題的典型現象及處理措施，便于應急處理，同時也要善于分析告警日志，進行預防性維修。