列車自動監控系統主備中心設計分析

導語：列車自動監控系統主備中心設計分析一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要：呼和浩特城市軌道交通工程首次采用了云平臺統一承載，實現了列車自動監控系統在云平臺上的集成運行。為了確保信號系統入云后，整個系統運行的穩定性和可靠性，設計部署主備控制中心。結合呼市列車自動監控系統主備控制中心的建設要求，分析云平臺上相關的設計需求；提出了一套基于云平臺的主備控制中心的切換方案，并設計了云平臺主備控制中心之間、中心與云外設備之間的數據流向分析。研究完成了主備中心相關功能的實現以及在云平臺上的項目應用部署，解決了業務系統轉為云平臺部署后所帶來問題，為其他軌道交通主備中心云平臺建設提供參考。

關鍵字：云平臺；信號系統；主用中心(MOCC)；備用中心(BOCC)；列車自動監控系統（ATS）

呼和浩特城市軌道交通工程是城軌交通云平臺的試點項目，云平臺作為一個集中式的硬件管理和資源動態分配平臺，上面部署了列車自動監控系統（AutomaticTrainSupervision,ATS）、綜合監控系統(IntegratedSupervisoryControlSystem，ISCS)、乘客向導系統（PassengerInformationSystem,PIS）等一系列生產業務系統，以及企業的辦公管理系統(OfficeAutomation，OA)。云平臺一旦發生故障，將會對眾多業務產生影響。其中ATS系統是最為關鍵的行車指揮系統[1]，一旦其出現故障，整個控制中心將無法執行相應功能，因此異地設置一套獨立運行的備用中心十分必要。同時，云平臺依賴網絡[2]，存在時延和網絡信息安全保護不足的問題。因此傳統的ATS系統設計方案不能簡單地平移部署到云平臺，需要結合云平臺的特點，探討相關部署要求，并對原有系統的功能進行設計調整。本文對整個系統主用中心與異地備用中心（簡稱“主備中心”）的功能需求、系統架構和功能實現等方面進行分析與研究。

1需求分析與功能設計

一般來說，主用中心是軌道交通調度員日常工作的主要場所，備用中心不會頻繁使用，故備用中心的云平臺資源配置可以作簡化處理，基于此進行主備中心需求分析。首先考慮選址問題，主備中心的選址不僅要防范各種可能的風險、滿足云平臺機房的建設條件，還要考慮建設成本，交通的便捷性和專業保障等多個因素，以確保主備中心的選址科學合理。其次，實際業務需求是本次研究的核心，涉及使用、維護和可靠性等多個方面，主要包括：

1）災備需求。一旦主用中心遇到地震、火災等特殊情況，無法繼續履行工作職能時，應立即啟用備用中心執行監控任務，確保運營的連續性。

2）運維需求。當主用中心云平臺需要進行短期整體性維護時，主用中心的工作人員應借助于本地工作終端和備用中心的中央服務器，繼續履行相應職責。為了保證兩個中心可快速平滑切換，并具備實時監控的條件，通過對ATS系統自身功能和數據結構的梳理，細化出以下五點功能。

1.1現場設備監控

主備中心應同時具備實時監視功能，不僅要對線路的列車、軌旁聯鎖設備、軌旁列控設備的運行狀態進行監視[3]，也要對整個ATS系統自身設備運行狀態進行監視。在控制操作上，因為指揮權的專一性要求，只有唯一的中心可以執行行車調度控制功能，所以要避免主備中心同時指揮，以確保最終責任的界定。

1.2統一設備維護

主備中心異地建設，按照傳統設置，需要引入兩個維護團隊，會帶來較大的人力成本。轉到云平臺部署后，維護團隊新增了云平臺管理維護功能，相應的維護工作內容也會進一步增加。為降低維護團隊的工作強度和工作壓力：主備中心需要具備簡潔的維護管理功能，借助于統一界面，實現對兩個中心設備的遠程維護；有了云平臺后，對于個別設備故障，維護人員可以借助于云平臺技術對設備進行遠程修復或者虛擬資源重新分配，大幅縮短故障修復時間。相對于傳統主備中心設置，可維護性得到更好的提升。

1.3運行數據同步

ATS系統包含兩部分數據：一部分是現場設備狀態的數據，兩個中心可以實時獲取，無需兩個服務器之間進行同步；另一部分是主用中心才會產生的列車運行基礎數據，如：用戶管理、計劃運行和列車出入庫數據等。主用中心服務器需要在這些數據產生后，自動同步給備用中心服務器。數據同步速度必須實時，控制在秒級；數據內容也必須正確完整，在同步的過程中需要增加相關的完整性檢查。兩邊服務器的實時正確同步才能確保兩個中心業務切換的連續，對在線列車的運行不產生任何影響。

1.4主備中心切換

1)單一中心設備的自動切換。ATS系統是一個實時監控系統，一旦出現中央服務器的宕機，就可能導致列車無法繼續運行。因此，對單一中心的中央服務器都采用了硬件獨立的雙機冗余部署，按照主機和備機的運行模式進行設計：備機自動監測主機的運行狀態，一旦主機出現宕機或設備工作異常，備機自動升級為主機，替代主機執行監控功能。

2）主備中心設備的人工切換。當主用中心發生云平臺故障或者ATS系統中央服務器雙機宕機故障時，控制權就需要切換到備用中心，啟用備用中心的行車監控功能，切換分兩種情況：一種是主用中心完全無法工作，需要備用中心的人員激活列車監控功能，在備用控制中心進行相應作業；另一種就是主用中心的工作終端和網絡還是可以與備用中心保持正常工作，這種場景下，主用中心的工作終端就可以切換連接到備用中心設備上，激活備用中心控制功能，進行指揮作業。這兩種場景的切換任何時刻都可能發生，切換前后兩個中心的狀態需要保持一致，切換時間需要控制在秒級，切換操作對在線運營的列車正常運行不能產生任何影響。

1.5工作終端交互

為滿足主備中心的設備互為備用的需求，工作終端需要同時連接主備中心服務器：正常情況下，主用中心的工作終端用于行車調度指揮，備用中心的工作終端用于在線培訓或在線維護。當主用中心發生故障情況下，主用中心的工作終端可以切換使用備用中心的中央服務器，繼續進行行車調度指揮。也可以直接安排人員啟用備用中心的工作終端進行行車調度指揮。

2選址設計

呼和浩特運營控制指揮中心是集中設計的基于云平臺的中心[4]，該中心在設計之初就預留了接入整個城市多條軌道交通線路的容量。借助于云平臺強大的可擴展能力，為后續多個線路的接入提前打好基礎。主用中心新建了調度指揮中心大樓，并設計了統一的機房，充分滿足了主用中心云平臺統一機房的建設要求。在備用中心選擇方面：首先，由于備用中心屬于非常用操作地點，考慮建設成本的因素下，其設備可以減配。盡管無需主用中心同樣面積的機房，但也需要充分考慮《GB50174-2017數據中心設計規范》云平臺機房建設的相關要求，能夠支撐備用中心云平臺的建設；其次，備用中心與主用中心在地理位置上需要相距一定距離，確保兩者之間滿足災備要求；最后，需考慮兩個中心的專業支持保障能力，便于工作人員和技術保障人員快速到達。對既有軌道交通線路所有的場所考察后，設計了以下評估因素：建設成本盡量低、建筑空間支持云平臺機房設備部署、物理地址距離主用中心10公里以上、網絡建設與既有線路網絡貫通便捷和工作人員出入交通方便。基于這些因素，借助層次分析法[5]最終評價得出1號線車輛段是軌道公司既有資產，運營成本較低；有足夠的建筑空間,與主用中心地址距離20公里，滿足災備需求，也可防護外部其他故障；同時該地點也與1號線和2號線相鄰，便于云平臺網絡快速實現與2號線網絡互通；車輛段具備專業的技術保障人員，緊急情況需要調配其他專業人員到備用中心工作，也可統一安排通行，確保運營快速恢復[6]；最終確定在呼和浩特軌道交通1號線車輛段建設2號線的備用中心。

3主備中心設計

3.1方案比選

控制中心設備部署主要包含工作終端部署和中央服務器部署兩個方面。首先，在工作人員的工作終端部署方面，盡管云平臺可以完成工作終端設備的虛擬化，也可以提供一套性能簡單的操作終端，簡稱瘦客戶端，其通過云平臺網絡和專用遠程桌面協議完成與云平臺內部虛擬機交互。因為工作終端包含了安全相關的功能操作，瘦客戶端的這種交互方式無法證明相關操控的安全性，故工作終端只能按照傳統定制化選型硬件進行部署。其次，在中央服務器部署方面，存在以云平臺技術為核心和以ATS系統技術為核心的兩種方案。方案1：借助于云平臺技術的動態分配資源和資源熱遷移特性來實現主備中心功能[7]。當云平臺的內部網絡或者計算資源發生硬件故障后，云平臺管理系統實現了故障檢測和資源重新調度的功能，將當前虛擬機計算需求調整到其他硬件資源進行計算，從而提高整體設備運行的可靠性。云平臺支持熱備份，即對在線的虛擬機相關資源進行在線備份。這些備份的虛擬機資源，在云平臺主用中心發生嚴重故障后，借助于維護人員的操作，可以將主用中心備份的虛擬機資源遷移到備用中心云平臺中[8]（簡稱“熱遷移”），重新啟動運行，也可實現主用中心的功能。經過分析，這種方案存在以下不足：

1）需要花費較長的時間才能夠識別設備故障，實時性不高；

2）在對虛擬機資源進行熱備份時，云平臺無法深入到每個業務系統的內部，只能將整個虛擬機資源的數據整體復制，浪費資源的同時也需要較長的時間；

3）云平臺對備份的虛擬機資源熱遷移后再次運行時，系統啟動后會含有部分滯后的信息，可能會給現場在線運行列車發送錯誤的命令。需要維護人員進一步檢查切換后的設備運行狀態，才能投入運營。方案2：借助于業務層的主備同步方案[9]，配合云平臺進行兼容性適配。傳統的設備配置方案包括應用服務器，通信前置機和數據庫服務器等獨立的物理設備。轉為云平臺后，服務器需要運行在云平臺計算單元中，見圖1。主用控制中心云平臺計算單元借助于云平臺的硬件資源部署了冗余服務器，構建了ATS系統強大的后臺計算單元，保障信號系統實時信息收集、計算、分發和存檔等工作。同時禁用云平臺動態分配硬件資源的特性，借助于云平臺資源管理系統，強制將各種服務器分別放在不同的硬件實體上，確保一旦發生單個服務器主機故障或者業務系統自身缺陷導致業務軟件宕機后，業務層能快速感知[10]，無縫切換到物理差異的備用服務器，可解決主用中心各個服務器雙機運行的可靠性問題。考慮到備用中心屬于臨時階段性的使用單元，因此備用控制中心云平臺計算單元采用了單機簡化配置的方式，滿足備用中心可臨時接管整條線路行車指揮的條件。備用中心與主用中心云平臺保持相互獨立運行，這種方案保留了傳統方案主備切換的實時性要求，同時利用了云平臺設備維護的便捷性。缺點是浪費了云平臺既有的資源動態分配的靈活性，也增加了對云平臺資源的消耗。比選上述方案，方案1節省資源，但ATS系統對實時性要求較高，無法使用。方案2雖然浪費了部分資源，但是滿足ATS系統的業務需求。因此，呼和浩特軌道交通2號線的主備中心設計采用方案2設計，通過ATS系統業務自身適配云平臺技術實現主備中心，確保兩個中心的可用性、實時性和可維護性。

3.2切換設計

主備中心設計的核心邏輯是實現兩個中心之間的無擾切換，包含服務器與工作終端的切換和服務器之間的信息同步兩個方面。應用服務器設計上，主用中心與備用中心需要實現同樣的功能，備用中心保持與主用中心狀態同步運行:主用中心各服務器雙機以“主機-備機”方式運行；備用中心各服務器單機以“主機”的方式運行。這種主備中心同時以主機運行的方式屬于雙活設計，都具備對在線列車進行監控的功能；但為了明確兩個中心的指揮權：同一時刻只能有一個中心對全線設備發出控制指令。主備中心業務層面設計了“主用”狀態，任何中心只有在獲得“主用”狀態后，相應的控制指令才可以下發給現場設備。傳統ATS系統主備中心切換方案是主機和備機的切換設計：一個中心的主機故障后，自動切換到備機；一主用中心雙機故障后，自動切換到備用中心服務器。這種設計經常會出現無必要的主備中心控制權自動倒切，也容易產生錯誤的數據同步。比如：在周期性檢修時，維護人員對主用中心雙機設備進行重啟操作后，備用中心將會自動升級代替主用中心。檢修完成后，維護人員需要操控備用中心設備，將控制權切換回主用中心。本方案中，工作人員在對主用中心設備雙機重啟后，在沒有人工授權操作情況下，備用中心不會自動獲得控制權,工作終端自動切換連接到備用中心，提供全線監視功能。等主用中心檢修完畢后，工作人員激活主用中心的控制權，工作終端又自動切換連接到主用中心。所有的檢修工作均在主用中心完成，無需再對備用中心設備進行操作。為了實現無擾切換，主備中心的應用服務器之間更需要保證雙機狀態的實時可靠同步。對于實時信息，主要是軌旁各種設備的狀態，包括列控設備、聯鎖設備、車載設備以及ATS系統設備狀態，由車站設備采集后同時發給主備中心的服務器。這樣主備中心的服務器就能實時獲取相應的信息，無需再在服務器之間進行同步；對于非實時信息，如用戶、系統參數、時刻表和出入庫計劃等信息，只能在具備“主用”授權的服務器上創建，然后借助于高可靠的數據同步協議，同步給另一個服務器。通過這種深入業務系統內部分類的信息同步，從而在有限的帶寬資源基礎上，在控制權切換后，完成兩個中心之間實時和可靠的信息同步，實現兩者之間無擾平滑過渡。

4方案實現

4.1系統架構

呼和浩特2號線的ATS系統是一個橫跨傳統車站信號設備、云平臺計算中心和主用中心控制大廳/車輛段災備控制中心的三層架構，見圖2。

1）車站信號設備作為現場終端節點，采集現場列控設備的狀態和發出控制指令。主要包括車站服務器、車站現地工作站、網關服務器和車站網絡設備等，其中車站服務器和網關服務器是其中最關鍵的節點，這些設備等同于云平臺的邊設備，計算功能比較單一。2）云平臺計算中心包括主用控制中心和備用控制中心兩個獨立的控制中心：主用控制中心的云平臺虛擬機中包括雙套的應用服務器，通信前置機和數據庫服務器；備用控制中心的設備包括單套的應用服務器，通信前置機和數據庫服務器。這兩個控制中心是ATS系統的大腦，負責實時狀態信息和行車計劃調整計算；。

3）主用中心控制大廳和車輛段災備控制大廳的工作終端設備主要是輔助中心云計算節點，提供人機交互操作。在主用中心控制大廳包括多套工作終端，分別用作調度主任工作站、調度工作站和維護工作站等；在車輛段災備控制中心也部署了少數工作終端，分別用作調度主任工作站、調度工作站和維護工作站等；在這些工作終端中，調度工作站是最關鍵的設備，確保ATS系統安全操作的安全性。

4.2整體數據流實現

ATS系統數據流交互包括縱向和橫向數據流。在縱向交互方面，包含自下而上的狀態數據和自上而下的運行控制數據；在橫向交互方面，主要是各個區域內各設備之間的數據交互。

1）縱向自下而上數據流：車站的信號設備一直與聯鎖設備、軌旁列控設備和車載設備進行信息交互，實時獲取當前線路的計軸、道岔、信號機、屏蔽門、軌旁列控、車載和車輛等一系列設備的狀態信息。這些信息同步發送給主備中心的應用服務器，進行緩存和記錄，并同步給當前連接的終端，提供在線監視服務。

2）縱向自上而下數據流：工作人員需要對現場設備進行控制，或者調整當前列車的運行計劃等，這些指令會由工作終端發給連接的應用服務器，經過合法性檢查后，在當前應用服務器內部執行或下發給對應設備所在的車站服務器執行。執行結果，由執行單元借助高可靠的數據通信協議同步發給備用的應用服務器，完成相應的信息同步。如：有授權的主用中心應用服務器接收到創建當天時刻表指令后，會完成新的當日時刻表創建，并同步發給備用中心應用服務器，創建相同的當日時刻表。一旦發生兩個中心之間的切換時，因為其內部信息一致，實時處理產生的結果會保持一致，則不會影響現場設備的運行。

3）橫向數據流：車站服務器執行關鍵信息的處理，也負責與車站聯鎖設備接口；網關計算機負責與軌旁列控設備接口，將獲取的信息經過預處理后發給車站服務器，車站服務器匯合聯鎖設備數據和列控設備數據，統一處理后，發給車站現地工作站和主備中心的應用服務器。在主備中心云平臺中，數據庫服務器負責現場歷史數據和各種時刻表信息的存儲；通信前置機負責實現ATS系統與其他業務系統之間數據交互，如綜合監控，乘客向導等系統交換列車運行、計劃信息等；應用服務器是控制中心的核心，從數據庫服務器存取各種數據，配合通信前置機完成與其他業務系統的信息交互，最為關鍵的就是完成與工作站終端之間的數據交互。數據之間的交互包含云平臺內外數據的交互，也包含不同業務系統之間的交互。這些數據交互需要滿足信息安全等級保護的要求：主備中心云平臺內部，在通信前置機對外接口上部署云內防火墻[11]，實現ATS系統業務與其他系統業務之間數據交互，滿足云內不同業務系統之間信息安全的要求；云內與云外設備之間數據交互，主要是云內的應用服務器與云外的工作終端和車站設備之間的數據交互。云平臺接口交換機和ATS系統云外交換機之間需要各自部署硬件防火墻實現云內外的信息安全隔離。

4.3主備中心切換

主備中心切換實現包含雙機自動切換和主備中心授權切換。雙機自動切換在主用中心內部進行。主用中心內部配備了兩臺功能相同各自獨立運行的服務器，如應用服務器A機和應用服務器B機，一臺作為主機運行，一臺作為備機運行。這兩個設備之間采用設備健康度診斷的方法：備機實時監控主機設備的運行狀態，周期性交換兩臺服務器的健康度診斷結果。當備機發現主機設備故障或者健康度出現降級時，備機自動通知主機退出，同時將自己升級為主機，接管線路運行，保障ATS系統可靠運行。主備中心授權切換是主備中心之間的控制權切換，采用人工授權的方式。根據既有軌道交通調度管理規則，線路的控制同一個時刻只能被一個中心管理[12]。因此，在主備中心“主用”授權轉換功能邏輯見圖3。系統初始化時，授權令牌處于無授權狀態；主用中心工作人員通過圖4工作終端授權交互界面進行操作；發出授權指令后，兩個中心的應用服務器會進行交互檢查，在確認滿足唯一性控制要求后，正式給予授權。同時，工作終端的主備中心圖標將會顯示授權狀態，便于調度和維護人員清晰了解當前授權中心。若此時備用中心人員也嘗試操作授權該令牌，則返回錯誤；若備用中心需要獲取授權，則必須在主用中心釋放該授權令牌后，才可以人工申請。除人工操作之外，主備中心也會實時監控該令牌授權的持續有效性，避免一個中心的應用服務器雙機宕機后，授權令牌無法釋放，進而進入死鎖狀態。當這種雙機宕機場景發生時，授權令牌在一定周期超時后，系統自動復位到初始無授權狀態，等待人工操作授權。

5總結

該主備中心設計方案一方面保留了傳統主備中心設計的實時性和可靠性，實現了主備中心在云平臺上的穩定運行以及相互之間的無擾切換；另一方面，借助于云平臺的虛擬化技術，進一步提升了主備中心設備的可維護性，使得設備遠程維護管理方式更加便捷，借助于云平臺瘦客戶端即可完成ATS系統設備的資源巡檢，遠程重啟和重新部署等一系列的工作，不僅節省了人力，也極大降低了維護成本和工作量。目前該方案已在呼和浩特2號線ATS系統中完成部署，經過一年多的現場實際運行和主備中心倒切測試，充分證明了整個方案設計的合理性和穩定性。在2號線實際運營過程中，僅發生過一次主用中心數據庫故障，調度員及時切換到備用中心，繼續開展行車調度工作，實現了設備遷移，但人員工位保持不變的效果，進一步驗證了本方案可行性，后續將進一步推廣到其他軌道交通項目中。

參考文獻

[1]周公建,滿化錄.北京市軌道交通亦莊線ATS子系統設計[J].市政技術,2010(S2):366-370.

[2]黃龍,張博.城市軌道交通云平臺建設方案分析[J].鐵道通信信號,2020,56(9):76-80.

[3]孫夢劍.淺談地鐵無人駕駛線路主、備控制中心的設置[J].建筑工程技術與設計,2018(24):3511.

[4]呂梅新.淺談云災備管理平臺建設[J].信息技術與信息化,2021(3):53-55.

[5]駱成蹊.使用層次分析法(AHP)解決異地災備數據中心選址問題[J].現代電視技術,2022(9):110-114.

[6]齊麟.地鐵清分中心災備系統設計的幾點建議[J].科技風,2018(10):195.

[7]陳曉,張龍軍.一種雙活云中心災備方案的設計與實現[J].中國新通信,2015(23):110-111.

[8]陳瑞軍,孟偉君,胡曉偉,等.城市軌道交通云平臺容災方案研究[J].城市軌道交通研究,2020,23(9):184-188.

[9]李蘇雯,康進譖,李連成.城市軌道交通通信系統主備用中心切換功能分析[J].鐵路計算機應用,2009,18(5):45-48.

[10]周公建,袁汪凰,李建彬.ATS系統動態時間同步方案研究[J].鐵道通信信號,2021,57(10):86-91.

[11]魏喜蓮.云數據中心網絡安全設備部署研究[J].鐵道通信信號,2021,57(4):41-47.

[12]孟娜娜,王志心,嚴海鑫.綜合監控系統主備控制中心切換功能分析[J].江蘇科技信息,2022,39(25):59-61,69.

作者:呂濤 周公建