「事件回顧」

1956年6月30日

美國大峽谷

天氣晴朗多云

廣袤的峽谷高原安靜如常

忽然間

云層遠處傳來飛機引擎的轟鳴聲

距離越來越近在云層中時隱時現

上午10點30分

在厚厚的云層遮蔽下

只聽“轟”一聲

一個大火球從云端竄落而下

美國史上最嚴重的客機空難發生了

兩架客機在大峽谷上空相撞

乘客和機組共計128人全部罹難

這就是“1956年大峽谷空中撞機事件”

針對此次空難事故

調查部門給出的結論是

因間歇性云減少視覺分離的時間

使駕駛艙可視性引起的視覺限制

空中交通管制人員不足

以及缺少途中空中交通咨詢情報

也是空難發生的重要原因

60多年前

飛機既沒有先進的機載電子設備

更沒有全球衛星導航定位系統

飛行員只能通過無線電告知調度員具體位置

當時的航管中心

就是一個擺著地圖和桌子的房間

航空管制人員會根據飛行位置信息

在地圖上移動飛機坐標

根本無法準確知道飛機的位置

在今天這是無法想象的

現在全世界每天有超過10萬個航班起降

每一刻都有上萬架飛機在空中飛行

如果依靠飛行員報告位置

出事的概率將急劇增大

那么現在每天全球這么多的航班

是如何避免空中相撞的？

 「空中廣播員“ADS-B系統”」

ADS-B系統

即“廣播式自動相關監視系統”

一種集通信與監視于一體的信息系統

把沖突探測、沖突避免、沖突解決、

ATC監視以及機艙綜合信息顯示

有機的結合起來

大致的原理是這樣的

飛機起飛后

從全球衛星導航定位系統獲取四維位置信息

包括經度、緯度、高度和時間

還附帶沖突告警信息

如飛行員輸入信息、航跡角、航線拐點等

以及飛機的識別信息和類別信息

然后機載電子設備將位置信息廣播出去

地面接收站在收到信息后

傳輸到空中交通管制人員控制中心

空管人員能實時準確的了解飛機的信息動向

如空域附近有多架飛機

互相之間會收到區域內飛機的位置廣播信息

沖突探測、沖突避免、沖突解決等機制

能排除飛機撞機的風險

然而即使如此

風險依然存在

倘若運行ADS-B系統的服務器出問題

那也將讓飛機的安全和安保置于風險之中

 「永遠在線的空中交通監控」

中國民用航空總局空中交通管理局

負責監督國家空中交通服務、民航通信、導航、

監視以及航空氣象和航班信息

非常清楚ADS-B系統對空中交通監控的重要性

可以說是一秒也不能沒有“它”

為保證ADS-B系統能穩定的運行

中國民用航空總局空中交通管理局

曾在冗余網絡模式下

用兩臺國外某主流廠商的x86服務器

運行較低版本的ADS-B系統

但在執行數據分析和編譯的過程中

服務器反復出現機器故障

破壞了整個ADS-B系統的穩定性

并導致ADS-B系統的崩潰

倘若單點故障無法消除

就意味著無法確保系統持續運行

不僅無法消除飛行過程的安全風險

還會增加管理人員的工作量和時間

經過項目組多方討論

決定選擇一款比傳統服務器容錯性更高的產品

作為ADS-B系統的服務器平臺

這種服務器要能在任何極端情況下

保證系統的穩定運行

最后他們選擇了Stratus ftServer服務器

看中的就是它的全雙工硬件設計架構

即內部是兩組完全一樣的子系統

ADS-B系統只需部署到其中的一組系統上

當這組系統出問題時

便瞬間切換到另外一組子系統上

過程無需人員介入

即使更換子系統或組件

也可以直接熱插拔完成替換

不會影響系統的正常運行

在插入的同時，CRU能自動完成數據同步

多路徑I/O故障轉移功能

可防止數據損壞或丟失

99.99999%的高可用性

徹底杜絕任何硬件故障帶來的安全風險

除此之外

Stratus ftServer服務器

還有自我監控、自我診斷、告警和補救功能

可提高運營效率并簡化問題管理

為系統管理員節省時間和工作量

服務器發展至今

很多人認為性能已歸于同質化

這家和那家都沒太大區別

CPU、內存、硬盤、主板

都是幾個主流廠商在供應

配置性能都差不多

但競爭力往往就在于差異化部分

對于這點，Stratus做到了

而且做的非常好

較之傳統服務器

Stratus ftServer最核心的競爭力就在于

“99.99999%”的高可用性

以及能保證業務永遠在線