高速鐵路調度集中基礎服務平臺的設計與實現

劉 雋，李士祥，朱艷軍

(中國鐵道科學研究院集團有限公司通信信號研究所，北京 100081)

調度集中是調度中心(調度員)對某一區段內的信號設備進行集中控制、對列車運行直接指揮、管理的技術裝備[1]。中國高速鐵路調度集中系統(簡稱“CTC系統”)是綜合了鐵路信號、通信、運輸等專業技術和計算機、網絡等現代信息技術，采用智能化分散自律設計原則，以列車運行調整計劃為中心，以車站運行線路信息與相關管理細則為約束條件，兼顧列車與調車作業流程，高度自動化、智能化的調度指揮系統[2-4]。

CTC系統核心的分散自律設計原則是指將整個系統的目標和任務事先按一定的方式分配給各子系統，然后由子系統間通過數據通信進行信息交換和相互協調，獨立完成目標或任務，實現了設備分散，功能分散，風險分散，同時提高了系統的可擴展性，便于對系統進行重構，實時地動態分配與管理系統，以適應不同的線路和環境要求[5-6]。

CTC系統屬于企業級綜合性業務系統，包括信息管理和實時控制兩部分，即“管控結合”類型的計算機應用系統[7]。CTC中心子系統包括數據庫服務器、應用服務器、接口服務器等服務器設備；調度員工作站、助理調度員工作站、綜合維修工作站、計劃員工作站等用戶終端設備。CTC車站子系統包括車站自律機、車站服務器、車務終端、電務維護終端等設備[8]。終端、服務器上運行了相應的軟件，眾多軟件、硬件分工協作，共同構成了CTC系統網絡。為確保能夠7×24 h不間斷運行，CTC系統在主要設備上采用了雙機熱備結構，即每一種主要終端或服務器都由2臺計算機組成，且軟、硬件的配置保持一致，它們以主、備用機的形式作為一個整體對外提供計算服務[9]。同時，CTC系統通過多種接口形式與其他相關系統進行調度信息的實時共享。

從上述功能與結構上看，無論終端還是服務器軟件，都要實現通信、雙機同步、主備裁決等基本功能。為降低設計和開發工作量，優化軟件架構，提高執行效率，實現代碼復用，CTC系統采用了企業級應用系統常用的分層架構。分層架構(Layered Architecture)是指將應用邏輯分解為不同的層。每一層中的組件處于一個特定的抽象層次上，在本層內保持內聚性，對其下各層保持松耦合性。分層架構體現了“職責分離”的思想，對相應的職責進行分組，有助于提高系統的可理解性和可維護性[10-12]。

CTC系統分層架構的底層是分布式的“基礎服務平臺”，在CTC系統的每一個終端、服務器上都部署基礎服務平臺的節點軟件，在基礎服務平臺之上構建終端和服務器應用軟件；由基礎服務平臺實現通信、雙機同步、主備裁決等基本功能，并以服務的形式提供給上層的應用軟件；應用軟件在基礎服務平臺的支持下，專注于進行調度業務邏輯的處理及調度業務信息的集中展現。圖1表示了CTC系統分層架構中軟件在各層中的部署情況。

圖1 CTC系統的分層架構

多智能體(multi-agent)技術主要用于系統的控制決策，其目標是讓若干個具備簡單智能卻便于管理控制的系統能通過相互協作實現復雜智能，使得在降低系統建模復雜性的同時，提高魯棒性、可靠性、靈活性。因此，幾乎所有涉及智能推理、規劃決策、協同控制等領域的相關問題均可以通過多智能體技術來處理[13]。近年來，多智能體被引入到列車運行控制研究領域，例如，文獻[14-17]將多智能體技術應用于列控系統的建模與仿真研究中，文獻[18]關注多智能體技術在列車追蹤運行方面的運用，文獻[19]采用多智能體技術設計聯鎖系統的框架，文獻[20]描述了多智能體技術在客運專線運營調度系統上的應用。但未見將多智能體技術應用在CTC系統設計方面的相關文獻。

因此，在分析CTC系統對基礎服務需求的基礎上，提出基于多智能體系統架構的基礎服務平臺設計方案，將智能體方法和面向對象分析與設計方法相結合，進行系統分析與建模，通過軟件設計模式、多線程等技術確保基礎服務平臺能夠滿足可擴展性、可靠性等方面的要求。

1 基礎服務平臺的功能需求

1.1 通信功能

由于CTC系統中的各類應用軟件之間，CTC系統與其他系統之間，以及雙機結構中的主備機之間，都需進行大量、實時的信息交換，基礎服務平臺首要的功能就是提供多種類型的通信服務[21]。歸納起來，通信類型以及應用范圍見表1。

表1 通信模式匯總

表1中，“本機通信”是應用軟件與基礎服務平臺之間的通信；“內網通信”是CTC網絡內各終端、服務器之間的通信；“外網通信”是CTC與聯鎖、列控、TDCS等系統之間的通信；“雙機通信”是雙機結構中的主備機之間的通信。由于上層的不同類型的應用軟件對通信的需求不盡相同，作為通信服務提供者的基礎服務平臺要能夠靈活、便捷地滿足應用軟件的需求。

1.2 主備裁決功能

由于采用雙機熱備結構，要求運行在上層的應用軟件處于主用或者備用狀態時，內部執行邏輯相同，界面內容一致，但用戶操作權限不同，對外輸出數據有別。應用軟件是否作以主用狀態運行需底層平臺向它們發出主備狀態命令，因此，基礎服務平臺應具備對雙機系統的主備狀態自動裁決功能。

1.3 狀態監測與報告功能

主備裁決的前提是感知每臺計算機當前的工作狀態，這就要求基礎服務平臺能夠對計算機的軟、硬件運行狀態進行實時的監測、匯總，并生成統一的狀態報告。

1.4 上述功能的集成

基礎服務平臺提供的上述各項功能都不是獨立存在的，相互之間具有較密切的關聯，例如，通信服務狀態需要被納入狀態監測的范圍，主備裁決需用到單播通信服務，而狀態報告也是主備裁決必不可少的輸入信息。由此可見，如何將上述功能進行有機的集成也是對基礎服務平臺提出的一項重要需求。

經過對需求的統一整理與分析，得到了基礎服務平臺的各功能模塊之間的結構關系，如圖2所示。

圖2 功能模塊關系

基礎服務平臺的每個節點軟件都應具備上述結構，且在其宿主機上獨立運行，其中各模塊負責內容如下所述。

狀態監測模塊負責對宿主機的軟、硬件運行狀態進行統一監測；

狀態報告模塊負責依據狀態監測結果生成狀態報告，并提供給主備裁決模塊；

主備裁決模塊負責根據本機狀態報告、對等機狀態報告等信息進行綜合運算，裁決宿主機的主備狀態；

通信管理模塊負責建立、管理通信通道，接收、發送信息；

配置管理模塊負責依據平臺節點軟件的配置文件內容，在啟動階段對其他模塊的啟動流程、運行參數統一管理。因此，該模塊以控制流的方式與其他模塊建立聯系。

從需求最終成為實用的產品，需經歷分析、設計、開發、測試等一系列密切相關的過程，這其中要解決的關鍵問題是：首先，要在設計階段確定基礎服務平臺的總體架構，架構決定了平臺的執行效率、安全性以及擴展性，是平臺能否成功的關鍵；其次，要在開發階段明確采用哪些具體的軟件開發技術來實現平臺中的各個功能模塊，這些技術決定了平臺對外提供服務的質量。

2 基礎服務平臺架構設計

依照分散自律設計原則，通過分析雙機結構中基礎服務平臺兩個節點軟件之間，以及每個節點軟件與其他節點軟件之間的關系，可以確定節點軟件應具備以下特點。

自主性：在沒有外界環境或其他節點軟件干預的情況下，平臺中的每個節點軟件都能夠自主地完成其主要功能，例如，配置管理、通信、狀態監測，并且能夠控制其內部的狀態。

社會性：節點軟件能夠主動和其他節點軟件交互，以實現其既定的目標，例如，通信、狀態報告。

被動響應能力：節點軟件能夠感知周圍環境的變化，并且能夠依據一定的規則產生實時響應，例如，狀態監測、狀態報告。

主動響應能力：為實現自身目標，節點軟件能夠主動執行一些操作，例如，主備裁決[18]。

經分析所得的結論是，基礎服務平臺節點軟件的上述特點符合智能體的定義，即“智能體(Agent)是處于某個特定的環境下的計算機系統，該系統可根據自身對環境的感知，按照已有的知識或通過自主學習，并與其他智能體進行溝通協作，在其所處的環境自主地完成設定的目標[13]。因此，完全可以采用智能體方法進行節點軟件的設計。

2.1 基礎服務平臺的智能體建模

利用智能體技術實現基礎服務平臺的首要步驟是確定節點軟件與智能體之間的映射關系。在面向對象分析與設計方法(Object Oriented Analysis & Design)中，對象(Object)被定義為一個計算實體，封裝了一些狀態，可以在這些狀態下執行某些動作和方法，且可以通過信息進行通信，所以對象和智能體有許多相似之處。同時，面向對象方法中廣泛使用的繼承、多態、泛化、組合等技術，可以有效提高系統設計與實現的效率和可靠性[20]。因此，在基礎服務平臺的分析和設計過程中，采用了面向對象與智能體相結合的設計方法，并完成了節點智能體的建模，即依照智能體元素(包括感知、動作、目標、計劃、事件、信念)規劃節點軟件功能模塊，以面向對象的UML方法表達功能模塊的關系模型。智能體元素與功能模塊的對應關系如表2所示。

表2 智能體元素與功能模塊對應關系

圖3是節點智能體UML用例。圖3中定義了節點智能體中各個功能模塊之間實際的相互關系，其中，uses代表調用關系，extends代表擴展關系，并用箭頭表明了方向。

圖3 節點智能體用例

與圖2相比，圖3中增加了一個“知識庫”功能模塊，智能體的其他功能模塊都需要通過調用知識庫來完成自身的功能。由于智能體具有自主性、社會性、主被動響應等屬性，因而需要內建知識庫，在運行過程中通過知識庫有計劃指導動作的執行，實現既定的自律目標。目前，知識庫內主要儲備了雙機主備裁決原則、信息流管理規則、信息過濾規則、監測點特征信息、狀態報告算法等知識。節點智能體所執行的任務不同，因此，其內部知識庫內容在整個平臺中是獨一無二的，也就是說平臺中的每個智能體都是唯一的。每一個智能體既要實現自身的服務目標，又要通過與其他智能體的交互，共同實現一個總體目標，這樣它們就以多智能體系統架構方式共同構建了一個完整的分布式基礎服務平臺。

2.2 基礎服務平臺的多智能體架構

由于基礎服務平臺是由多個節點智能體組成，整個平臺就構成了一個多智能體系統。多智能體系統是指：可以相互協作的多個簡單智能體為完成某些全局或者局部目標，使用相關技術組成的分布式智能系統[13]。多智能體系統的研究方法實際是用模擬人類社會系統的運作機制，采用多個智能體進行協作，通過任務分解和任務協調來提高整個系統的能力。同時，通過多智能體之間的合作還可以克服單個智能體知識不完全、處理信息不確定等缺點，因此，多智能體系統是適合于基礎服務平臺這類分布式系統的架構方案。

在多智能體系統中，由于未設置能夠進行全局控制的角色，數據是分散存儲在各個智能體中的，每個智能體內部的運算也是異步進行的，因而，每個智能體所具備的能力和掌握的信息都是不完整的。為達到既定的總體目標，多智能體系統中的每一智能體個體，除前面提到的自主性、社會性、響應能力，還應該具備以下特點。

面向目標性：每個智能體都有一個具體的目標，確保為CTC系統提供可靠、高效的服務。

協作性：一個智能體所需實現的目標只是總體目標的組成部分。對于不同的智能體，它們的目標之間有可能存在沖突，例如，雙機結構中的A、B機都要成為主用機。這就需要智能體之間通過協商的方式來共同實現系統的總體目標。

綜合以上分析，用圖示方法給出基礎服務平臺中各類智能體之間關系與交互內容的架構方案，如圖4所示。

圖4 基礎服務平臺節點智能體之間的交互關系方案

圖4中，宿主機-A、宿主機-B以及在其中運行的應用軟件、節點智能體軟件共同構成了CTC系統中的一套雙機主備結構。圖示內容展現了宿主機內節點智能體與應用軟件之間、雙機節點智能體之間，以及節點智能體與平臺中其他節點智能體之間的關系和主要的信息流內容，箭頭方向代表了信息流向，這是設計智能體模型結構、通信機制、交互原語、協商機制的基本依據。下面根據信息流編號進行說明。

(1)8號信息流表示節點智能體發送給應用軟件的主備狀態命令。

(2)9號信息流是應用軟件發出的心跳信息。

(3)10號信息流是應用軟件之間發送和接收的調度業務數據。

(4)11號信息流是節點智能體從宿主機獲得的運行狀態信息。

(5)12號信息流是節點智能體轉發的調度業務數據。

(6)13號信息流是節點智能體發出的狀態報告信息。

(7)14號信息流是來自其他節點智能體的狀態報告信息。

(8)15號信息流是雙機間的心跳信息。

(9)16號信息流是雙機間的同步數據。

除主要的調度業務數據、雙機同步數據，智能體與應用軟件之間、雙機智能體之間、平臺中的各節點智能體之間通過命令、心跳、狀態報告等信息進行實時、廣泛的通信聯絡，以共同協商、協作的方式，遵從智能體知識庫中內建的規則與算法，實現基礎服務平臺對外提供服務的總體目標。

3 智能體功能模塊的實現

基礎服務平臺的多智能體架構設計屬于系統的宏觀方面，而智能體功能模塊的實現則是具體的微觀部分。

在智能體主要功能模塊的實現過程中，軟件設計模式(Software Design Pattern)、多線程(Multithreading)等軟件開發技術得到了廣泛的應用，并且在軟件擴展性、結構穩定性，以及代碼執行效率等方面起到了關鍵性的作用。

軟件設計模式是為解決軟件開發領域中多種重復出現的經典問題而提出的解決方案，通過對面向對象編程經驗的總結，體現了軟件設計技巧中最重要的方法和原則。不斷變化的需求是軟件設計需要不斷面對的問題，其解決之道就是封裝變化。設計模式通過尋找軟件中可能存在的“變化”，利用抽象的方法對這些變化進行封裝。由于抽象不涉及具體的實現，代表了一種無限的可能性，使得軟件系統能夠以擴展的方式滿足未來的需求變化。

工廠方法(Factory Method)模式通過定義一個用于創建對象的接口，讓子類決定實例化哪一個類。在配置管理模塊中，從配置文件中讀取信息，利用工廠方法依次將狀態監測、狀態報告、主備裁決等模塊啟動執行；在通信管理模塊中，具體的TCP、UDP、SerialPort通信類的實例化操作也是通過工廠方法實現的。

觀察者(Observer)模式定義對象的一種一對多的依賴關系，當一個對象的狀態發生變化時，所有依賴于它的對象都得到通知并自動更新。當以太網卡、串口、應用軟件、通信通道等被監測對象的運行狀態發生變化時，狀態監測模塊是以觀察者模式獲得的狀態變化通知；在通信管理模塊中，當通信對象收到了有效信息，也是以觀察者模式給具體的信息處理對象發送通知。

狀態(State)模式允許一個對象在其內部狀態改變時改變它的行為，對象看起來似乎修改了它的類。主備裁決模塊完全以狀態模式構建，通過不間斷從狀態報告模塊、其他節點智能體獲得信息，對自身所處的環境進行實時判斷，并確定本節點智能體當前應該進入的狀態。

多線程是軟件在運行過程中并發執行多個線程的技術。該技術充分利用了計算機的計算資源，尤其是對中央處理器的時間片使用率進行了優化，因而，能夠提高軟件的整體運行效率，同時也增強了軟件的靈活性。

從表1可以看出，一個智能體的通信管理模塊要應對來自不同通信方向、不同通信方式的信息。為滿足大數據量、實時處理的通信請求，節點智能體中的每個通信通道都分配了至少一個獨立的線程，負責執行數據接收與發送任務，同時還有多個后臺線程負責信息轉發、過濾，以及通信對象狀態監視。

上述兩項技術在平臺的開發過程中并不總是獨立運用的，例如，在主備裁決模塊中，通過設計模式與多線程的融合，最終實現了多線程狀態模式：設置一個獨立的監視線程，負責監視當前狀態的執行情況以及管理狀態之間的切換過程；設置一個狀態執行線程，在監視線程的控制下負責執行具體的當前狀態運算代碼。不同類型技術的綜合運用，加強了節點智能體及整個基礎服務平臺的執行效率與穩定性。

4 基礎服務平臺的應用

基礎服務平臺目前已應用于“高鐵信號綜合仿真測試系統”(簡稱“測試系統”)中，該系統是涵蓋聯鎖、列控、調度集中、無線閉塞中心等關鍵信號安全設備的虛實結合的綜合測試平臺，其設計目標是加強系統間的試驗驗證，優化現場驗證方案，降低施工安全風險。測試系統按照功能可從下到上依次分為：半真實半仿真系統層、真實設備適配層、測試驅動管理層。其中，實物設備包括聯鎖、列控中心、TSRS、CTC、RBC、ATP車載設備、安全數據網和GSM-R網絡設備。基礎服務平臺即位于CTC系統中，實現了調度集中模式下的分散自律控制。測試系統的結構如圖5所示。

圖5 高鐵信號綜合仿真測試系統結構

5 結語

高速鐵路調度指揮是涉及多種業務、多個層次、多項因素，復雜的實時運輸資源調度工作，為確保高速鐵路調度集中系統能夠充分發揮作用，提高調度指揮效能，將分散自律原則的理論研究與具體運用相結合，首次提出了基于多智能體架構的基礎服務平臺方案。其目的在于充分利用多智能體技術解決分布式問題，尤其是其在交通控制方面具有的優勢，提高調度指揮的智能化水平，填補了在CTC設計與實現領域應用多智能體技術的空白。由于全面采用智能體設計思想，結合面向對象分析與設計方法，以及設計模式、多線程等具體的軟件開發技術，基礎服務平臺的開發效率得到了有效提升，平臺的可用性和可靠性也得到了充分保證。本方案已在高速信號綜合仿真測試系統中應用，并得到測試與驗證，將多智能體架構應用于調度指揮系統的構建，并與其他軟件開發技術綜合運用，在實踐中是切實可行的，同時為未來進行智能化調度系統的設計與開發積累了寶貴的經驗。