孫 斌
(北京鐵城建設監理有限責任公司 北京 100855)
綜合監控系統作為城市軌道交通體系的重要控制系統,是保障城市軌道交通安全運營的基礎內容,行車指揮則是綜合監控系統的重要發展方向。 考慮到我國各個省會城市開展大規模的城市建設,城市軌道交通建設與控制將會成為省會城市未來發展的重要研究話題,有必要行車指揮下的城市軌道交通綜合監控系統技術展開詳細分析。
在21 世紀初,我國超一線城市為提升城市發展活力,擴大交通系統運行能力,開始建設大規模的城市軌道交通,以電力調整與環境調整為設計核心的綜合監控系統設計方案,是當時主流設計思路。 其本質是環境與設備監控系統(building automation system,BAS)與電力監控系統(power supervisory control and data acquisition,PSCADA)的組合設計。 在城市軌道交通綜合監控系統實際運行中,會和閉路電視、乘客導向、列車自動監控系統(automatic train supervision,ATS)等功能系統進行數據交互。 受限于當時的綜合監控系統技術局限性,功能系統的數據交互的行為本質上只是由綜合監控系統單方面向功能系統提供例如硬件設備工作狀態等數據信息。 隨著城市快速發展,城市軌道交通需要處理海量的數據信息,以電力調整與環境調整為設計核心的綜合監控系統已經無法滿足現階段的綜合監控系統的云應用需求。 而有關城市軌道交通綜合監控系統的各類應用技術在近些年得到快速發展,為供電、機電等機械設備提供更可靠的信息化管理條件,可以探索綜合監控系統的信息化升級,實現綜合監控系統數據的統一化管理。 根據城市軌道交通的運行需求,在人機交互界面實現統一化操作,是當前城市軌道交通綜合監控系統技術創新與實踐的重要研究方向[1]。
2.1.1 城市軌道交通綜合監控系統運行需求
對于城市軌道交通綜合監控系統的設計思路,需要分析現階段的城市軌道交通運營管理真實需求。 多個功能系統協同合作,即多系統聯動,是保障城市軌道交通綜合監控系統穩定運行的核心內容,即在綜合監控系統設計中,需要保證可以順利實現聯動功能。 可以根據現階段城市軌道交通的運營管理規章制度,設計在不同條件的運營場景需求。 比如在啟動城市軌道交通運營系統后,需要進行一次全系統的自檢作業,包括BAS、PSCADA、ATS 等都需要以報警態的方式進行自檢。 通過檢查后,再對信號系統、供電系統、火災信息等進行詳細檢查,如果出現報警信息,需要及時將問題信息發送至人工調度臺,由調度技術人員采用人工方式進行處理,并對當天的城市軌道交通運營計劃部分細節內容進行調整。 判斷當天是正常工作日、節假日或其他日期,選擇相應的時間模式,確認具體的城市軌道交通綜合監控系統運行數據。 在完成各種機械設備的自檢后,正式開啟城市軌道交通。 可以認為,城市軌道交通的運營管理主要涉及早間開站、晚間關站兩個重要時間節點,以及正常運營與異常運營兩種運營情況等內容。 在對城市軌道交通運營場景進行分析后,可以發現城市軌道交通核心為運輸,涉及作為運輸目標的人,以及作為運輸載體的車。 在車輛運行過程中,需要通過信號系統進行有效指揮,為車輛安全運行提供安全保障。 而ATS系統可以為調度技術人員、值班人員提供當前車輛運行狀態的數據信息,可以讓城市軌道交通運營獲得更為強有力的技術條件,在設計城市軌道交通綜合監控系統時,需要將ATS 系統進行合理應用。
2.1.2 城市軌道交通綜合監控系統設計內容
在大量的數據分析、國內外城市軌道交通綜合監控系統對比中,許多優秀設計內容都是將行車指揮作為綜合監控系統的核心內容使用。 在對城市軌道交通綜合監控系統進行設計時,可以在保持中心、車站、現場三級控制模式,以及中心、車站兩級管理模式的原設計基礎上,針對中心級機械設備與核心級機械設備的相互關聯展開相應分析。 對于中心級機械設備,涉及實時服務器、包含磁盤陣列的歷史服務器、信號通信前端處理器(front end processor,FEP),以及若干的工作站;對于核心級機械設備,涉及服務器、信號通信FEP、綜合監控FEP,以及若干的工作站。 對于中心和車站通信模式,使用獨立光纖+以太網,構成工業級別的以太環網組網模式,滿足數據信息的快速、精準傳輸[2]。
2.2.1 方案實施基礎內容
對于城市軌道交通綜合監控系統技術方案實施,可以細化為軟件系統與服務器兩個方面。 對于軟件系統,考慮到在以往使用的綜合監控系統平臺軟件,是以UNIX 系統作為設計工具,ATS 軟件是以操作系統作為設計工具。 為合理提升城市軌道交通綜合監控系統的后期維護效率,需要對綜合監控系統的核心系統進行平臺移植,全部以操作系統進行設計。 對于大量機械設備的操作界面,也采用統一化處理,結合相應的數據庫融合,實現綜合監控系統功能的有效整合。 由此生成的數據總線開發需求,也采用重新開發設計方案,讓數據總線可以適配于城市軌道交通綜合監控系統;對于服務器,在原本的城市軌道交通綜合監控系統設計中,采用1+1 模式的配置模式,即使用兩套實時服務器,以一套使用一套備用的方式,保障綜合監控系統的穩定運行。 而在之后的設計中,可以開源整合成一套實時服務器的配置模式,采用云端服務器+檢測數據實時化分析,降低實時服務器的運行時間成本,從而突出城市軌道交通綜合監控系統的行車指揮核心功能[3]。
2.2.2 城市軌道交通綜合監控系統基礎邏輯
對于城市軌道交通綜合監控系統基礎邏輯,可以劃分為以下幾個環節:第一環節、在啟動城市軌道交通綜合監控系統后,列車正式開始運行,針對列車是否正點運行的運行狀態進行分析。 如果列車的偏離程度小于預設水平,則由綜合監控系統自動調整,讓列車恢復到整合運行狀態。 如果列車的偏離程度大于預設水平,則由調度技術人員進行人工控制;第二環節,乘客信息系統(public address system,PIS)/公共廣播系統(passenger information system,PA)系統發布單次列車到站相關信息。 在此過程中,需要判斷供電區域的工作狀態,通過電力調整與環境調整顯示進行輔助分析。 對于調整列車的運行狀態,通過PIS/PA對車站內的乘客進行疏導,利用PIS/PA 對列車內的乘客進行提醒,啟動BAS 阻災模式。 如果綜合監控系統無法有效判斷,仍然由調度技術人員作人工控制。 對于列車到車站之間的區間障礙物,與供電區域判斷模式相仿,但是需要額外增加閉路電視(closed circuit television,CCTV)切換功能與遠程控制(remote control,RC)切換功能,確保列車與乘客的安全。 由調度技術人員負責做二次處理另外還有信號故障、車輛故障、地面火災、列車火災等判斷需求,參考列車到車站之間的區間障礙物進行判斷[4]。
2.2.3 方案實施效果
將本文設計的城市軌道交通綜合監控系統應用到某超一線城市的城市軌道交通線路后,經過當地交通委組織竣工驗收,正式開始試運營。 經過近十年的運行分析,該條線路先后經歷二期車站、二期車輛段的接入,線路控制中心遷移,西延車站接入等多次線路層面的調整,當前負責三十余座地下車站,以及兩座車輛段與一座停車場的監控控制。 每天處理百萬級別的客流量,為六十余列城市軌道交通提供運營指揮需求。 在大量的運行數據分析中,可以發現該條線路在采用本文設計的綜合監控系統后,平均無故障時間遠超過以往采用的電力調整+環境調整的綜合監控系統平均無故障時間。
我國現階段的城市軌道交通綜合監控系統技術,需要花費較多的資金,采購進口服務器,購買相應的服務器平臺系統,才能保障城市軌道交通的安全運營。 本文以三級控制+兩級管理模式為基礎,設計的綜合監控系統可以大幅度降低軟件系統的開發支出,降低硬件設備的采購成本,仍然無法處理進口服務器與平臺系統的資金成本問題。 我國近些年計算機技術得到發展,以云平臺技術為主的各類新興技術逐漸從研發領域步入生產領域,已經成為各個領域的重要生產工具。 可以考慮將云平臺技術與城市軌道交通綜合監控系統進行融合,逐步擺脫對于進口服務器平臺系統的技術依賴,也可以探索綜合監控系統未來發展方向。 在分析國內外的研究內容后,可以從橫向、縱向兩個方向,開展云平臺技術應用的相關研究。
在城市軌道交通綜合監控系統中應用云平臺技術,可以為前者提供大量的計算資源。 如何合理應用云平臺技術帶來的計算資源,提升城市軌道交通運營管理綜合質量,則是應用云平臺技術需要處理的重要內容。 現階段城市軌道交通綜合監控系統采用的分離化軟件開發模式,不再匹配云平臺技術在硬件資源高效利用方面的實際需求。現階段的云平臺技術應用理論,是由城市軌道交通綜合監控系統的各個子系統提出有關資源調用的具體需求,由云平臺技術利用虛擬化,設計虛擬中央處理器與虛擬內存,向各個子系統合理分配相應的計算資源[5]。 意味著分析運行表現,云平臺技術是一種硬件資源的運行模式。 而在功能本質層面上分析,云平臺則是由若干具有相對獨立性質的虛擬硬件構成的虛擬硬件組。 相比以往的硬件集群模式下的冗余服務器部署方法,硬件虛擬化的云平臺技術部署,可以極大降低設計硬件使用數量,有效提升城市軌道交通綜合監控系統的設計與改造經濟效益。 針對云平臺技術的橫向軟件系統信息互通需求,可以考慮從以下兩個方向進行合理解決:方向一,建設一個軟件平臺,將城市軌道交通綜合監控系統的各個子系統轉化為功能模塊,以模塊形式在軟件平臺上進行運行。 對于建設的軟件平臺,主要負責與云平臺技術的云管理系統進行技術層面的聯動與數據層面的整合,確保兩者的有效融合,并根據各個子系統的運行需求,以動態化的方式,對計算資源做合理分配。 通過此方式,可以讓軟件平臺明確各個功能模塊的真實計算資源需求,又可以讓計算資源得到科學分配,以此實現云平臺技術的計算資源有效管控。 方向二,保障城市軌道交通綜合監控系統的各個子系統軟件擁有相對獨立特性,讓各個軟件和云管理系統做必要的信息交互處理。 對于信息交互的內容,涉及計算資源需求、計算資源劃分等重要信息。 對于云管理系統,則以各個軟件發出的各個子系統對于計算資源的真實需求,做相應的計算資源分配、回收等基礎管理工作。 如果出現資源分配或回收沖突問題,云管理系統也需要與涉及的子系統軟件進行相互交互,實現城市軌道交通綜合監控系統的高效率管理[6]。
縱向系統架構優化升級與橫向軟件系統信息互通具有相對關系,但是在實際應用中,需要謹慎考慮。 特別是在城市軌道交通綜合監控系統原有的硬件架構仍然處于正常運行狀態下,直接升級成匹配云平臺技術使用需求的硬件架構,需要對優化升級的必要性做合理分析。 針對本文設計城市軌道交通綜合監控系統底層邏輯基礎的中心、車站、現場三級控制模式,可以通過云平臺技術的計算資源優勢,對控制模式下的運行體系進行調整。 因為在當前運行體系下,會在監控系統中心、各個車站設置許多服務器,不僅存在較大的服務器維護工作量,而且維護工作也具有較大的分散性,在一定程度上增加城市軌道交通綜合監控系統的整體運行維護成本[7]。 將云平臺技術應用到城市軌道交通綜合監控系統后,可以對中心服務器做相應的整合處理,并將各個車站的服務器設置計劃取消掉。 而且,云平臺技術還可以有效提升通信傳輸系統的最大容量,可以根據當地經濟條件與城市軌道交通的發展情況,設置專用于綜合監控系統的大容量數據傳輸網絡,滿足數據傳輸的需求。 同時,做好邊緣計算的強化工作,提升縱向系統的數據計算性能,提高機械設備的運行安全性。 通過云平臺技術,可以對城市軌道交通綜合監控系統的縱向層級做簡化處理,并將原本分散在各個車站的服務器做集中化處理,由控制中心的服務器提供整條線路的綜合監控系統運行需求,進而有效降低服務器的維修管理時間成本,合理控制各類機械設備的維修周期。 而且,大容量數據傳輸網絡也可以取代原本的骨干通信網,讓云平臺起來可以與計算單元產生直接聯系,不再需要常規的中心服務器—骨干通信網—車站服務器—計算單元的冗余信息傳輸模式,進一步降低數據信息傳輸的時間成本,避免出現數據信息損失問題。
通過橫向信息互通+縱向結構優化的雙重設計,可以極大發揮云平臺技術的海量數據計算性能,讓城市軌道交通綜合監控系統實現技術層面的升級與優化。
綜上所述,在開展城市軌道交通綜合監控系統技術創新工作時,除參考本文提供的基礎理論內容外,也可以根據城市當前經濟條件與未來發展需求,合理吸納有關云平臺技術內容,實現綜合監控系統的長期優化。 在應用云平臺技術后,需要將城市軌道交通綜合監控系統技術的應用重心轉移到軟件系統定期更新、硬件設備科學維護等方面,確保城市軌道交通的穩定運營,為地區經濟發展提供良好的基礎條件。