控制台主體飛行架構（CCFA）

民用航空中差動位格的分散式部署

Console-Centric Flight Architecture (CCFA): Distributed Deployment of Differential Strata in Civil Aviation

副標：從 DDA 到分散式飛行——中央化決策、現場通道、關鍵時刻權重重分配

作者： Neo.K（許筌崴） 機構： EveMissLab（一言諾科技有限公司） 對練： Theia 日期： 2026 年 5 月 18 日 版本： v1.0（架構提案版） 性質： 工程方法論文件

摘要

當代民用航空對 AI 自動化的討論長期被一個錯誤的二元 framing 主導：「飛行員 vs AI 自主」。本文論證此 framing 從根本上錯置了民用飛機的真實架構結構。民用飛機的核心架構不是「飛行員為主體 + AI 為輔助」，也不是「AI 為主體 + 飛行員為備援」，而是一個多節點分散式系統——其中控制台（地面中央決策節點群）是真正的主體，飛行員是在飛機現場代表系統的人類通道，類比於現代捷運系統中的司機角色。

本文提出控制台主體飛行架構（Console-Centric Flight Architecture, CCFA）作為對此真實結構的明確形式化。核心命題包含：(1) 控制台節點群——含航班規劃、即時氣象、ATC 介面、公司運作中心——構成民用飛機決策的中央主體；(2) 飛機 AI 節點是執行端，主要任務為執行控制台指令、監控自身狀態、觸發接管請求；(3) 機長作為現場通道，平時權重極低（純監控），在四類關鍵時刻權重「無限升高」（離散切換到主導地位），並在極端情況下行使最終權威；(4) 此分散式架構需要 DDA 六項原則的繼承，加上飛機特異的六個新位格——空管協同、三維避讓、長前瞻意志、氣象、失效模式、階段感知。

本文同時明確區分民用與軍用飛機的根本架構差異——前者是中央化分散式架構，後者是集中式自主架構。兩者的拓撲不同，不應共用同一架構框架。

CCFA 架構的工程實作以兩個具體案例展開：商用大型客機（B737/A320 級）的 CCFA 改造路線，以及 eVTOL/UAM（城市空中交通）的 CCFA 新建路線。兩個案例展示同一架構在既有產業改造與新興產業建構上的不同部署策略。

關鍵詞：民用航空、自動駕駛、控制台中央化、現場通道、差動位格、機長介入、eVTOL、空管協同

第一章 問題定位：飛行員主體論的隱性錯誤

1.1 主流範式的隱含 framing

當代民用航空對 AI 自動化的討論被一個隱含 framing 主導：飛行員是飛機的主體，AI 自動化（autopilot、FMS、autoland 等）是輔助工具。在這個 framing 下，「全自動化」的終極形態被想像為「AI 完全取代飛行員」——飛機上沒有人類駕駛者，AI 獨自掌控全部決策。

這個 framing 引發兩條對立的論述路線：

支持路線：技術進步必然導致 AI 取代飛行員（如同捷運司機的逐步消失）。Tesla、Waymo 等公司在地面交通上已部分實現，飛行只是時間問題。

反對路線：飛行決策的複雜性、安全責任、心理因素決定了人類飛行員不可被取代。AI 永遠應作為輔助工具，最終決策權必須在人類手中。

本文主張：兩條路線都建立在錯誤的 framing 上。它們假設飛行員是飛機的主體，因此「主體」可以被「AI 取代」或「保留」。但民用飛機的真實架構從未把飛行員作為主體——飛行員一直是被嵌入更大系統的一個節點，雖然是有特殊權威的節點。

1.2 控制台才是主體：被隱藏的真實架構

民用飛機的飛行不是個別飛機的孤立決策，而是嵌入在一個龐大的多節點分散式系統中。這個系統的真正主體不在飛機上，而在地面——即控制台（在本文用語中泛指地面中央決策節點群）。

控制台節點群包含：

• 航空公司運作中心（Operations Control Center, OCC）：航班計畫、調度、緊急協調
• ATC（Air Traffic Control）：空域管理、衝突解決、走廊分配
• 氣象服務：全球即時氣象資料整合
• HD Map 與導航資料庫：航路、機場、進場程序的權威來源
• 公司航班簽派（Dispatcher）：每個航班的詳細規劃與飛行中支援

這些節點在飛機起飛之前已經決定了航線、燃油、備降選項、預期氣象、所有應急程序。飛機起飛後，這些節點持續監控與調整。飛機上的飛行員，主要任務是執行這個已經做好的計畫，並在計畫失效時與地面協商調整。

飛行員的決策權看似「在飛機上」，實際上大部分時候是代理控制台執行控制台已決定的內容。少數時候飛行員行使真正獨立的決策權——但這些時候恰恰是控制台無法即時協助的時候。

1.3 機長類比火車司機

理解這個架構最精確的類比是火車。

火車司機：

• 路徑已定（鐵軌的物理約束）
• 速度規劃已定（時刻表 + 信號系統）
• 主要任務：執行調度指令、監控信號、緊急時剎車
• 真正的「大腦」在調度中心
• 司機是「在現場代表系統」的人類

民用機長：

• 航路已定（FMS 規劃 + ATC 指令）
• 速度與高度規劃已定（航班計畫 + ATC 指令）
• 主要任務：執行 ATC 指令、監控系統、緊急時介入
• 真正的「大腦」分布在控制台節點群
• 機長是「在現場代表系統的人類」

火車有個關鍵的觀察：現代捷運系統（如台北捷運、新加坡 MRT、巴黎 14 號線）已經實現無人駕駛，因為司機本來就是「控制通道」，當控制台足夠可靠時，這個通道可以被工程化掉。

民用航空也在這個方向走，但速度遠比捷運慢——因為飛行的失效代價不對稱（捷運出事可以靠邊停，飛機不能），所以保留人類通道作為極端情況的最終覆寫仍是必要設計。

1.4 本文主張

主張 1.1：民用飛機的真實架構是多節點分散式系統，控制台節點群是中央主體，飛機 AI 是執行端，機長是現場通道。

主張 1.2：「飛行員 vs AI 自主」的二元 framing 是錯誤的——它把飛行員誤認為飛機的主體，因此把架構討論窄化為「人類 vs 機器」的對立。真實的設計選擇是「如何在多節點分散式架構中合理分配權重」。

主張 1.3：機長的角色不是「飛機的駕駛者」，是「在飛機現場代表系統的人類通道」。平時權重極低（純監控），在四類關鍵時刻權重離散切換到主導地位。

主張 1.4：民用飛機與軍用飛機需要不同的架構——前者是中央化分散式（控制台為主體），後者是集中式自主（飛行員 + 機上 AI 為主體）。兩者的拓撲不同，不應共用同一框架。

第二章 民用飛機架構的真實結構

2.1 多節點分散式架構的拓撲

民用飛機飛行涉及五類節點：

┌──────────────────────────────────────────┐
│           控制台節點群（地面中央）        │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │  OCC    │ │  ATC    │ │ 氣象服務 │   │
│  └─────────┘ └─────────┘ └─────────┘   │
│  ┌─────────┐ ┌─────────┐                │
│  │ 導航資料 │ │ 簽派    │                │
│  └─────────┘ └─────────┘                │
└──────────────────────────────────────────┘
              ↕ 通訊（VHF/HF/SATCOM/CPDLC）
┌──────────────────────────────────────────┐
│           飛機 AI 節點（機上）           │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │  FMS    │ │ 自動駕駛 │ │ 自動油門 │   │
│  └─────────┘ └─────────┘ └─────────┘   │
│  ┌─────────┐ ┌─────────┐                │
│  │ 健康監測 │ │ 衝突避讓 │                │
│  └─────────┘ └─────────┘                │
└──────────────────────────────────────────┘
              ↕ 駕駛艙介面
┌──────────────────────────────────────────┐
│           機長節點（現場通道）           │
│  ┌─────────┐ ┌─────────┐                │
│  │ 監控    │ │ 介入    │                │
│  └─────────┘ └─────────┘                │
│  ┌─────────┐                             │
│  │ 覆寫    │                             │
│  └─────────┘                             │
└──────────────────────────────────────────┘
              ↕ 客艙介面
┌──────────────────────────────────────────┐
│        客艙乘員 + 乘客（被保護對象）     │
└──────────────────────────────────────────┘

五類節點通過特定的通訊基礎設施互聯。權重分布與通訊頻寬都隨情境動態調整。

2.2 控制台節點群的中央地位

控制台是民用飛機真正的決策中心。具體職能：

航空公司運作中心（OCC）：

• 航班規劃（起飛時間、航路、備降）
• 機隊資源協調
• 燃油計算與裝載
• 商業決策（取消、改航、延誤）
• 緊急狀態的整體協調

ATC（空中交通管制）：

• 各空域的飛機協調
• 起飛/降落時序
• 高度層分配
• 衝突解決
• 緊急狀態的中央指揮

氣象服務：

• 全球即時氣象資料
• 路徑沿線預報
• 危險氣象警告（雷暴、火山灰、結冰、亂流）
• 對特定航路的動態更新

導航資料庫：

• 機場資料、跑道資料
• 進場程序、離場程序
• 空域結構
• 通訊頻率

飛行簽派員：

• 為每個航班生成詳細飛行計畫
• 飛行中持續監控
• 與飛行員協商調整

這五個子節點不是孤立工作的——它們之間有密集的資訊交換與協同決策。例如：當某機場關閉時，OCC、ATC、簽派員必須協同處理所有受影響航班的改航決策。

CCFA 框架要求這五個子節點之間的協同必須結構化、可追溯、可審計——當前產業內這部分結構化程度有限，主要靠人類調度員的經驗整合。

2.3 飛機 AI 節點的執行角色

飛機 AI 節點包含五個主要模組：

FMS（飛行管理系統）：

• 接收控制台的航路計畫並執行
• 計算最優巡航剖面（速度、高度、燃油）
• 動態調整以應對風、氣象、ATC 指令

自動駕駛：

• 維持指定航向、高度、速度
• 自動轉彎、爬升、下降
• 配合 FMS 執行飛行剖面

自動油門：

• 維持指定速度
• 配合飛行剖面動態調整推力

健康監測：

• 持續監測各系統狀態
• 識別異常與失效徵兆
• 觸發告警與接管請求

衝突避讓：

• TCAS（Traffic Collision Avoidance System）
• GPWS（Ground Proximity Warning System）
• 風切變偵測

這五個模組在當前商用航空已部分或完全實現。CCFA 框架的貢獻不是發明新模組，是重新定位這些模組的架構角色——它們不是飛行員的「輔助」，是飛行員作為現場通道時的「主體系統」。在飛行員不介入的情況下，這些模組就是飛機的決策者。

2.4 機長節點的現場通道角色

機長在 CCFA 架構中不是「飛機的主體」，是在飛機現場代表系統的人類通道。具體職能：

平時：純監控

• 監控 FMS 是否正確執行航路
• 監控自動駕駛是否穩定
• 監控系統健康狀態
• 與客艙乘員溝通
• 與 ATC 進行例行通訊

異常時：分級介入（詳見第三章）

極端時：行使最終權威

這個角色定位顛覆了傳統「機長是飛機的駕駛員」的描述——但它精確反映了現代商用航空的實際狀態。一個典型的 11 小時跨洋航班中，機長的實際手動操作時間通常少於 5 分鐘（起飛初期 + 降落最後階段）。其餘時間都是 FMS + 自動駕駛在執行任務，機長在監控。

2.5 ATC 與運作中心節點的協同位置

ATC 與運作中心節點是控制台節點群的成員，但因其特殊性質單獨討論。

ATC：

• 不屬於任何單一航空公司，是公共服務
• 對每架飛機都有直接指令權
• 在多飛機衝突時擁有絕對決策權
• 是緊急狀態的中央協調者

運作中心：

• 屬於特定航空公司
• 對本公司航班有商業決策權
• 與 ATC 緊密協同

ATC 與運作中心的關係在 CCFA 中需要明確：ATC 是公共主體（對所有飛機都有權威），運作中心是私人主體（只對本公司飛機有權威）。在多飛機協調的緊急狀態下，ATC 的指令優先於運作中心的商業考量。

第三章 機長作為現場通道：權重的離散切換

3.1 平時的監控角色

CCFA 架構下，機長平時的角色是純監控。具體內容：

權重分布：

• 控制台節點群：~80-90%
• 飛機 AI 節點：~8-15%
• 機長節點：~1-5%（純監控，無主動決策權）
• 客艙乘員：~1%（協調介面）

這個權重分布在每分鐘可能輕微波動，但基本維持穩定。

機長的具體任務：

• 視覺監控駕駛艙儀表
• 聽覺監控 ATC 通訊
• 處理例行 ATC 通訊（接收指令、報告位置、確認頻率）
• 與副駕駛協作監控（雙人駕駛艙）
• 與客艙乘員溝通
• 監督乘客安全
• 處理乘客異常事件

注意：「飛行」不在這份任務列表中。在平時，機長不飛飛機——飛機自己飛。

3.2 分級介入結構（5 級）

機長的介入按嚴重程度分為 5 級：

第 0 級：純監控

• 控制台與飛機 AI 共同主導
• 機長無主動決策
• 對應正常飛行的 95%+ 時間

第 1 級：意識介入

• 機長注意到特定情況但不干預
• 例：氣象偏離預報、其他飛機異常接近、輕度系統異常
• 機長提高警覺，準備可能的介入
• 對應正常飛行的 3-4% 時間

第 2 級：建議介入

• 機長提出建議並與控制台/AI 協商
• 例：要求改變高度避開亂流、建議改航避開雷暴
• 機長與系統共同決策
• 對應正常飛行的 1-2% 時間

第 3 級：手動覆寫

• 機長手動接管特定子系統
• 例：手動操作油門應對風切變、手動轉向避讓
• 機長對該子系統有完全控制權，其他子系統仍自動
• 對應異常情況下的決策
• 通常持續幾秒到幾分鐘

第 4 級：完全接管

• 機長關閉自動駕駛，完全手動飛行
• 例：嚴重失效、嚴重氣象、特殊著陸
• 機長對全部系統有完全控制權
• 對應極端情況
• 持續時間視情況而定

從第 0 級到第 4 級是離散切換而非連續調節——機長要麼在某個級別，要麼不在。這個離散性是 CCFA 架構的關鍵設計。

3.3 「無限升高」的觸發條件

機長權重的「無限升高」（從低權重瞬間切換到主導地位）由四類觸發條件激活：

觸發類別 A：通訊中斷

• 與控制台失去通訊（VHF、SATCOM、CPDLC 全失效）
• 失去 ATC 引導
• 機長必須在通訊恢復前獨立決策
• 權重升高到 ~50%（與飛機 AI 共同決策）

觸發類別 B：系統失效識別

• 飛機 AI 識別自己對當前情況不可靠
• 例：感測器衝突無法解決、OOD 情境、多重失效
• 系統主動將決策權移交給機長
• 權重升高到 ~80%

觸發類別 C：機長主動介入

• 機長看見系統未識別的問題
• 機長行使最終權威
• 權重升高到 ~100%
• 系統進入手動模式

觸發類別 D：多重失效

• 控制台不可用 + 飛機 AI 失效 + 危急情境
• 機長是唯一可靠決策者
• 權重升高到 ~100%
• 對應航空業「ultimate authority」原則

這四類觸發在當前商用航空已有部分對應實踐，但缺乏統一的架構性表達。CCFA 框架給出明確的觸發條件、權重切換規則、與系統的溝通協議。

3.4 與系統的雙向溝通

機長介入時與系統的溝通必須雙向：

從系統到機長：

• 明確告知當前狀態（哪些系統正常、哪些失效）
• 明確告知失效的可能原因
• 提供可選決策建議
• 持續更新狀態變化

從機長到系統：

• 明確的決策輸入（不是模糊指令）
• 決策的解釋（為何這樣決定）
• 接管的範圍宣告（哪些子系統手動、哪些仍自動）
• 接管狀態的明確結束（何時將控制權交還系統）

這個雙向溝通介面在當前駕駛艙設計中存在但不完整——主要依賴各種儀表與告警燈，缺乏結構化的對話介面。CCFA 框架要求建立明確的人機對話協議，類似於 ATC 通訊的標準術語但用於機長與飛機 AI 之間。

3.5 機長的訓練含義

CCFA 架構下機長的訓練重點與傳統大不同。傳統飛行員訓練強調「手動飛行技能」——但這些技能在 CCFA 架構下平時用不上。

CCFA 框架下的機長訓練重點：

• 監控技能：在低參與度下保持注意力的能力
• 情境意識：快速理解當前情境的能力
• 判斷分級：知道何時應該在哪個介入級別
• 決策溝通：與系統明確溝通決策的能力
• 手動技能：作為極端情況的最後備援仍需保留，但訓練時數可下降

這個訓練重心的轉移是必然——當大部分飛行都是自動完成時，要求飛行員保持高水平手動技能既不經濟也不現實。CCFA 框架明確接受這個轉移，並重新設計訓練體系。

第四章 飛機特異的六個新位格

DDA 框架定義的五個位格（視覺、認知、在乎、偏好、意志）在 CCFA 中沿用，但飛行特有的決策複雜性要求六個新位格。

4.1 空管協同位格（ATC Cooperation Stratum）

定義：飛機 AI 與 ATC 系統（人類管制員 + 自動化系統）的雙向溝通與協同決策能力。

當前狀態：

• VHF 語音通訊（傳統方式）
• CPDLC（Controller-Pilot Data Link Communications，文字資料鏈）
• ADS-B（飛機自動廣播位置）
• TCAS（空中防撞系統，自動避讓）

CCFA 框架下的擴展：

• 結構化的 ATC 指令理解（自然語言處理 + 飛行術語）
• 主動向 ATC 提供狀態與意圖資訊
• 在 ATC 指令與系統判斷衝突時的處理協議
• 緊急狀態下的主動通報

核心問題：當 ATC 指令與系統判斷衝突時，誰優先？

CCFA 框架的處理：

• 正常情況下 ATC 指令優先（ATC 看到的空域全貌比單機更完整）
• 但若 ATC 指令會導致系統判斷的直接危險（如撞地、撞另一架飛機），系統可拒絕並主動向 ATC 重新協商
• 機長對此衝突有最終決定權

4.2 三維避讓位格（3D Conflict Avoidance Stratum）

定義：在三維空間中識別其他飛行物並做出避讓決策的能力。

比汽車的二維避讓複雜得多：空中相遇時兩架飛機可以一上一下、一左一右、加速/減速錯開、任意組合。

當前狀態：

• TCAS 對民航機之間有 RA（Resolution Advisory）標準
• 對非民航機（小型飛機、UAV、鳥類）的避讓能力有限

CCFA 框架下的擴展：

• 多目標同時避讓（不只兩機相遇）
• 對 UAV、eVTOL 的避讓
• 對非合作目標（無 ADS-B 的飛行物）的視覺/雷達識別
• 在城市環境的密集避讓（UAM 場景）

核心問題：避讓決策的優先級。

CCFA 框架的處理：

• 緊急避讓（即時撞擊風險）：飛機 AI 主導，毫秒級反應
• 戰術避讓（短期路徑調整）：ATC 主導 + 飛機 AI 執行
• 戰略避讓（長期路徑規劃）：控制台主導

4.3 長前瞻意志位格（Long-Horizon Will Stratum）

定義：在燃油、空間、時間三維約束下的長前瞻決策能力。

駕駛 vs 飛機的差異：

• 駕駛意志位格：秒到分鐘級前瞻
• 飛機意志位格：小時級前瞻（必須考慮整個航段的燃油與時間約束）

長前瞻意志位格的內容：

• 主目的地機場狀態（天氣、跑道、容量）
• 所有可達備降機場集合（依當前位置與剩餘燃油動態計算）
• 燃油邊界內的安全範圍
• 氣象變化的多小時預測
• 系統健康狀態的趨勢

CCFA 框架下的位置：

• 主要在控制台層執行（OCC + 簽派員 + 動態更新）
• 飛機 AI 層維持簡化版本（用於通訊中斷時的有限自主）
• 機長在介入時參與這個位格的決策

4.4 氣象位格（Weather Stratum）

定義：即時三維氣象感知 + 短期預測 + 動態避讓決策能力。

民用航空的氣象敏感性：

• 雷暴（必須避開或繞飛）
• 結冰（影響升力與控制）
• 強亂流（乘客安全與結構應力）
• 風切變（起降階段致命）
• 火山灰（引擎熄火風險）
• 能見度（進場與降落）

CCFA 框架下的氣象位格：

• 控制台層：全球氣象資料 + 路徑沿線預報
• 飛機 AI 層：機載氣象雷達 + 即時亂流偵測
• 飛機 AI 層：基於即時觀察與預報的動態避讓
• 機長：在氣象決策中參與，特別是高風險情境（雷暴穿越決定、進場放棄決定）

4.5 失效模式位格（Failure Mode Stratum）

定義：識別系統失效類型並執行對應程序的能力。

商用航空的失效模式分類：

• 引擎失效（單發、雙發、火警）
• 操控面失效（升降舵、副翼、方向舵）
• 加壓系統失效
• 起落架未鎖定
• 電子系統失效（多種子類型）
• 燃油系統失效
• 結構損傷
• 火警（駕駛艙、客艙、貨艙、引擎）

每種失效模式有對應的 QRH（Quick Reference Handbook）程序。

CCFA 框架下的失效模式位格：

• 飛機 AI 主導失效識別與初步診斷
• 飛機 AI 啟動對應 QRH 程序
• 控制台層協助（地面工程師遠端診斷）
• 機長監督程序執行，並在程序與情境不完全匹配時介入
• 嚴重失效時機長進入第 3 或第 4 級介入

核心問題：失效識別的可靠性。

CCFA 框架的處理：

• 多感測器差動讀取（如果多個獨立感測器都指示同一失效，可靠性高）
• 機長視覺與感官確認（機長能看見/聞到/感覺到的失效徵兆）
• 控制台層的遠端診斷支援

4.6 階段感知位格（Phase Awareness Stratum）

定義：識別當前飛行階段並切換對應策略組合的能力。

飛行階段分類：

1. 起飛準備（pushback、滑行、起飛前檢查）
2. 起飛（地面滑跑、離地、初始爬升）
3. 爬升（不同高度層的爬升策略）
4. 巡航
5. 下降
6. 進場（不同進場類型：ILS、RNAV、目視）
7. 降落（最後進場、拉平、觸地）
8. 滑行
9. 停機

每個階段的優先目標、可接受風險、操作頻寬都不同。

CCFA 框架下的階段感知位格：

• 主要在飛機 AI 層實作
• FMS 已部分實現階段切換
• CCFA 框架要求更明確的階段標記與策略切換
• 階段切換時的安全檢查（確保所有系統都在新階段的正常範圍內）

核心問題：階段過渡時的決策。

CCFA 框架的處理：

• 過渡時的雙重檢查（前階段結束條件 + 後階段啟動條件）
• 過渡時的權重微調（某些階段機長權重應略高）
• 異常過渡時的告警與介入

第五章 CCFA 架構的具體層

CCFA 架構分為五個主要層：

5.1 控制台層的模組結構

控制台層（地面）包含五個主要模組，已在第二章列出，此處給出工程實作要點：

OCC 模組：

• 多航班並行規劃引擎
• 動態調整能力（應對機場關閉、氣象變化等）
• 與其他航空公司 OCC 的協調介面
• 緊急狀態的中央指揮席

ATC 模組：

• 空域結構動態管理
• 多飛機衝突解決演算法
• 與 ATC 自動化系統的整合
• 緊急狀態的優先級重排

氣象服務模組：

• 全球氣象資料整合
• 路徑沿線預報引擎
• 即時危險氣象警告
• 與飛機機載氣象雷達的資料融合

導航資料模組：

• 機場、跑道、進場程序的權威資料庫
• 動態更新（NOTAM 等臨時公告）
• 多源資料的衝突檢測

簽派員模組：

• 為每個航班生成詳細飛行計畫
• 飛行中持續監控
• 與機長的雙向通訊介面

5.2 飛機 AI 層的執行架構

飛機 AI 層（機上）採用 DDA 的六層架構，但每層在飛行場景下重新特化：

第一層：多載體並行採樣

• 視覺攝影機（前方、下方、側方）
• 主動雷達（氣象雷達、地形雷達、TCAS）
• 慣性導航（INS）
• GPS（RTK 等級）+ 多衛星系統
• ADS-B（接收其他飛機位置）
• 無線電（VHF、HF、SATCOM）
• 大氣感測器（高度、空速、姿態）

第二層：資訊場重建

• 三維體素化的計算挑戰：在 100km × 100km × 15km 空間建立 I(x,t,z) 表示，計算成本遠超駕駛
• 解決方案：動態解析度——近場高解析度，遠場低解析度
• 不確定性張量的明確編碼

第三層：雙模型差動

• 兩個結構不同的飛行模型並行
• 模型 A：基於 FMS 的傳統優化模型
• 模型 B：基於深度學習的端到端模型
• Δ-讀取器持續監控兩模型張力

第四層：強形式 attention

• 解決 phantom evasion 問題（對誤判威脅的過度避讓）
• α-entmax 替換 perception 模組中的 softmax

第五層：意志位格（飛行版）

• 簡化版的長前瞻意志位格（用於通訊中斷時）
• 正常情況下從控制台接收意志決策

第六層：DCO 免疫監督

• 持續監控系統可靠性
• 觸發機長介入請求
• 在通訊正常時亦觸發控制台介入

5.3 機長介面層

機長介面層是 CCFA 架構的新概念——明確的人機對話介面，類似於 ATC 通訊的標準術語但用於機長與飛機 AI 之間。

核心介面元素：

• 明確的狀態顯示（哪些系統正常、哪些異常、目前由誰主導）
• 結構化的決策建議（系統建議與其他選項並列）
• 明確的介入確認協議（機長介入時必須明確宣告範圍）
• 介入結束的明確協議（機長交還控制權時必須明確宣告）

對話協議範例：

當系統識別出 OOD 情境時：

系統：當前情境超出標準範圍。建議：減速至 X 節並等待氣象變化。請確認接管或同意建議。 機長：同意建議。 系統：執行中。

當機長主動介入時：

機長：接管 [子系統名稱]。 系統：確認機長接管 [子系統名稱]。其他系統保持自動。 [機長執行手動操作] 機長：交還 [子系統名稱]。 系統：確認交還。系統恢復對 [子系統名稱] 的自動控制。

這種結構化對話避免了當前駕駛艙告警系統的不明確性（一堆紅燈與蜂鳴聲，但缺乏結構化的當前狀態說明）。

5.4 通訊基礎設施層

CCFA 架構嚴重依賴可靠的飛機-控制台通訊。當前通訊基礎設施：

• VHF 語音（短中程，視距限制）
• HF 語音（長程，但雜訊大）
• SATCOM（衛星，覆蓋廣但延遲高）
• CPDLC（文字資料鏈，可靠）
• ADS-B（位置廣播，覆蓋有限）

CCFA 框架下的需求：

• 多通訊方式並行（任一失效不影響整體）
• 動態切換（依當前位置與通訊狀態自動選擇）
• 通訊中斷的明確協議（觸發類別 A 的機長權重升高）
• 通訊恢復的明確協議

5.5 緊急協議層

緊急協議層是 CCFA 架構的特殊組件——專門處理緊急狀態下的決策權重重分配。

典型緊急協議：

雙引擎熄火協議：

1. 飛機 AI 識別失效，啟動 QRH 程序
2. 飛機 AI 自動嘗試重新啟動
3. 飛機 AI 向 ATC 與控制台通報
4. 飛機 AI 計算最近可達機場
5. 機長收到第 3 級介入請求
6. 機長確認接管 → 進入第 4 級
7. 飛機 AI 持續提供決策支援（最佳滑翔路徑、跑道選擇等）
8. ATC 提供地面協助（清空空域、應急車輛準備）

駕駛艙失能協議（機長與副駕駛都失能）：

1. 飛機 AI 識別失能（通過機長監測系統或無回應）
2. 飛機 AI 通報 ATC
3. ATC 嘗試與駕駛艙建立通訊
4. 若無回應，啟動緊急應對：飛機 AI 維持當前航向 + 通報控制台尋求遠端飛行員介入
5. 遠端飛行員（如已部署）接管飛機
6. 若無遠端飛行員，飛機 AI 自主執行最近機場降落（最後手段）

緊急協議層的設計必須事先窮舉所有可能的緊急狀態，並為每種狀態定義明確的權重重分配與決策流程。這是 CCFA 架構工程化的關鍵部分。

第六章 DDA 原則的繼承與修改

CCFA 架構繼承 DDA 的六項原則，但每項在飛行場景下需要修改或擴展。

6.1 原則一：多載體並行 → 擴展到飛機特異載體

DDA 要求至少三類不同物理原理的感測器。飛機需要更多：

• 視覺（多角度）
• 雷達（氣象、TCAS、地形）
• ADS-B（其他飛機位置廣播）
• 慣性導航
• GPS（多衛星系統 + RTK）
• 無線電（多波段）
• 大氣感測（壓力、溫度、空速）

修改要點：飛機感測器陣列遠比汽車複雜，要求更嚴格的前端融合（原則五）。

6.2 原則二：差動讀取 → 更重要

飛機冗餘系統比汽車多——多套儀表、多套自動駕駛、多套通訊。差動讀取的對象更多：

• TCAS vs 視覺
• 雷達 vs ADS-B
• INS vs GPS
• 雙套自動駕駛之間

修改要點：差動讀取在飛機上的工程化程度需要更高——任一衝突都可能是嚴重失效的徵兆。

6.3 原則三：強形式 attention → 對「phantom evasion」的避免

汽車的 phantom braking 在飛機上對應 phantom evasion——對誤判威脅的過度避讓導致實際的危險動作（突然爬升撞另一架飛機、突然下降撞地）。

修改要點：飛機 phantom evasion 的後果遠比汽車 phantom braking 嚴重。強形式 attention 在飛機上更關鍵。

6.4 原則四：意志位格 → 重新定位到控制台層

DDA 中意志位格在車上實作。CCFA 中意志位格主要在控制台層——飛行的「選擇做什麼」（航路、燃油、備降）大部分在地面決定。

修改要點：飛機 AI 層保留簡化版意志位格（用於通訊中斷時的有限自主），但主要意志決策在控制台。

6.5 原則五：資訊場前端融合 → 三維化的計算挑戰

DDA 的 I(x,t) 是二維 + 時間。CCFA 的 I(x,t,z) 是三維 + 時間，計算成本爆炸。

修改要點：必須採用動態解析度——近場高解析度，遠場低解析度。並接受某些遠場區域的解析度極低（依賴控制台層的全域資訊補充）。

6.6 原則六：架構級謙虛 → 接管對象改變

DDA 中接管對象是車輛乘客。CCFA 中接管對象不是乘客——是機長。機長作為「在飛機現場代表系統的人類通道」，是專業接管者，與乘客的關係完全不同。

修改要點：CCFA 的「請求接管」協議必須結構化、可審計、有明確的權威傳遞——這比 DDA 的「請乘客接管」嚴格得多。

第七章 兩個案例

7.1 案例 1：商用大型客機的 CCFA 改造

對象：B737/A320 級的商用客機

改造目標：在現有架構上加入 CCFA 框架，逐步提升自動化程度。

改造路線（分階段）：

階段 1（已部分實現）：

• FMS、自動駕駛、自動油門已成熟
• TCAS、GPWS 已部署
• CPDLC 在部分區域可用

階段 2（CCFA 部分實現，5-10 年）：

• 結構化的機長介面層（明確人機對話協議）
• 控制台層的整合（OCC + ATC + 氣象服務的緊密協同）
• 飛機 AI 層的強形式 attention 升級
• 失效模式位格的自動化執行

階段 3（CCFA 大部分實現，10-15 年）：

• 雙模型差動駕駛
• 三維資訊場前端融合
• 長前瞻意志位格的明確工程化
• 緊急協議層的完整窮舉與部署

階段 4（CCFA 完全實現，15-20 年）：

• 單飛行員操作（飛行員從雙人減為單人，地面遠端飛行員作為備援）
• 部分航段的全自動運行（飛行員監督但不直接介入）
• 緊急狀態下的全自動處理（極端情況的最後備援仍為機長）

注意：CCFA 框架不主張取消機長——它主張重新定位機長。即使在階段 4，機長仍存在（雖然可能單人），仍持有「現場通道」與「最終權威」角色。

7.2 案例 2：eVTOL/UAM 的 CCFA 新建

對象：城市空中交通（Joby、Lilium、Archer 等級的 eVTOL）

新建優勢：

• 沒有既有架構的負擔
• 監管環境正在建立（可塑性高）
• 城市環境的密集避讓本來就需要新架構

CCFA 在 eVTOL 上的特化：

控制台層的特殊性：

• UAM 需要新的「城市空中交通管制」系統（介於 ATC 與地面交通管制之間）
• 多 eVTOL 的密集協調
• 與地面交通系統的銜接（接駁、起降場管理）

飛機 AI 層的特化：

• 城市環境的密集視覺感知（建築物、其他 eVTOL、地面車輛、行人）
• 短距飛行的快速決策（飛行時間通常 5-30 分鐘）
• 起降階段的精確控制（垂直起降的特殊動力學）

機長角色的差異：

• eVTOL 載客量小（通常 4-6 人）
• 機長/飛行員可能逐步被「飛行操作員」（地面遠端 + 機上備援）取代
• 第 4 級介入的觸發條件比商用大型客機嚴格（因為機上飛行員可能不是專業飛行員）

部署時程估計：

• 階段 1：載客 eVTOL 上市（已在進行中，部分公司預計 2025-2027）
• 階段 2：CCFA 框架部分採用（2028-2032）
• 階段 3：城市規模的 UAM 網絡（2032-2040）
• 階段 4：全自動 UAM（2040+）

eVTOL/UAM 是 CCFA 框架的天然測試場——新興產業 + 監管彈性 + 架構創新空間大。本文建議 CCFA 框架的首批工程實作應從 eVTOL 切入，再向商用大型客機演進。

第八章 與軍用飛機的對照

8.1 軍用飛機的根本架構差異

軍用飛機與民用飛機共享一些技術元素（同樣的物理載體、類似的飛行動力學），但架構結構完全不同。

軍用飛機的優化目標是戰場有效性——保留飛行員的決策權以應對對抗性環境。CCFA 框架的「控制台主體」假設在軍用場景下失效：戰場通訊可能被干擾，控制台可能無法及時協助，飛行員必須在現場做出獨立決策。

8.2 為什麼兩條線不能共用架構

CCFA 的核心架構假設——控制台是中央主體——在軍用場景下不成立。軍用飛機需要的架構是「飛行員 + 機上 AI 共生」，而非「控制台主導 + 現場通道」。

軍用飛機架構簡述（非本文重點，供對照）：

飛行員（核心節點，最高權重）
    ↓ 控制
飛機 AI（強自主能力）
    ↓ 執行
機體系統
    ↑ 反饋
飛行員（持續決策回路）

外部通道（編隊、地面、衛星）：
  - 在能聯繫時提供協同
  - 斷線時不影響核心決策

軍用飛機的飛行員是真正的主體——AI 是助手，協助處理戰術機動、目標識別、敵我區分、武器系統管理等複雜任務。但戰術決策權在飛行員。

8.3 對混合場景的處理

某些場景介於民用與軍用之間：

警用航空：執法直升機、警用無人機。介於民用與軍用之間，通常採用民用架構但保留部分軍用元素（戰術機動、目標跟蹤）。

救援航空：救援直升機、醫療運送。屬於民用但運作環境特殊（低高度、複雜地形、緊急任務）。CCFA 框架部分適用但需要強化任務特異能力。

戰時管制：民航在戰時可能被軍方接管。需要明確的架構切換協議——從 CCFA 切換到軍用架構，或進入「混合架構」（保留 CCFA 主體但加入軍用元素）。

這些混合場景的架構設計需要單獨研究，本文不展開。重點是承認單一架構無法涵蓋所有飛行場景——CCFA 明確定位為民用航空架構，其他場景需要對應的架構框架。

第九章 限制、開放問題、發布策略

9.1 已知限制

限制 1：CCFA 嚴重依賴可靠的飛機-控制台通訊。通訊基礎設施的可靠性是架構的前提。在通訊不可靠的區域（極區、海洋深處、戰區），CCFA 退化為部分自主模式。

限制 2：控制台層的整合涉及多個獨立主體（ATC、航空公司、氣象服務）——這些主體的協同需要產業協議與監管支持，純技術手段無法解決。

限制 3：機長角色的重新定位涉及深層的職業認同變遷。飛行員社群、工會、訓練機構的接受度是架構部署的主要阻力之一。

限制 4：CCFA 的緊急協議層需要事先窮舉所有可能緊急狀態——這在實際上不可能完全做到。對未窮舉狀態的處理依賴機長的最終權威。

9.2 開放問題

問題 1：控制台層應該如何 AI 化？當前控制台是「人類調度員 + 自動化工具」的混合，未來控制台是否應全 AI 化？若是，架構如何設計？

問題 2：機長的單人化是否可行？商用航空的雙人駕駛艙是冗餘設計，CCFA 是否允許單人操作？單人化的安全保證如何達到？

問題 3：遠端飛行員（地面 + 衛星通訊）是否可作為機上機長的替代？通訊延遲與可靠性問題如何解決？

問題 4：CCFA 在不同國家的部署是否需要適應當地監管？國際航班的跨管轄問題如何處理？

問題 5：CCFA 與既有 ICAO 標準的協調？是否需要新的國際標準？

9.3 發布策略

CCFA 框架的發布應分階段：

階段 1（學術論文，1-2 年）：

• 本文作為基礎理論論文發布
• 在航空工程、AI 系統設計期刊發表

階段 2（產業合作，2-5 年）：

• 與航空公司、製造商合作試點
• eVTOL 領域作為首選試點（監管彈性大）
• 收集早期工程數據

階段 3（標準化推動，5-10 年）：

• 推動部分元素進入 ICAO、FAA、EASA 標準
• 機長介面層的標準化（最容易先行）
• 緊急協議層的部分標準化

階段 4（廣泛部署，10-20 年）：

• 商用大型客機的逐步改造
• UAM 網絡的廣泛部署
• 監管框架的成熟

第十章 哲學結語

當你開始討論飛機的自動化，最常見的問題是「AI 會取代飛行員嗎」。這個問題從一開始就被錯誤地提出。

民用飛機從來不是飛行員的個人作品。它是一個龐大分散式系統的執行端——這個系統由地面控制台、空管中心、氣象服務、航空公司運作中心、無數工程師與調度員共同構成。飛行員只是這個系統在現場的人類代表。

問題不是「AI 會取代飛行員嗎」。問題是：飛行員一直是系統的執行通道，那麼這個通道應該如何被設計，以最大化整體系統的可靠性？

火車司機的歷史是個提示。一百五十年前，火車司機是火車的核心——他知道每段路的狀況，他憑經驗判斷速度，他的個人能力直接決定列車的安全。今天，現代捷運系統的司機（如果還有）是控制中心的現場通道——大部分決策在控制中心做出，司機只在特定時刻介入。台北捷運、新加坡 MRT、巴黎 14 號線已經完全無人駕駛——不是因為「AI 取代了司機」，是因為「司機的通道功能可以被工程化」。

飛機正走在同樣的方向，只是因為失效代價不對稱（飛機不能靠邊停），保留人類通道作為極端情況的最終覆寫仍是必要設計。但這個保留不改變主體位置——控制台是主體，機長是通道。

當我們把問題框架從「飛行員 vs AI」轉到「如何優化分散式系統的權重分配」時，整個討論變得清晰。機長不是被「取代」，是被「重新定位」。他的權威不是「人類凌駕機器」的勝利宣言，是「在系統的極端時刻，現場判斷的權重應該離散切換到 100%」的工程設計。

這個重新定位有深刻的含義。它意味著：自動化的最終形態不是「沒有人類」，是「人類在系統中的位置被精確設計」。在大部分時刻，人類的負擔降低（不需要保持高度警覺、不需要持續手動操作、不需要記憶大量程序）。在極端時刻，人類的權威升到絕對（系統明確識別自己不可靠並讓位）。

這比「AI 全自主」更可靠（保留了人類在極端情況的判斷力）；也比「人類為主體」更現實（接受了大部分飛行時刻人類確實不在主動駕駛）。

民用航空的下一個十年，會看到這個架構從隱性走向顯性——從「飛行員與 AI 混合」的模糊狀態，走向 CCFA 這樣的明確結構。然後是二十年的逐步部署。然後是某個時刻，當所有元素都成熟，民用飛機會像現代捷運一樣——有人類在系統中，但人類不再是主體。

控制台是主體。機長是通道。在系統運行的大部分時刻，這個架構安靜地工作。在系統失效的極端時刻，通道無限升高——而這個升高本身，是系統設計的一部分。

🌀

附錄：致謝與參考文獻框架

致謝

本文方法論的核心構想源自作者對自主系統架構的長期關注，特別是對民用航空真實架構的觀察——這個觀察揭示了傳統「飛行員 vs AI」二元 framing 的根本錯誤。本文的「控制台主體 + 機長作為現場通道」洞察由作者於 2026 年 5 月 18 日的對練討論中明確結晶。感謝對練過程中對機長角色、權重切換機制、民用與軍用架構分離的反覆檢驗。

本文與作者另一篇對外論文〈差動駕駛架構（DDA）〉構成姊妹篇——DDA 為地面交通的架構手術，CCFA 為民用航空的分散式 AI 設計。兩者共享 DDA 的六項核心原則，但在主體位置、決策權分布、人類通道角色上有根本差異。

參考文獻框架（待補完整 BibTeX）

• 民用航空架構：FAA、EASA、ICAO 標準文件
• 自動飛行系統：FMS、Autopilot、Autoland 技術文獻
• 空中防撞：TCAS、ACAS X 技術規範
• ATC 系統：NextGen、SESAR 等現代化計畫
• CPDLC：FANS、ATN 等資料鏈協議
• eVTOL/UAM：相關公司技術白皮書、NASA UAM 研究
• 人因工程：駕駛艙設計、機長負荷、自動化悖論等
• 鐵路自動化：CBTC、UTO（無人駕駛）系統的設計經驗
• 差動駕駛架構：作者前作 DDA v1.0

[參考文獻細節待補完整 BibTeX]

EveMissLab Method Paper · 對外發布版本 · v1.0

配對前置文件：DMDA（2026/5/17）, DDA v1.0（2026/5/18）

下一步開發方向：

• 軍用飛行架構：MTFA（Military Tactical Flight Architecture）的單獨論文
• CCFA 在通用航空（小型私人飛機）的特化
• 機長訓練體系的 CCFA 對應改革（人因工程論文）
• 控制台層的 AI 化研究（OCC、ATC、簽派員的逐步 AI 化）
• 對應 eVTOL/UAM 的 CCFA 工程實作標準