城軌信號系統云平臺RAM指標分析

徐 偉，張德明，宋 欣

目前，城市軌道交通行業正在加速轉型，從10年前的單線建設進入到線網建設，從運營地鐵到經營地鐵，從功能出行到智能出行。信息化建設也已進入到大規模開發和應用階段，云計算、大數據等新一代信息技術在城市軌道交通行業逐漸得到廣泛應用。為推動我國“互聯網+城市軌道交通”戰略，遵循《中國城市軌道交通智慧城軌發展綱要》，2021年中國城市軌道交通協會發布了《城市軌道交通云平臺構建技術規范》。本文針對云平臺和信號系統ATS深度融合涉及的RAM指標進行計算分析，為信號系統上云提供依據，對推動城市軌道交通行業信號系統數字化、智慧化轉型升級具有重要意義。

1 云平臺

云平臺定義：設置在數據中心內的云計算平臺，部署了各種計算、網絡、存儲、安全資源，可提供各種云計算服務的能力，具有統一的資源、安全、服務等平臺管理軟件。

城市軌道交通云平臺兼顧了計算和數據存儲處理，其特征如下。

1）硬件管理對使用者和管理者高度抽象，云計算分布式的資源向用戶隱藏了實現細節，并最終以整體的形式呈現給用戶。用戶只需具備網絡條件，即可通過客戶端來訪問平臺資源。

2）基礎設施的能力具備高度的彈性，可以根據需要進行動態擴展和配置。

3）能劃分獨立資源池。根據需求來動態地劃分或釋放不同的物理和虛擬資源。

4）資源可計量。云平臺通過計量的方法對存儲、計算、寬度、網絡、用戶資源進行自動控制和優化，監測資源的使用情況，并向用戶提供報告。

按照軌道交通行業規定，軌道交通列車運行控制系統需在故障-安全環境中運行，對實時計算和網絡安全的要求很高。傳統ATS架構屬于單機和網絡的組合，對單機、操作系統、網絡、業務軟件都是透明可控的。而云平臺由于存在虛擬機管理中間層，對消息鏈路、單機、操作系統都進行了高度封裝，無法判別系統性能和通信延時的影響程度，虛擬化軟件疊加硬件造成不可控因素較多，使得用戶使用云平臺時，為邏輯復雜性感到擔憂，需要對云平臺的開發進行規范。

2 規范要求

目前，城市軌道交通安全可靠性技術標準，主要參考歐洲電工標準化委員會（CENELEC）制定的鐵路安全相關標準：EN50126，定義了整個鐵路系統的安全性、可靠性［1］；EN50128，定義了子系統軟件部分的安全完整性［2］；EN50129，定義了整個系統及硬件部分的安全性、可靠性［3］；EN50159，定義了通信系統的安全完整性等級。另外，IEC 61508，給出了確定安全完整性等級的方法。

安全完整性等級（SIL）為安全功能提供相對降低風險的級別，或用于指定降低風險的目標級別。安全完整性是定量元素和非定量元素的組合體。定量元素一般與硬件有關，如隨機失效。非定量元素則與軟件有關，如技術條件、文件、程序等失效。SIL置信度是根據多個定量和非定量因素結合確定的，在基于IEC 61508的功能安全標準中，定義了4個SIL［4］。

安全評估的目的就是在限定條件下，判斷信號系統的功能安全性實現程度。為了評估這個實現程度，將其分為2點證明：①設計有安全功能（能夠有效防護可預見的危險）；②安全功能可用性高（在設定的條件下）。在SIL等級定義中，通常關注安全功能可用性［6］。

在《城市軌道交通CBTC信號系統—ATS子系統規范》（CZJS/T 0030—2015）中，ATS系統安全性要求為SIL2級［5］。為了實現安全性等級，需要底層設備硬件、軟件滿足相應的RAM要求。ATS系統一直使用商品現貨作為硬件載體，是首個能驗證上云的系統。在軟件開發中，遵循SIL2級安全完整性開發流程和開發方法［7］。其系統RAM要求滿足下列規定：①系統可用性應不低于99.98%；②MTBF（平均無故障工作時間）應大于3500 h；③MTTR（平均修理時間）應不大于45 min。

3 ATS結構

3.1 傳統結構

傳統ATS結構分為控制中心和車站2級，主要包括服務器子系統（COM）、操作子系統（HMI）、計劃子系統（Schedule）、接口子系統（ITF）。傳統ATS總體結構組成見圖1。

圖1 傳統ATS總體結構組成

控制中心ITF是與其他非信號系統的接口；車站ITF是與聯鎖、ATO/ATP等信號系統的接口。車站和控制中心的數據通過COM實現交換。HMI、Schedule、ITF分別與COM進行信息交換。

硬件采用雙機熱備的有Schedule、COM和ITF等子系統。本文以傳統ATS系統中的控制中心設備為例，說明在傳統結構下的設備構成。傳統ATS系統中心設備框架見圖2。

圖2 傳統ATS系統中心設備框架

主用中心中，應用服務器、數據庫服務器、外部接口服務器、通信服務器均為雙套熱備布置，調度操作站（HMI）、時刻表編輯工作站和運行圖工作站等都是單機設置，所有設備通過100 Mb/s以太網接口連接［8］。

3.2 云平臺結構

在云平臺中，將所有服務器納入云平臺部署及管理，工作站采用云桌面的方式，充分利用云平臺虛擬化技術，實現硬件資源利用最大化。云平臺ATS系統結構見圖3。

圖3 云平臺ATS系統結構

在云平臺ATS結構中，為了達到CBTC核心業務系統對數據庫高可用的要求，采用一主一備模式，包含主、備份節點服務器各2臺，主、備用存儲陣列各1臺，全部使用交叉連接，并在管理交換機上配置數據分析平臺和運維管理平臺，所有工作站采用虛擬機方式提供云桌面支持。

傳統ATS和云平臺ATS的可靠性與成本比較見表1。

表1 傳統ATS和云平臺ATS的可靠性與成本比較

相對于傳統結構，云平臺結構基于開源云平臺配置，采用通用的X86硬件結構，能夠有效降低用戶成本，節省了一次性投入成本和運維成本；利用開放型技術、松耦合架構，讓用戶有更多的自主選擇性，擺脫了大廠設備的局限性和約束性，大大提升了系統設備的可維護性。

4 RAM分析

ATS上云后，使用新的云平臺軟硬件替代原有的硬件冗余方案，不會改變系統既有的安全功能。下面將從技術上分析云平臺硬件和軟件RAM（可靠性、可用性、可維修性）指標。

4.1 云平臺硬件

云平臺RAM指標應能夠滿足ATS業務系統的要求。針對信號系統設備，其隨機失效完整性就是系統隨機失效的概率，該值對ATS系統可用性指標影響較大。失效包括：工作模式、環境、磨損、過應力、應力降級等。這部分與硬件元器件損壞、軟件失效、環境干擾相關，能夠量化的是硬件失效率。傳統降低硬件失效率的技術有雙機備份、軟件切換、功能組合等。

本文以主流云平臺PAAS層中常見的VMware云平臺管理程序為例，介紹其特有的虛擬分布式存儲（vSAN），并進行可用性分析。

vSAN是專為虛擬機設計的極其簡單的存儲，具有速度快、恢復能力強、動態性優等優點，是針對超融合基礎架構推出的一款存儲解決方案，也是一個軟件驅動的體系結構，可通過虛擬化的x86服務器實現計算、網絡連接和共享存儲。vSAN會池化與服務器連接的閃存設備和硬盤（HDD），以便為虛擬機創建一個富有彈性的高性能共享數據存儲。

在可靠性和可用性方面，vSAN和傳統存儲一樣，都是基于RAID方案。不同的是vSAN使用了純軟件RAID和容錯失敗策略（FTT）。FTT是存儲對象可以容忍的主機故障數，可為每個虛擬機獨立設定數據可用性指標。例如，對于只有1份數據（FTT=0），沒有備份數據，數據可用性等于數據所在硬件可用性。通常，硬件可用性在99%范圍內，即每年3.65天停機時間。設定更高的FTT策略，能有效降低不可用概率。當FTT=1時，即備份1份數據，數據可用性至少提高到99.99%；當FTT=2時（備份2份，一共3份），可用性提高到99.9999%。通常來說，對于FTT=n，必須有超過n個主機發生故障，數據才不可用。

總的來說，云平臺特有的虛擬分布式存儲設備的容錯失敗策略FTT，對云平臺整體可用性的指標具有較大的影響。下面對整體云平臺設備的MTBF進行計算。

對于硬件產品，定義故障概率的常用指標：AFR（年化故障率）和MT B F（平均無故障工作時間）。

例如：固態硬盤Intel 3710，AF R為0.44%。常用的希捷600 G硬盤（型號為ST600MM0009），M T B F為2×106h，A FR為0.44%［9］。企業級硬盤和固態硬盤A F R從0.44%～0.87%。主流商用X86服務器的M T B F一般大于50萬h（故障率低于1.7%/年），也有一些達到了100萬h（故障率為0.87%/年）。假設2臺服務器同時發生故障（取故障率0.88%/年），其A F R故障率為

上述結果意味著每10000臺服務器每年可能會有0.7744臺發生故障，滿足ATS系統要求的最低故障率250.2857%/年（MTB F≥3500 h）。

其他設備包括機架、主機、控制器的可用性都可從供應商處獲得。比如，常用的商用服務器產品，華為OceanStor5000系列融合存儲主機可靠性規格：方案級可靠性99.9999%，MTB F為106h，M T T R為2 h［10］。該 設 備 的 可 用 性 為。在實際工程中，還需要考慮機架、控制器、SSD/HDD等其他設備的故障，這些都可從供應商處獲取企業級硬件設備的可用性指標。例如常用的單點設備的故障概率，機架為0.99998，SSD為0.99998，主機為0.9998，緩存為0.99998。在上述所有器件部署于虛擬分布式存儲中時，無拷貝保護（FTT=0），總的組合概率為（機架）0.99998×（SSD）0.99998×（緩存）0.99998×（主機）0.9998≈0.99974，意味著每年仍有（1-0.99974）×365×24≈2.28 h會停機。

在上述計算中，完全依賴廠家提供的設備數據，并使用了最嚴苛的計算。在現場環境中，為了保守起見，只取到每個設備的最后一個9，再次計算，（機架）0.9999×（SSD）0.9999×（緩存）0.9999×（主機）0.999≈0.9987，意味著每年仍有11.39 h會停機。對于ATS系統應用，仍然無法接受。

為了提高設備可用性，需要使用容錯失敗策略。假設FTT=1，有一個備份數據，即如果2個數據都不可用，設備才會停機，在此條件下再計算不可用概率，（1-0.9987）2=0.000001689，對應可用性概率是0.999998。可以看到，在FTT=1下，可用性從2個9提高到5個9，呈現出指數級增長的趨勢。

總的來說，通常1臺虛擬機包含多個硬、軟件對象，假設有10個對象，每個對象可用性為0.999991，這整體的可用性為0.99999110=0.99991。即虛擬機可用性從單機的5個9降低到4個9。為了提高可用性，在FTT=2的情況下（3個副本），如果要宕機，需要3個副本同時宕機，再算一遍，(1-0.9987)3=0.000000002197，數據可用性為1-0.000000002197=0.999999997803，提升到8個9，這樣就達到了足夠可用的等級了。

通過上述計算，可以總結出硬件設備的可用性隨著數據保護策略FTT的增加，呈現指數級增長。數據保護策略的使用提高了云服務整體硬件可用性指標，為應用可用性提供了有力技術支撐。

參考傳統ATS系統可用性要求99.98%，即每年有0.02%×365×24×60=105.12 min的宕機時間。在整體設備可用性最不利（0.9987）的情況下，當FTT=1時，云平臺整個系統可用性計算結果為0.999998，遠超要求的99.98%。

通過前面的計算有效性分析，證明了云平臺硬件架構作為新的ATS系統架構滿足可靠性和可用性使用要求。

4.2 云平臺軟件

大部分云平臺的底層仍然使用虛擬機平臺，主機硬件和軟件故障造成的影響與可用性有最直接的關系。以最常見的VMware軟件為例，當出現硬件和軟件故障時，云平臺軟件通過虛擬機中容錯機制（FT）和高可用性（HA）來保證不宕機，提高了系統的可維護性。

4.2.1 容錯機制（FT）

大多數任務可以使用虛擬機容錯機制。容錯機制通過創建和維護一個輔助虛擬機，來確保主虛擬機的連續可用性。該虛擬機與主虛擬機相同，且在發生故障時可隨時切換。工作時，主虛擬機會持續復制到輔助虛擬機，以便輔助虛擬機可以隨時接管工作，此外主虛擬機和輔助虛擬機會持續監控彼此的狀態以維護FT可用。如果主虛擬機故障，系統將會執行故障切換，立即啟用輔助虛擬機以替換主虛擬機，并自動重新建立其他FT冗余。如果運行輔助虛擬機的主機發生故障，則該主機立即會被新的FT替換。總之，在任一情況下，都不會遭遇服務中斷和數據丟失的情況。

容錯機制的響應完全自動化，保護操作系統中運行的所有關鍵任務，而無需進行特別標定。當基礎架構出現故障時，不會造成停機和數據丟失，不會中斷原有TCP連接。FT會自動部署在群集中的2臺獨立的物理服務器上，只有這2臺服務器同時發生故障，FT才會失效。通過前面計算獲知，2臺服務器同時故障的可能性為0.007744%，這是一個非常小的概率。

典型FT用例：需要始終保持可用的應用程序，尤其是具有長時間客戶端連接的應用程序，在硬件故障期間保持這些連接；不能通過其他方式實現群集功能的自定義應用程序；可以通過自定義群集方案提供高可用性，但方案太復雜，很難進行配置和維護。這些FT的情況，非常符合軌道交通ATS應用軟件的運行環境要求。

啟動FT的必備條件：群集中至少有2臺物理服務器，至少有1個共享存儲卷，FT要求至少有獨立的10 Gb/s網絡，25/40/100 Gb/s網絡將更好，通常受服務器和網絡性能資源限制，FT僅支持創建一份輔助虛擬機。

FT就緒時間長短取決于硬件和網絡性能，通常包含以下因素：虛擬機的內存大小，虛擬機的存儲大小（如果主虛擬機和輔助虛擬機位于不同的存儲上），用于FT日志記錄的網絡帶寬大小。

FT復刻的最主要限制因素仍然是磁盤性能。以磁盤I/O的性能為例，對網絡I/O和磁盤I/O進行對比，取性能較低的一方作為計算的依據。一般來說，共享存儲的磁盤I/O約為200 MB/s。

假設虛擬機的配置為32 GB內存、500 GB存儲，以FT網絡10 Gb/s為例，計算初始FT就緒時間。

僅考慮網絡I/O的就緒時間=（32 GB+500 GB）/（10 Gb/s/8）=425.6 s

僅考慮共享磁盤I/O的就緒時間=（32 GB+500 GB）/200 MB/s=2660 s

可以看出，在采用共享磁盤下，FT的性能制約仍取決于磁盤I/O性能，配置更高I/O的SSD盤或接口能極大縮短FT的復刻準備時間和啟動性能。

ATS的系統要求可維護時間≤45 min，從上面的計算可以得出，在FT已開啟的情況下，切換時間可忽略。即使在最不利情況（普通SATA共享存儲），重新開啟FT，復刻數據需2660 s（44 min），也能夠滿足ATS可維護時間要求。

為了分散風險，架構設計中通常在一個群集設置多臺主機，分配2個獨立的共享存儲，或者vSAN。讓所有的主機都可以訪問這2個共享存儲或者vSAN。vSAN可采用多個副本（FTT）來保障數據不丟失，進一步降低了數據丟失的風險。

4.2.2 高可用性（HA）

HA運行機制是監控群集中的主機及虛擬機，通過配置合適的策略，當群集中的主機或虛擬機發生故障時，可以自動到其他主機上重新啟動，最大限度保證重要服務不中斷。這也正是將多臺主機添加到一個群集管理的目的，可以統一管理及使用這些高級HA特性。

主機的故障類型包括：物理硬件故障或電源等原因導致的主機停止運行；主機網絡中斷導致的主機與網絡隔離；主機跨網絡分區導致連接不上副機。

在主機發生故障時，HA將嘗試在任一指定的主機上重新啟動其虛擬機；如果不行，則HA會嘗試在群集內的其他主機上重新啟動虛擬機。為了避免因故障間隔時間、最短正常運行時間監測信息等非瞬態錯誤而反復重置虛擬機，HA可以設置監控敏感度。HA通過在主機出現故障時重新啟動虛擬機來為虛擬機提供基本級別的保護，相比FT，HA提供了更高級別的可用性。在HA的幫助下，典型的ATS設備硬件、網絡故障、系統死機等，都能夠通過重啟系統來恢復應用服務，其可維護時間僅取決于軟件系統重啟時間。

以上所述都是針對主機計劃外停機和災難的保護，對于計劃內的停機維護，虛擬機軟件也提供了較完善的保護機制。比如vMotion方法，通過主動備份的方式，實現遷移過程中服務不中斷。云平臺RAM計算中，通過數據保護策略和群集管理，能明顯降低云平臺系統的隨機失效概率，各項RAM指標均超過現有ATS系統規定要求。

5 結論

1）在云平臺建設和應用已經成為趨勢的情況下，信號系統上云的過程一直顯得較為謹慎，一方面，云平臺作為新興系統，設備廠商需要不斷證明其硬件、軟件RAM指標滿足目前信號系統使用要求；另一方面，信號系統廠家也應該努力熟悉、適應云平臺群集使用策略和管理方法，高效發揮出云平臺在系統部署、恢復、運維方面的優勢。

2）通過比較傳統ATS系統和云平臺ATS系統的結構，從云平臺硬件、軟件二方面說明其能滿足信號系統RAM指標要求，對于提高現有設備的系統轉型和上云發展，具有重要的參考意義。