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

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

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

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

1需求分析與功能設計

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

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

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

1.1現(xiàn)場設備監(jiān)控

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

1.2統(tǒng)一設備維護

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

1.3運行數(shù)據(jù)同步

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

1.4主備中心切換

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

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

1.5工作終端交互

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

2選址設計

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

3主備中心設計

3.1方案比選

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

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

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

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

3.2切換設計

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

4方案實現(xiàn)

4.1系統(tǒng)架構

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

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

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

4.2整體數(shù)據(jù)流實現(xiàn)

ATS系統(tǒng)數(shù)據(jù)流交互包括縱向和橫向數(shù)據(jù)流。在縱向交互方面，包含自下而上的狀態(tài)數(shù)據(jù)和自上而下的運行控制數(shù)據(jù)；在橫向交互方面，主要是各個區(qū)域內各設備之間的數(shù)據(jù)交互。

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

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

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

4.3主備中心切換

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

5總結

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

參考文獻

[1]周公建,滿化錄.北京市軌道交通亦莊線ATS子系統(tǒng)設計[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)解決異地災備數(shù)據(jù)中心選址問題[J].現(xiàn)代電視技術,2022(9):110-114.

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

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

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

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

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

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

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

作者:呂濤 周公建