歷史上的一次大的因為用户界面導致的災難 [譯]_風聞

我想花點時間探討歷史上的一次大的因為用户界面導致的災難：1988 年 7 月 3 日，美軍海軍導彈巡洋艦 USS Vincennes (CG-49) 在波斯灣上空誤擊伊朗航空 655 號航班，機上 290 人全部遇難。

當時，這起災難令人不解。Vincennes 裝備了當時最新的宙斯盾作戰系統（Aegis Combat System），這是全球最先進的防空系統，利用先進的計算機技術設計用於同時識別、追蹤並擊落數百架蘇聯轟炸機。那麼，它如何可能在面對一架單獨的民用飛機時犯下如此嚴重的錯誤呢？

美國海軍的官方報告完全為宙斯盾開脱，將責任歸咎於艦員。但後來曝光的細節強烈表明，擊落事件至少部分是因為宙斯盾用户界面的重大缺陷。

如果你對這個事件不太瞭解，可以在維基百科上找到一個頁面，裏面有詳細的介紹（網頁鏈接）。因此，我不打算回顧整個事件，而是想專注於導致 Vincennes 艦長和船員犯下這一重大錯誤的用户界面問題。

（這是一個複雜的話題，我會盡量簡短地説明，保證。）

圖一：1988 年 7 月 3 日被 USS Vincennes 擊落的空客 A300B2-203 EP-IBU 飛機。

圖二：美國海軍導彈巡洋艦 USS Vincennes。

伊朗航空 655 號航班被災難性擊落的第一個用户界面缺陷出現在飛機從伊朗班達爾阿巴斯國際機場起飛後不久。

無論是過去還是現在，世界上所有大型飛機都裝有一種稱為 IFF（“識別敵友”）的裝置。這是一個無線電應答器，能夠對請求做出回應，提供一組代碼，以表明飛機是民用還是軍用，以及其類型。

Flight 655 安裝了識別友敵系統 (IFF)，並準確報告其為民用客機。起飛後不久，Vincennes 查詢其 IFF，得到確認為民用客機。到此為止，一切正常。

問題出在 Aegis 系統的 IFF 控制枱操作上。操作員通過控制器移動光標至目標位置，並按下按鈕來“鎖定”新目標進行追蹤。一旦“鎖定”，Aegis 就會追蹤該目標。但問題是，除非操作員執行額外步驟，將光標固定於該目標，否則隨着目標移動，光標不會跟隨。它將繼續在目標_原來的位置_發送 IFF 請求，直到操作員再次移動光標。

在 Flight 655 的情況中，操作員正確地鎖定了目標，但未固定光標。因此，當 Flight 655 離開時，Vincennes 仍向其起飛跑道發送 IFF 請求。

緊接着從該跑道起飛的是伊朗的一架 F-14 軍用戰鬥機。光標在跑道上停留約 90 秒，足以讓 Vincennes 接收到軍用戰鬥機的 IFF 響應。於是 Flight 655 從未知目標被重新歸類為可能的敵對目標。

當 Vincennes 船長和船員查看顯示器時，他們從那時起看到的是一個被標記為 F-14 戰鬥機的、朝他們方向前進的目標。

圖三：一名水手操作 Aegis 控制枱

接下來的問題源於 Aegis 系統向船員反饋數據的方式。

整個系統基於屏幕設計。每位船員都有自己的屏幕來處理他們負責的數據。這些數據隨後彙總到一組大型顯示器上，供船長和高級官員監控總體情況。

這本身並無不妥。但關鍵在於，為高層決策者設計的“大局觀”儀表板視圖的成敗完全取決於提供給該視圖的數據。設計儀表板需要壓縮和總結信息。如果簡單地傳遞所有信息，會令決策者不堪重負。因此，問題在於決定包含哪些信息，而哪些不包含。

在 Aegis 防禦系統的原始版本中，大型顯示屏可以展示所有被跟蹤目標的位置和航向，但並未顯示它們的高度。這一點至關重要，因為高度，尤其是高度的變化，是判斷被跟蹤目標意圖的關鍵線索。例如，如果一架飛機正向你飛來但同時在上升，它攻擊你的可能性就較低。相反，如果它向你俯衝，這通常預示着攻擊。

Vincennes 艦長在監視一個向他靠近的目標時，由於大屏幕沒有顯示高度信息，他無法迅速判斷該目標是在上升還是下降。這些關鍵信息雖然存在，但只能在操作員的小屏幕上深入查找，而非在大屏幕的總體情況展示中。

圖四：Aegis 在 USS Vincennes 上的顯示屏

隨着 Flight 655 逐漸靠近，Vincennes 的艦長意識到他需要明確該飛機是在上升還是下降。因此，他請求了這一信息，但這時發生了第三次也是最後一次用户界面（UI）的失敗。

Aegis 的一大特色功能是能從多艘船隻的傳感器中提取並統一展示數據。在一個任務組中，所有船隻通過數據鏈路相連。當多艘船隻監測到同一個目標時，Aegis 能自動整合這些信息，形成一個對所有連接船隻上的操作員都可見的統一跟蹤目標。

為了方便識別這些被跟蹤目標，Aegis 會為每一個新目標分配一個四位數的追蹤編號。不同船隻對同一目標的追蹤編號可能不同。Aegis 將整合這些信息，選定一個編號作為官方編號，並捨棄其他編號。

然而，這個過程中存在兩個用户界面問題。首先，被捨棄的追蹤編號會被回收利用，分配給新的目標。其次，當 Aegis 改變某個目標的追蹤編號時，並沒有明顯的提示，編號只是在顯示屏上默默變化。

當 Flight 655 起飛時，同時被 Vincennes 和其護航艦 USS Sides 發現並追蹤。Vincennes 給它分配的追蹤編號是 4474，而 Sides 分配的是 4131。Aegis 將這兩個監測信息統一在 4131 這個編號下。隨後，4474 這個編號被重新分配給了一架正在下降的美國 A-6 轟炸機。

在做出開火決定的關鍵時刻，Vincennes 號的艦長請求了一份關於飛機高度的報告。但他未意識到飛機的追蹤編號已變更，還以為它是原先分配的 4474 號。因此，他要求了關於 4474 號的信息，值班人員便在控制枱輸入了這個編號。結果顯示目標正在快速下降。

事實上，655 航班並未下降，自從從 Bandar Abbas 起飛後一直在上升。但在這個決定性時刻，Aegis 系統的操作員卻在監視另一架完全不同的飛機。

圖5：一架美國 A-6“入侵者”轟炸機。

接着，Vincennes 號艦長下達了開火命令，隨後發生的是一場悲劇。

我不是要把這次誤擊事件的全部責任推到 Aegis 身上。實際上，如果你去查看維基百科，會發現那天早晨出現了許多問題。

但同時，Aegis 系統在此也不是完全無辜。其界面設計不佳，導致 Vincennes 號的船員誤解了他們所面臨的真實情況。

海軍的報告責怪船員沒有正確使用系統，但對於那些設計信息系統的人來説，這顯然是在逃避責任。人在壓力下容易犯錯，而戰鬥場合的壓力尤為巨大。如果一個系統不能適應這種壓力環境——如果它不能全力支持操作員，即使在出現失誤時也能確保他們獲取必要信息——那麼問題不在於操作員，而在於設計者。

The End

@寶玉xp