windy/my-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

remove airport wiki

Browse Source
This commit is contained in:
windyboy
2026-04-15 14:34:24 +08:00
parent a42a9a612f
commit 81d62725d8
98 changed files with 0 additions and 17004 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/config.toml
-7
View File
@@ -1,8 +1 @@
personality = "pragmatic" personality = "pragmatic"
[mcp_servers.qmd]
command = "bun"
args = ['C:\Users\windy\.bun\install\global\node_modules\qmd\src\qmd.ts', "mcp"]
[mcp_servers.qmd.env]
INDEX_PATH = 'C:\Users\windy\.qmd\index.sqlite'
airport-wiki/.gitignore
-6
View File
@@ -1,6 +0,0 @@
node_modules/
.obsidian/
.trash/
*.log
# 已被新方案取代
机场数据中心建设方案.md
airport-wiki/.markdownlint.json
-15
View File
@@ -1,15 +0,0 @@
{
"default": true,
"MD013": false,
"MD025": false,
"MD036": false,
"MD040": false,
"MD033": false,
"MD034": false,
"MD037": false,
"MD028": false,
"MD031": false,
"MD032": false,
"MD022": false,
"MD007": false
}
airport-wiki/SCHEMA.md
-388
View File
@@ -1,388 +0,0 @@
---
title: Wiki Schema
created: 2026-04-08
updated: 2026-04-10
type: schema
tags: [meta]
---
# Wiki Schema
## Domain
機場智能化工程 — 涵蓋機場智算中心（數據中心）技術建設與航班運營管理兩大領域。
**第一領域：機場智算中心技術**
機場數據中心/智算中心的規劃、設計、硬件選型、網路架構、等級標準、液冷供電、預制模塊化建設。
**第二領域：航班運營管理**
機場運營系統（AODB/A-CDM/SMGCS/BHS/FIDS）、航班數據交換標準、供應商對比、運營流程優化。
## Conventions
- 文件名：小寫、中劃線、無空格（如 `tier-iii-design.md`）
- 每個 wiki 頁面以 YAML frontmatter 開頭
- 使用 `[[wikilinks]]` 建立頁面間鏈接（每頁至少 2 個外部鏈接）
- 更新頁面時同步更新 `updated` 日期
- 新頁面必須添加到 `index.md` 對應版塊
- 所有操作追加到 `log.md`
## Frontmatter
```yaml
---
title: 頁面標題
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | comparison | query | summary
tags: [從下方標籤體系選取]
sources: [raw/articles/source-name.md]
confidence: 0.0-1.0 # 知識置信度（可選，預設 0.5）
sources_count: N # 支持該事實的來源數量（可選）
last_confirmed: YYYY-MM-DD # 最近一次確認時間（可選）
superseded_by: page-name # 被哪個頁面替代（可選，見 supersession 機制）
supersedes: page-name # 替代了哪個頁面（可選）
status: active|stale|dormant|archived # 知識狀態（預設 active）
relationships: # 實體頁面專用（可選）
- target: page-name
type: uses|deploys|depends_on|supersedes|...
detail: 可選描述
confidence: 0.0-1.0
---
```
## Tag Taxonomy（標籤體系）
### 智算中心技術標籤
- 等級標準：`tier-iii`, `tier-iv`, `ansi/tia-942`, `uptime-institute`
- 網路架構：`network`, `fiber`, `switching`, `routing`, `wan`, `lan`, `dci`, `infiniband`, `roce`
- 硬件設施：`server`, `gpu`, `storage`, `power`, `cooling`, `ups`, `generator`, `cab`, `pdu`, `liquid-cooling`
- 物理安全：`security`, `cctv`, `access-control`, `biometric`, `perimeter`
- 選址與土建：`site`, `building`, `floor-plan`, `reinforcement`, `load-bearing`
- 供應商：`vendor`, `oem`, `integrator`, `contractor`
- 項目管理：`planning`, `design`, `construction`, `commissioning`, `timeline`, `rfp`
- 合規認證：`certification`, `audit`, `fire-code`, `insurance`
- 運維管理：`monitoring`, `maintenance`, `mttf`, `mttr`, `sla`
### 航班運營標籤
- 運營系統：`a-cdm`, `aodb`, `smgcs`, `bhs`, `fids`, `vdgs`, `rms`, `dcb`
- 航班數據：`flight-data`, `milestone`, `ssim`, `ctot`, `tobt`, `tsat`
- 場面活動：`airside`, `taxiway`, `runway`, `apron`, `stand`, `deicing`
- 旅客服務：`passenger`, `smart-gating`, `self-service`, `biometric`, `app`
- 行李系統：`bag-trace`, `rfid`, `sorting`, `ibs`, `early-bag-storage`
- 數據交換：`api`, `integration`, `xml`, `idx`, `cidx`
- 系統架構：`open-architecture`, `dicos`, `acris`, `vendor-lock-in`, `capability-multiplier`
- 前沿技術：`digital-twins`, `agentic-ai`, `biometric`, `human-centered-design`, `hyper-personalization`, `sustainability`
- 運營設施：`aocc`, `ioc`
### 知識管理標籤
- `knowledge-management`：知識管理與 wiki 運營
- `confidence`：置信度相關內容
- `supersession`：替代機制
- `forgetting`：遺忘曲線 / 知識衰減
- `consolidation-tier`：整合層次（working/episodic/semantic/procedural）
- `knowledge-graph`：知識圖譜、實體關係圖
- `entity`：實體頁面標記
- `typed-relationship`：類型化關係（uses/deploys/depends_on 等）
- `automation`：自動化操作鉤子
- `event-hooks`：事件驅動架構
### 通用標籤
- `ai-ml`：AI/ML 應用
- `comparison`：對比分析
- `timeline`：時間線
- `glossary`：術語表
- `draft`：草稿
- `archived`：歸檔
- `stale`：已過時（被 supersede）
- `dormant`：休眠（長期未訪問）
## Page Thresholds（頁面創建規則）
- **創建獨立頁面** 當一個實體/概念在 2+ 來源中被提及，或在一個來源中處於核心位置
- **追加到現有頁面** 當來源提到已在覆蓋範圍內的內容
- **不建頁面** 僅一次提及、細節性內容、或超出本領域的內容
- **拆分頁面** 當頁面超過 ~200 行時，拆分為子主題並交叉鏈接
- **歸檔頁面** 內容完全被取代時，移至 `_archive/`
## Directory Structure（目錄結構）
```
airport-wiki/
├── SCHEMA.md # 本文件
├── index.md # 內容總索引
├── log.md # 操作日誌
├── 機場智算中心技術方案.md # 綜合技術方案
├── 機場航班數據管理運營方案.md # 運營管理方案
├── concepts/
│ ├── tech-infrastructure/ # 智算中心技術（9頁）
│ │ ├── airport-data-center-overview.md
│ │ ├── gpu-cluster.md
│ │ ├── network-architecture.md
│ │ ├── power-and-cooling.md
│ │ ├── tier-iii-design.md
│ │ ├── tier-iv-design.md
│ │ ├── prefab-modular-dc.md
│ │ ├── modern-airport-trends.md
│ │ └── glossary.md
│ ├── flight-operations/ # 航班運營系統（16頁）
│ │ ├── a-cdm.md
│ │ ├── aodb-core.md
│ │ ├── aodb-vendors.md
│ │ ├── smgcs.md
│ │ ├── baggage-handling.md
│ │ ├── flight-data-exchange.md
│ │ ├── smart-gating.md
│ │ ├── deicing-operations.md
│ │ ├── airport-systems-landscape.md
│ │ ├── agentic-ai-airports.md
│ │ ├── aocc-ioc.md
│ │ ├── biometric-corridors.md
│ │ ├── digital-twins-airports.md
│ │ ├── future-airport-info-center.md
│ │ ├── open-architecture.md
│ │ └── universal-design-airports.md
│ └── knowledge-management/ # 知識管理（3頁，2026-04-13 新增）
│ ├── memory-lifecycle.md # 置信度/superset/遺忘機制
│ ├── knowledge-graph.md # 實體圖譜/類型化關係
│ └── wiki-operations.md # 事件鉤子/自動化
├── comparisons/ # 橫向對比
│ ├── airport-dc-case-studies.md
│ └── airport-operations-systems.md
├── entities/ # 機場實體案例
│ ├── index.md # 實體索引 + 關係圖譜
│ ├── shenzhen-airport.md
│ ├── zhengzhou-airport-hangang.md
│ ├── fuzhou-changle-airport-bsj.md
│ ├── jfk-airport.md
│ ├── pittsburgh-airport.md
│ ├── rome-fiumicino-airport.md
│ └── singapore-changi-airport.md
├── _archive/ # 被 supersede 的歷史版本（待建立）
└── raw/
├── articles/
├── papers/
├── transcripts/
└── assets/
```
## Entity Pages（實體頁面）
每個主要實體一頁，包括：
- 概述 / 是什麼
- 關鍵事實和數據
- 與其他實體的 Typed Relationships（`relationships` 字段）
- 來源引用
- 置信度（`confidence`）、來源數量（`sources_count`）、最後確認時間（`last_confirmed`）
```yaml
# entities/example.md frontmatter 格式
type: entity
entity_type: airport # airport | vendor | hardware | system | standard | project
confidence: 0.9
sources_count: 2
last_confirmed: 2026-04-13
relationships:
- target: another-entity
type: uses|deploys|depends_on|supersedes|...
confidence: 0.85
```
## Concept Pages（概念頁面）
每個概念/主題一頁，包括：
- 定義 / 解釋
- 當前知識狀態
- 開放問題或爭議
- 相關概念（[[wikilinks]]）
## Comparison Pages（對比頁面）
並排分析，包括：
- 比較對象及原因
- 對比維度（表格格式優先）
- 結論或綜合判斷
- 來源
## Update Policy（更新政策）
### Supersession 機制（新）
當新信息與現有內容衝突或更新現有內容時：
1. 將新內容寫入原頁面，更新 `updated` 日期
2. 舊版本完整內容移動至 `_archive/[original-name]-[date].md`
3. 舊版本 frontmatter 添加：
```yaml
superseded_by: [new-page-name]
superseded_date: YYYY-MM-DD
status: stale
```
4. 新版本 frontmatter 添加：
```yaml
supersedes: [old-page-name]
supersedes_date: YYYY-MM-DD
```
5. 觸發 `On memory write` 鉤子，記錄至 log.md
### 衝突檢測（原有，擴展）
新信息與現有內容衝突時：
1. 檢查日期 — 新來源通常取代舊來源
2. 如確實矛盾，記錄雙方立場和日期、來源
3. 在 frontmatter 標記：`contradictions: [page-name]`
4. 在 lint 報告中標記待用戶審核
### Confidence Decay（新增）
定時任務自動衰減置信度：
- 架構決策：每月衰減 0.5%
- 供應商/硬件規格：每月衰減 1%
- 項目進度：每月衰減 5%
- 每次被引用/確認：置信度恢復 +0.1，上限 0.98
## Glossary（術語表）
建設和運營涉及的英文縮寫和術語，統一在 `concepts/tech-infrastructure/glossary.md` 中解釋。
---
# LLM Wiki v2 擴展架構
*(基於 Andrej Karpathy 原版模式，融合 LLM Wiki v2 和 agentmemory 經驗)*
## 核心理念：停止重新推導，開始積累編譯
### 現有架構回顧
- **原始數據**：`raw/` 目錄中的來源文件，保持原始、未經編輯
- **Wiki 頁面**：經過整理、鏈接的知識頁面（`concepts/`, `entities/`, `comparisons/`）
- **Schema 文檔**：`SCHEMA.md`，將通用 LLM 轉化為有紀律的知識工作者
### v2 關鍵擴展
#### 1. 記憶生命周期（Knowledge Lifecycle）
知識具有生命周期，不是所有內容永久有效：
- **置信度評分**：每個事實應基於來源數量、新近性、矛盾情況攜帶分數（0.0-1.0）
- **替代機制**：新信息明確替代舊聲明，支持知識版本控制
- **遺忘機制**：實施保留曲線（如艾賓浩斯遺忘曲線），逐步降低未使用知識的優先級
- **整合層次**：知識壓縮管道：
- **工作記憶**：近期觀察（當前會話）
- **情景記憶**：會話總結（跨工作記憶的壓縮）
- **語義記憶**：跨會話事實（穩定知識）
- **程序記憶**：從重複語義中提煉的工作流和模式
#### 2. 超越扁平頁面：知識圖譜
用類型化知識圖譜增強 wiki 頁面：
- **實體提取**：提取結構化實體（人員、項目、庫、概念）及類型、屬性、關係
- **類型化關係**：使用語義加權連接，如 `uses`、`depends_on`、`contradicts`、`supersedes`
- **圖譜遍歷查詢**：導航連接以發現下游影響，超越關鍵詞搜索
#### 3. 真正可擴展的搜索（關鍵突破）
當 `index.md` 超出 ~100-200 頁時變得不可行：
- **混合搜索**：融合三種信息流：
1. **BM25**：關鍵詞匹配（支持詞幹提取/同義詞）
2. **向量搜索**：通過嵌入實現語義相似度（例如 OpenAI `text-embedding-3-small`）
3. **圖譜遍歷**：基於實體關係的遍歷搜索
- **結果融合**：使用倒數排名融合（Reciprocal Rank Fusion）合併結果
- **保留 `index.md`**：僅作為人工可讀目錄，不再是主要檢索工具
#### 4. 自動化：從手動到事件驅動
減少人工維護負擔：
- **事件鉤子**（自動觸發）：
- **新來源時**：自動攝入、提取實體、更新圖譜/索引
- **會話開始/結束時**：加載上下文、將會話壓縮為觀察
- **查詢時**：如質量分數 > 閾值，自動回寫答案
- **內存寫入時**：檢查矛盾
- **定時任務**：定期 lint、整合、保留衰減
- **自動攝入管道**：`raw/` 中新增源文件 → 自動解析 → 創建/更新 wiki 頁面
#### 5. 質量與自我糾正
防止噪聲積累的控制機制：
- **評分一切**：LLM 生成內容應獲得質量分數（結構良好、引用來源、一致性）。低分標記待審查/重寫
- **自我修復**：Lint 操作應自動修復孤立頁面、過時聲明、損壞的交叉引用
- **矛盾解決**：基於新近性、權威性和支持觀察，LLM 應提出更可能正確的主張
#### 6. 多智能體與協作
為多個智能體或人員擴展模式：
- **網狀同步**：合併來自並行智能體的觀察；使用帶時間戳的最後寫入獲勝衝突解決
- **共享 vs 私有**：知識範圍劃分（個人偏好 vs 項目架構）
- **工作協調**：輕量級協調以防止重複工作並跟踪進展
#### 7. 隱私與治理
處理敏感信息和問責：
- **攝入時過濾**：在 wiki 存儲前自動剝離 API 密鑰、憑據、個人身份信息
- **審計追踪**：記錄所有操作（攝入、編輯、刪除、查詢）的時間戳、更改和原因
- **批量操作**：用於過時內容刪除、導出、合併的經過審計且可逆操作
#### 8. 結晶化：從探索中提煉
自動將已完成的工作鏈提煉為結構化摘要：
- **處理過程**：提取問題、發現、涉及的文件/實體、經驗教訓
- **結果**：創建一等級 wiki 頁面，用新事實強化知識庫
#### 9. 超越 Markdown 的輸出格式
基於受眾和問題的知識存儲應支持多樣輸出：
- 對比表格、時間線可視化、依賴關係圖、幻燈片、結構化數據導出（JSON、CSV）、簡報
## 實施路線圖
### 階段 1：基礎 LLM Wiki（已實現）
- ✓ 原始來源存儲（`raw/`）
- ✓ Wiki 頁面（`concepts/`, `entities/`, `comparisons/`）
- ✓ Schema 文檔（`SCHEMA.md`）
- ✓ 目錄索引（`index.md`）
- ✓ 操作日誌（`log.md`）
### 階段 2：v2 擴展（本次升級目標）
1. **記憶生命周期**：置信度評分、替代機制、遺忘曲線
2. **知識圖譜**：實體提取、類型化關係、圖譜可視化
3. **混合搜索**：BM25 + 向量 + 圖譜遍歷
4. **自動化鉤子**：事件驅動維護
5. **質量控制**：自我糾正、矛盾檢測
6. **結晶化**：工作鏈提煉
### 階段 3：高級功能
1. **多智能體協作**：網狀同步、衝突解決
2. **隱私過濾**：自動敏感信息剝離
3. **多格式輸出**：API 導出、可視化生成
## 實施細節
### 混合搜索設置
```
# 檢索層級
1. BM25 關鍵詞匹配（使用 ripgrep + 同義詞詞典）
2. 向量語義搜索（使用 OpenAI embeddings）
3. 知識圖譜遍歷（實體關係路徑）
4. 結果融合（RRF 算法）
```
### 記憶衰減公式
```
confidence_t = confidence_0 * exp(-λ * t) + Σ(citations * 0.1)
λ = 衰減率（每月 0.005-0.05，依內容類型）
```
### 自動化鉤子示例
```bash
# 新增來源時
on_new_source() {
parse_source → extract_entities → create_wiki_pages → update_index
}
# 會話結束時
on_session_end() {
compress_session → update_episodic_memory → decay_confidence
}
# 定期任務（每週）
cron_weekly() {
run_lint → fix_issues → prune_dormant → regenerate_embeddings
}
```
## 參考文檔
- [[knowledge-management/memory-lifecycle.md]] - 記憶生命周期詳細設計
- [[knowledge-management/knowledge-graph.md]] - 知識圖譜實現指南
- [[knowledge-management/wiki-operations.md]] - wiki 運營與自動化
- [[hybrid-search.md]] - 混合搜索系統文檔
- [[llm-wiki-v2-reference.md]] - LLM Wiki v2 完整參考
```
airport-wiki/_archive/aodb-redirect-stub.md
-16
View File
@@ -1,16 +0,0 @@
---
title: AODB — 機場運營數據庫
created: 2026-04-08
updated: 2026-04-10
type: concept
tags: [aodb, flight-data, system]
---
# AODB — 機場運營數據庫
> 本頁已拆分。內容遷移至以下子頁面：
- **[[aodb-core]]** — 核心概念、A-CDM 架構、Milestone 定義、選型決策樹
- **[[aodb-vendors]]** — 5 大供應商深度分析（AODB-vendor comparison）
本文件保留作為索引入口。
airport-wiki/comparisons/airport-dc-case-studies.md
-50
View File
@@ -1,50 +0,0 @@
---
title: 机场数据中心案例对比
created: 2026-04-08
updated: 2026-04-08
type: comparison
tags: [comparison, case-study]
sources: [raw/articles/dubai-airport-huawei-dc.md, raw/articles/daxing-airport-vertiv.md, raw/articles/2025-airport-construction-summit.md]
---
# 机场数据中心案例对比
## 代表案例
| 机场 | 北京大兴国际机场 | 迪拜国际机场（DXB） | 大连金州湾国际机场 |
|------|----------------|-------------------|------------------|
| 投运/状态 | 2019年（已投运） | 2019年后（已投运） | 在建 |
| 等级 | 未公开（推测Tier III+） | Tier III 双认证 | 规划Tier III+ |
| 总功率 | 未公开 | 1MW | 未公开 |
| 单柜密度 | 未公开 | 10kW/rack | 高密度（智算趋势） |
| 制冷方案 | Liebert PEX+ 精密空调 | 变频行级空调+密闭通道 | 风液融合 |
| 建设模式 | 传统建设 | 预制模块化（集装箱） | BIM+数字化 |
| PUE | 未公开 | <1.6 | 目标<1.4 |
| 建设周期 | 3年+ | 10个月 | 预计3-4年 |
| 智能化 | 19平台68系统 | NetEco管理 | BIM+AI巡检 |
## 关键差异分析
### 建设模式
- **大兴机场**：传统建设，长周期，大规模一次性投入
- **迪拜机场**：预制模块化，快速交付，弹性扩容
- **大连金州湾**：BIM+数字孪生，建运一体化
### 制冷方案演进
- **大兴机场时代**：风冷精密空调（2019年主流）
- **迪拜机场**：变频行级+密闭通道（PUE<1.6）
- **2025年后**：风液融合，适配50-120kW高密度机柜
### 智能化水平
- **大兴机场**：平台化，整合70+系统
- **迪拜机场**：NetEco统一运维
- **大连/新机场**：AI巡检机器人、数字孪生
## 经验总结
1. **快速交付选预制模块化**：迪拜案例10个月交付，节省50%时间
2. **高功率密度选液冷**：单机柜50kW以上必须液冷
3. **BIM是新建机场标配**：设计施工运维一体化
4. **Tier III是机场数据中心基准**：迪拜机场明确要求Tier III双认证
> 相关：[[tech-infrastructure/airport-data-center-overview]] | [[tech-infrastructure/tier-iii-design]] | [[tech-infrastructure/modern-airport-trends]]
airport-wiki/comparisons/airport-operations-systems.md
-49
View File
@@ -1,49 +0,0 @@
---
title: 机场运营系统供应商对比
created: 2026-04-08
updated: 2026-04-08
type: comparison
tags: [system, vendor, comparison]
---
# 机场运营系统供应商对比
## AODB 供应商
| 维度 | adb safegate Cortex AODB | Amadeus AODB | AirportLabs SkyCore AODB | PDC AODB |
|------|--------------------------|--------------|--------------------------|----------|
| **AI 支持** | 是（模块化+AI） | 有限 | 是 | 待确认 |
| **2025 部署** | 全球枢纽 | 全球（覆盖 95% 航司计划） | 芝加哥 ORD（2025.8） | 多机场模式 |
| **A-CDM 集成** | 原生支持 | 原生支持 | 原生支持 | 原生支持 |
| **云化** | 是 | SaaS（Amadeus cloud） | 是 | 本地/混合 |
## 智能机位管理供应商
| 维度 | Assaia StandManager | adb safegate AmberFAIR | AirportLabs SkyCore RMS |
|------|---------------------|------------------------|-------------------------|
| **发布时间** | 2025 | — | — |
| **核心技术** | AI 视频分析 | 可持续分配算法 | 机位资源管理 |
| **集成方式** | API / 云 | API / 云 | API / 云 |
## BHS 供应商（头部）
| 维度 | Siemens Logistics | Beumer Group | Vanderlande | Alstef |
|------|-------------------|--------------|-------------|--------|
| **技术亮点** | RFID 全流程追踪 | Tote-based 分拣 | 高吞吐量分拣 | 仓储自动化 |
| **2025 动态** | 斩获多个大合同 | Tote 技术快速推广 | — | — |
| **目标市场** | 大型枢纽 | 大型枢纽 | 全类型 | 全类型 |
## A-SMGCS 厂商
| 厂商 | 专注领域 |
|------|----------|
| Frequentis | 空管通信与监视 |
| Saab | SMR 场面雷达 |
| TERMA | 场面灯光控制 |
| NADIN（欧洲） | 全系列 A-SMGCS |
## 综合评价
- **全栈机场平台**：adb safegate、Amadeus、Siemens 覆盖多个子系统
- **专注细分领域**：Assaia（视频AI）、AirportLabs（停机位）专注单点突破
- **集成趋势**：各厂商积极推动开放 API，兼容 IATA A-CDM Toolkit 数据模型
airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md
-252
View File
@@ -1,252 +0,0 @@
# AODB 事件 Schema 草案
## 1. 文档定位
本文档定义 AODB MVP 阶段的统一事件信封和关键事件 payload 草案，用于实现、联调和消费者契约评审。
## 2. 统一事件信封
所有事件必须使用统一 envelope：
```json
{
"event_id": "uuid",
"event_type": "PublishedFactUpdated",
"schema_version": 1,
"occurred_at": "2026-04-13T16:00:00Z",
"produced_at": "2026-04-13T16:00:01Z",
"source": {
"system": "aodb-flight-service",
"organization": "airport-ops",
"channel": "internal"
},
"idempotency_key": "string",
"correlation_id": "string",
"aggregate_type": "FlightOperation",
"aggregate_id": "flight_123",
"quality": {
"confidence": "confirmed",
"flags": []
},
"payload": {}
}
```
## 3. 字段说明
| 字段 | 说明 | 必填 |
| --- | --- | --- |
| `event_id` | 全局唯一事件 ID | 是 |
| `event_type` | 事件类型 | 是 |
| `schema_version` | schema 版本 | 是 |
| `occurred_at` | 业务发生时间 | 是 |
| `produced_at` | AODB 产出时间 | 是 |
| `source` | 来源系统和组织 | 是 |
| `idempotency_key` | 幂等键 | 是 |
| `correlation_id` | 关联链路 ID | 是 |
| `aggregate_type` | 聚合类型 | 是 |
| `aggregate_id` | 聚合 ID | 是 |
| `quality` | 可信度和数据质量标记 | 否 |
| `payload` | 事件负载 | 是 |
## 4. 事件列表
### 4.1 `FlightImported`
用途：
- 表示计划航班已进入 AODB 标准化流程。
```json
{
"payload": {
"flight_id": "flight_123",
"flight_key": "MU-1234-2026-04-13-1",
"op_date": "2026-04-13",
"carrier": "MU",
"flight_number": "1234",
"leg_no": "1",
"batch_id": "ssim_batch_001"
}
}
```
### 4.2 `MilestoneObserved`
用途：
- 表示接收到一条原始或标准化里程碑观测。
```json
{
"payload": {
"observation_id": "obs_001",
"flight_id": "flight_123",
"milestone_type": "ALDT",
"observed_value": "2026-04-13T15:22:00Z",
"source_sequence": "aidx-889",
"raw_message_ref": "msg_777"
}
}
```
### 4.3 `PublishedFactUpdated`
用途：
- 表示 Published Fact 发生变化，是对外共享的关键事件。
```json
{
"payload": {
"flight_id": "flight_123",
"field_name": "ALDT",
"previous_value": "2026-04-13T15:20:00Z",
"current_value": "2026-04-13T15:22:00Z",
"decision_ref": "decision_321",
"published_state_version": 9
}
}
```
### 4.4 `TurnaroundLinked`
用途：
- 表示到离港航班形成过站关联。
```json
{
"payload": {
"turnaround_id": "ta_001",
"arrival_flight_id": "flight_arr_001",
"departure_flight_id": "flight_dep_001",
"tail_number": "B-1234",
"link_confidence": "estimated"
}
}
```
### 4.5 `ResourceAssigned`
用途：
- 表示资源分配已生效。
```json
{
"payload": {
"allocation_id": "alloc_001",
"resource_id": "stand_12",
"resource_type": "Stand",
"flight_id": "flight_123",
"turnaround_id": "ta_001",
"lock_type": "hard",
"assignment_source": "manual",
"validity_window": {
"start_at": "2026-04-13T15:00:00Z",
"end_at": "2026-04-13T16:30:00Z"
}
}
}
```
### 4.6 `ResourceConflictDetected`
用途：
- 表示资源冲突被识别出来。
```json
{
"payload": {
"resource_id": "stand_12",
"resource_type": "Stand",
"conflict_type": "time_overlap",
"affected_allocations": ["alloc_001", "alloc_002"],
"affected_flights": ["flight_123", "flight_456"],
"rule_ref": "resource.time-window.v1"
}
}
```
### 4.7 `AlertRaised`
用途：
- 表示告警进入打开状态。
```json
{
"payload": {
"alert_id": "alert_001",
"alert_type": "resource_conflict",
"severity": "high",
"related_aggregate_type": "ResourceAllocation",
"related_aggregate_id": "alloc_001",
"summary": "Stand 12 conflict detected"
}
}
```
### 4.8 `ManualDecisionRecorded`
用途：
- 表示人工裁决已经完成。
```json
{
"payload": {
"decision_id": "decision_321",
"decision_type": "field_override",
"target_aggregate_type": "FlightOperation",
"target_aggregate_id": "flight_123",
"field_name": "ALDT",
"selected_value": "2026-04-13T15:22:00Z",
"reason": "tower confirmation",
"operator": "ops_user_007"
}
}
```
### 4.9 `ReviewTaskOpened`
用途：
- 表示复核任务已创建。
```json
{
"payload": {
"review_task_id": "review_001",
"review_type": "milestone_conflict",
"target_aggregate_type": "FlightOperation",
"target_aggregate_id": "flight_123",
"reason": "conflicting ALDT observations"
}
}
```
## 5. 版本演进规则
- `schema_version` 必须随破坏性变更升级。
- 非破坏性新增字段只允许追加，不允许重定义现有字段含义。
- 下游必须按“忽略未知字段”实现兼容。
- 被废弃字段必须至少保留一个发布周期。
## 6. Topic 建议
| Topic | 用途 | 分区键 |
| --- | --- | --- |
| `aodb.flight.events` | FlightOperation 和 Published Fact 事件 | `flight_id` |
| `aodb.resource.events` | 资源分配和冲突事件 | `flight_id` |
| `aodb.alert.events` | 告警和处置事件 | `alert_id` |
| `aodb.review.events` | 人工复核和裁决事件 | `target_aggregate_id` |
## 7. 消费者要求
- 必须按 `event_id` 去重。
- 必须处理至少一次投递。
- 必须把 `quality.flags` 作为强语义，而不是展示附注。
- 不得把查询接口结果当作事件流补偿来源。
airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md
-65
View File
@@ -1,65 +0,0 @@
# AODB 字段级权威矩阵
## 1. 文档定位
本文档用于定义 AODB 关键字段的来源优先级、更正规则、人工覆盖规则和对外可见性。它是 Published Fact 生成和测试用例设计的直接依据。
## 2. 适用原则
- 规则粒度以字段为准，而不是以“整条航班记录”统一处理。
- 原始 Observation 永不改写。
- Published Fact 只能由字段级权威矩阵和裁决逻辑生成。
- 人工覆盖必须事件化和审计化。
## 3. 字段矩阵
| 字段 | 字段类别 | 主来源 | 次来源 | 默认可信度规则 | 过期规则 | 更正规则 | 人工覆盖规则 | 对外可见性 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| SIBT / SOBT | 计划时间 | SSIM / 计划导入 | 人工计划调整 | 计划导入为 `reported`，人工调整为 `confirmed` | 新计划版本到达后旧计划失效 | 新批次或更高版本覆盖旧计划 | 允许，必须记录变更原因 | 返回当前值 + 来源 |
| EOBT | 预计时间 | 航司计划源 | 机场运行 | 航司上报优先 | 超过配置阈值后降为 `suspect` | 新版本或更正报文优先 | 允许 | 返回当前值 + 来源 + 可信度 |
| TOBT | 协同计划时间 | 航司 / 地服 | 机场运行 | 航司 / 地服 `confirmed` 高于机场运行 `reported` | 若长时间未更新且实际进度明显偏离，则标记 `suspect` | 显式更正优先 | 允许，必须给出裁决摘要 | 返回当前值 + 裁决摘要 |
| TSAT | 系统计算时间 | AODB / PDS | 机场运行人工调整 | 系统计算缺省 `estimated` | 新一轮计算生成后旧值过期 | 高版本计算结果覆盖低版本 | 允许，需记录算法版本和人工原因 | 返回当前值 + 算法版本 |
| TTOT | 系统计算时间 | AODB / PDS | 机场运行人工调整 | 同 TSAT | 同 TSAT | 同 TSAT | 同 TSAT | 返回当前值 + 算法版本 |
| ELDT | 预计到达时间 | ANSP / 外部运行态 | 系统预测 | ANSP 上报高于系统预测 | 若距当前时间过远且无更新，可信度下降 | 新版本或更正优先 | 允许 | 返回当前值 + 可信度 |
| ALDT | 实际到达时间 | ANSP / 机场运行 | 航司 | ANSP / 机场运行 `confirmed` 优先 | 实际时间不过期，但可被更正 | 明确更正或更高序列覆盖 | 允许，需进入人工裁决 | 返回当前值 + 来源 |
| AIBT | 实际到位时间 | 地服 / 机场运行 | 航司 | 地服 / 机场运行优先 | 实际时间不过期，但可被更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
| EIBT | 预计到位时间 | 系统计算 | 运行动态派生 | 系统计算缺省 `estimated` | 新估算生成后旧值过期 | 新估算覆盖旧估算并留历史 | 允许 | 返回当前值 + 可信度 |
| AOBT | 实际推出时间 | 地服 / 机场运行 | 航司 | 地服优先 | 实际时间不过期，但可更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
| ATOT | 实际起飞时间 | ANSP | 航司 / 机场运行 | ANSP 优先 | 实际时间不过期，但可更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
| Flight Status | 航班状态摘要 | Published Fact 推导 | 人工裁决 | 由里程碑和取消状态综合推导 | 状态持续有效直到新事实生成 | 更正走 Published Fact 重新计算 | 允许，需生成裁决事件 | 返回当前值 + 裁决摘要 |
| Cancelled Flag | 取消标记 | 航司 / 计划源 | 机场运行 | 航司取消优先 | 取消后持续有效，直到明确恢复 | 恢复必须有显式更正 | 允许，需高级别审计 | 返回当前值 + 来源 |
| Turnaround Link | 航班配对 | 系统配对 | 人工配对修正 | 人工修正高于自动配对 | 当关联航班变化时旧配对失效 | 更正产生 `TurnaroundCorrected` | 允许 | 返回当前值 + link_confidence |
| Stand Assignment | 资源分配 | 机场运行系统 | 人工调度 | 自动分配默认为 `estimated`，人工为 `confirmed` | 时间窗失效后不再生效 | 新分配替换旧分配并保留历史 | 必须支持 | 返回当前值 + 覆盖摘要 |
| Gate Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
| Belt Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
| Counter Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
## 4. 冲突裁决优先级
当多个 Observation 竞争同一字段时，按以下顺序裁决：
1. 字段权威来源优先级
2. 明确更正 / 更高版本号
3. `confidence`
4. `occurred_at`
5. `source_sequence` 或 `ingest_sequence`
6. 人工裁决
## 5. 最小输出契约
对外查询至少返回：
- `current_value`
- `source`
- `confidence`
- `last_decision_summary`（可空）
- `updated_at`
- `data_quality_flags`
## 6. 测试场景
1. ALDT 出现 ANSP 与航司冲突，系统自动按来源优先级裁决。
2. TOBT 出现多个地服更正，系统按更正版本和时间序列更新。
3. Stand Assignment 在延误后重新分配，旧分配转历史，新分配变当前值。
4. Turnaround 自动配对后被人工修正，系统产生 `TurnaroundCorrected`。
5. Cancelled Flag 被恢复时，必须有显式更正，不允许静默取消取消状态。
airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md
-176
View File
@@ -1,176 +0,0 @@
# AODB 最小部署拓扑草案
## 1. 文档定位
本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于细化高层设计中的部署、SLO 和容灾约束。
## 2. 目标
- 以单机场私有化部署为前提
- 优先满足当前态统一、事件不丢、审计可回放
- 用最少组件完成可恢复、可观测、可演练的运行形态
## 3. 逻辑拓扑
```text
+-------------------------+
| External Systems |
| SSIM / AIDX / AFTN |
+------------+------------+
|
v
+-------------------+
| Kong Gateway |
+-------------------+
|
+---------------+----------------+
| | |
v v v
+----------------+ +----------------+ +------------------+
| Flight Service | | Milestone Svc | | External API Svc |
+----------------+ +----------------+ +------------------+
| | |
+-------+-------+----------------+
|
v
+----------------------+
| PostgreSQL/Timescale |
| Current + Audit + |
| Outbox |
+----------+-----------+
|
v
+---------------+
| CDC/Publisher |
+-------+-------+
|
v
+-------+
| Kafka |
+---+---+
|
+----------+-----------+
| |
v v
+----------------+ +----------------+
| Resource Svc | | Alert Service |
+----------------+ +----------------+
+----------------+
| Redis Cache |
+----------------+
+-------------------------------+
| Prometheus / Grafana / Loki |
+-------------------------------+
```
## 4. 部署分区建议
### 4.1 状态层
- PostgreSQL / TimescaleDB
- Kafka
- Redis
要求：
- 与无状态服务分离部署
- 具备独立备份和恢复策略
### 4.2 无状态业务层
- Flight Operation Service
- Milestone Service
- Resource Service
- Alert Service
- External API Service
- CDC / Publisher
要求：
- 多副本
- 滚动升级
- 配置和密钥外置
### 4.3 平台观测层
- Kong
- Keycloak
- Prometheus
- Grafana
- Loki
## 5. 高可用建议
### 5.1 PostgreSQL / TimescaleDB
- 主备部署
- 定期全量备份 + WAL / PITR 能力
- 演练主备切换
### 5.2 Kafka
- 多 broker
- `replication factor >= 3`
- `min ISR >= 2`
- 消费位点外部可追踪
### 5.3 Redis
- 主从或哨兵
- 缓存失效不应影响核心写链路
### 5.4 无状态服务
- 至少 2 副本
- 健康检查 + 自动重启
- 发布器必须支持重复执行幂等
## 6. 最小恢复策略
### 6.1 数据库故障
- 切换到备实例
- 根据最近备份和 WAL 进行恢复
- 恢复后执行 Published Fact 与 Outbox 对账
### 6.2 Kafka 堆积或单 broker 故障
- Broker 恢复后消费者追赶
- 重点检查订阅延迟、DLQ 率、CDC 积压
### 6.3 CDC / Publisher 中断
- 根据 Outbox 位点断点续传
- 保证重复发布不产生重复副作用
### 6.4 查询层异常
- 核心写链路不中断
- 对外查询可降级，但订阅恢复后必须可补偿
## 7. 关键观测指标
| 指标 | 含义 |
| --- | --- |
| ingest_to_publish_latency_p95 | 接入到发布的 P95 延迟 |
| outbox_backlog | Outbox 堆积量 |
| cdc_publish_retry_count | 发布重试次数 |
| kafka_consumer_lag | 消费滞后量 |
| dlq_rate | 解析失败和旁路率 |
| conflict_mttr | 冲突平均处置时间 |
| review_task_open_count | 未关闭复核任务数 |
## 8. 关键演练场景
1. PostgreSQL 主备切换
2. Kafka 单 broker 故障恢复
3. CDC 中断和断点恢复
4. 订阅端断线重连与游标补偿
5. 关键字段回放抽检
## 9. 与高层设计的关系
- 本文档细化 `开源机场运营数据库（AODB）高层设计文档.md` 中的部署与 SLO 章节。
- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。
airport-wiki/concepts/aodb/AODB 核心需求提炼.md
-111
View File
@@ -1,111 +0,0 @@
# AODB 核心需求提炼
## 1. 文档定位
本文档定义 AODB 的业务目标、范围边界、核心能力和约束条件，作为高层设计和技术选型的上位输入。
- 目标对象：年旅客吞吐量 500 万至 3000 万的中型机场
- 目标系统：机场运营数据库（AODB）及其核心协同能力
- 使用方式：作为 `开源机场运营数据库（AODB）高层设计文档.md` 和 `开源技术栈选型决策.md` 的上位需求输入
## 2. 业务目标与范围
### 2.1 业务目标
1. 建立航班运营单一事实源（SSOT），消除多系统数据不一致。
2. 支撑航班计划、动态运行、资源分配和里程碑协同的闭环运营。
3. 通过事件驱动架构实现秒级数据传播，提升调度响应效率。
4. 以开源技术栈实现可控成本、可持续演进和私有化可部署能力。
### 2.2 范围边界
MVP（首期必须）：
- 航班计划导入（SSIM）与动态更新（AIDX/AFTN）
- 机位/登机口/行李转盘/值机柜台基础资源分配
- A-CDM 核心里程碑管理与变更发布
- 运营告警（延误、资源冲突）
- 外部数据共享接口（查询 + 事件订阅）
- 审计、裁决、人工复核闭环
非 MVP：
- 高级优化排班（全局优化/仿真）
- 深度 AI 预测（跨季节模型、异常解释）
- 多机场统一调度与集团化运营
- 起飞排序和复杂流处理平台化能力
### 2.3 范围约束
- 单机场优先，跨机场能力不作为 MVP 前提。
- MVP 聚焦“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为前提。
- 若外部系统稳定性不足，必须预留灰度、手工复核和数据质量标记兜底流程。
- 首期不要求深度历史迁移，只要求新接入链路具备统一主键、幂等和审计能力。
## 3. 功能需求清单
| 功能域 | 核心能力 | 输入 | 输出 | MVP |
| --- | --- | --- | --- | --- |
| 航班数据管理 | 航班计划导入、动态更新、历史回放、航班配对（Linking） | SSIM、AIDX、AFTN | 标准化航班主数据与状态流 | 是 |
| 资源管理 | 机位/登机口/行李转盘/值机柜台分配与冲突检测 | 航班状态、资源可用性、规则 | 资源分配结果、冲突事件 | 是 |
| A-CDM 里程碑 | 里程碑采集、校验、发布、追踪 | ANSP/航司/地服事件 | 里程碑状态、时序记录 | 是 |
| 裁决与复核 | 数据冲突复核、人工覆盖、事件重放 | 冲突事件、复核任务 | 裁决记录、发布事实 | 是 |
| 告警与预警 | 延误告警、冲突告警、超阈值告警 | 实时事件、规则配置 | 告警通知、处置状态 | 是 |
| 信息共享（ACISP） | 面向航司/管制/地服的数据查询与订阅 | 业务实体与事件 | 外部查询/订阅接口 | 是 |
| 实时计算增强 | EIBT/EXIT/EXOT 预测、TSAT 计算 | 运行态事件、历史统计 | 预测结果、排序建议 | P1 |
| 起飞排序（PDS） | TSAT/TTOT/EXOT 规则计算与可追溯 | 里程碑、滑行预测、管制约束 | 排序建议与调整记录 | P1 |
## 4. 标准与集成要求
- AIDX（Aviation Information Data Exchange）：用于航班动态交换。
- SSIM Chapter 7：用于季节性时刻表批量导入。
- AFTN/SITA Type B：用于传统航电与运行消息接入。
- ACARS（可选）：用于补充机载状态数据接入。
集成约束：
1. 所有外部输入必须经过标准化映射层，生成统一内部事件模型。
2. 所有关键写入必须具备幂等键和可追溯来源字段。
3. 解析失败消息必须进入死信队列并提供人工复核入口。
4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。
## 5. 非功能需求
| 维度 | 目标值 | 最低可接受值 | 说明 |
| --- | --- | --- | --- |
| 可用性 | 月度 99.95% | 月度 99.9% | 保障核心运行时段可用 |
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 覆盖接入到发布事实主链路 |
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 当前态和事件流必须可对账 |
| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 支撑单机场容灾恢复 |
| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 覆盖自动裁决和人工动作 |
| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 对外查询和订阅必须受控 |
## 6. 架构约束
- Flight 当前态必须只有一个写主，不允许多个系统直接并行改写权威字段。
- 所有关键写入必须带来源、时间、幂等键和关联 ID。
- 原始观测、裁决记录、发布事实必须分层保存，不允许只保留当前值。
- 查询接口和事件订阅接口必须分离，不允许把查询层当作事实流输出。
- 人工覆盖、回滚和复核必须事件化、审计化。
## 7. 术语与缩写（权威定义）
| 缩写 | 定义 |
| --- | --- |
| AODB | Airport Operational Database，机场运营数据库 |
| SSOT | Single Source of Truth，单一事实源 |
| A-CDM | Airport Collaborative Decision Making，机场协同决策 |
| TSAT | Target Start-up Approval Time，目标放行时间 |
| TTOT | Target Take-off Time，目标起飞时间 |
| EXOT | Estimated Taxi-Out Time，预计滑出时间 |
| EXIT | Estimated Taxi-In Time，预计滑入时间 |
| EIBT | Estimated In-Block Time，预计靠桥时间 |
| Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 |
## 8. 关联文档
- `airport-wiki/concepts/aodb/开源技术栈选型决策.md`
- `airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md`
- `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md`
- `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md`
- `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md`
airport-wiki/concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-001 MVP 不引入 Flink
## 状态
Accepted
## 背景
首期目标是完成单机场 AODB 核心闭环，规模为 500 万至 3000 万旅客机场，优先解决当前态统一、资源冲突和审计问题。
## 决策
MVP 不引入 Flink。首期只保留 Kafka 事件骨干和应用服务内流式处理逻辑。预测、CEP 和复杂有状态计算推迟到 P1。
## 原因
- 首期复杂度应优先让位于交付确定性。
- 预测与复杂流处理不是首期闭环前提。
- Flink 会显著提高部署、运维和故障恢复复杂度。
## 后果
- MVP 中实时计算能力受限。
- 事件契约和聚合边界必须为未来引入 Flink 预留演进空间。
airport-wiki/concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-002 Kafka 作为唯一事件骨干
## 状态
Accepted
## 背景
AODB 需要支撑事件可回放、订阅分发、补偿和审计。
## 决策
Kafka 作为唯一事实事件骨干。所有对外事件订阅都以 Kafka 上的标准化事件为源头，禁止多路事件源头并存。
## 原因
- 统一重放和补偿语义。
- 避免“写库成功但未发布”或“已发布但未落库”的治理空洞。
- 降低外部消费者理解成本。
## 后果
- 事件可靠发布必须依赖 Outbox + CDC。
- 查询 API 不能被下游误当作事件事实源。
airport-wiki/concepts/aodb/adr/ADR-003 事实分层模型.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-003 事实分层模型
## 状态
Accepted
## 背景
AODB 需要同时处理多源观测、字段裁决和对外权威事实发布。
## 决策
采用 `Observation / Decision / Published Fact` 三层模型。
## 原因
- 让 SSOT 真正表示“经过治理后发布的事实”。
- 保证原始观测、人工覆盖和当前值三者不互相污染。
- 便于审计、回放和责任归因。
## 后果
- 数据模型和事件模型会更明确，但设计和实现复杂度略有上升。
- Published Fact 的任何变更都必须可追溯到 Observation 和 Decision。
airport-wiki/concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-004 FlightOperation 写主归属
## 状态
Accepted
## 背景
原方案中 Flight、Milestone、Resource、Alert 边界存在写入重叠风险。
## 决策
Flight 当前权威态只能由 `Flight Operation Service` 写入，其他服务只能产生观测、候选事实、资源事实或告警事实。
## 原因
- 避免多个服务共同修改同一当前态。
- 降低一致性和回放复杂度。
- 方便将 Published Fact 聚合到单一领域对象。
## 后果
- Milestone 和 Resource 服务必须通过事件影响 Flight 当前态。
- Flight Service 需要承担更明确的聚合协调责任。
airport-wiki/concepts/aodb/adr/ADR-005 Turnaround 独立建模.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-005 Turnaround 独立建模
## 状态
Accepted
## 背景
仅以单航班建模无法充分表达到离港配对、机尾号上下文和资源联动。
## 决策
将 `Turnaround` 作为首期核心领域对象，引入最小独立建模。
## 原因
- 支撑航班配对（Linking）需求。
- 提高资源分配和时序解释能力。
- 为换机、延误联动和周转分析提供上下文。
## 后果
- 文档和模型复杂度上升。
- 配对修正和不完整配对需要额外的事件和审计语义。
airport-wiki/concepts/aodb/adr/ADR-006 资源锁定模型.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-006 资源锁定模型
## 状态
Accepted
## 背景
单纯的资源时间窗分配无法表达建议分配、已确认分配和人工强制覆盖。
## 决策
ResourceAllocation 支持 `soft lock` 和 `hard lock` 两种锁定语义。
## 原因
- 表达自动建议和人工强制分配的区别。
- 支持冲突检测、覆盖和回滚的可解释性。
- 为未来优化排班预留空间。
## 后果
- 冲突检测和分配逻辑需要区分锁定强度。
- 人工覆盖必须伴随审计和事件输出。
airport-wiki/concepts/aodb/adr/ADR-007 查询与订阅分离.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-007 查询与订阅分离
## 状态
Accepted
## 背景
将 GraphQL Subscription 或查询层直接作为事实流会混淆读取和事件分发语义。
## 决策
对外查询接口和事件订阅接口分离设计。
## 原因
- 查询和事件分发的稳定性、回放、限流语义不同。
- 便于明确外部消费者的消费契约。
- 降低把查询接口误当权威事件骨干的风险。
## 后果
- 需要独立设计事件订阅网关或分发适配层。
- API 文档要分别描述查询和订阅契约。
airport-wiki/concepts/aodb/adr/ADR-008 Outbox 与 CDC.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-008 Outbox 与 CDC
## 状态
Accepted
## 背景
AODB 必须避免“写库成功但没发事件”或“发了事件但没落库”。
## 决策
采用 `Outbox Pattern + CDC` 作为写库与发事件一致性策略。
## 原因
- 能把数据库状态变化和事件发布绑定到同一事务边界。
- 适合首期 Kafka 作为唯一事件骨干的架构。
- 支持失败重试、断点恢复和事件回放。
## 后果
- 需要部署 CDC / 发布器组件。
- 发布流程和 Outbox 堆积需要专门监控。
airport-wiki/concepts/aodb/adr/ADR-009 PostgreSQL HA.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-009 PostgreSQL HA
## 状态
Accepted
## 背景
Published Fact、审计和 Outbox 都依赖 PostgreSQL，数据库可用性直接决定系统可用性。
## 决策
MVP 必须采用 PostgreSQL 高可用部署，并具备备份恢复和 PITR 或等价能力。
## 原因
- 满足 RTO / RPO 目标。
- 为审计、重放和一致性提供稳定基础。
- 避免首期把可靠性寄托在应用层补偿上。
## 后果
- 部署和运维门槛上升，但这是首期必须承担的复杂度。
- 需要单独演练主备切换和恢复流程。
airport-wiki/concepts/aodb/adr/ADR-010 人工裁决事件化.md
-24
View File
@@ -1,24 +0,0 @@
# ADR-010 人工裁决事件化
## 状态
Accepted
## 背景
AODB 中数据冲突、资源覆盖和解析失败都可能需要人工参与。
## 决策
所有人工裁决、人工覆盖和人工复核动作必须事件化和审计化，禁止仅通过数据库备注或日志留痕。
## 原因
- 人工动作是业务事实的一部分。
- 需要对外解释当前值为何成立。
- 便于回放、对账和合规审计。
## 后果
- Case 流程和审计模型需要更完整。
- 首期必须实现最小人工复核状态机。
airport-wiki/concepts/aodb/开源技术栈选型决策.md
-101
View File
@@ -1,101 +0,0 @@
# 开源技术栈选型决策
## 1. 决策目标与原则
本文档用于对 AODB 技术栈做唯一主选决策，避免多方案并列导致实施阶段反复。
决策原则：
1. 满足中型机场场景下的稳定性与可维护性。
2. 优先选择成熟开源生态和团队可落地能力。
3. 对核心路径采用单一主选，备选仅定义触发条件。
4. 支持私有化部署和后续多机场扩展。
5. MVP 优先收敛复杂度，不以技术先进性替代交付确定性。
## 2. 技术栈总览
### 2.1 MVP 主选
| 分层 | 主选方案 | 说明 |
| --- | --- | --- |
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
| 时序存储 | TimescaleDB | 里程碑、观测与审计时间序列 |
| 缓存与热点读 | Redis 7 (Valkey) | 高频读、短期缓存、去重辅助 |
| 事件总线 | Apache Kafka 3.x | 统一事件骨干和可回放能力 |
| 协议集成 | Apache Camel | AIDX / AFTN / SITA 协议适配 |
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
| 认证授权 | Keycloak 24 | OIDC / OAuth2 与 RBAC |
| 可观测性 | Prometheus + Grafana + Loki | 指标、看板、日志观测 |
| 容器平台 | Kubernetes + Helm | 标准化部署与环境一致性 |
### 2.2 后续启用组件
| 组件 | 定位 | 启用触发条件 | 当前决策 |
| --- | --- | --- | --- |
| Flink | 有状态流处理、预测、CEP | EIBT / EXIT / EXOT 预测进入上线范围，且简单流式处理无法满足延迟和可恢复性目标 | P1 |
| Drools | 复杂规则平台 | 规则量、规则变更频率和回放需求超过代码化规则可维护边界 | P1 |
| Temporal | 长流程编排与补偿 | 人工复核、跨系统补偿和状态机复杂度超出单服务事务编排能力 | P1 |
| Hasura | 快速 GraphQL 查询与订阅暴露 | 前端字段裁剪、实时订阅和权限编排复杂度显著上升 | 可选 |
| OpenSearch | 搜索与分析投影 | 全文检索、复杂检索、跨字段搜索成为上线能力 | P1 |
| Linkerd | 服务间 mTLS 与服务治理 | 服务数量、零信任要求和多团队治理复杂度显著增加 | 可选 |
| MinIO | 对象存储 | 需要保存批量导入文件、报文附件和复核证据对象 | 可选 |
| React + TypeScript + PWA | 运营终端前端栈 | 本期建设自研终端而非只做系统接口时启用 | 可选 |
## 3. 关键决策与备选触发条件
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
| --- | --- | --- | --- | --- |
| 搜索引擎 | 暂不纳入 MVP | OpenSearch | 上线阶段需要全文检索、复杂筛选和日志联动检索时 | MVP 不为未来检索需求预埋过重组件 |
| GraphQL 引擎 | 暂不纳入核心路径 | Hasura / PostGraphile | 面向运营终端的字段选择和订阅编排复杂度上升时 | 查询接口与事件骨干分离 |
| 工作流引擎 | 暂不纳入 MVP | Temporal | 人工复核和补偿流程演进为复杂长事务时 | MVP 先用应用服务内状态机 |
| 服务网格 | 暂不纳入 MVP | Linkerd / Istio | 服务间零信任、mTLS 和流量治理要求增强时 | 中型机场首期不引入服务网格 |
| 流处理引擎 | 暂不纳入 MVP | Flink | 预测 / CEP / 大规模乱序处理成为上线前提时 | 首期不以预测能力为闭环前提 |
| 规则引擎 | 代码化规则 + 版本化配置 | Drools | 规则规模和运营配置频率显著增长时 | 降低首期认知与运维成本 |
## 4. 分层选型理由（精要）
### 4.1 数据层
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
- Redis 负责热点读、去重辅助和临时缓存，减轻主库读取压力。
- 首期不引入搜索引擎，避免为非关键路径增加一套额外状态系统。
### 4.2 消息与处理层
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
- 首期不引入 Flink，先聚焦标准化、裁决、发布事实和资源冲突闭环。
- 首期规则逻辑采用应用内代码化实现，并以版本化配置和回放测试约束演进。
### 4.3 集成与接口层
- Camel 统一协议适配，减少自研连接器维护成本。
- Kong 提供统一北向入口及治理能力。
- 查询接口和事件订阅接口分离，避免将查询层误用为事实事件骨干。
### 4.4 安全与基础设施层
- Keycloak 提供统一身份与授权管理。
- Kubernetes + Helm 提供标准化部署与环境一致性。
- 可观测性先聚焦指标、日志和告警，链路追踪和服务网格在服务规模扩大后再引入。
## 5. 风险与缓解
| 风险 | 影响 | 缓解措施 |
| --- | --- | --- |
| Kafka 运维门槛高 | 实施初期效率下降 | 提供最小可运行拓扑、标准化 Topic 规划和 SRE Runbook |
| 多协议接入数据质量不稳定 | 里程碑发布事实误差 | 建立标准化校验、死信队列和人工复核流程 |
| 规则逻辑散落在服务代码 | 规则可维护性下降 | 统一规则目录、版本化配置和回放测试 |
| 未来再引入 Flink / Temporal 成本上升 | 迁移复杂度提升 | 通过事件契约、聚合边界和 ADR 先锁死演进接口 |
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
## 6. 版本与升级策略
- 技术栈版本采用“年度主版本评审 + 季度补丁更新”策略。
- 升级优先级：安全补丁 > 稳定性修复 > 新功能。
- 升级前必须完成回归测试、性能基线对比和回滚演练。
## 7. 与架构文档的边界
- 本文档回答“首期选什么、为什么选、何时启用后续组件”。
- 具体数据模型、事件契约、流程编排细节在 `开源机场运营数据库（AODB）高层设计文档.md` 中定义。
- 本文档不替代 ADR；关键决策以 `airport-wiki/concepts/aodb/adr/` 下文件为准。
airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md
-510
View File
@@ -1,510 +0,0 @@
# 开源机场运营数据库（AODB）高层设计文档
## 1. 文档目标
本文档定义 AODB MVP 的技术方案基线，重点回答以下问题：
1. AODB 在 MVP 内承载哪些业务闭环，以及哪些能力明确不做。
2. 系统如何划分聚合、服务、数据流和事件边界。
3. 航班、里程碑、资源、告警等核心对象如何建模。
4. 发布事实如何在观测、裁决、审计和订阅之间保持一致。
5. 查询、订阅、部署、容灾和可观测性如何落到可实现架构。
适用范围：年旅客吞吐量 500 万至 3000 万机场，优先支持单机场部署。
## 2. 设计原则
- 单一事实源：AODB 对外发布单一当前权威事实，不暴露“谁最后写入”式伪一致。
- 事实分层：原始观测、裁决记录、发布事实必须分层建模。
- 写主清晰：每个核心聚合只允许一个服务写入，避免跨服务共享可变状态。
- 事件驱动：状态变化通过事件传播，系统通过契约解耦。
- 规则可解释：字段权威、冲突裁决、人工覆盖必须可追溯、可回放、可解释。
- 渐进复杂度：MVP 先建立稳定闭环，不引入复杂优化平台和长事务编排平台。
## 3. 范围定义
### 3.1 MVP 范围
首期只覆盖以下闭环：
- 航班计划导入与实时状态更新
- 航班配对与过站上下文最小建模
- 基础资源分配：Stand、Gate、Belt、Counter
- 关键里程碑跟踪与发布事实治理
- 延误、资源冲突和数据质量告警
- 对外查询接口与事件订阅
- 审计、人工裁决、重放与复核闭环
### 3.2 非 MVP 范围
首期不纳入以下能力：
- 全局优化排班和复杂资源优化求解
- 深度 AI 预测和自适应调度
- Flink 驱动的复杂 CEP 平台
- Temporal 驱动的复杂长事务工作流平台
- 多机场统一调度中心能力
## 4. 总体架构
### 4.1 架构分层
| 层级 | 主要能力 | MVP 主路径组件 | 说明 |
| --- | --- | --- | --- |
| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 接收计划、动态、资源和人工操作输入 |
| 业务层 | 航班当前态、观测治理、资源分配、告警处置、外部接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 承担领域逻辑和对外契约 |
| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 负责异步传播和回放 |
| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | 保存当前态、审计链路和热点读模型 |
| 平台层 | 认证鉴权、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | 提供运行时底座 |
### 4.2 核心技术链路
MVP 主链路采用“接入标准化 -> 观测入库 -> 裁决生成 -> 发布事实更新 -> 事件发布 -> 查询/订阅消费”的结构：
1. 外部计划或运行动态通过接入层进入系统。
2. Milestone Service 将输入标准化为 Observation，并按幂等键写入。
3. 规则引擎根据字段权威矩阵和当前上下文生成 Decision。
4. Flight Operation Service 更新 Published Fact 和当前状态摘要。
5. 同一事务内写入 Outbox，由 CDC 发布到 Kafka。
6. External API Service 对外提供查询接口和事件订阅接口。
7. 告警、人工裁决和重放都沿同一事实链路工作，不直接绕过 Published Fact。
### 4.3 领域划分与聚合边界
为避免多服务共同修改同一业务对象，MVP 采用以下聚合边界：
| 聚合 | 职责 | 主键 | 写主 | 发布事件 | 只读依赖 |
| --- | --- | --- | --- | --- | --- |
| FlightOperation | 航班当前权威态、运行状态、发布事实 | `flight_id` | Flight Operation Service | `FlightUpdated`、`PublishedFactUpdated` | Turnaround、MilestoneObservation、ResourceAllocation |
| MilestoneObservation | 里程碑原始观测、标准化观测、候选事实 | `observation_id` | Milestone Service | `MilestoneObserved`、`MilestoneNormalized` | FlightOperation |
| Turnaround | 到达航班、离港航班、飞机周转上下文 | `turnaround_id` | Flight Operation Service | `TurnaroundLinked`、`TurnaroundCorrected` | FlightOperation |
| ResourceAllocation | 资源占用、锁定、冲突、覆盖 | `allocation_id` | Resource Service | `ResourceAssigned`、`ResourceUnassigned`、`ResourceConflictDetected` | FlightOperation、Turnaround |
| AlertCase | 告警和处置对象 | `alert_id` | Alert Service | `AlertRaised`、`AlertAcknowledged`、`AlertCleared` | FlightOperation、ResourceAllocation |
边界约束：
- Flight 当前权威态只能由 `Flight Operation Service` 写入。
- Milestone Service 负责观测和候选事实，不直接改写 Flight 当前态。
- Resource Service 只拥有资源占用与冲突事实，不直接修改 Flight 当前态中的非资源字段。
- Alert Service 不产生业务事实，只管理处置状态和告警生命周期。
### 4.4 核心服务职责
- `Flight Operation Service`
- 管理 FlightOperation 当前态。
- 维护 Published Fact。
- 负责 Turnaround 建模和关联修正。
- `Milestone Service`
- 接收外部运行动态。
- 解析、标准化并形成 MilestoneObservation。
- 依据字段权威矩阵给出候选事实。
- `Resource Service`
- 管理资源主数据和资源分配。
- 进行适配校验、冲突检测、人工覆盖和回滚。
- `Alert Service`
- 管理告警、确认、关闭、抑制和处置轨迹。
- `External API Service`
- 提供查询接口。
- 提供事件订阅接口或订阅分发适配层。
- 不作为权威事实生成者。
## 5. 核心模型
### 5.1 核心标识约定
- Flight
- `flight_key`：`carrier + flight_number + op_date + leg_no`
- `flight_id`：内部不可变主键
- Turnaround
- `turnaround_id`
- 可关联一个到达航班和一个离港航班
- MilestoneObservation
- `observation_id`
- 幂等键优先使用上游报文 ID、序列号或批次 + 行号
- Resource
- `resource_id`
- `resource_type + resource_code` 唯一
- ResourceAllocation
- `allocation_id`
- 幂等键由 `resource_id + validity_window + assignment_source + correlation_id` 组合约束
### 5.2 核心实体与关系
- FlightOperation：指定运行日上的航班运行对象，包含当前发布事实和状态摘要。
- Turnaround：将到达航班、离港航班和飞机周转上下文关联起来，用于资源和时序联动。
- MilestoneObservation：里程碑观测记录，保留原始来源、标准化结果和候选事实。
- Resource：资源主数据，MVP 覆盖 Stand、Gate、Belt、Counter。
- ResourceAllocation：资源分配记录，含有效窗口、锁定类型、来源和覆盖原因。
- AlertCase：告警对象，关联 FlightOperation 或 ResourceAllocation。
- DataQualityFlag：对冲突、低可信度、超窗乱序、待裁决等问题做结构化标记。
关系约束：
- 一个 FlightOperation 对应多个 MilestoneObservation。
- 一个 Turnaround 可关联一个到达航班和一个离港航班，也允许只有单侧航班待补全。
- 一个 Resource 在时间轴上可关联多个 ResourceAllocation，但硬冲突不允许同时生效。
- AlertCase 可关联具体 FlightOperation、Turnaround 或 ResourceAllocation。
### 5.3 FlightOperation 最小字段组
- 主键：`flight_id`、`flight_key`
- 属性：`carrier`、`flight_number`、`op_date`、`leg_no`、`direction`
- 机体上下文：`aircraft_type`、`tail_number`（可空）
- 状态：`flight_status`
- 发布事实：计划 / 预计 / 实际时间类字段
- 当前资源摘要：Stand / Gate / Belt / Counter
- 质量摘要：冲突标记、待裁决标记、最近裁决摘要
- 关联：`turnaround_id`（可空）
### 5.4 Turnaround 最小字段组
- `turnaround_id`
- `arrival_flight_id`
- `departure_flight_id`
- `tail_number`
- `aircraft_type`
- `turnaround_status`
- `link_source`
- `link_confidence`
约束：
- 配对可以晚于航班导入发生。
- 配对修正必须产生 `TurnaroundCorrected` 事件并保留审计。
- 若未知配对，FlightOperation 仍可独立运行，但资源和里程碑解释能力下降。
## 6. 事实分层模型
### 6.1 三层模型
| 层 | 含义 | 是否可变 | 用途 |
| --- | --- | --- | --- |
| Observation | 上游原始或标准化观测 | 否 | 追溯、回放、取证 |
| Decision | 规则或人工裁决结果 | 否 | 解释为什么当前事实成立 |
| Published Fact | 当前对外权威事实 | 是 | 查询、订阅、共享 |
### 6.2 SSOT 定义
AODB 的 SSOT 不等于“数据库中的最后一次写入”，而是：
- 由 Observation 输入
- 经字段级权威矩阵与裁决逻辑处理
- 最终形成并发布的 Published Fact
### 6.3 状态写入三元信息
所有关键状态写入都必须附带：
- `source`
- `confidence`
- `decision`（可空）
其中：
- Observation 必须保存原始来源和原始时序。
- Decision 必须保存裁决者、依据、原因和裁决时间。
- Published Fact 必须能追溯到 Observation 和 Decision。
### 6.4 字段级权威矩阵（最小集）
| 字段 | 主来源 | 次来源 | 更正规则 | 人工覆盖 | 对外可见性 |
| --- | --- | --- | --- | --- | --- |
| ALDT | ANSP / 机场运行 | 航司 | 明确更正或高版本号优先 | 允许 | 返回当前值 + 来源 |
| AIBT | 地服 / 机场运行 | 航司 | 同上 | 允许 | 返回当前值 + 来源 |
| EIBT | 系统计算 | 运行动态派生 | 新计算覆盖旧计算并留历史 | 允许 | 返回当前值 + 可信度 |
| TOBT | 航司 / 地服 | 机场运行 | 最新有效更正优先 | 允许 | 返回当前值 + 裁决摘要 |
| TSAT | AODB / P1 PDS | 机场运行 | 新计算版本优先 | 允许 | 返回当前值 + 算法版本 |
| Stand Assignment | 机场运行系统 | 人工调度 | 人工覆盖优先并保留原因 | 必须审计 | 返回当前值 + 覆盖摘要 |
| Gate Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
| Belt Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
| Counter Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
## 7. Flight 状态模型
### 7.1 最小状态机
- Planned：已导入计划但尚无有效运行动态。
- Active：已有运行动态、里程碑或资源变更。
- Completed：已达到收敛里程碑并进入归档策略。
- Cancelled：取消或无效，但保留完整历史。
### 7.2 状态迁移原则
- 状态迁移由 Published Fact 驱动，而不是由单个外部系统直接声明。
- 若存在冲突或裁决，不回滚 Observation 历史，只更新 Published Fact 和当前状态摘要。
- 状态修正必须能通过事件和审计链路回放。
## 8. 历史、审计与回放
### 8.1 数据存储视图
- `ObservationLog`
- 保存原始或标准化观测
- `DecisionLog`
- 保存规则命中和人工裁决
- `PublishedCurrentState`
- 保存当前对外权威事实
- `AuditTrail`
- 保存 `who / what / when / why`
### 8.2 基本约束
- PublishedCurrentState 的任何关键字段变更都必须能在 ObservationLog 和 DecisionLog 中找到原因链路。
- 人工覆盖不得改写原始 Observation，只能新增 Decision 并更新 Published Fact。
- 历史回放以事件和日志为准，不以任意时点快照为首期前提。
## 9. 资源模型与冲突治理
### 9.1 Resource 模型
每个 Resource 至少具备：
- `resource_id`
- `resource_type`
- `resource_code`
- `status`
- `capability_profile`
- `compatibility_constraints`
- `parent_resource_id`（可空）
- `operational_calendar`
### 9.2 ResourceAllocation 模型
每个 ResourceAllocation 至少具备：
- `allocation_id`
- `resource_id`
- `flight_id`
- `turnaround_id`（可空）
- `allocation_status`
- `assignment_source`
- `lock_type`（`soft` / `hard`）
- `validity_window`
- `override_reason`（可空）
- `derived_from_event`
- `conflict_flags`
### 9.3 冲突分类
| 冲突类型 | 说明 | 是否阻断 | 是否允许人工覆盖 |
| --- | --- | --- | --- |
| 时间冲突 | 占用时间窗重叠 | 是 | 是 |
| 适配冲突 | 机型、能力或运行属性不匹配 | 是 | 受限 |
| 状态冲突 | 资源停用、维护、冻结 | 是 | 否 |
| 策略冲突 | 本地策略或运营规则违反 | 视规则 | 是 |
### 9.4 四类资源规则口径
- Stand
- 关注机型适配、拖曳、到离港时间窗、过站联动。
- Gate
- 关注旅客流程时间窗、国际国内属性、步行距离和能力约束。
- Belt
- 关注到港时序、机型、行李量经验参数和恢复能力。
- Counter
- 关注值机开放窗口、航司差异化规则和共享柜台能力。
### 9.5 人工覆盖原则
- 自动分配只产生建议或默认分配。
- 人工覆盖必须记录原因、证据、操作者和影响范围。
- 回滚必须和覆盖一样事件化和审计化。
## 10. 事件模型与一致性
### 10.1 事件分类
| 事件类别 | 说明 | 示例 |
| --- | --- | --- |
| Domain Events | 聚合内部事实变化 | `FlightUpdated`、`ResourceAssigned` |
| Integration Events | 对外共享的标准化事件 | `PublishedFactUpdated`、`AlertRaised` |
| Audit Events | 审计和裁决事件 | `ManualDecisionRecorded` |
| Case Events | 人工复核和告警处置状态变化 | `ReviewTaskOpened`、`AlertAcknowledged` |
### 10.2 MVP 事件清单
- `FlightImported`
- `FlightUpdated`
- `TurnaroundLinked`
- `TurnaroundCorrected`
- `MilestoneObserved`
- `MilestoneNormalized`
- `PublishedFactUpdated`
- `ResourceAssigned`
- `ResourceUnassigned`
- `ResourceConflictDetected`
- `AlertRaised`
- `AlertAcknowledged`
- `AlertCleared`
- `DataQualityFlagged`
- `ManualDecisionRecorded`
- `ReviewTaskOpened`
- `ReviewTaskClosed`
### 10.3 事件归属表
| 事件 | 归属聚合 | 触发条件 | 是否对外发布 | 是否可回放 |
| --- | --- | --- | --- | --- |
| `MilestoneObserved` | MilestoneObservation | 收到有效运行动态 | 否 | 是 |
| `PublishedFactUpdated` | FlightOperation | 当前权威事实发生变化 | 是 | 是 |
| `ResourceAssigned` | ResourceAllocation | 资源分配生效 | 是 | 是 |
| `ResourceConflictDetected` | ResourceAllocation | 检测到冲突 | 是 | 是 |
| `ManualDecisionRecorded` | Decision / Audit | 人工裁决完成 | 是 | 是 |
| `AlertRaised` | AlertCase | 达到告警条件 | 是 | 是 |
### 10.4 统一事件信封
所有业务事件必须具备：
- `event_id`
- `event_type`
- `schema_version`
- `occurred_at`
- `produced_at`
- `source`
- `idempotency_key`
- `correlation_id`
- `aggregate_id`
- `payload`
### 10.5 幂等、顺序和更正语义
- 所有写入事件必须携带 `idempotency_key`。
- 顺序保证以 `flight_id` 为最小粒度。
- 更正必须显式表达，不允许静默覆盖已发布事实。
- 乱序允许在可配置窗口内重排，超窗进入审计旁路并打数据质量标记。
### 10.6 写库与发事件一致性
MVP 采用 `Outbox Pattern + CDC`：
- 业务服务在同一事务内更新 PublishedCurrentState 并写入 Outbox。
- CDC / 发布器将 Outbox 可靠发布到 Kafka。
- 发布失败必须可重试、可恢复、可审计。
## 11. 查询接口与事件订阅
### 11.1 接口分离原则
- 查询接口负责读取 Published Fact、历史明细和告警状态。
- 事件订阅负责分发标准化事件流。
- 查询接口不是事实流；订阅接口不承担读模型查询职责。
### 11.2 查询接口
最小查询对象：
- FlightOperation 当前态
- MilestoneObservation 明细
- ResourceAllocation 生效集
- AlertCase 生命周期
最小要求：
- 支持按 `op_date`、`flight_id / flight_key`、资源类型、状态过滤
- 返回更新时间和数据版本
- 关键字段返回 `source / confidence / decision summary`
### 11.3 事件订阅接口
最小要求：
- 按 `event_type`、`flight_id`、`op_date` 过滤
- 至少一次投递
- 支持断线重连和补偿
- 基于 `event_id` 或游标回放
- 支持租户隔离、连接数和推送速率限流
### 11.4 消费者契约
- 顺序仅保证到 `flight_id`
- 消费者必须按 `event_id` 去重
- 消费者必须处理数据质量标记和裁决摘要
- 回放窗口和游标语义必须文档化
## 12. 规则体系与人工复核
### 12.1 规则分类
- `authority rules`
- `validation rules`
- `conflict rules`
- `alert rules`
- `allocation heuristics`
### 12.2 规则最小模板
每条规则都必须定义：
- 输入
- 输出
- 优先级
- 命中条件
- 可解释字段
- 回放测试方式
### 12.3 人工复核对象
- 解析失败复核
- 里程碑冲突复核
- 资源冲突裁决
- 人工覆盖审批
### 12.4 Case 状态机
- `open`
- `assigned`
- `reviewing`
- `decided`
- `replayed`
- `closed`
原则：
- 所有人工动作都必须事件化。
- 所有人工动作都必须形成审计记录。
## 13. 非功能与部署
### 13.1 最小 SLO
| 指标 | 目标值 | 最低可接受值 |
| --- | --- | --- |
| 可用性 | 月度 99.95% | 月度 99.9% |
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 |
| 容灾恢复 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
| 审计覆盖率 | 100% 关键变更可追溯 | 99.9% 可追溯 |
### 13.2 最小部署拓扑
| 组件 | 部署方式 | 高可用方式 | 失败影响 | 恢复方式 |
| --- | --- | --- | --- | --- |
| PostgreSQL / TimescaleDB | Stateful 部署 | 主备切换 + 定时备份 | 当前态和审计写入受影响 | 备份恢复 + 故障切换 |
| Kafka | 多副本集群 | 副本和 ISR 保障 | 事件流中断或降级 | Broker 恢复 + 消费追赶 |
| CDC / 发布器 | 无状态服务 | 多副本 + 幂等发布 | Outbox 堆积 | 断点续传 + 重试 |
| API / 业务服务 | 无状态部署 | 多副本 | 查询或写入能力降级 | 滚动恢复 |
| Redis | 主从或哨兵 | 缓存级高可用 | 热点查询性能下降 | 重建缓存 |
### 13.3 关键容灾约束
- PostgreSQL 必须具备 PITR 或等价恢复能力。
- Kafka 必须明确 `replication factor`、`min ISR`、保留窗口和重放策略。
- Outbox / CDC 必须具备断点恢复和重复投递幂等能力。
- 容灾演练必须覆盖数据库切换、事件堆积、订阅重连和回放。
### 13.4 可观测性要求
- 所有写路径必须具备请求追踪、事件追踪和审计追踪三类关联 ID。
- 关键链路必须暴露延迟、失败率、积压量和重试次数指标。
- 人工裁决、资源覆盖和更正事件必须进入统一审计检索视图。
- 订阅接口必须暴露连接数、滞后量、推送速率和补偿次数指标。
## 14. 文档边界与引用
- 本文档定义首期可开工的技术方案，不展开字段级数据字典和实现细节。
- 技术栈主选和启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
- 需求边界以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
- 字段级权威矩阵以 `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md` 为准。
- 事件 envelope 和 payload 草案以 `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md` 为准。
- 最小部署拓扑和恢复策略草案以 `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md` 为准。
- 关键设计取舍以 `airport-wiki/concepts/aodb/adr/` 下 ADR 为准。
airport-wiki/concepts/flight-operations/a-cdm.md
-87
View File
@@ -1,87 +0,0 @@
---
title: A-CDM — Airport Collaborative Decision Making
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [operations, system, integration]
sources: [raw/articles/iata-acdm-toolkit-2025.md]
---
# A-CDM — Airport Collaborative Decision Making
## 定义
A-CDM（Airport Collaborative Decision Making，机场协同决策）是 IATA 与 Eurocontrol 联合推动的运营协同概念，通过建立信息共享机制，使机场各运营方（航司、机场、地面服务商、管制）在统一的操作视图下做决策，提升航班可预测性和机场整体效率。
## 核心原则
| 原则 | 说明 |
|------|------|
| **SSOT** | Single Source of Operational Truth — 所有参与方使用同一套数据 |
| **Milestone 标准化** | 统一关键运营事件和时间节点定义 |
| **Variable Taxi-Times（VTT）** | EXOT/EXIT 预测，减少滑行时间不确定 |
## 关键 Milestone
A-CDM 定义 16 项标准化时间节点（完整定义见 [[aodb-core#a-cdm-milestone-完整定义16项扩展版]]），核心项包括：
| 缩写 | 全称 | 中文 |
|------|------|------|
| TOBT | Target Off-Block Time | 目标推出时间（航司/地服录入） |
| TSAT | Target Start-Up Approval Time | 目标启动许可时间（= TTOT - EXOT） |
| CTOT | Calculated Take-Off Time | ATFM 计算起飞时间（流量管理） |
完整里程碑从 ELDT（预计落地）到 ATIGT（实际靠桥）覆盖航班全生命周期。
## A-CDM 系统架构
```
┌─────────────────────────────────────────────────────────────┐
│ A-CDM Systems │
├──────────────┬──────────────────┬──────────────────────────┤
│ AODB │ ACISP │ PDS │
│ 航班数据库 │ 信息共享平台（SSOT） │ Pre-Departure Sequencer │
│ │ │ TSAT = TTOT - EXOT │
└──────────────┴──────────────────┴──────────────────────────┘
```
### ACISP（A-CDM Information Sharing Platform）
- 多渠道接入（Web + 手持终端）
- 各参与方直接录入 TOBT 等数据
- 集成 AODB、VDGS、RMS、PDS、塔台、地面服务系统
### PDS（Pre-Departure Sequencer）
- 依据管制设定的离港率（departure rate）分配起飞序列
- 约束条件：CTOT（ATFM）、VTT、机位限制
- 软约束：航司优先级、航班互换、寒区优先权
- 核心公式：**TSAT = TTOT - EXOT**
## 参与方
1. **机场运营方（Airport Operator）** — 资源协调
2. **航司（Aircraft Operators）** — 提供 TOBT，提供航班动态
3. **地面服务商（Ground Handlers）** — 过站保障时间更新
4. **空管（ANSP）** — 提供跑道离港率和 CTOT
## A-CDM 效益
- 优化离港流量，减少航班在地面等待时间
- 提升航班准点率
- 与 ATFM（空管流量管理）实时联动
- 减少跑道容量浪费
- 增强不正常情况下的恢复能力
## 现状
- 全球已实施 A-CDM 的机场：**40+**（以欧洲为主）
- IATA 2025 年 6 月发布最新 **A-CDM Toolkit**
- 澳大利亚已将 A-CDM 深度整合入国家 ATFM 系统
## 相关链接
- [[aodb-core]] — A-CDM 的数据基础设施
- [[smgcs]] — 场面活动监控与 A-CDM 共享场面状态数据
- [[flight-data-exchange]] — 数据交换标准（IATA SSIM）
- [[deicing-operations]] — 除冰运营是 A-CDM 过站时间的重要变量
airport-wiki/concepts/flight-operations/agentic-ai-airports.md
-63
View File
@@ -1,63 +0,0 @@
---
title: 機場 Agentic AI
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [ai-ml, passenger, digital-twins, system]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 機場 Agentic AI（人工智能智能體）
## 概述
**Agentic AI（人工智能智能體）** 是具備自主決策能力的 AI 系統，能夠根據環境變化自動調整行為，無需人工逐例干預。在機場場景中，這代表 AI 從簡單的規則問答進化為能夠感知、推理、規劃並執行動作的智能實體。
在信息中心場景下，Agentic AI 驅動的虛擬助手和多語言聊天機器人能夠通過自然語言處理（NLP）與旅客進行流暢互動。
## 核心能力
### 1. 自然語言交互
AI 虛擬助手能處理文本和語音查詢，提供：
- 多語言實時翻譯
- 複雜問題理解與回答
- 上下文記憶與連續對話
### 2. 自主決策與執行
Agentic AI 不只是問答，而是能：
- 根據實時航班動態自動更新推送內容
- 根據客流密度自動調整航站樓環境參數
- 在檢測到異常排隊時自動觸發資源調度建議
### 3. 主動服務（Proactive Service）
從「被動響應」轉向「主動出擊」：
- 根據旅客行程、主動推送登機提醒
- 根據位置提供個性化餐飲/零售優惠
- 根據實時路況提供最優步行路線
## 典型案例：羅馬菲烏米奇諾機場（ADR）
2025 年底，羅馬機場引入生成式 AI 驅動的虛擬助手，提供：
- 停車信息與預訂
- 地面交通選擇
- 實時航班狀態
- 行李追蹤
- 個性化餐飲推薦
## 與傳統規則引擎的對比
| 維度 | 傳統規則引擎 | Agentic AI |
|------|------------|-----------|
| 交互方式 | 關鍵詞匹配 | 自然語言理解 |
| 適應能力 | 固定規則，無法自學習 | 持續學習，隨數據優化 |
| 決策能力 | 基於预设规则 | 自主規劃與執行 |
| 個性化 | 統一響應 | 根據旅客画像定制 |
## 相關概念
- [[future-airport-info-center]] — Agentic AI 是未來機場信息中心虛擬助手的技術核心
- [[digital-twins-airports]] — 數字孿生為 Agentic AI 提供實時物理環境感知數據
- hyper-personalization-airports — Agentic AI 驅動超級個性化服務
airport-wiki/concepts/flight-operations/airport-systems-landscape.md
-106
View File
@@ -1,106 +0,0 @@
---
title: 機場運營系統全景圖
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [system, integration, flight-data, comparison]
---
# 機場運營系統全景圖
## 系統層級架構
```
┌─────────────────────────────────────────────────────────────────┐
│ 應用服務層 │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌────────┐ │
│ │ 航班智能調度 │ │ 行李追蹤 │ │ 安防視頻分析 │ │ 機位優化 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌────────┐ │
│ │ 除冰管理 │ │ 旅客服務體驗 │ │ 場面活動監控 │ │ 碳排放管理│ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 數據交換層 │
│ SSIM │ AIRIMP │ CIDX │ IATA-OS │ XML real-time feeds │
├─────────────────────────────────────────────────────────────────┤
│ 核心數據中樞 │
│ │
│ ┌──────────────────────────────┐ │
│ │ AODB │ │
│ │ 機場運營數據庫（SSOT） │ │
│ └──────────────────────────────┘ │
│ ↑ ↓ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ A-CDM 協同 │ │ FIDS 顯示 │ │
│ │ 決策平台 │ │ 信息服務 │ │
│ └─────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 資源管理層 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌─────────────┐ │
│ │ RMS 機位 │ │ DCB 登機口 │ │ BHS 行李 │ │ SMGCS 場面 │ │
│ │ 資源管理系統│ │ 分配管理 │ │ 處理系統 │ │ 引導控制 │ │
│ └────────────┘ └────────────┘ └────────────┘ └─────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│ 感知探測層 │
│ │
│ ADS-B │ SMR雷達 │ Multilateration │ RFID │ VDGS │
│ 場面監視 │ 車輛追蹤 │ 飛機精確定位 │ 行李追蹤 │ 泊位引導 │
└─────────────────────────────────────────────────────────────────┘
```
## 核心系統職責對照
| 系統 | 全稱 | 核心職責 | 依賴關係 |
|------|------|---------|---------|
| **AODB** | Airport Operational Database | 航班數據中樞（SSOT），所有系統的單一數據源 | 上游：SSIM/Airline feeds；下游：幾乎所有系統 |
| **A-CDM** | Airport Collaborative Decision Making | 跨組織協同決策，TOBT/TSAT/TTOT 時間管理 | 依賴 AODB；輸出至 PDS 排序器 |
| **PDS** | Pre-Departure Sequencer | 起飛序列分配，CTOT 合規校核 | 依賴 A-CDM 的 TSAT/TTOT |
| **FIDS** | Flight Information Display System | 旅客信息顯示，實時航班動態 | 依賴 AODB 實時數據 |
| **RMS** | Resource Management System | 停機位分配與優化 | 依賴 AODB 航班計劃 |
| **DCB** | Departure Controller Working position / Gate Management | 登機口協調 | 依賴 AODB + RMS |
| **BHS** | Baggage Handling System | 行李分揀追蹤 | 依賴 AODB 航班動態；上游：SSIM CIDX |
| **SMGCS** | Surface Movement Guidance & Control System | 場面活動監視與引導 | 依賴 AODB + 場面雷達/ADS-B |
| **VDGS** | Visual Docking Guidance System | 飛機泊位精確引導 | 依賴 RMS 機位分配 |
| **CDM** | Collaborative Decision Making（A-CDM 核心） | 參與方協同，TOBT 共享 | 各運營方輸入 |
## 數據流向總圖
```
航司（EOBT/TOBT）
↓ SSIM / XML
AODB（航班數據中樞 SSOT）
↓
┌───┴───┐
↓ ↓
A-CDM FIDS
(協同) (顯示)
↓
PDS
(起飛排序)
↓
ANSP/塔台
```
## 關鍵標準與接口
| 接口標準 | 用途 | 格式 |
|---------|------|------|
| SSIM | 航班計劃批量交換 | Flat file |
| IATA-OS | 運營數據實時交換 | XML/JSON |
| CIDX | 地面保障/行李數據交換 | XML |
| ARINC 消息 | ATC/雷達數據 | ARINC 協議 |
| ASTERIX | 場面監視數據交換 | 二進制 |
| ADS-B | 飛機廣播式自動相關監視 | 1090ES |
## 相關鏈接
- [[aodb-core]] — AODB 核心概念與 A-CDM 架構
- [[a-cdm]] — A-CDM 協同決策系統
- [[smgcs]] — 場面活動引導控制
- [[baggage-handling]] — 行李處理系統
- [[flight-data-exchange]] — 數據交換標準詳解
- [[smart-gating]] — 智能登機口與機位優化
- [[deicing-operations]] — 除冰運營管理
> 参见：[[comparisons/airport-operations-systems]] — 供应商横向对比
airport-wiki/concepts/flight-operations/aocc-ioc.md
-81
View File
@@ -1,81 +0,0 @@
---
title: 機場運控中心（AOCC/IOC）
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [aocc, ioc, a-cdm, flight-data, system, ai-ml]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 機場運控中心（AOCC / IOC）
## 概述
**機場運控中心（Airport Operations Control Center，AOCC）** 或 **綜合運營中心（Integrated Operations Center，IOC）** 是機場數字化運營的神經中樞。它將機場內各子系統（航班流、旅客流、行李流、能源、安防）的數據統一匯聚，實現跨部門協同調度與全景可視。
典型功能：「運行一張圖」——在一個屏幕上展示機場整體運行狀態，支撑快速決策。
## 市場數據
| 指標 | 數值 |
|------|------|
| 市場規模（2026） | 18.38 億美元 |
| 市場規模（2034） | 40.5 億美元 |
| CAGR | 10.38% |
| 核心驅動 | 實時數據整合需求、跨部門協同 |
（來源：Fortune Business Insights, TAV Technologies, 2026）
## 核心功能
### 航班流統一調度
- 整合 A-CDM 數據（TOBT/TSAT/TTOT）
- 預測飛機推出時間，優化登機口分配
- 與空管、航空公司實時協同
### 旅客流監控
- 實時客流密度監控（安檢、排隊、登機口）
- 異常擁堵預警與自動疏導
- 與信息屏/移動端推送系統聯動
### 行李流追蹤
- 與 BHS 系統對接，實時行李狀態
- 延誤行李預警與後續航班協調
### 能源與設施管理
- 數字孿生支持預測性維護
- 暖通、空調、照明遠程調控
- 與 Net Zero 目標對接
## 典型廠商與方案
### 華為機場智能運控中心
基於 5G、雲計算和大數據底座，實現「運行一張圖」：
- 打破傳統系統的「數據孤島」
- 航班流、旅客流、行李流統一調度
- 數據來源：[[a-cdm]]、BHS、FIDS
### TAV Technologies
提供 IOC/AOCC 相關產品線，覆蓋機場運營控制全流程。
## 與 A-CDM 的關係
AOCC 是 A-CDM 的升級形態：
- A-CDM 專注於航班協同決策
- AOCC 擴展至機場所有運營維度（旅客、行李、能源、安防）
- 二者共享相同的數據底座（AODB）
詳見 [[a-cdm]]。
## 相關概念
- [[a-cdm]] — A-CDM 是 AOCC 的航班數據核心輸入
- [[aodb-core]] — AODB 是 AOCC 的統一數據底座
- [[future-airport-info-center]] — AOCC 為信息中心提供後台運行數據支撐
- [[digital-twins-airports]] — 數字孿生是 AOCC 實時監控與預測性維護的技術基礎
airport-wiki/concepts/flight-operations/aodb-china.md
-243
View File
@@ -1,243 +0,0 @@
---
title: AODB — 中國市場現狀與國產化替代
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [aodb, china-market, localization, travelsky, wanda-info, cetc, beijing-capital]
sources: [raw/articles/aodb.md]
---
# AODB — 中國市場現狀與國產化替代
> 本頁聚焦中國機場 AODB 市場的國產化進程、主要廠商與典型案例。國際供應商對比見 [[aodb-vendors]]。
## 政策背景與驅動力
### 標準規範
中國民航局高度重視機場信息系統的標準化與自主可控，相關核心標準：
| 標準 | 發布機構 | 說明 |
|------|---------|------|
| **MH/T 5103-2020** | 中國民航局 | 《民用運輸機場信息集成系統技術規範》—— 為國內 AODB 建設提供明確標準，定義了信息集成系統的架構、數據接口、功能要求 |
| **智慧民航建設路線圖** | 中國民航局 | 「十四五」和「十五五」規劃明確要求機場核心系統國產化比例提升，AODB 被列為重點攻關對象 |
| **數據安全法 / 個人信息保護法** | 全國人大 | 機場運營數據涉及航班、旅客個人信息，必須滿足數據本地化存儲要求，進口系統合規成本陡增 |
### 國產化驅動因素
1. **成本因素**：進口系統（尤其是 SITA、Amadeus）許可費和維保費昂貴，年度維保通常為初期許可費的 18-22%，長期成本負擔重
2. **數據安全**：進口系統的境外數據通道面臨嚴格審查，航班數據屬於關鍵信息基礎設施數據
3. **定制能力**：進口系統定制化開發需通過原廠，響應週期長、成本高
4. **自主可控**：類似北京首都機場案例，掌握核心技術才能真正保障重大活動期間的系統穩定性
---
## 主要國產廠商深度分析
---
### 1. 中國民航信息集團（TravelSky）— 機場信息集成系統
**定位：** 中國民航 IT 國家隊，PSS 領域絕對領導者，機場集成系統頭部供應商
#### 核心優勢
|| 維度 | 說明 |
|------|------|------|
| **數據天然互通** | 中國民航信息集團同時運營中國的 CRS（機票分銷系統）和 DCS（離港系統），與國航、南航、東航等主要航司數據天然打通，AODB 可直接獲取航班動態而無需額外接口 |
| **國產化標杆** | 2025 年實現離港系統（ DCS）全棧國產化，是民航業首家完成核心系統全棧國產化的企業，AODB 具備同樣的國產化能力 |
| **機場覆蓋廣** | 在國內中大型機場擁有廣泛的項目積累，熟悉國內民航業務流程和監管要求 |
| **政策支持** | 作為央企，在重大項目招投標中具備政策支持優勢 |
#### 現有產品線
| 產品 | 說明 |
|------|------|
| **機場信息集成系統（AIIS）** | 以 AODB 為核心的機場運營數據平台，支持航班動態、資源分配、計費結算 |
| **機場協同決策（A-CDM）** | 與 AODB 深度集成，支持 A-CDM 協同決策全流程 |
| **民航大數據平台** | 面向民航局的行業級數據分析平台 |
#### 目標場景
- 已有或計劃採用 TravelSky DCS 的機場
- 需要與國內航司數據無縫對接的機場
- 對數據本地化有剛性要求的大型樞紐
- 響應「智慧民航」政策要求的機場
---
### 2. 萬達信息股份有限公司 — 萬達機場集成系統（AIIS）
**定位：** 國內較早涉足機場信息化的上市企業，以上市公司標準化產品交付能力著稱
#### 核心技術特性
|| 特性 | 說明 |
|------|------|
| **AODB 為核心的集成架構** | 國內首家明確以 AODB 為核心的機場運營管理系統廠商，技術路線與國際標準接軌 |
| **全棧產品線** | 除了 AODB，還提供 FIDS、資源管理、行李追蹤等配套系統，減少多廠商集成複雜度 |
| **標準化程度高** | 產品化程度高，實施流程規範，降低項目風險 |
| **A股上市公司** | 具備穩定的資本市場支持，長期服務能力有保障 |
#### 典型部署案例
| 機場 | 規模 | 部署內容 |
|------|------|---------|
| **上海浦東國際機場** | 年旅客量 > 7000萬 | AODB + 資源管理核心模塊 |
| **寧波櫟社國際機場** | 年旅客量 ~ 1000萬 | 機場信息集成系統 |
| **溫州龍灣國際機場** | 年旅客量 ~ 1000萬 | 機場信息集成系統 |
#### 技術架構
- 數據庫：支持 Oracle / PostgreSQL
- 中間件：標准企業服務總線（ESB）
- 接口：支持 AIDX、XML、JSON API
- 部署：本地部署為主，支持混合雲
#### 目標場景
- 年旅客量 500 萬 - 5000 萬的中大型機場
- 偏好標準化、產品化交付以控制項目風險
- 需要一站式採購（減少多廠商協調成本）
- 以上市公司為長期服務商選擇標準
---
### 3. 中電科數字技術股份有限公司（CETC Digital）— 機場數字化
**定位：** 央企背景，機場弱電系統集成專家，智慧機場整體解決方案提供商
#### 核心優勢
|| 維度 | 說明 |
|------|------|------|
| **央企資源整合能力** | 中國電科集團在電子信息領域擁有完整產業鏈，能整合雷達、通信、計算、存儲等資源 |
| **弱電系統整合** | AODB 不僅是軟件系統，CETC 在機場弱電（網絡、數據中心、節點設備）的整體集成能力強 |
| **數據中心建設** | 參與多個千萬級機場的智慧化改造和數據中心建設，AODB 運行環境自主可控 |
| **軍民融合** | 繼承中國電科在軍航空管領域的技術積累，系統可靠性標準高 |
#### 主要能力
- **機場弱電總包**：網絡架構、數據中心、服務器集群的規劃與建設
- **核心軟件研發**：機場運營軟件平台的定製開發
- **智慧機場整體諮詢**：從規劃到交付的全過程服務
- **數據融合平台**：多源數據（空管、航司、地面服務）的統一路由與清洗
#### 典型項目
- **北京大興國際機場**：參與弱電系統集成（不僅是 AODB，而是整個數字化基礎設施）
- **成都天府國際機場**：智慧機場整體數字化規劃與實施
- **多個千萬級機場**智慧化改造項目
#### 目標場景
- 需要整個機場數字化基礎設施統籌建設的大型樞紐
- 對數據中心、網絡架構有自主可控要求的機場
- PPP / EPC 模式下的機場建設項目
- 需要央企信用背書和長期運維保障的政府機場
---
## 典型案例：北京首都國際機場 AODB 自主研發
首都機場作為中國最繁忙的樞紐（A級機場，年旅客量峰值超過 1 億），其 AODB 系統完成了從進口產品到完全自主可控的轉型，是中國機場 AODB 國產化最具代表性的案例。
### 背景與痛點
| 痛點維度 | 具體問題 |
|---------|---------|
| **成本** | 進口系統年度維保費用高昂，每年維保支出相當於新建系統費用的近四分之一 |
| **升級受限** | 核心技術掌握在原廠手中，功能升級需要依賴原廠開發，響應週期長 |
| **安全隱患** | 航班運營數據通過境外通道傳輸，面臨數據安全審查壓力 |
| **定制困難** | 機場特有業務需求（如特殊活動保障）難以在原系統中實現 |
### 實施路徑
1. **技術調研階段（3個月）**：信息技術團隊對原系統進行代碼級分析，摸清數據模型、業務邏輯和接口規範
2. **自主設計階段（2個月）**：參照 MH/T 5103-2020 標準，設計新系統架構，確保與國際標準接軌
3. **開發與測試（6個月）**：基於 Oracle + Java 技術棧完成核心功能開發，進行多輪壓力測試
4. **並行運行與割接（3個月）：新舊系統並行運行，逐步將流量遷移到新系統
**總工期：14個月**
### 核心成效
| 指標 | 改善前 | 改善後 |
|------|--------|--------|
| 每日航班計劃校驗次數 | 3次人工校驗 | 1次自動校驗 |
| 維護工作量 | 高（依賴原廠）| 降低30%+ |
| 重大活動保障響應 | 需要原廠支持 | 團隊自主可控 |
| 系統升級成本 | 高（原廠報價）| 大幅降低 |
> 首都機場的成功證明，大型樞紐 AODB 自主研發在技術上是可行的，關鍵在於有足夠的技術積累和14個月以上的持續投入。
### 適用性分析
| 因素 | 評估 |
|------|------|
| **技術可行性** | 高——民航信息技術團隊實力強，能掌握核心代碼 |
| **資源投入** | 高——需要10+人核心團隊，14個月以上工期 |
| **適用範圍** | 超大型樞紐（年旅客量>3000萬）有此實力和必要性；中小機場不建議自研 |
| **風險點** | 自研系統缺少大型樞紐實際運行驗證，保障重大活動前需充分測試 |
---
## 選型決策：國產 vs 進口
| 維度 | 國產廠商 | 進口廠商 |
|------|---------|---------|
| **政策合規** | 天然滿足數據本地化和國產化要求 | 需要額外數據安全審查 |
| **與國內航司數據互通** | TravelSky 等廠商天然具備數據通道 | 需要額外接口開發 |
| **國際航班數據覆蓋** | 覆蓋中國航司為主，國際航司依賴 SSIM/IAI接口 | Amadeus 等覆蓋全球95%+航司 |
| **定制化響應** | 本地團隊響應快，成本低 | 原廠響應慢，費用高 |
| **大型樞紐案例** | 首都機場（自研）、浦東等 | SITA 150+機場、Amadeus 700+機場 |
| **AI/ML 能力** | 較弱，處於追趕階段 | Amadeus、ADB Safegate 有原生AI能力 |
| **初期投資** | 較低（本地部署，性價比方案）| 高（許可費+實施費）|
| **長期維保成本** | 可控，本地團隊 | 高（年度維保 18-22% 許可費）|
### 建議路徑
**超大型樞紐（> 3000萬旅客）**：
- 有實力和資金 → 首都機場模式（自研，掌握核心技術）
- 需要快速交付 → SITA Operations Manager 或 Amadeus AODB
**中大型機場（1000-3000萬旅客）**：
- 首選國產頭部廠商（TravelSky、民航信科旗下產品）
- 已有進口 DCS/FIDS 系統 → 選擇與現有系統集成度好的方案
**中小型機場（< 1000萬旅客）**：
- 國產 SaaS 化輕量方案（按年訂閱，降低初期投入）
- RESA INFOPAX（歐洲產品，國內支持團隊需確認）
---
## 監管標準與合規要點
### MH/T 5103-2020 核心要求
《民用運輸機場信息集成系統技術規範》規定的 AODB 核心要求：
1. **航班數據管理**：支持航班計劃、動態數據的全生命周期管理
2. **資源管理**：停機位、登機口、行李轉盤等資源的分配與查詢
3. **數據分發**：向 FIDS、DCS、資源管理系統等下游系統分發數據
4. **接口標準**：支持與空管、航司、地面服務商的數據交換
5. **系統可靠性**：支持 7×24 小時運行，可用性 ≥ 99.99%
### 數據本地化要求
| 數據類型 | 存儲要求 |
|---------|---------|
| 航班計劃數據 | 必須本地存儲 |
| 旅客個人信息 | 必須本地存儲，符合《個人信息保護法》|
| 航班動態數據 | 必須本地存儲 |
| 跨境傳輸 | 需通過安全評估，涉及關鍵信息基礎設施需申報 |
---
## 相關鏈接
- [[aodb-core]] — AODB 核心概念、技術標準與 A-CDM 里程碑
- [[aodb-vendors]] — 國際供應商深度分析（SITA、Amadeus、Collins、RESA、ISO Software 等）
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
- [[flight-data-exchange]] — SSIM、AIDX、XML/CIDX 等數據交換標準
- [[comparisons/airport-operations-systems]] — 機場運營系統供應商全景對比
airport-wiki/concepts/flight-operations/aodb-core.md
-163
View File
@@ -1,163 +0,0 @@
---
title: AODB — 機場運營數據庫（核心概念）
created: 2026-04-08
updated: 2026-04-10
type: concept
tags: [aodb, flight-data, system, database, a-cdm]
sources: [raw/articles/aodb.md]
---
# AODB — 機場運營數據庫（核心概念）
> 本頁為 AODB 核心概念。供應商深度分析見 [[aodb-vendors]]。
## 定義
AODB（Airport Operational Database，機場運營數據庫）是機場信息系統的**核心數據中樞**，負責集中管理航班運營相關的所有靜態和動態數據，為各業務系統提供單一數據源（SSOT — Single Source of Truth）。
## 核心功能
| 功能 | 說明 |
|------|------|
| 航班數據管理 | 存儲航班計劃、動態更新、歷史記錄 |
| 資源管理 | 機位、登機口、設備、人員的配置與分配 |
| 運營事件註冊 | 記錄所有關鍵運營時間節點（A-CDM milestones） |
| 多源數據融合 | 支持 IATA SSIM、ARINC 協議、XML/CIDX、實時傳感器數據 |
| 實時計算 | 生成衍生數據（EIBT、EXIT 等預測值） |
| 告警與預警 | 航班延誤、衝突檢測、資源超負載告警 |
## AODB 在 A-CDM 架構中的位置
```
┌────────────────────────────────────────────────────────────┐
│ A-CDM Ecosystem │
├──────────────┬──────────────────────┬─────────────────────┤
│ AODB │ ACISP │ PDS │
│ 核心數據庫 │ 信息共享平台（SSOT） │ 起飛排序器 │
│ 航班數據中樞 │ │ TSAT = TTOT - EXOT │
└──────────────┴──────────────────────┴─────────────────────┘
↑
各航司/管制/地面服務商系統 ──────────────────────→
```
## 供應商概要對比
| 廠商 | 定位 | 典型機場規模 | 上線週期 |
|------|------|--------------|----------|
| ADB SAFEGATE Cortex | AI 驅動全棧樞紐平台 | >3000萬旅客 | 2-3個月 |
| Amadeus | 雲優先，95%全球航司覆蓋 | >1000萬旅客 | 1-2個月 |
| AirportLabs SkyCore | 雲原生，性價比方案 | 500萬-5000萬 | 2-4週 |
| PDC Aviation | 多機場模式，傳統穩定 | <2000萬旅客 | 1-2週 |
| Indra InBASE | Aena網絡，拉美標杆 | 所有規模 | 1-2個月 |
| **SITA Operations Manager** | **全球巨頭，超大型樞紐** | **>4000萬旅客** | **2-4個月** |
| Collins Aerospace AirDB | 混合部署，軍工級可靠性 | 所有規模 | 1-3個月 |
| RESA INFOPAX | 中小型，移動端出色 | <1500萬旅客 | 2-4週 |
| ISO Software SKYport | Oracle 技術棧，德系品質 | 500萬-3000萬 | 1-2個月 |
> 詳細供應商分析見 [[aodb-vendors]]
---
## 市場規模與增長趨勢
| 指標 | 數據 | 來源 |
|------|------|------|
| 全球機場信息系統市場（2024）| 42.4 億美元 | Research and Markets |
| 全球機場信息系統市場（2030）| 53.6 億美元（CAGR ~4%）| Research and Markets |
| **AODB 專項市場（2024）** | **約 8.2 億美元** | Growth Market Reports |
| **AODB 專項市場（2033）** | **超過 50 億美元** | Growth Market Reports |
AODB 市場增速顯著高於整體機場信息系統，反映智慧機場建設對核心數據中樞的剛性需求。
## 關鍵技術標準
### AIDX（Aviation Information Data Exchange）
IATA、ATA、ACI 共同認可的全球 XML 消息標準，用於航空公司、機場、第三方之間交換航班運營數據。是 SESAR A-CDM 信息交換的標準格式。所有現代 AODB 必須原生支持 AIDX 接口。
> 詳細規範（消息類型、XML 結構、運營狀態碼、A-CDM 里程碑代碼）見 [[flight-data-exchange]]。
### SSIM（Standard Schedules Information Manual）
IATA 定義的航班時刻表交換格式標準。AODB 需能解析 SSIM 文件（如 Chapter 7 格式），自動構建機場季節性航班計劃。
> 詳細規範（SCR 報文14字段格式、協調員響應代碼）見 [[flight-data-exchange]]。
### 傳統航空報文標準
即使 XML 和 API 日漸普及，AODB 仍需支持以下傳統格式以確保與老系統的互操作性：
| 標準 | 說明 |
|------|------|
| **AFTN** | 航空固定電信網報文，國家級空管數據骨幹 |
| **SITA Type B** | SITA 網絡報文格式，ARINC 兼容 |
| **ACARS** | 飛機通信尋址與報告系統，實時飛機動態數據 |
## 中國市場與國產化
中國民航局高度重視機場信息系統的標準化與自主可控。《民用運輸機場信息集成系統技術規範》(MH/T 5103-2020) 為國內 AODB 建設提供了明確標準。在「十四五」和「十五五」智慧民航建設規劃推動下，國產化替代進程顯著加速。
**典型案例：北京首都國際機場**
- 原有外資系統成本高、升級困難、存在安全隱患
- 歷時14個月，信息技術團隊從代碼級掌握核心技術，自主研發新一代 AODB
- 成效：每日航班計劃發布由3次人工校驗簡化為1次，維護工作量減少30%+
詳細國產廠商分析見 [[aodb-china]]。
## A-CDM Milestone 完整定義（16項擴展版）
| 縮寫 | 全稱 | 中文 | 更新責任方 |
|------|------|------|------------|
| ELDT | Estimated Landing Time | 預計落地時間 | 系統計算 |
| ALDT | Actual Landing Time | 實際落地時間 | ANSP（管制） |
| EOBT | Estimated Off-Block Time | 預計推出時間（航班計劃） | 航司 |
| AOBT | Actual Off-Block Time | 實際推出時間 | 地面服務商 |
| COBT | Calculated Off-Block Time | 計算推出時間（配合CTOT） | AODB |
| TOBT | Target Off-Block Time | 目標推出時間 | 航司/地面服務商 |
| TSAT | Target Start-Up Approval Time | 目標啟動許可時間 | AODB/PDS |
| TTOT | Target Take-Off Time | 目標起飛時間 | AODB/PDS |
| ATOT | Actual Take-Off Time | 實際起飛時間 | ANSP |
| CTOT | Calculated Take-Off Time | ATFM 計算起飛時間 | ATFM（Network Manager） |
| EXOT | Expected Taxi-Out Time | 預計滑出時間 | AODB VTT 模塊 |
| EIBT | Expected In-Block Time | 預計靠橋時間 | AODB VTT 模塊 |
| EXIT | Expected Taxi-In Time | 預計滑入時間 | AODB VTT 模塊 |
| AIBT | Actual In-Block Time | 實際靠橋時間 | 地面服務商 |
| ATIGT | Actual Time In Gate | 實際靠橋時間（通用） | 地面服務商 |
| TTIGT | Target Time In Gate | 目標靠橋時間 | AODB |
> 16項里程碑覆蓋航班從預計落地到靠橋的完整生命周期。AODB 需自動捕捉所有時間戳，觸發相應業務規則，並通過 AIDX 接口與各國流量管理系統（NMOC）交換數據。
## 選型決策樹
```
年旅客量 > 4000萬（超大型樞紐）
├── 需要極強數據治理 + IROPS 能力 → SITA Operations Manager
├── 需要全棧統一管理 + AI 預測 → ADB SAFEGATE Cortex AODB
└── 有實力自研 + 長期自主可控 → 首都機場模式（自研）
年旅客量 3000-4000萬
├── 需要全棧統一管理 → ADB SAFEGATE Cortex AODB
├── 已有 Amadeus Altéa → Amadeus AODB
└── 需要極強數據治理 → SITA Operations Manager
年旅客量 1000-3000萬
├── 需要快速上線 + 雲原生 → AirportLabs SkyCore AODB
├── 已有 Amadeus 系統 → Amadeus AODB
├── 預算有限 → RESA INFOPAX / ISO SKYport
└── 美洲/混合部署偏好 → Collins AirDB
年旅客量 < 1000萬
├── 多機場集團 → PDC AODB（Multi-Airport Mode）
├── 快速上線（< 2週）→ PDC AODB
├── 歐洲/非洲本地支持 → RESA INFOPAX
└── 拉丁美洲 Aena 網絡 → Indra InBASE AODB
```
## 相關鏈接
- [[a-cdm]] — A-CDM 依賴 AODB 作為核心數據源
- [[aodb-vendors]] — 5大供應商深度分析與技術對比
- [[flight-data-exchange]] — SSIM/XML 數據交換標準
- [[smart-gating]] — 機位管理系統依賴 AODB 數據
- [[baggage-handling]] — 行李系統與 AODB 航班動態聯動
- [[comparisons/airport-operations-systems]] — 供應商綜合對比
airport-wiki/concepts/flight-operations/aodb-vendors.md
-495
View File
@@ -1,495 +0,0 @@
---
title: AODB — 供應商深度分析
created: 2026-04-08
updated: 2026-04-10
type: concept
tags: [aodb, vendor, comparison, ai-ml]
sources: [raw/articles/aodb.md, raw/articles/aodb-manus-2026.md]
---
# AODB — 供應商深度分析
> 本頁為 AODB 供應商詳細分析。核心概念見 [[aodb-core]]。
## 主要供應商深度分析
---
### 1. ADB SAFEGATE — Cortex AODB
**定位：** 大型樞紐首選，AI 驅動全棧機場運營平台
#### 技術架構
| 層級 | 技術特性 |
|------|---------|
| 核心引擎 | AI/ML 引擎驅動資源分配和運營規劃 |
| 模塊化設計 | Flight Grids / Seasonal Schedule / Message Centre / Reference Data / Alarms |
| 數據驗證 | 表格邏輯校驗 + 多源數據優先級判定 |
| 仿真能力 | "What-if" 模擬，支持運營控制與效率評估 |
| 移動端 | 移動端優化界面，角色化信息定制 |
| 審計追踪 | 全操作審計日誌，支持多種格式導出 |
#### 核心技術特性
- **多源數據優先級判定**：多個來源的運營時間數據自動驗證和優先級排序
- **"What-if" 仿真模擬**：優化配置方案評估，支持管理決策
- **歷史數據同步**：過期數據自動歸檔至歷史表，支持在線查詢和賬單生成
- **集中告警模塊**：支持自定義規則觸發告警，覆蓋規劃與日常運營
- **參考數據統一分發**：統一管理 Reference Data，向 Cortex 生態模塊和第三方系統分發
#### 部署與安全
| 項目 | 詳情 |
|------|------|
| 部署方式 | Web 界面，雲托管 + 本地多種選項 |
| 安全認證 | ISO27001 認證，NIST 合規 |
| 安全監控 | 雲態勢配置檢測 + 異常行為識別 |
| 運維支持 | 全面安全監控覆蓋 |
#### 生態集成
- **Time2Integrate**：集成生態基礎，支持與停機位管理（Apron Manager）、場面燈控、VDGS 等第三方系統對接
- **ACISP 兼容**：原生支持 A-CDM 信息共享平台
- **Cortex 套件**：Service（CMMS 維護管理）、Apron Manager（機位管理）統一聯動
#### 目標場景
- 年旅客量 > 3000 萬的大型樞紐
- 需要 AODB + A-CDM + Smart Gating + SMGCS 統一管理
- 對 AI 預測分析有明確需求
---
### 2. Amadeus — Airport Operational Data Base
**定位：** 雲優先，95% 全球航司數據覆蓋，中大型機場
#### 技術架構
| 層級 | 技術特性 |
|------|---------|
| 部署模式 | 純雲托管（state-of-the-art data center），無本地基礎設施依賴 |
| 數據覆蓋 | 95% 全球航司，**提前 365 天**獲取航班計劃數據 |
| 數據更新 | 實時自動推送（Live feed），無需人工錄入 |
| 多站點支持 | 跨多機場同步運行，站點間航班數據實時共享 |
| 集成層 | 與 Amadeus Altéa DCS、H-RMS、PROPworks、BRS、Sequence Manager 深度整合 |
#### 核心模塊
| 模塊 | 功能 |
|------|------|
| **AODB Core** | 航班計劃與動態數據管理，提前 365 天可見 |
| **A-CDM Portal** | 實時停機坪視圖（雷達集成），協同運營儀表盤 |
| **Sequence Manager** | 歐洲 Eurocontrol CDM 合規，TSAT 智能計算 |
| **Turnaround Manager** | 過站階段監控，預測延誤連鎖效應 |
| **F-RMS** | 固定資源管理（登機口、行李帶），甘特圖界面 |
| **FIDS** | 航班信息顯示系統，自動從 AODB 拉取實時更新 |
#### A-CDM Portal 關鍵技術指標
- **雷達集成**：場面活動實時視圖，跟踪飛機位置
- **協同決策**：航司、地面服務商、管制共享同一操作視圖
- **非正常事件告警**：儀表盤高亮異常，支持下鑽分析
- **角色權限控制**：基於角色的數據訪問與更新分配
#### 與 Altéa 生態的協同優勢
Amadeus AODB 天然集成 Altéa（全球最廣泛使用的乘客服務系統），帶來獨特優勢：
- 航司 DCS 數據直連 AODB，passenger 動態實時反映
- 地面處理器可通過 Altéa DCS 直接錄入過站完成時間
- 賬單系統（BRS）基於 AODB 數據自動生成
#### 目標場景
- 已有或計劃採用 Amadeus Altéa 的機場
- 需要長周期航班規劃（365 天可見性）
- 希望減少本地 IT 基礎設施投入
- 多機場統一管理
---
### 3. AirportLabs — SkyCore AODB
**定位：** 雲原生、中型機場性價比方案，2025 年落地芝加哥 ORD
#### 技術架構
| 層級 | 技術特性 |
|------|---------|
| 基礎設施 | **Red Hat OpenShift**（雲原生 Kubernetes 平台）|
| 消息中間件 | **ActiveMQ**（實時數據流）|
| API 網關 | **3scale API Management**（安全、可擴展外部訪問）|
| 身份管理 | **Keycloak**（集中身份與訪問控制）|
| 架構模式 | **事件驅動**（Event-driven architecture）|
| 數據交換 | **雙向**實時交換，涵蓋所有關鍵系統 |
#### 核心功能
| 功能 | 說明 |
|------|------|
| **規則引擎編輯器** | 可視化配置業務規則，無需編碼 |
| **實時通知中心** | 所有運營corner實時推送 |
| **自服務能力** | 全運營環節自助服務 |
| **無限並發用戶** | 支持多公司用戶同時在線 |
| **模塊化計費** | 按需訂閱，只為所需組件付費 |
#### 生態系統集成
SkyCore AODB 並非孤立產品，而是 AirportLabs 全套生態的核心：
| 關聯產品 | 用途 |
|---------|------|
| **Allegra RMS** | 資源管理（機位優化分配）|
| **VisionAir FIDS** | 航班信息顯示 |
| **Laminar IQFMS** | 隊列管理 |
| **GCAM** | 登機口協調 |
| **Community App** | 機場內部通信 |
| **AirportLabs Billing** | 計費 |
| **ADR** | 機場數據倉庫 |
| **Pocket Flights** | 移動端航班追踪 |
#### 重大部署案例
- **芝加哥奧黑爾 ORD**（2025 年 8 月完成初始部署）
- 合作方：International Gate Control（IGC）
- 覆蓋：SkyCore AODB + Allegra RMS 核心功能
- 支持方：Chicago Department of Aviation（CDA）
#### 設計認可
- **Red Dot Award 2024**：用戶界面設計與最大可用性獲獎
#### 目標場景
- 年旅客量 500 萬 ~ 5000 萬的中型機場
- 需要快速部署（weeks 級別而非 months）
- 需要雙向數據交換和運營自動化
- 預算敏感但追求現代雲架構
---
### 4. PDC Aviation — AODB
**定位：** 多機場模式專家，北歐/加拿大系，小型機場快速上線
#### 技術架構
| 層級 | 技術特性 |
|------|---------|
| 架構模式 | **事件驅動**，服務器佔用小 |
| 數據庫 | **Oracle**（行業標準，可靠性高）|
| 開發語言 | Java + C（任務適配）|
| 數據交換 | **Publish-Subscribe Webservices**（發布-訂閱模式）|
| 消息格式 | XML 或 compact JSON |
| 接口支持 | Type-B 消息（SITA、ARINC）或 POP3 郵件 Type-B |
| 響應時間 | **1-2 秒**（事件驅動，實時性有保障）|
#### 核心能力
| 能力 | 說明 |
|------|------|
| **多機場模式（Multi-Airport Mode）** | 獨立機場或機場集團統一管理，單基礎設施架構 |
| **全在線可配置** | 基於表格配置，無硬編碼參數；隨機場成長在線更新 |
| **快速上線** | 小型機場**2 週**內完成部署和運營 |
| **PDC SCORE 集成** | Slot 協調數據實時接入，季節性航班數據從源頭獲取 |
| **全天候支持** | 7×24 小時支持（現場 + 遠程）|
#### 系統集成清單
| 系統類型 | 具體接入 |
|---------|---------|
| ATC | 雷達系統（AIMS）|
| Slot 協調 | PDC SCORE |
| BHS | 行李處理系統 |
| Docking | 泊位引導系統 |
| FIDS | 航班信息顯示系統 |
| AFAS | 自動航班到達系統 |
| Billing | 計費系統 |
#### 客戶案例
- **Aarhus Airport（丹麥）**：6 年無因系統問題導致的停機記錄
- **Torp Airport（挪威）**：6 年運行無停機，財務/質量經理背書
#### 目標場景
- 年旅客量 < 2000 萬的小中型機場
- 需要多機場統一管理（機場集團場景）
- 需要極快上線（競爭激烈的新興市場）
- 偏好傳統可靠 Oracle 技術棧
---
### 5. Indra — InBASE AODB
**定位：** Aena 親睞，西班牙/拉丁美洲最大機場網絡
#### 技術架構
| 層級 | 技術特性 |
|------|---------|
| 實現技術 | **J2EE**（業界標準）|
| 架構風格 | 開放式架構，完全可擴展 |
| CDM 合規 | **Level 3**（信息共享、協同飛行管理、起飛前排序、不利條件 CDM）|
| 部署模式 | 單機場或**多機場集中架構**（單基礎設施服務多個機場）|
#### 功能模塊
| 模塊 | 功能 |
|------|------|
| **核心模塊** | 實時管理、系統管理基礎信息管理、外部系統集成 |
| **編程模塊** | 生成系列信息（航班編程）|
| **調度模塊** | 從 slot 協調系統接收航班時刻表，實時部署運營信息 |
| **資源分配** | 圖形化界面管理值機櫃台、登機口、機位、行李提取帶 |
| **計費模塊** | 基於資源使用量向航司計費 |
| **KPI 報告** | 可定義運營指標（準點率、取消失）、告警閾值、儀表盤 |
#### 主要客戶
- **Aena（全球最大機場運營商）**：47 個機場生產運行
- 馬德里 Barajas（主要樞紐）
- 巴塞羅那 El Prat（主要樞紐）
- 覆蓋西班牙全境及拉丁美洲（Aena 擴張中）
- **GAP 機場網絡（墨西哥）**：rollout 進行中
#### 目標場景
- 已有 Indra 其他空管/機場系統的機場
- 拉丁美洲機場網絡
- 需要多機場集中管控
---
## 供應商綜合技術對比（9廠商）
|| 維度 | ADB SAFEGATE Cortex | Amadeus | AirportLabs SkyCore | PDC | Indra InBASE | SITA Operations Manager | Collins AirDB | RESA INFOPAX | ISO SKYport |
||------|---------------------|---------|---------------------|-----|--------------|----------------------|--------------|--------------|-------------|
| **部署模式** | 雲托管 + 本地 | 純雲 | 雲原生（OpenShift）| 本地/混合 | 本地/集中 | 雲托管 + 本地 | 混合部署 | 本地/SaaS | 本地/雲原生 |
| **數據庫** | 未公開 | 未公開 | PostgreSQL（推測）| Oracle | J2EE 標準 | 未公開 | 未公開 | 未公開 | Oracle |
| **消息中間件** | 未公開 | 私有 | ActiveMQ | Publish-Subscribe WS | JMS（推測）| 未公開 | 未公開 | 私有 | 未公開 |
| **AI/ML 能力** | 原生 AI 引擎 | 有限 | 規則引擎（可視化）| 無 | 無 | Total Optimizer AI（2024）| 動態資源分配 | 無 | 無 |
| **"What-if" 仿真** | 支持 | 否 | 否 | 否 | 否 | 支持 | 否 | 否 | 否 |
| **多機場模式** | 支持 | 支持 | 支持 | **原生多機場** | 集中架構 | 支持 | 支持 | 支持 | 支持 |
| **A-CDM 原生支持** | 是 | 是 | 是 | 是 | Level 3 CDM | 是 | 是 | 是 | 是 |
| **上線週期** | 2-3 個月 | 1-2 個月 | **2-4 週** | **1-2 週** | 1-2 個月 | 2-4 個月 | 1-3 個月 | 2-4 週 | 1-2 個月 |
| **數據覆蓋** | 依賴集成 | **95% 航司 365 天** | 依賴集成 | 依賴集成 | Aena 網絡 | 依賴集成 | 依賴集成 | 依賴集成 | 依賴集成 |
| **生態完整性** | 極強（Cortex 全套）| 強（Altéa 生態）| 強（AirportLabs 全套）| 中（PDC SCORE）| 中（Indra 空管）| 極強（SITA 全套）| 強（Collins 全套）| 中（RESA 計費）| 中（ISO 全套）|
| **國際案例規模** | 全球樞紐 | 全球大型 | 100+ 機場，ORD 旗艦 | 北歐/加拿大為主 | Aena 47 機場 | **150+ 機場** | 美洲/歐洲主流 | 歐洲/非洲中型 | 歐美中等規模 |
| **安全認證** | ISO27001, NIST | 未公開 | 未公開 | 未公開 | 未公開 | ISO27001 | 未公開 | 未公開 | 未公開 |
| **典型目標機場** | >3000萬 | >1000萬 | 500萬-5000萬 | <2000萬 | 所有規模 | **>4000萬** | 所有規模 | <1500萬 | 500萬-3000萬 |
## 關鍵技術差異分析
### AI 能力梯隊
|| 梯隊 | 廠商 | AI 能力 |
|------|------|---------|---------|
| 第一梯隊 | ADB SAFEGATE、SITA | ADB SAFEGATE 原生 AI 引擎 + ML；SITA Total Optimizer AI（2024年發布），支持機場整體運營優化 |
| 第二梯隊 | Amadeus、AirportLabs | Amadeus 有限 AI（輔助決策）；AirportLabs 規則引擎 + ML 可視化配置 |
| 第三梯隊 | Collins、RESA | Collins 動態資源分配算法（無原生 ML）；RESA 無 AI，純規則引擎 |
| 無 AI | PDC、Indra、ISO Software | 傳統規則驅動，無 AI/ML |
### 實時性能
|| 廠商 | 響應時間承諾 | 架構依據 |
|------|-----------|---------|
| PDC | **1-2 秒** | 事件驅動 + Oracle |
| Amadeus | 實時推送（< 5s）| 私有雲基礎設施 |
| ADB SAFEGATE | 實時（規格未公開）| 模塊化 + 內存計算 |
| AirportLabs | 實時流（ActiveMQ）| 事件驅動 + OpenShift |
| Indra | 實時（規格未公開）| J2EE 企業架構 |
| SITA | 實時（規格未公開）| SITA 私有全球骨幹網絡 |
| Collins | 實時（毫秒級 FIDS 同步）| AirVue FIDS 原生集成 |
| RESA | 實時（規格未公開）| 輕量級模塊化架構 |
| ISO Software | 實時（規格未公開）| Oracle 企業級架構 |
### 生態鎖定程度
|| 級別 | 廠商 | 說明 |
|------|------|------|
| **極高鎖定** | SITA | SITA 地面電信網絡、SITA@Airports 生態全綁定，換出成本極高 |
| **高鎖定** | Amadeus | 換出成本極高（Altéa PSS 深度綁定）|
| **中高鎖定** | ADB SAFEGATE | Cortex 套件深度集成，空側數據獨有 |
| **中鎖定** | AirportLabs、Collins | 全套生態但 API 開放；AirVue FIDS 集成 |
| **中低鎖定** | RESA、ISO Software | 模塊化但生態相對封閉 |
| **低鎖定** | PDC、Indra | Oracle + 標準 WS / J2EE 標準，易替換 |
## 相關鏈接
- [[aodb-core]] — AODB 核心概念與 A-CDM 架構
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
- [[comparisons/airport-operations-systems]] — 運營系統供應商全景對比
---
### 6. SITA — Operations Manager
**定位：** 全球航空 IT 巨頭，超大型樞紐首選，150+ 機場部署
#### 核心技術特性
|| 特性 | 說明 |
|------|------|
| **"最可信信源"引擎** | 區別於傳統 AODB 僅記錄數據，SITA 內置複雜業務規則引擎，能從多個衝突數據源中自動評估並選擇最準確的信息 |
| **Total Optimizer AI 平台** | 2024 年新推出 AI 驅動平台，將 AODB 數據與機器學習結合，實現機場整體運營（準點率、容量、環保指標）的動態優先級優化 |
| **主動預警機制** | 在航班延誤或資源衝突發生前提供預測性告警，支持 IROPS（不正常航班）快速恢復 |
| **全球 24/7 SGS 支持體系** | SITA Global Services 提供全天候多語言支持 |
#### 優勢與劣勢
|| 維度 | 評價 |
|------|------|------|
| **優勢** | 數據治理能力極強；全球覆蓋最廣；適合超大型多跑道樞紐；与 SITA Airports 生態無縫整合 |
| **劣勢** | 實施週期長；系統架構較重；定制化開發成本高昂；數據治理強但界面相對傳統 |
#### 目標場景
- 年旅客量 > 4000 萬的超大型國際樞紐
- 多機場集團統一管理（跨國家/地區）
- 對數據治理和 IROPS 恢復能力有剛性需求
- 已有 SITA 地面電信網絡和機場設施的機場
---
### 7. Collins Aerospace — AirDB (AirPlan)
**定位：** 部署靈活性極高，美洲/歐洲主流，軍民融合背景
#### 核心技術特性
|| 特性 | 說明 |
|------|------|
| **混合部署模式** | 支持本地數據中心、私有雲或公有雲部署，滿足不同機場的數據合規要求 |
| **AirVue FIDS 原生協同** | 與市場領先的 AirVue 航顯系統深度耦合，旅客獲取的信息與後台數據庫毫秒級同步 |
| **動態資源分配算法** | 支持社交距離邏輯（如間隔分配登機口和行李轉盤），後疫情時代新增 |
| **軍民融合背景** | Collins（Raytheon Technologies 子公司）繼承 ARINC 軍航技術積累，系統穩定性標準極高 |
#### 優勢與劣勢
|| 維度 | 評價 |
|------|------|------|
| **優勢** | 部署靈活性最高；與 FIDS 和網絡基礎設施集成度好；界面現代化；軍工級可靠性 |
| **劣勢** | 亞太地區本地化支持團隊相對較小；在歐洲以外非 Amadeus 生態環境中集成成本高 |
#### 目標場景
- 美洲、歐洲大型機場
- 需要本地數據合規（如數據不出境的政府機場）
- 已有 Collins Aerospace 其他系統（雷達、通信）的機場
- 需要與現有 FIDS 無縫集成的機場
---
### 8. RESA — INFOPAX AODB
**定位：** 中小型/區域性機場性價比方案，歐洲/非洲廣泛應用，移動端支持出色
#### 核心技術特性
|| 特性 | 說明 |
|------|------|
| **模塊化輕量級設計** | 包含基礎數據、季節計劃、實時動態三個核心模塊，易于實施 |
| **INFOPAX EXPRESS** | 專用移動端訪問應用，支持高級權限管理，為臨時用戶開放特定數據視圖 |
| **快速部署** | 中小型機場可在數週內完成上線 |
| **計費模塊整合** | 原生支持機場資源使用計費結算 |
#### 優勢與劣勢
|| 維度 | 評價 |
|------|------|------|
| **優勢** | 實施快；成本效益高；移動端支持好；歐洲/非洲有穩定客戶群 |
| **劣勢** | 應對超大型機場海量並發數據的能力未經驗證；AI/ML 能力較弱 |
#### 目標場景
- 年旅客量 < 1500 萬的中小型/區域性機場
- 歐洲、非洲機場（本地支持網絡覆蓋好）
- 預算敏感，追求快速上線和低 TCO
- 需要移動端為臨時員工/承包商開放數據訪問
---
### 9. ISO Software — SKYport AODB
**定位：** 歐美中等規模機場，Oracle 技術棧現代化方案，德系品質
#### 核心技術特性
|| 特性 | 說明 |
|------|------|
| **雲原生架構** | 基於現代雲架構設計，支持容器化和微服務部署 |
| **Oracle 數據庫底層** | 企業級 Oracle 保障事務一致性和高可用性 |
| **現代化 UI** | HTML5/Vue 響應式界面，用戶體驗對標互聯網產品 |
| **德系品質** | ISO Software Systeme（德國）出品，工程標準嚴謹，文檔完善 |
#### 優勢與劣勢
|| 維度 | 評價 |
|------|------|------|
| **優勢** | Oracle 技術棧成熟穩定；德系售後服務嚴謹；中等規模機場功能完整 |
| **劣勢** | 與大型國際樞紐的定制化需求有差距；AI 能力弱 |
#### 目標場景
- 年旅客量 500 萬 - 3000 萬的中等規模機場
- 歐洲機場（德語區、西班牙語區覆蓋好）
- 偏好 Oracle 技術棧且需要現代化界面的機場
- 需要標準化實施流程以控制風險的機場
---
## 報價與商業模式
### 傳統許可費模式（On-Premise License）
適用於對數據絕對控制有要求的大型樞紐機場：
|| 費用類型 | 區間 |
|---------|------|
| 初期軟件許可與實施費 | 50 萬 - 150 萬美元 |
| 硬件與中間件成本 | 10 萬 - 30 萬美元（雙機熱備、Oracle 授權等）|
| 年度維保費（SLA）| 初期軟件許可費的 18% - 22% |
### SaaS 雲訂閱模式（Cloud Subscription）
適用於中小型機場或尋求降低初期 CapEx 的機場：
|| 費用類型 | 區間 |
|---------|------|
| 實施與接入費 | 10 萬 - 30 萬美元 |
| 年度訂閱費 | 15 萬 - 50 萬美元/年（按年旅客吞吐量或航班架次階梯計費）|
> 優勢：包含雲基礎設施成本、自動升級和 24/7 監控，總體擁有成本（TCO）更平滑。
---
## 選型量化評估矩陣
進行 AODB 選型時，建議機場採用以下權重矩陣進行打分評估（總分 100 分）：
|| 評估維度 | 權重 | 評估指標說明 | 領先廠商示例 |
|----------|------|--------------|--------------|
| **數據處理與準確性** | 25% | 多源數據融合規則引擎、「最可信信源」機制、併發處理能力 | SITA, Amadeus |
| **系統架構與可靠性** | 20% | 高可用架構（99.99%）、災備切換時間（RTO/RPO）、雲原生支持 | Collins, ISO Software |
| **標準兼容與集成性** | 20% | 原生支持 AIDX、SSIM、A-CDM 里程碑，開放 API 豐富度 | Indra, SITA |
| **智能化與預測能力** | 15% | AI 資源優化、旅客/行李流量預測、What-if 場景模擬 | Amadeus, ADB Safegate |
| **本地化服務與合規** | 10% | 本地技術支持團隊規模、符合本國民航局數據安全與國產化要求 | 國產廠商（萬達信息、民航信科）|
| **總體擁有成本（TCO）** | 10% | 5年期軟硬件投資、實施費、維保費及定製開發費率 | RESA, 國產廠商 |
### 不同規模機場選型建議
| 機場規模 | 年旅客量 | 推薦方案 |
|---------|---------|---------|
| 超大型國際樞紐 | > 4000萬 | SITA Operations Manager 或具備極強研發實力的自主研發方案（如首都機場模式）|
| 中大型區域樞紐 | 1000萬 - 4000萬 | Amadeus AODB、Collins AirDB 或國產頭部廠商（萬達信息、民航信科）|
| 中小型及支線機場 | < 1000萬 | RESA INFOPAX、ISO SKYport 或基於 SaaS 的輕量級雲方案 |
---
## 相關鏈接
- [[aodb-core]] — AODB 核心概念與 A-CDM 架構
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
- [[aodb-china]] — 中國市場現狀與國產化替代
- [[comparisons/airport-operations-systems]] — 運營系統供應商全景對比
airport-wiki/concepts/flight-operations/baggage-handling.md
-63
View File
@@ -1,63 +0,0 @@
---
title: BHS — 机场行李处理系统
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [bag-trace, system, operations]
sources: [raw/articles/baggage-handling-market-2025.md]
---
# BHS — 机场行李处理系统
## 定义
BHS（Baggage Handling System，行李处理系统）覆盖行李从值机托运到目的地提取全流程的分拣、输送、追踪管理。
## 行业规模（2025）
- **市场规模：** USD 7,630 百万（2024年）→ USD 13,640 百万（2033年），CAGR 6.67%
- **主要驱动：** IATA Res. 753 合规要求、RFID 强制推广、硬件升级需求
## IATA Resolution 753
强制要求在以下四个节点追踪行李并向航空公司数据系统报告：
| 节点 | 英文 | 说明 |
|------|------|------|
| 接收 | Acceptance | 值机口接收并记录 |
| 装载 | Loading | 装入飞机货舱 |
| 中转 | Transfer | 航班衔接时的转运 |
| 到达 | Arrival | 到达目的地交付 |
> RFID 追踪精度接近 100%，是满足 Res. 753 的核心技术。
## 核心技术
| 技术 | 说明 |
|------|------|
| **RFID** | 替代条码，近零误读率；IATA Res. 753 合规核心 |
| **Tote-based 分拣** | 以轮式载具（tote）代替皮带直接分拣，大幅降低行李损坏率 |
| **Cross-Belt Sorter** | 高速分拣机，处理量可达 6000+ 件/小时 |
| **实时行李状态 API** | 42% 旅客通过航司 App 实时查看行李状态，驱动低延迟数据需求 |
| **Early Bag Storage（EBS）** | 提前储存行李，平衡高峰时段处理压力 |
## 主要供应商
| 厂商 | 动态（2025） |
|------|------|
| Siemens Logistics | 斩获多个大型枢纽合同 |
| Beumer Group | Tote-based 技术快速成为高吞吐量航站楼标准 |
| Vanderlande | 行李处理系统巨头 |
| Alstef | 分拣与仓储自动化 |
## 系统效益指标
- 实施 RFID + 实时追踪后，行李错运率降低 **30-50%**
- 预测性维护减少计划外停机 **30-50%**
- 维护成本降低 **18-25%**
## 相关链接
- [[aodb-core]] — 行李系统与 AODB 航班动态联动（航班延误影响行李分拣优先级）
- [[flight-data-exchange]] — CIDX/XML 数据交换标准
- [[a-cdm]] — 航班动态影响行李中转分拣时机
airport-wiki/concepts/flight-operations/biometric-corridors.md
-48
View File
@@ -1,48 +0,0 @@
---
title: 機場生物特徵走廊
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [biometric, passenger, digital-identity, security, self-service]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 機場生物特徵走廊（Biometric Corridors）
## 概述
**生物特徵走廊（Biometric Corridor）** 是機場實現「出行一張臉」（One Face Travel）的核心使能技術。旅客在信息中心或自助終端（Kiosks）完成一次身份驗證（通常是面部識別）後，其數字身份即可在安檢、登機、免稅店購物等全流程中通行無阻，無需重複出示護照或登機證。
## 核心價值
| 價值 | 說明 |
|------|------|
| **減少排隊時間** | 一次認證，全流程通行，避免重複排隊 |
| **提升通行效率** | 自動化身份核驗，減少人工干預 |
| **無縫旅客體驗** | 從抵達機場到登機，全程無需接觸任何證件 |
| **數據驅動洞察** | 實名客流追蹤，支持精細化運營管理 |
## 關鍵支撐技術
- **面部識別（Face Recognition）**：主流生物識別方式，非接觸式
- **數字身份（Digital Identity）**：旅客數字身份與實體護照信息的安全綁定
- **自助終端（Kiosks）**：提供首次身份註冊與驗證的交互入口
- **開放架構接口**：與安檢系統、航空公司系統、免稅店系統的安全對接（參見 [[open-architecture]]）
## 典型應用
- **新加坡樟宜機場 T5**：100% 無接觸服務規劃，生物識別走廊是核心
- **SITA 生物識別解決方案**：覆蓋從值機到登機的全流程
- **美國 CBP 生物識別出口**：美國海關與邊境保護局推動的機場生物識別系統
## 挑戰
- **數據隱私**：生物識別數據屬於敏感個人信息，存儲和傳輸需符合 GDPR 等法規
- **網路安全**：生物識別系統面臨被攻擊和偽造的風險
- **跨系統互操作性**：不同廠商和機場的生物識別系統需要標準化接口（與 [[open-architecture]] 直接相關）
## 相關概念
- [[future-airport-info-center]] — 生物特徵走廊是信息中心「無縫出行」體驗的核心使能技術
- [[open-architecture]] — 開放架構為生物特徵走廊提供跨系統互聯互通標準
- [[smart-gating]] — 生物特徵走廊與智能登機口密切相關
airport-wiki/concepts/flight-operations/deicing-operations.md
-65
View File
@@ -1,65 +0,0 @@
---
title: 除冰运营管理
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [operations, airside, safety]
sources: [raw/articles/detroit-deicing-system.md, raw/articles/aircraft-deicing-2025.md]
---
# 除冰运营管理
## 定义
飞机除冰（Aircraft Deicing）是在结冰或积雪条件下，飞行前清除飞机表面冰雪的操作。机场除冰运营管理覆盖除冰液管理、调度排班、环保合规。
## 关键标准
| 标准 | 说明 |
|------|------|
| ARINC | 航电与地面系统接口标准 |
| AEA（国际航空电子企业协会） | 除冰液规格与使用指南 |
| FAA / EASA | 适航与操作规章 |
## 除冰液（ADF）管理
| 类型 | 成分 | 特点 |
|------|------|------|
| **Propylene Glycol（PG）** | 丙二醇 | 主流，大型机场（如 DTW）大规模回收再用 |
| **Ethylene Glycol（EG）** | 乙二醇 | 早期使用，环境毒性较高 |
**代表案例：底特律 DTW**
- 全球最大 ADF 管理系统运营方
- 4 个远程除冰坪 + 回收系统
- 除冰径流与一般雨水完全分流
- 回收丙二醇用于塑料/油漆生产（循环经济）
## 除冰运营调度要素
- **集中资质数据库**：除冰操作人员资质、证书、实时可用性
- **实时排班调整**：运营中心可在数分钟内调整除冰班组
- **合规框架**：劳动法规、集体协议、休息规定
- **响应时间窗口**：从气象预警到除冰完成的时间预测
## 除冰对 A-CDM 的影响
除冰时间是 TOBT（目标推出时间）的关键输入变量之一：
- 实际除冰完成时间直接影响 AOBT（实际推出时间）
- 除冰延误会级联影响 TSAT、TTOT，进而影响离港排序
- 2025 年 IATA A-CDM Toolkit 将除冰运营状态纳入过站监控（TMS — Turnaround Monitoring）
## 除冰坪布局（大型机场典型）
```
远程除冰坪（Remote Deicing Pad）
↑
行李车道 ─── 除冰设备（Elevated Platform / Grooming Vehicle）
↑
飞机推出后进入除冰坪，完成后滑行至跑道
```
## 相关链接
- [[a-cdm]] — 除冰状态是 A-CDM 过站时间的关键变量
- [[smgcs]] — 除冰后滑行需要 SMGCS 引导
- [[aodb-core]] — 除冰事件时间节点记录在 AODB Milestone 体系中
airport-wiki/concepts/flight-operations/digital-twins-airports.md
-48
View File
@@ -1,48 +0,0 @@
---
title: 機場數字孿生
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [digital-twins, ai-ml, iot, sustainability, system]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 機場數字孿生（Digital Twins）
## 概述
**數字孿生（Digital Twin）** 為機場物理環境創建高精度的虛擬副本。通過接入物聯網（IoT）感測器數據，系統能夠實時監控航站樓內的運行狀態，並在虛擬環境中進行模擬、預測和優化。
## 應用場景
### 旅客服務端
- **客流瓶頸模擬**：提前識別擁堵區域，通過數字標牌引導旅客避開
- **資源調度優化**：模擬不同資源分配方案，選擇最優策略
- **數字標牌動態調整**：根據實時客流自動切換顯示內容
### 運營後台端
- **預測性維護**：基於設備運行數據預測故障時間，減少意外停機
- **能源管理優化**：實時調整暖通、空調、照明，降低能耗（與 Net Zero 目標相關）
- **容量規劃**：模擬未來客流場景，支撐基礎設施擴建決策
## 核心技術架構
```
物理層（航站樓、設備、傳感器）
↓ IoT 數據採集
數字孿生層（虛擬副本 + 實時同步）
↓ 模擬引擎
應用層（客流優化 / 預測性維護 / 能源管理）
```
## 典型廠商
- **Bentley Systems**：專注於數字孿生基礎設施領域，擁有機場數字孿生相關解決方案
## 相關概念
- [[future-airport-info-center]] — 數字孿生是信息中心實時監控與客流優化的技術底座
- [[agentic-ai-airports]] — AI 智能體利用數字孿生數據進行自主決策
- sustainability-airports — 數字孿生是機場實現 Net Zero 能源優化的重要工具
airport-wiki/concepts/flight-operations/flight-data-exchange.md
-266
View File
@@ -1,266 +0,0 @@
---
title: 航班数据交换标准
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [flight-data, api, integration, system]
sources: [raw/articles/iata-ssim-2026.md, raw/articles/schedule-data-exchange-2025.md, raw/articles/aidx-xml-imp-guide-v22.1.md]
---
# 航班数据交换标准
## 定义
航班数据交换标准是 IATA 主导的全球航空数据格式规范，涵盖航班计划、运营动态、地面保障数据的标准化报文格式，是机场信息化系统的数据互操作基础。
## 核心标准
| 标准 | 全称 | 用途 |
|------|------|------|
| **SSIM** | Standard Schedules Information Manual | 航班计划数据交换格式 |
| **AIRIMP** | Airline Industry Reservations Interline Message Procedures | 订座与运价报文 |
| **AHM** | Airport Handling Manual | 地面操作数据标准 |
| **CIDX** | Cargo Interchange Data Standard | 货运数据交换（部分机场也用于航班动态） |
| **IATA-OS** | IATA-OS Data Model | 机场运营数据模型（与 ICDM 合并演进） |
## SSIM — Standard Schedules Information Manual
|| 项目 | 信息 |
|------|------|
|| 最新版本 | **第 36 版（2026）** |
|| 发布频率 | 年度 |
|| 适用范围 | 全球所有 IATA 成员航司及合作伙伴 |
|| 核心内容 | 航班计划报文格式、最小衔接时间（MCT）、机场协调程序 |
SSIM 是航班计划数据交换的行业基准，采用**固定长度报文格式（flat file）**，支持批量数据交换。
### SSIM 信息数据行字段定义（Chapter 6/7 SCR 报文）
每行数据包含 14 个固定字段，固定位置，不可变长：
```
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGPAGP1000 1055BCNBCN JP
^1 ^3 ^4 ^6 ^7 ^8 ^9 ^10 ^11
```
| 字段 | 名称 | 内容 | 示例 |
|------|------|------|------|
| 1 | Action Code | 操作代码（N=新请求/C=变更/D=删除） | N |
| 2 | Arrival Flight Designator | 到达航班（航司代码+航班号，最低3位数字） | XZ101 |
| 3 | Departure Flight Designator | 出发航班（航司代码+航班号） | XZ102 |
| 4 | Period Start | 有效期开始 | 20JUN |
| 5 | Period End | 有效期结束 | 20AUG |
| 6 | Weekdays of Operation | 周运营日（1=周一～7=周日，1-7数字串） | 0234500 |
| 7 | Number of Seats | 座位数（3位数字） | 189 |
| 8 | Aircraft Subtype | IATA 机型代码（3位） | 738 |
| 9 | Origin Airport | 出发/到达机场代码（同一行往返） | AGP |
| 10 | Arrival Time (UTC) | 到达时间（UTC，过夜加1后缀） | 1000 |
| 11 | Departure Time (UTC) | 出发时间（UTC） | 1055 |
| 12 | Next/Destination Airport | 目的地/下一机场代码 | BCN |
| 13 | Arrival Service Type | 到达服务类型（J=定期客机/P=调机） | J |
| 14 | Departure Service Type | 出发服务类型 | P |
### SSIM SCR 报文示例
**标准 turnaround 格式（新请求）：**
```
SCR /schedule@carrier.com
S21 01APR DUB
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGP1000 1055BCN JP
SI NEW SERIES
GI BEST REGARDS
```
含义：S21航季，4月1日发给 DUB 机场，XZ 航司新 slot 请求，XZ101 进港/XZ102 出港，6月20日—8月20日每周二三四五执飞，189座，B738 机型，AGP 进港 1000z，BCN 出港 1055z。
### 协调员响应代码
| 代码 | 含义 |
|------|------|
| K | 确认（Confirmed） |
| X | 变更（Change required） |
| U | 拒绝（Refused） |
| O | 建议（Offer alternative） |
---
## AIDX — Aviation Information Data Exchange
|| 项目 | 信息 |
|------|------|
|| 类型 | XML 消息标准（ISO/IEC 19757-3） |
|| 版本 | v22.1（每年 2 次发布） |
|| 覆盖 | 约 **180 个**数据元素，涵盖航班运营全生命周期 |
|| 开发者 | IATA Delivery on Orders Working Group（80+ 航司/机场/厂商参与） |
|| 适用范围 | 航司↔机场↔第三方，运营动态实时交换 |
AIDX 由 IATA、ATA、ACI 共同认可，是 SESAR A-CDM、ACI ACRIS A-CDM Web Services、ICAO A-CDM（亚太区）信息交换的标准格式。
### 三种核心消息类型
| 消息类型 | 用途 | 方向 |
|----------|------|------|
| `IATA_AIDX_FlightLegNotifRQ` | 无请求方主动通知（推送） | 发送方 → 接收方 |
| `IATA_AIDX_FlightLegRQ` | 查询请求 | 发送方 → 接收方 |
| `IATA_AIDX_FlightLegRS` | 响应/确认 | 接收方 → 发送方 |
### 集成模式
**模式1：无请求方主动通知（推送）**
```
Sender → IATA_AIDX_FlightLegNotifRQ → Receiver
Sender ← IATA_AIDX_FlightLegRS ← Receiver（可选确认）
```
**模式2：查询 + 同步响应**
```
Sender → IATA_AIDX_FlightLegRQ → Receiver
Sender ← IATA_AIDX_FlightLegRS ← Receiver
```
### XML 数据结构（IATA_AIDX_FlightLegNotifRQ）
```xml
<IATA_AIDX_FlightLegNotifRQ Version="2" TimeStamp="2017-01-16T17:27:49Z"
TransactionIdentifier="1484587669244" Target="Production" PrimaryLangID="en-us">
<Originator CompanyShortName="UAL" TravelSector="A" Code="UA" CodeContext="3"/>
<DeliveringSystem CompanyShortName="DEN" TravelSector="C" Code="DEN" CodeContext="3"/>
<FlightLeg>
<LegIdentifier>
<Airline CodeContext="3">UA</Airline>
<FlightNumber>1815</FlightNumber>
<DepartureAirport CodeContext="3">LAX</DepartureAirport>
<ArrivalAirport CodeContext="3">IAH</ArrivalAirport>
<OriginDate>2017-01-16</OriginDate>
<RepeatNumber CurrentInd="true">1</RepeatNumber>
</LegIdentifier>
<LegData InternationalStatus="Domestic">
<ServiceType>J</ServiceType>
<OperationalStatus>OP</OperationalStatus>
<CabinClass Class="7">
<PaxCount Qualifier="70A" Usage="Actual">166</PaxCount>
<SeatCapacity>166</SeatCapacity>
</CabinClass>
<AircraftInfo>
<AircraftType>737</AircraftType>
<AircraftSubType>73Q</AircraftSubType>
<Registration>N77518</Registration>
<TailNumber>518</TailNumber>
</AircraftInfo>
<AirportResources Usage="Actual">
<Resource DepartureOrArrival="Departure">
<PassengerGate>70A</PassengerGate>
</Resource>
<Resource DepartureOrArrival="Arrival">
<PassengerGate>E8</PassengerGate>
<BaggageClaimUnit>C5</BaggageClaimUnit>
</Resource>
</AirportResources>
<OperationTime OperationQualifier="OFB" CodeContext="9750" TimeType="ACT">2017-01-16T14:28:00Z</OperationTime>
<OperationTime OperationQualifier="TKO" CodeContext="9750" TimeType="ACT">2017-01-16T14:41:00Z</OperationTime>
<OperationTime OperationQualifier="TDN" CodeContext="9750" TimeType="ACT">2017-01-16T17:27:00Z</OperationTime>
<OperationTime OperationQualifier="ONB" CodeContext="9750" TimeType="EST">2017-01-16T17:33:00Z</OperationTime>
</LegData>
</FlightLeg>
</IATA_AIDX_FlightLegNotifRQ>
```
### 航班唯一标识（UFI）规则
`LegIdentifier` 构成唯一标识，必须严格遵循以下规则：
| 字段 | 规则 |
|------|------|
| `OriginDate` | **静态** — 即使航班改期仍不变，以首个航段的 UTC 计划出发日期为准 |
| `ArrivalAirport` | **静态** — 航班备降后原字段不变，新增 `PlannedArrivalAptHistory` 记录 |
| `OperationalSuffix` | **静态** — 如需变更须取消原航班并创建新航班 |
| `RepeatNumber` | 同一计划日期的重复起飞次数，1=首次尝试 |
### 运营状态代码
| 代码 | 含义 | 使用场景 |
|------|------|----------|
| OP | Operational Flight | 正常执行 |
| NOP | Non-Operational | 计划但不执行 |
| DV | Diverted | 备降 |
| DX | Cancelled | 取消 |
| RT | Re-route | 改航路 |
| GRT | Ground Return | 返回始发地（未起飞） |
| SQ | Re-instate | 恢复已取消/备降航班 |
### A-CDM 里程碑时间代码（Codeset 9750）
| 代码 | 含义 | 阶段 |
|------|------|------|
| SCH | Scheduled | 计划 |
| INI | Flight Plan Activated | 起飞前 |
| OFB | Off Blocks（撤轮档） | 推出 |
| TKO | Takeoff（起飞） | 离地 |
| FIN | Final Approach | 最后进近 |
| TDN | Touch Down（落地） | 接地 |
| LAN | Landed | 落地 |
| ONB | On Blocks（靠桥） | 停靠 |
### 时间类型
| 类型 | 含义 |
|------|------|
| SCT | Scheduled Time（计划时间） |
| EST | Estimated Time（预计时间） |
| ACT | Actual Time（实际时间） |
> **注意**：所有时间必须为 UTC，以 `xsd:DateTime` 格式传输，后缀 Z。元素缺失=无更新；`xsi:nil="true"`=显式清空；空元素（如 `<PassengerGate/>`）可能引发校验错误。
### 技术规范
| 项目 | 要求 |
|------|------|
| 字符编码 | UTF-8 |
| 时间格式 | xsd:DateTime，UTC，末尾 Z |
| 重复元素 | 使用 `RepeatIndex` 属性标记序号 |
| Nil 值 | 使用 `xsi:nil="true"`，禁止空白元素 |
| 传输机制 | 未规定（可基于 HTTPS REST、SFTP、WebService 等） |
### SSIM 与 AIDX 对比
| 维度 | SSIM Flat File | AIDX XML |
|------|----------------|----------|
| 数据类型 | 航班计划（季节性/批量） | 航班运营动态（实时） |
| 更新频率 | 批量定时交换（航季） | 实时推送/查询 |
| 格式 | 固定长度字段（ mainframe 遗留格式） | 树形 XML 结构 |
| 复杂度 | 低（字段固定），但解析困难 | 高（180+ 元素），但扩展性强 |
| 典型场景 | slot 协调、季节计划 | A-CDM、地面保障、旅客信息 |
| IATA 策略 | 逐步向 XML/IATA-OS 迁移 | 主推方向，已广泛部署 |
## IATA Schedule Data Exchange Program（2025 新动态）
- **2025 年 8 月启动**：航司可从 IATA 数据库**接收**其他航司的航班计划数据
- **数据范围**：航班计划 + MCT（Minimum Connect Time）异常数据
- **开放性**：向所有航司开放，包括非 IATA 成员
- **与现有 DDS / CDD 协同**：IATA Direct Data Solutions 系列扩展
## 数据流向示意
```
航司 ──SSIM格式──→ 机场 AODB ──ACISP──→ 各运营系统
│ │
│←──── 运营更新（动态）───────→│
│ │
└──── 地面服务商 ────────────┘
```
## XML vs. 传统 Flat File
| 维度 | SSIM Flat File | XML/IATA-OS |
|------|----------------|-------------|
| 结构 | 固定长度字段 | 树形结构，可扩展 |
| 实时性 | 批量/定时交换 | 支持实时 API |
| 主流场景 | 计划数据批量交换 | 运营动态实时共享 |
| IATA 推进方向 | 逐步向 XML/IATA-OS 迁移 | — |
## 相关链接
- [[aodb-core]] — AODB 是数据交换标准的最终接收与处理方
- [[a-cdm]] — A-CDM 的 ACISP 平台实现运营数据实时共享
- [[baggage-handling]] — 行李数据也通过类似报文标准交换
airport-wiki/concepts/flight-operations/future-airport-info-center.md
-97
View File
@@ -1,97 +0,0 @@
---
title: 未來機場信息中心
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [passenger, ai-ml, digital-twins, biometric, aocc, human-centered-design]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 未來機場信息中心（Future Airport Info Center）
## 概述
**未來機場信息中心（Future Airport Info Center）** 是機場數字化轉型中的核心樞紐概念。它不再僅是一個提供航班時刻表和簡單指引的物理服務台，而是演變為一個高度集成、數據驅動且以旅客為中心的智能交互樞紐。
核心概念在於**「連接智能」（Connected Intelligence）**：將物理基礎設施、數字系統（如 AODB、RMS）與前沿技術（AI、數字孿生、生物識別）深度融合，為旅客提供無縫、個性化且無障礙的出行體驗，同時大幅提升機場運營效率與安全裕度。
## 核心技術趨勢
### 人工智能與智能體（Agentic AI）
AI 已從簡單的規則問答演進為具備自主決策能力的智能體（Agentic AI）。AI 驅動的虛擬助手和多語言聊天機器人能通過 NLP 與旅客流暢互動，提供：
- 實時航班動態
- 行李追蹤
- 個性化零售推薦
- 動態尋路服務
AI 還能根據實時客流密度自動調整航站樓內的環境參數（溫濕度、照明），並優化信息屏幕的顯示內容。
### 數字孿生（Digital Twins）
數字孿生為機場物理環境創建高精度虛擬副本。通過接入 IoT 感測器數據，信息中心能實時監控航站樓運行狀態：
- **預測性維護**：提前識別設備故障
- **客流瓶頸模擬**：提前調度資源
- **數字標牌引導**：引導旅客避開擁堵區域
- **全局容量優化**：優化流量分配
詳見 [[digital-twins-airports]]。
### 生物識別與數字身份
「無接觸」與「無縫通行」是未來機場的重要標誌。旅客在信息中心或自助終端（Kiosks）完成一次身份驗證後，其數字身份即可在安檢、登機、免稅店購物等全流程中通行無阻（「出行一張臉」）。
這種「生物特徵走廊」（Biometric Corridors）極大地減少了排隊時間。
### 智能運控平台（AOCC & IOC）
信息中心依託於強大的機場運行控制中心（AOCC）或綜合運營中心（IOC）。華為推出的機場智能運控中心解決方案基於 5G、雲計算和大數據底座，打破了傳統系統的「數據孤島」，實現了航班流、旅客流和行李流的統一調度與全景可視（「運行一張圖」）。詳見 [[aocc-ioc]]。
## 設計理念三大方向
### 1. 人本設計（Human-Centered Design）
從「客戶體驗」到「人類體驗」——信息中心設計更關注旅客的情感與心理需求。將冰冷的技術隐藏在溫暖的建築與家具設計中，減輕旅客的旅行焦慮。universal design 將成為標配，確保信息系統對所有人群（包括老年人和殘障人士）的無障礙訪問。
### 2. 超級個性化（Hyper-Personalization）
信息中心從「被動響應」轉向「主動服務」——根據旅客的行程、偏好甚至實時位置，通過移動端或數字標牌推送定制化的餐飲優惠、登機提醒或最優步行路線。
### 3. 可持續性與綠色運營
信息中心硬件設施採用環保材料與低能耗技術。通過數字孿生與 AI 優化航站樓能源消耗，成為機場實現凈零排放（Net Zero）目標的重要輔助節點。
## 典型案例
| 機場 | 項目 | 核心內容 |
|------|------|---------|
| 紐約 JFK | T6 + New Terminal One（SITA + CCM） | 數字標牌、智能尋路、無障礙服務、沉浸式設計 |
| 羅馬 Fiumicino（ADR） | 生成式 AI 虛擬助手（2025） | 文本/語音自然交互、停車、交通、航班、行李一站式 |
| 匹茲堡國際機場（PIT） | 通用設計認證（2026.02） | 全球首個 Universal Design 認證機場 |
| 新加坡樟宜 | T5 + SITA 體驗中心 | 100% 無接觸服務、亞太數字化轉型示範 |
## 市場規模
| 細分市場 | 2024-2025估值 | 2030-2034預測 | CAGR |
|---------|--------------|--------------|------|
| 機場信息系統 | 37-42 億美元 | 51-53.6 億美元 | 3.5-4.0% |
| 智能機場整體市場 | 66.1 億美元（2025） | 108.3 億美元（2030） | 10.36% |
| AOCC | 18.38 億美元（2026） | 40.5 億美元（2034） | 10.38% |
基礎信息系統增長平穩；AOCC 和智能機場整體解決方案正以兩位數速度增長。
## 挑戰
- **遺留系統整合**：打破數據孤島、实现新旧系统无缝对接成本高昂且複雜（與 [[open-architecture]] 直接相關）
- **網路安全與數據隱私**：生物識別和實時數據廣泛應用，勒索軟件、數據泄露風險急劇增加
## 相關概念
- [[airport-systems-landscape]] — 機場運營系統全景，信息中心的上游數據源
- [[open-architecture]] — 信息中心的技術架構原則，開放接口是連接智能的基礎
- [[aodb-core]] — AODB 是信息中心背後的核心數據中樞
- [[agentic-ai-airports]] — AI 智能體是信息中心虛擬助手的技術核心
- [[digital-twins-airports]] — 數字孿生為信息中心提供實時物理環境模擬
- [[biometric-corridors]] — 生物特徵走廊是無縫通行的核心使能技術
- [[aocc-ioc]] — AOCC/IOC 是信息中心的後台運營支撐
- [[universal-design-airports]] — 通用設計是信息中心無障礙服務的核心理念
airport-wiki/concepts/flight-operations/open-architecture.md
-131
View File
@@ -1,131 +0,0 @@
---
title: 機場開放架構
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [open-architecture, security, integration, vendor, system, ai-ml]
sources: [raw/articles/aci-tsa-open-architecture-2023.md]
---
# 機場開放架構（Open Architecture）
## 定義
**開放架構（Open Architecture，簡稱 OA）** 是一種系統設計方法，其核心理念是採用**基於標準的、可互操作的**軟硬體組件來構建機場的各類系統（尤其是安檢系統）。
根據美國運輸安全管理局（TSA）的定義：
> Open Architecture (OA) is a design approach in which equipment components, such as software and hardware, are standards-based and interoperable.
與傳統的封閉式、專有架構不同，開放架構強調技術基礎設施的規格和接口是公開的、非專有的，從而允許不同廠商的設備和軟體能夠無縫協作。
機場開放架構將原本各自獨立、互不相容的系統（安檢設備、旅客處理系統、行李處理系統等）通過統一的標準和開放的接口連接起來，使其能夠靈活組合、升級和替換。
## 背景與發展
傳統機場安檢系統高度依賴單一供應商的專有技術，存在以下問題：
- 不同廠商的設備之間缺乏數據和接口標準化，難以互聯互通
- 系統升級和更換成本高昂，週期漫長
- 創新速度受限於單一供應商的研發節奏
- 安全威脅不斷演變，但系統響應能力不足
**關鍵里程碑：**
- **2020 年 7 月**：ACI EUROPE 發布《機場安保系統開放架構》
- **2023 年 8 月**：TSA 發布《開放架構路線圖》（Open Architecture Roadmap）
- **2023 年 8 月**：ACI 發布《機場安全系統開放架構》第二版（纳入網路安全要求）
## 四大核心價值
| 價值 | 說明 |
|------|------|
| **打破供應商鎖定** | 不同廠商的設備可通過標準化接口協同工作，機場可自由選擇各領域最先進組件（Best of Breed） |
| **模組化設計** | 組件可獨立升級、替換或新增，無需整體更換，降低技術更新帶來的業務中斷風險 |
| **能力倍增器** | 大幅擴展現有系統效能——威脅檢測算法升級、預測性維護、跨系統數據分析 |
| **加速創新與競爭** | 開放競爭環境鼓勵更多廠商參與，加快新技術研發和應用速度 |
## 三大核心工作流（Workstreams）
### 1. 技術標準（Technical Standards）
| 標準 | 全稱 | 用途 |
|------|------|------|
| **DICOS** | Digital Imaging and Communication in Security | 安檢數據（X光圖像）標準格式 |
| **ACRIS** | Aviation Community Recommended Information Services | 語義數據模型，提供通用數據字典 |
| **OPSL API** | Open Platform Software Library API | 開放平台軟體庫接口 |
| **Common Use / SITA** | — | 基於開放 API 的通用旅客處理平台 |
### 2. 測試、安全與認證（Testing, Security and Certification）
目標：
- 制定新認證流程，確保符合監管要求
- 保護各參與方的知識產權（IP）、專有文檔
- 保護測試數據（如圖像數據）不被未經授權共享
### 3. 商業與責任（Commercial and Liability）
在多供應商組件構成的「系統之系統」中，建立明確框架界定：
- 防範安全事件的責任歸屬
- 滿足檢測標準的責任歸屬
- 設備維護的責任歸屬
- 保護機密信息的責任歸屬
## 關鍵推動組織
| 組織 | 角色 |
|------|------|
| **TSA** | 主要推動者，發布 OA 路線圖，推動美國機場安檢系統向開放架構轉型 |
| **ACI / ACI EUROPE** | 發布《機場安全系統開放架構》指南文件，為全球機場提供參考框架 |
| **SITA** | 推動基於開放 API 的 Common Use 通用平台，支持機場系統集成 |
| **DHS S&T** | 支持開放架構相關研發項目，推動下一代安檢成像技術的開放集成 |
| **Smiths Detection、Vanderlande** | 積極響應開放架構理念，開發符合 OA 標準的設備 |
## 主要應用場景
### 1. 安檢系統（最核心）
- 將不同廠商的 X 光機、CT 掃描儀、人體掃描儀等集成到統一平台
- 獨立升級威脅檢測算法，無需更換整套硬體
- TSA 已在美国多個機場開展示範項目
### 2. 旅客處理系統
- 基於開放 API 的通用旅客處理平台
- 支持自助值機、自助行李托運、生物識別通關
- 不同航空公司共享同一套設備和系統（SITA Common Use）
### 3. 行李處理系統
- Vanderlande 等廠商提出開放軟體架構方案
- 行李分揀和追蹤系統採用開放接口
- 與安檢系統、航班信息系統無縫對接
### 4. 機場運營管理
- 基於開放架構的 A-CDM 協同決策系統
- 航班信息、資源分配、地面交通數據的標準化集成
- 支持智慧機場數字化轉型
## 發展趨勢
| 趨勢 | 說明 |
|------|------|
| **標準化深化** | TSA 路線圖和 ACI 指南更新後，技術標準將覆蓋更多機場子系統 |
| **全球推廣** | 從美國率先推動，逐步擴展到歐洲、亞太，成為全球機場建設主流方向 |
| **AI 與數據融合** | 開放架構為 AI 威脅識別算法快速部署奠定基礎 |
| **數字身份集成** | 物理和數字憑證互認，推動無縫化旅客出行體驗 |
| **網路安全強化** | 系統開放程度提高後，網路安全成為核心考量（ACI 已將網路安全納入高層級要求）|
## 機場 4.0 藍圖
開放架構是邁向「機場 4.0」認知數字生態系統的基礎 blueprint。它賦予機場更高的敏捷性，使其能夠以前所未有的靈活性應對不斷變化的安全威脅、監管要求和旅客需求。
## 相關概念
- [[airport-systems-landscape]] — 機場運營系統全景圖，OA 是其中的系統集成原則
- [[aodb-core]] — AODB 是開放架構下的核心數據中樞
- [[baggage-handling]] — BHS 行李系統受益於開放架構實現跨供應商集成
- [[flight-data-exchange]] — 航班數據交換標準是開放架構接口層的具體實現
- [[smart-gating]] — 智能登機口可受益於開放架構的設備集成
## 參考來源
- [TSA - What is Open Architecture?](https://www.tsa.gov/travel/frequently-asked-questions/what-open-architecture)
- [TSA - Open Architecture Roadmap (2023)](https://www.tsa.gov/sites/default/files/oa/_roadmap/_20230717/_508c-r1.pdf)
- [ACI - Open Architecture for Airport Security Systems (2nd Edition, 2023)](https://www.aci-europe.org/downloads/resources/TSA-230504-7/_4.1%20Attachment%201%20OA%20for%20Airport%20Security%20Systems%202nd%20Edition%20%20FINAL.pdf)
- [Smiths Detection - Moving towards Open Architecture](https://www.smithsdetection.com/insights/moving-towards-open-architecture/)
airport-wiki/concepts/flight-operations/smart-gating.md
-54
View File
@@ -1,54 +0,0 @@
---
title: AI Smart Gating — 智能停机位管理
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [operations, gate, system]
sources: [raw/articles/assaia-standmanager-2025.md, raw/articles/ai-smart-gating-2025.md]
---
# AI Smart Gating — 智能停机位管理
## 定义
AI Smart Gating（智能机位管理）指利用 AI 算法实时优化停机位（gate/stand）分配的系统，目标是最小化滑行时间、提升机位利用率、减少航班延误。
## 核心功能
| 功能 | 说明 |
|------|------|
| 实时机位分配 | 基于航班动态（实际到达时间、机型、衔接航班）动态重分配 |
| 冲突检测 | 机位时间重叠、翼展冲突、拖车路径冲突预警 |
| 预测性分析 | 预测机位冲突并提前调整 |
| 多目标优化 | 平衡航司偏好、旅客步行距离、地面滑行时间 |
| 可持续性指标 | 减少地面滑行燃油消耗和碳排放 |
## 关键技术
- **约束规划（Constraint Programming）**：处理复杂的业务规则和硬约束
- **强化学习（RL）**：从历史分配数据中学习最优策略
- **数字孪生**：机场场面仿真，用于分配方案评估
- **实时数据集成**：AODB 航班动态 +场面活动（SMGCS）数据
## 供应商动态（2025）
| 厂商 | 产品 | 进展 |
|------|------|------|
| Assaia | **StandManager** | 2025 年发布，基于 AI 的停机位资源管理系统 |
| adb safegate | **AmberFAIR** | 可持续机位分配算法 |
| AirportLabs | **SkyCore RMS** | 2025 年 8 月已部署于芝加哥 ORD |
| Airsimate (Northeast Systems) | 机位优化平台 | — |
## AI Smart Gating 趋势（2025）
- **从被动调度到主动管理**：AI 系统能预判延误并主动重分配，而非被动响应
- **全网络优化**：单机场优化 → 多机场协同优化
- **标准化推进**：IATA 与 Eurocontrol 推动 A-CDM 数据接口标准化，使 AI 系统能获取实时航班数据
- **经济效益**：减少飞机滑行时间直接降低燃油成本和碳排放
## 相关链接
- [[a-cdm]] — 协同决策为智能机位分配提供实时数据
- [[smgcs]] — 场面活动监控防止机位冲突
- [[aodb-core]] — 机位管理依赖 AODB 航班数据
- [[deicing-operations]] — 除冰作业影响航班推出时间，影响机位占用时长
airport-wiki/concepts/flight-operations/smgcs.md
-57
View File
@@ -1,57 +0,0 @@
---
title: SMGCS / A-SMGCS — 场面活动引导与控制系统
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [airside, system, safety]
sources: [raw/articles/smgcs-lax-2025.md, raw/articles/a-smcgs-market-2025.md]
---
# SMGCS / A-SMGCS — 场面活动引导与控制系统
## 定义
- **SMGCS**（Surface Movement Guidance and Control System，场面活动引导与控制系统）：在低能见度条件下（< 1200ft RVR）管控飞机地面滑行、推出、起飞、落地的程序与系统。
- **A-SMGCS**（Advanced SMGCS，高级场面活动引导与控制系统）：在 SMGCS 基础上增加了场面活动监视、路径引导和冲突预警功能。
FAA 要求日均旅客量达到一定规模的机场必须制定并维护 SMGCS Plan。
## 功能层级
| 级别 | 功能 |
|------|------|
| L1 场面监视 | 探测场面所有活动目标（飞机、车辆）位置 |
| L2 路径引导 | 为飞行员/司机提供最优滑行路径和冲突预警 |
| L3 运动规划 | 自动优化场面资源分配（停机位、滑行路线） |
| L4 场景管理 | 异常情况（紧急救援、鸟击）自动响应 |
## A-SMGCS 市场数据（2025）
- **市场规模：** USD 5,922.47 百万（2025年）
- **主要驱动：** 能见度受限机场的运营安全合规需求、AI 预测分析集成
- **趋势：** 到 2025 年，A-SMGCS 正深度融合 AI/ML 进行场面活动预测
## 核心技术组件
| 组件 | 说明 |
|------|------|
| **场面探测雷达（ASDE-X / SMR）** | 探测飞机和车辆精确位置 |
| **ADS-B 接收站** | 飞机广播式自动相关监视 |
| **多点定位（Multilateration）** | 基于 TDOA 的精确定位 |
| **场面灯光引导系统** | 停止排灯、可变距灯（VSLS） |
| **VDGS（Visual Docking Guidance System）** | 泊位引导系统（机位停稳指示） |
| **CDM 集成接口** | 与 A-CDM 共享场面状态数据 |
## SMGCS Plan 关键内容（以 LAX 为例）
- 低能见度运营程序（分类：LVP Level 1/2/3）
- 跑道等待点/停止排灯控制程序
- 地面车辆活动限制区域
- 应急救援路线保障
- 年度评审机制（LAX SMGCS Working Group）
## 相关链接
- [[a-cdm]] — A-CDM 共享场面数据用于离港排序
- [[aodb-core]] — 场面状态数据汇入 AODB
- [[smart-gating]] — 机位分配与场面活动联动
airport-wiki/concepts/flight-operations/universal-design-airports.md
-58
View File
@@ -1,58 +0,0 @@
---
title: 機場通用設計
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [passenger, human-centered-design, accessibility, self-service]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 機場通用設計（Universal Design）
## 概述
**通用設計（Universal Design）** 源自建築與產品設計領域，核心理念是：**產品和環境的設計應對所有人（包括老年人和殘障人士）都盡可能地適用，而不需要特別改造或特殊設計。**
在機場語境下，信息中心與航站樓的通用設計確保所有旅客都能平等、順暢地獲取信息和使用服務。
## 典型實踐
### 匹茲堡國際機場（PIT）—— 全球首個通用設計認證
2026 年 2 月，PIT 成為全球首個獲得「通用設計」認證的機場：
- **直觀數字尋路系統**：清晰的路線引導，無需依賴工作人員協助
- **高可見度信息顯示屏**：大字體、高對比度、適合視障旅客
- **適應性交互終端**：高度可調節，支援輪椅使用者
- **多感官反饋**：視覺 + 聽覺 + 觸覺三種交互模式
## 與人本設計的關係
通用設計是人本設計（Human-Centered Design）在無障礙維度的具體落地：
```
Human-Centered Design（廣義人本設計）
├── 情感需求：減輕旅行焦慮、溫暖的建築語言
├── 認知需求：直觀界面、清晰信息層次
└── 身體需求：通用設計、無障礙設施
```
## 在信息中心中的體現
| 維度 | 具體措施 |
|------|---------|
| 視覺 | 大字體、高對比度、可調亮度 |
| 聽覺 | 語音播報、噪音屏蔽提示 |
| 觸覺 | 盲文標識、觸覺反饋界面 |
| 認知 | 簡化語言、圖標化表達、多語言 |
| 移動 | 無障礙通道、高度可調終端 |
## 監管背景
- **ADA（美國殘疾人法案）**：美國機場的合規底線
- **ACI 無障礙指南**：全球機場無障礙設計參考框架
- **ISO 21542**：建築構造無障礙設計國際標準
## 相關概念
- [[future-airport-info-center]] — 通用設計是信息中心「人類體驗」維度的核心原則
- [[human-centered-design-airports]] — 通用設計是 HCD 在無障礙領域的具體實踐
airport-wiki/concepts/knowledge-management/automation-hooks.md
-569
View File
@@ -1,569 +0,0 @@
---
title: 自动化钩子与事件驱动架构
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, automation, event-hooks, operations]
confidence: 0.9
sources_count: 5
last_confirmed: 2026-04-13
status: active
relationships:
- target: SCHEMA.md
type: implements
detail: "v2 自动化机制"
confidence: 0.95
- target: knowledge-management/memory-lifecycle.md
type: triggers
detail: "置信度衰减和整合"
confidence: 0.85
- target: knowledge-management/knowledge-graph.md
type: updates
detail: "自动更新实体关系"
confidence: 0.9
- target: hybrid-search.md
type: maintains
detail: "嵌入和索引更新"
confidence: 0.9
---
# ⚡ 自动化钩子与事件驱动架构
基于 **LLM Wiki v2** 的事件驱动维护系统，为机场智能化工程 wiki 提供自动化知识管理。通过事件钩子响应 wiki 操作，减少手动维护负担。
> **核心目标**：将手动知识维护转变为事件驱动的自动化流程，确保 wiki 内容的新鲜度、一致性和质量。
---
## 🏗️ 事件架构总览
### 事件类型与触发器
| 事件类型 | 触发器 | 触发条件 | 响应延迟 |
|----------|--------|----------|----------|
| **来源新增** | 文件系统监视 | `raw/` 中新增 `.md` 文件 | 即时 (15s) |
| **页面创建** | `write_file()` 调用 | `concepts/`, `entities/` 等目录 | 即时 (5s) |
| **页面更新** | `patch()` 调用 | 现有页面内容修改 | 即时 (5s) |
| **页面归档** | 文件移动至 `_archive/` | 手动操作或自动 supersede | 即时 (5s) |
| **用户查询** | `web_search()` 或 `search_files()` | 搜索操作 | 异步 (<60s) |
| **定时任务** | cron 调度器 | 每日/每周/每月 | 指定时间 |
### 自动化钩子执行顺序
```
新来源 → on_new_source() → 来源解析 → 实体提取 → 页面创建/更新
↓
页面创建/更新 → on_page_change() → 关系更新 → 嵌入更新 → 索引更新
↓
定时任务 → cron_daily/weekly/monthly() → 质量检查 → 置信度衰减
↓
用户查询 → on_user_query() → 结果记录 → 潜在答案生成 → 反馈学习
```
---
## 🔧 主要钩子实现
### 1️⃣ `on_new_source()` - 新来源自动摄入
```python
def on_new_source(source_path: str):
"""
处理 raw/ 目录中的新来源文件
1. 解析来源内容
2. 提取实体和事实
3. 创建/更新 wiki 页面
4. 更新相关索引
"""
# 1. 读取并解析来源
content = read_file(source_path)
metadata = extract_metadata(content) # 作者、日期、类型等
# 2. 提取实体和事实
entities = extract_entities(content)
facts = extract_facts(content, entities)
# 3. 更新现有页面或创建新页面
for fact in facts:
target_page = find_or_create_page(fact.topic)
# 检查是否有冲突
conflict = check_conflict(target_page.content, fact.content)
if conflict:
# 触发 supersession 流程
supersede_page(target_page, fact.content, source_path)
else:
# 追加新事实
update_page(target_page, fact.content, source_path)
# 4. 更新嵌入和图谱
trigger_embedding_update()
trigger_graph_reconciliation()
# 记录日志
log_event("source_ingested", {
"source": source_path,
"entities_extracted": len(entities),
"facts_added": len(facts),
"timestamp": now()
})
```
**机场场景示例**：
```
事件: 新增 raw/articles/shenzhen-airport-smart-gating-2026.md
响应:
1. 解析文章：深圳机场2026年智能登机口升级
2. 提取实体：深圳机场、SITA、生物识别走廊
3. 更新页面：
- concepts/smart-gating.md → 添加深圳案例
- entities/shenzhen-airport.md → 更新智能登机口信息
4. 更新关系：深圳机场 → uses → 生物识别走廊
```
### 2️⃣ `on_page_change()` - 页面变更处理
```python
def on_page_change(page_path: str, change_type: str, old_content: Optional[str] = None):
"""
处理页面创建、更新、删除
参数:
- change_type: "create" | "update" | "delete" | "archive"
- old_content: 仅 update 时提供
"""
if change_type == "create":
# 新页面：初始化嵌入和关系
embedding = generate_embedding(page_path)
save_embedding(page_path, embedding)
# 提取关系并更新图谱
relationships = extract_relationships(page_path)
update_knowledge_graph(page_path, relationships)
elif change_type == "update":
# 页面更新：检查语义变化
old_embedding = load_embedding(page_path)
new_embedding = generate_embedding(page_path)
similarity = cosine_similarity(old_embedding, new_embedding)
if similarity < 0.7: # 语义显著变化
# 重新计算相关页面的嵌入
trigger_related_embeddings_update(page_path)
# 更新所有引用该页面的关系
update_incoming_relationships(page_path)
elif change_type in ["delete", "archive"]:
# 页面删除/归档：清理相关数据
remove_embedding(page_path)
remove_from_knowledge_graph(page_path)
# 更新引用（设置 superseded_by 或删除链接）
update_references_to_page(page_path, change_type)
# 更新搜索索引
update_search_index(page_path, change_type)
log_event("page_changed", {
"page": page_path,
"type": change_type,
"semantic_change": similarity if change_type == "update" else None,
"timestamp": now()
})
```
### 3️⃣ `cron_weekly()` - 每周维护任务
```python
def cron_weekly():
"""
每周日自动执行的维护任务
1. 完整性检查 (lint)
2. 置信度衰减和更新
3. 嵌入重新生成
4. 性能分析
"""
print("=== 每周维护任务开始 ===")
start_time = now()
# 1. 运行完整性检查
lint_report = run_lint_check()
# 自动修复可修复的问题
auto_fixed = lint_report.auto_fix()
# 记录需要手动干预的问题
manual_tasks = lint_report.get_manual_tasks()
# 2. 置信度衰减
decayed_pages = decay_confidence_scores()
# 3. 嵌入重新生成（全量）
pages_updated = regenerate_all_embeddings()
# 4. 搜索索引重建
rebuild_search_index()
# 5. 性能分析
performance_report = analyze_search_performance()
# 6. 生成维护报告
report = generate_maintenance_report({
"duration_seconds": (now() - start_time).total_seconds(),
"lint_fixed": auto_fixed,
"lint_manual": len(manual_tasks),
"pages_decayed": len(decayed_pages),
"embeddings_regenerated": pages_updated,
"search_metrics": performance_report.metrics,
"timestamp": now()
})
# 保存报告
save_report(report, "weekly-maintenance")
# 如有需要手动干预的问题，发送通知
if manual_tasks:
notify_maintainer("手动维护任务待处理", manual_tasks)
print(f"=== 每周维护任务完成，耗时 {report.duration_seconds}s ===")
return report
```
### 4️⃣ `on_user_query()` - 查询响应与学习
```python
def on_user_query(query: str, results: List[str], user_feedback: Optional[Dict] = None):
"""
处理用户搜索查询
1. 记录查询模式
2. 潜在答案生成
3. 质量评估和反馈学习
"""
# 1. 查询分类和记录
query_type = classify_query(query)
log_search_event({
"query": query,
"type": query_type,
"results_count": len(results),
"user_id": get_user_id(), # 匿名或会话ID
"timestamp": now()
})
# 2. 检查是否需要生成新答案
if should_generate_answer(query, results):
answer = generate_potential_answer(query, results)
# 评估答案质量
quality_score = evaluate_answer_quality(answer, query, results)
if quality_score > 0.8: # 高质量答案
# 自动创建/更新查询页面
create_query_page(query, answer, quality_score)
log_event("answer_generated", {
"query": query,
"answer_page": f"queries/{slugify(query)}.md",
"quality_score": quality_score,
"timestamp": now()
})
# 3. 处理用户反馈（如有）
if user_feedback:
process_user_feedback(query, results, user_feedback)
# 更新搜索排名权重
update_search_weights(query_type, user_feedback)
# 4. 查询模式分析
analyze_query_patterns(query, results)
return {
"logged": True,
"query_type": query_type,
"potential_answer_generated": should_generate_answer(query, results),
"feedback_processed": bool(user_feedback)
}
```
---
## ⏰ 定时任务调度
### 每日任务 (`cron_daily`)
```python
SCHEDULE = {
"daily": {
"time": "02:30", # 凌晨执行，避免影响使用
"tasks": [
"verify_recent_changes", # 检查24小时内变更
"update_recommendations", # 更新推荐系统
"clean_temp_files", # 清理临时文件
"backup_incremental" # 增量备份
]
}
}
def cron_daily():
"""每日凌晨执行的任务"""
tasks = [
# 1. 验证最近变更
verify_recent_changes(since=datetime.now() - timedelta(days=1)),
# 2. 更新个性化推荐
update_recommendations(),
# 3. 清理临时文件
clean_temp_files(max_age=timedelta(days=7)),
# 4. 增量备份
backup_incremental(target="s3://wiki-backups/daily/")
]
return execute_tasks(tasks, name="daily_maintenance")
```
### 每周任务 (`cron_weekly`)
```python
def cron_weekly():
"""每周日执行的全量维护"""
return {
"lint": run_lint_check(),
"embeddings": regenerate_all_embeddings(),
"confidence": decay_confidence_scores(),
"index": rebuild_search_index(),
"report": generate_weekly_report()
}
```
### 每月任务 (`cron_monthly`)
```python
def cron_monthly():
"""每月1日执行的深度维护"""
return {
"archival": archive_stale_content(older_than=timedelta(days=180)),
"model_evaluation": evaluate_embedding_models(),
"capacity_planning": analyze_growth_trends(),
"security_audit": run_security_checks(),
"comprehensive_report": generate_monthly_report()
}
```
---
## 🚀 实施部署
### 阶段 1：基础钩子（当前）
- ✅ `on_page_change()` 记录至日志
- ✅ 新增来源手动触发处理
- 🔄 定期 lint 检查（手动）
### 阶段 2：自动化管道（1-2周）
- 🔄 文件系统监视：`raw/` 新增自动触发
- 🔄 页面变更自动更新嵌入和关系
- 🔄 每周自动维护脚本
- 🔄 搜索结果记录与分析
### 阶段 3：高级自动化（1个月）
- 🔄 智能答案生成（质量阈值 >0.8）
- 🔄 自适应权重调整（基于用户反馈）
- 🔄 异常检测和自动修复
- 🔄 多环境部署（开发/测试/生产）
### 阶段 4：智能运维（未来）
- 🔄 预测性维护（基于历史模式）
- 🔄 A/B 测试搜索算法
- 🔄 跨wiki知识同步
- 🔄 故障自愈能力
---
## 🔧 技术实现细节
### 钩子注册机制
```python
class HookRegistry:
"""事件钩子注册中心"""
def __init__(self):
self.hooks = defaultdict(list)
def register(self, event_type: str, callback: Callable, priority: int = 0):
"""注册钩子"""
self.hooks[event_type].append({
"callback": callback,
"priority": priority
})
self.hooks[event_type].sort(key=lambda x: x["priority"])
def trigger(self, event_type: str, **kwargs):
"""触发事件"""
for hook in self.hooks.get(event_type, []):
try:
hook["callback"](**kwargs)
except Exception as e:
log_error(f"钩子执行失败: {event_type}", e)
# 全局钩子注册器
hooks = HookRegistry()
# 注册示例
hooks.register("page_created", on_page_change, priority=10)
hooks.register("source_added", on_new_source, priority=5)
```
### 文件系统监视
```python
import watchdog
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
class WikiFileHandler(FileSystemEventHandler):
"""监视 raw/ 目录的变更"""
def on_created(self, event):
if event.is_directory:
return
path = event.src_path
if path.startswith("/raw/") and path.endswith(".md"):
# 触发来源处理钩子
hooks.trigger("source_added", source_path=path)
def on_modified(self, event):
if event.is_directory:
return
path = event.src_path
if not path.startswith("/raw/"):
# 触发页面变更钩子
hooks.trigger("page_changed", page_path=path, change_type="update")
# 启动监视器
observer = Observer()
observer.schedule(WikiFileHandler(), "/path/to/wiki", recursive=True)
observer.start()
```
### 定时任务调度器
```python
import schedule
import time
def setup_scheduler():
"""配置定时任务"""
# 每日凌晨任务
schedule.every().day.at("02:30").do(cron_daily)
# 每周日任务
schedule.every().sunday.at("03:00").do(cron_weekly)
# 每月1日任务
schedule.every().month.at("04:00").do(cron_monthly)
print("定时任务已配置")
# 运行调度器（后台线程）
import threading
def run_scheduler():
while True:
schedule.run_pending()
time.sleep(60) # 每分钟检查一次
thread = threading.Thread(target=run_scheduler, daemon=True)
thread.start()
# 应用启动时调用
setup_scheduler()
```
---
## 📊 监控与告警
### 关键指标监控
| 指标 | 阈值 | 告警级别 | 响应动作 |
|------|------|----------|----------|
| **处理失败率** | >5% | 警告 | 检查日志，重启服务 |
| **嵌入更新延迟** | >24h | 警告 | 手动触发嵌入生成 |
| **页面冲突数量** | >10 | 警告 | 审核冲突内容 |
| **搜索查询失败** | >20% | 严重 | 检查搜索索引 |
| **磁盘使用率** | >80% | 警告 | 清理或扩容 |
### 告警规则示例
```yaml
alerts:
- name: "high_failure_rate"
condition: "rate(failed_hooks_total[5m]) / rate(hooks_total[5m]) > 0.05"
severity: "warning"
description: "钩子执行失败率超过5%"
actions: ["send_slack", "create_jira"]
- name: "search_degradation"
condition: "search_response_time_p95 > 3000"
severity: "critical"
description: "搜索P95响应时间超过3秒"
actions: ["page_oncall", "rollback_search"]
```
---
## 🔄 故障恢复流程
### 常见故障场景
1. **钩子执行失败**
```bash
# 1. 查看错误日志
tail -f /var/log/wiki/hooks.log
# 2. 暂时禁用问题钩子
disable_hook("on_page_change", "problematic_callback")
# 3. 手动执行受影响操作
run_manual_cleanup()
```
2. **嵌入生成中断**
```bash
# 1. 检查嵌入存储完整性
verify_embeddings_integrity()
# 2. 重新生成受影响页面
regenerate_embeddings_for_pages(since="2026-04-10")
# 3. 重建搜索索引
rebuild_search_index()
```
3. **关系图谱不一致**
```python
# 自动一致性检查
def reconcile_knowledge_graph():
# 1. 检测孤立实体
orphans = find_orphaned_entities()
# 2. 检查关系对称性
mismatches = validate_relationship_symmetry()
# 3. 修复不一致
fix_inconsistencies(orphans + mismatches)
return {"fixed": len(orphans + mismatches)}
```
---
## 📚 相关文档
- [[knowledge-management/memory-lifecycle.md]] - 置信度衰减和整合机制
- [[knowledge-management/knowledge-graph.md]] - 实体关系自动提取
- [[hybrid-search.md]] - 搜索结果记录和权重调整
- [[wiki-backup-recovery.md]] - 备份和恢复流程
- [[performance-monitoring.md]] - 系统性能监控
---
> **状态**: 当前实现基础钩子记录。下一步：部署文件系统监视和定时任务。最后更新：2026-04-13。
airport-wiki/concepts/knowledge-management/knowledge-graph.md
-200
View File
@@ -1,200 +0,0 @@
---
title: 知识图谱
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, knowledge-graph, entity, typed-relationship]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# 知识图谱
## 概述
传统 wiki 是页面的平面集合，通过 wikilinks 连接。规模化后这种模式的局限显现：链接只说"A 与 B 相关"，不说明**如何**相关。知识图谱在页面之外增加结构化关系层，让查询可以从"A 出发，追踪所有依赖 B 的节点"。
本页阐述知识图谱在本 wiki 中的设计与集成方案。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
## 核心思想
> 页面（pages）用于阅读，图（graph）用于导航和发现。
当用户问"升级 Redis 版本的影响"时：
- **页面搜索**：关键词匹配，返回包含 Redis 的页面
- **图遍历**：从 Redis 节点出发，沿 `depends_on` / `uses` 边向外走，追踪所有下游实体
---
## 实体提取（Entity Extraction）
摄入来源时，提取结构化实体而非仅存储文本。
### 实体类型
| 实体类型 | 示例 |
|----------|------|
| **机场** | 深圳宝安机场、郑州航空港、福州长乐机场 |
| **供应商** | NVIDIA、Vertiv、华为、ADB SAFEGATE、Amadeus |
| **硬件型号** | GB200 NVL72、H100 SXM5、HGX H100 |
| **系统/平台** | AODB、A-CDM、SMGCS、BHS |
| **标准/协议** | NCCL、RDMA、RoCE、Infiniband |
| **项目** | 郑州万卡集群、福州长乐智算中心 |
| **人/组织** | （可选择是否记录）|
### 实体元数据
```yaml
# entities/shenzhen-airport.md frontmatter 扩展
type: entity
entity_type: airport # airport | vendor | hardware | system | standard | project
confidence: 0.95
sources_count: 3
relationships: # 预定义关系（也在页面正文中用 wikilink）
- target: gpu-cluster-shenzhen
type: deploys
confidence: 0.9
- target: nvidia-h100
type: uses
confidence: 0.95
- target: aodb-core
type: operates
confidence: 0.85
```
---
## 类型化关系（Typed Relationships）
Wikilink 只说"A 连接到 B"，Typed Relationship 说明**关系的语义**。
### 预定义关系类型
| 关系类型 | 含义 | 示例 |
|----------|------|------|
| `deploys` | 部署/安装 | 深圳机场 deploys GPU集群 |
| `uses` | 使用（某技术/产品） | 深圳机场 uses NVIDIA GB200 |
| `depends_on` | 依赖 | GPU集群 depends_on 液冷系统 |
| `contradicts` | 矛盾/否定 | 旧方案 contradicts 新方案 |
| `supersedes` | 替代 | GB200 supersedes H100 |
| `caused` | 导致 | 功耗过高 caused 液冷需求 |
| `integrates_with` | 与…集成 | AODB integrates_with A-CDM |
| `competes_with` | 竞争 | Amadeus AODB competes_with ADB SAFEGEGO AODB |
| `part_of` | 属于/组成 | BHS part_of 行李处理系统 |
| `references` | 参考 | 本文 references NVIDIA白皮书 |
### 关系置信度
每条关系独立持有置信度：
> 深圳机场 uses GB200 NVL72，关系置信度 0.9（来源：深圳机场官方报道 + 华为官宣）
---
## 图遍历查询示例
### 示例 1：寻找 GPU 集群依赖
```
问题：郑州航空港 GPU 集群的电力需求是多少？
图遍历路径：
郑州航空港
→ deploys → gpu-cluster-zhengzhou
→ uses → GB200 NVL72
→ power_draw → 查询 power-and-cooling.md
→ depends_on → 液冷系统
→ 答案：NVL72 单卡 1200W，72卡集群 86.4MW（需液冷）
```
### 示例 2：供应商竞争分析
```
问题：ADB SAFEGATE 和 Amadeus 在 AODB 领域有何差异？
图遍历：
ADB SAFEGATE AODB
→ competes_with → Amadeus AODB
→ 两者都 integrate_with → A-CDM
→ 参考 aodb-vendors.md 对比表
```
### 示例 3：故障链追溯
```
问题：机坪 FODS 传感器故障影响了哪些系统？
图遍历：
FODS 传感器
→ feeds → SMGCS
→ feeds → 场面活动管理
→ 间接影响 → 停机位分配（RMS）
→ 快速找到受影响实体
```
---
## 本 Wiki 的实施路径
### 阶段 1：手动标注（当前可行）
在 `entities/` 页面中逐步添加 `relationships` 字段，手动梳理实体间关系。
目标：覆盖核心机场实体和关键供应商关系。
### 阶段 2：自动化关系提取（中期目标）
在 ingestion 流程中增加实体识别步骤：
- 来源文本 → NER 提取实体
- 实体类型分类（机场/供应商/硬件/系统/标准）
- 关系模式匹配（uses/deploys/integrates_with 等）
### 阶段 3：图数据库（远期目标）
当关系数量超过 ~500 条时，考虑引入图数据库：
- **Neo4j**：成熟，支持 Cypher 查询
- **Age**（PostgreSQL 扩展）：与现有工作流更易集成
- 图遍历替代关键词搜索，提升查询质量
---
## 当前实体关系图（示例）
```
┌─────────────────┐
│ 深圳宝安机场 │◄─── deploys ────┐
└────────┬────────┘ │
│ uses │ uses
┌────────▼────────┐ ┌───────▼────────┐
│ NVIDIA GB200 │─────────►│ 华为自研芯片 │
│ NVL72 │ supersedes │
└────────┬────────┘ └────────────────┘
│ power_draw (1200W/GPU)
┌────────▼────────┐
│ 液冷系统 │
│ (PUE < 1.15) │
└────────┬────────┘
│ supports
┌────────▼────────┐
│ 电力供应系统 │
│ (双路 N+1) │
└─────────────────┘
┌─────────────────┐ integrates_with ┌─────────────────┐
│ AODB │◄───────────────────────────►│ A-CDM │
│ (ADB SAFEGEGO) │ │ │
└────────┬────────┘ └────────┬────────┘
│ competes_with │
│ │ feeds
┌────────▼────────┐ ┌────────▼────────┐
│ Amadeus AODB │ │ SMGCS │
└─────────────────┘ └─────────────────┘
```
---
## 相关页面
- [[memory-lifecycle]] — 置信度、superset、遗忘机制
- [[wiki-operations]] — 实体提取的自动化钩子
- [[aodb-vendors]] — 供应商竞争关系的具体例子
- [[gpu-cluster]] — GPU 与其他硬件的关系
- [[power-and-cooling]] — 电力/冷却是 GPU 集群的依赖关系
airport-wiki/concepts/knowledge-management/knowledge-lifecycle.md
-474
View File
@@ -1,474 +0,0 @@
---
title: 知识生命周期与遗忘曲线
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, knowledge-lifecycle, confidence-decay, supersession]
confidence: 0.9
sources_count: 3
last_confirmed: 2026-04-13
status: active
relationships:
- target: automation-hooks.md
type: governed-by
detail: "置信度衰减触发事件"
confidence: 0.95
- target: knowledge-management/knowledge-graph.md
type: updates
detail: "实体关系老化机制"
confidence: 0.85
- target: hybrid-search.md
type: influences
detail: "搜索排名权重衰减"
confidence: 0.8
- target: quality-control.md
type: informs
detail: "质量评估和归档决策"
confidence: 0.9
---
# 🔄 知识生命周期与遗忘曲线
模拟人类记忆的**置信度衰减**和**层次化整合**机制，为机场智能化 wiki 建立动态的知识管理系统。通过时间衰减、源验证和层次整合，确保 wiki 内容的时效性和准确性。
> **核心理念**：知识不是静态的，而是随时间演化的有机体。新知识活跃，旧知识衰减，冲突知识整合。
---
## 🧠 记忆分层模型
### 1️⃣ **工作记忆层** (Working Memory)
| 特征 | 处理机制 | 时间窗口 |
|------|----------|----------|
| **新加入的知识** | 高置信度 (0.8-1.0) | 1-30 天 |
| **主动使用频率高** | 强化学习 | 短期活跃 |
| **来源新鲜** | 来源评分高 | 即时可用 |
| **易于修改** | 标记为待验证 | 高度可变 |
**适用场景**：刚发布的政策、新机场案例、技术规格更新
### 2️⃣ **长期记忆层** (Long-term Memory)
| 特征 | 处理机制 | 时间窗口 |
|------|----------|----------|
| **已验证的知识** | 中等置信度 (0.5-0.8) | 31-365 天 |
| **多源验证** | 冲突解决完毕 | 稳定引用 |
| **整合完善** | 关联其他知识 | 结构性存储 |
| **定期回顾** | 周期性强化 | 访问频率中 |
**适用场景**：成熟技术标准、核心运营流程、基础架构文档
### 3️⃣ **归档记忆层** (Archived Memory)
| 特征 | 处理机制 | 时间窗口 |
|------|----------|----------|
| **过时但参考性** | 低置信度 (0.1-0.5) | >1 年 |
| **历史价值** | 标记为过时 | 只读访问 |
| **替代关系** | superseded_by 链接 | 背景参考 |
| **最小维护** | 不参与搜索 | 低成本存储 |
**适用场景**：旧版标准、历史案例、被替换的技术方案
---
## 📉 置信度衰减机制
### 衰减函数
```python
def decay_confidence(current_confidence: float,
age_days: int,
usage_frequency: float,
sources_count: int) -> float:
"""
计算置信度衰减
参数:
- current_confidence: 当前置信度 (0-1)
- age_days: 知识创建天数
- usage_frequency: 最近30天访问频率 (0-1)
- sources_count: 引用来源数量
"""
# 基础衰减因子：时间衰减（类似艾宾浩斯遗忘曲线）
base_decay = 0.95 ** (age_days / 30) # 每月衰减5%
# 强化因子：使用频率和来源数量
reinforcement = (usage_frequency * 0.3) + (min(sources_count, 5) * 0.05)
# 应用衰减
new_confidence = current_confidence * base_decay
# 应用强化（减缓衰减）
new_confidence += (1 - base_decay) * reinforcement
# 确保在 [0.05, 1.0] 范围内
return max(0.05, min(1.0, new_confidence))
```
### 衰减策略表
| 衰减因子 | 影响权重 | 触发条件 | 调整幅度 |
|----------|----------|----------|----------|
| **时间衰减** | 60% | 创建时间 >30 天 | -2%/月 |
| **使用频率** | 20% | 每月访问次数 | ±0.5%/次 |
| **来源数量** | 15% | 引用来源增减 | ±1%/个 |
| **冲突数量** | 5% | 发现矛盾事实 | -5%/冲突 |
| **用户反馈** | 额外 | 明确确认/否认 | ±10%/次 |
### 衰减示例计算
```python
# 示例：智能登机口技术页面
page_confidence = {
"current": 0.85, # 当前置信度
"age_days": 90, # 创建90天
"usage_frequency": 0.6, # 中等使用频率
"sources_count": 3, # 3个来源
"conflicts": 1 # 1个冲突
}
# 计算衰减
new_confidence = decay_confidence(
current_confidence=0.85,
age_days=90,
usage_frequency=0.6,
sources_count=3
)
# 应用冲突惩罚
if page_confidence["conflicts"] > 0:
new_confidence -= 0.05 * page_confidence["conflicts"]
print(f"原始置信度: 0.85 → 衰减后: {new_confidence:.2f}")
# 输出: 原始置信度: 0.85 → 衰减后: 0.76
```
---
## 🔄 知识整合层次
### 层次 1: **事实级整合**
```python
def integrate_facts(existing_fact: Fact, new_fact: Fact) -> IntegrationResult:
"""
整合新事实到现有知识
返回: 保持原样 | 更新 | 并列 | 弃用
"""
# 1. 检查直接冲突
if is_direct_conflict(existing_fact, new_fact):
return resolve_conflict(existing_fact, new_fact)
# 2. 检查互补性
if is_complementary(existing_fact, new_fact):
return merge_facts(existing_fact, new_fact)
# 3. 检查相关性
if is_related(existing_fact, new_fact):
return link_facts(existing_fact, new_fact)
# 4. 无关联则独立存储
return IntegrationResult.KEEP_BOTH
```
### 层次 2: **页面级整合**
```python
def integrate_pages(target_page: Page, new_content: str, source: str):
"""
整合新内容到现有页面
"""
# 1. 提取关键事实
new_facts = extract_facts(new_content)
# 2. 与页面现有事实比较
for fact in new_facts:
# 查找匹配的现有事实
matches = find_matching_facts(target_page, fact)
if not matches:
# 新事实：添加
target_page.add_fact(fact, source)
elif len(matches) == 1:
# 匹配事实：整合
result = integrate_facts(matches[0], fact)
if result == IntegrationResult.UPDATE:
# 更新现有事实（提高置信度）
matches[0].update(fact, source)
elif result == IntegrationResult.DEPRECATE:
# 弃用旧事实
matches[0].mark_deprecated(fact, source)
else:
# 多个匹配：需要人工审核
target_page.flag_for_review(fact, matches)
# 3. 更新页面置信度
target_page.recalculate_confidence()
```
### 层次 3: **主题级整合**
```python
def integrate_topic(topic: str, new_sources: List[str]):
"""
整合新来源到主题（如"智能登机口"）
"""
# 1. 获取主题相关页面
related_pages = get_pages_by_topic(topic)
# 2. 对每个新来源
for source in new_sources:
content = read_source(source)
# 3. 分发给相关页面
for page in related_pages:
# 检查相关性
relevance = calculate_relevance(content, page)
if relevance > 0.3:
integrate_pages(page, content, source)
# 4. 创建新页面（如需）
uncovered_aspects = find_uncovered_aspects(content, related_pages)
for aspect in uncovered_aspects:
create_new_page(aspect, content, source)
# 5. 主题级置信度更新
update_topic_confidence(topic)
```
### 层次 4: **领域级整合**
```python
def integrate_domain(domain: str, time_period: str = "monthly"):
"""
跨主题的领域级整合（如"机场运营技术"）
"""
# 1. 获取领域内所有主题
topics = get_topics_in_domain(domain)
# 2. 识别跨主题模式
cross_topic_patterns = analyze_cross_topic_patterns(topics)
# 3. 整合重复信息
deduplicate_across_topics(topics)
# 4. 更新主题关系图
update_domain_relationship_graph(domain, topics)
# 5. 生成领域报告
report = generate_domain_integration_report(domain, topics)
return report
```
---
## 🗑️ 知识淘汰与归档
### 淘汰决策树
```
开始
↓
置信度 < 0.3 ?
├─ 是 → 标记为过时
└─ 否 →
↓
有更新的替代版本？
├─ 是 → superseded_by 链接
└─ 否 →
↓
创建时间 > 2 年？
├─ 是 → 归档建议
└─ 否 → 保持活跃
```
### 归档流程
```python
def archive_knowledge():
"""
自动知识归档流程
1. 识别候选
2. 验证替代关系
3. 执行归档
4. 更新引用
"""
# 1. 识别归档候选
candidates = find_archive_candidates()
for candidate in candidates:
# 2. 检查是否有替代版本
replacement = find_replacement(candidate)
if replacement:
# 3. 建立 superseded_by 关系
candidate.superseded_by = replacement
# 4. 移动页面到归档目录
archive_path = move_to_archive(candidate)
# 5. 更新所有引用
update_references(candidate, replacement)
log_event("page_archived", {
"page": candidate.path,
"replacement": replacement.path,
"reason": "superseded_by",
"timestamp": now()
})
else:
# 无替代版本：降低搜索权重
candidate.search_weight *= 0.1
log_event("page_deprecated", {
"page": candidate.path,
"reason": "no_replacement",
"timestamp": now()
})
return {"archived": len(candidates)}
```
---
## 🎯 置信度驱动的搜索排名
### 搜索评分算法
```python
def calculate_search_score(page: Page, query: str, user_context: Dict) -> float:
"""
结合置信度、相关性和时效性的搜索评分
"""
# 1. 基础文本相关性 (BM25)
text_relevance = bm25_score(page.content, query)
# 2. 语义相关性 (嵌入相似度)
semantic_relevance = embedding_similarity(page.embedding, query_embedding)
# 3. 置信度调整
confidence_adjustment = page.confidence ** 2 # 平方加权，高置信度优势更大
# 4. 时效性调整（新知识优先）
recency_adjustment = 1.0 / (1 + page.age_days / 180) # 半年衰减一半
# 5. 用户个性化（如有历史数据）
personalization = calculate_personalization_score(page, user_context)
# 综合评分
score = (
text_relevance * 0.4 +
semantic_relevance * 0.4 +
confidence_adjustment * 0.15 +
recency_adjustment * 0.05 +
personalization * 0.1 # 如果用户有历史数据，否则为0
)
return score
```
### 置信度阈值
| 置信度区间 | 搜索可见性 | 推荐系统 | 自动引用 |
|------------|------------|----------|----------|
| **0.8-1.0** | 最高优先级 | 主动推荐 | 自动引用 |
| **0.6-0.79** | 正常显示 | 可能推荐 | 谨慎引用 |
| **0.4-0.59** | 较低权重 | 很少推荐 | 标记警告 |
| **0.2-0.39** | 需明确搜索 | 不推荐 | 避免引用 |
| **<0.2** | 隐藏（归档） | 不推荐 | 不引用 |
---
## 📊 生命周期监控
### 仪表板指标
```python
def get_lifecycle_metrics():
"""
返回知识生命周期关键指标
"""
return {
"total_pages": count_pages(),
"by_confidence": {
"high": count_pages(confidence_min=0.8),
"medium": count_pages(confidence_min=0.5, confidence_max=0.79),
"low": count_pages(confidence_min=0.2, confidence_max=0.49),
"archived": count_pages(confidence_max=0.19)
},
"decay_rate": calculate_average_decay_rate(),
"conflict_resolution_rate": get_conflict_resolution_rate(),
"archival_rate": count_archived_last_month(),
"average_age_days": get_average_page_age()
}
```
### 健康检查
```python
def health_check_lifecycle():
"""
生命周期系统健康检查
"""
issues = []
# 检查过度衰减
if get_average_decay_rate() > 0.1:
issues.append("置信度衰减过快")
# 检查冲突积压
if count_unresolved_conflicts() > 20:
issues.append("未解决冲突过多")
# 检查归档堆积
if count_candidates_for_archive() > 50:
issues.append("归档候选积压")
# 检查更新频率
if days_since_last_integration() > 30:
issues.append("整合操作长期未执行")
return {
"status": "healthy" if not issues else "needs_attention",
"issues": issues,
"metrics": get_lifecycle_metrics()
}
```
---
## 🚀 实施路线图
### 阶段 1：基础衰减（当前）
- ✅ 页面级置信度字段
- ✅ 简单的基于时间的衰减
- 🔄 每周自动衰减脚本
### 阶段 2：智能整合（2-4周）
- 🔄 事实级冲突检测
- 🔄 页面级整合算法
- 🔄 置信度驱动的搜索排名
- 🔄 基础仪表板
### 阶段 3：高级生命周期（1-2月）
- 🔄 主题级和领域级整合
- 🔄 自适应衰减参数
- 🔄 用户反馈集成
- 🔄 预测性归档建议
### 阶段 4：自主管理（未来）
- 🔄 自适应的遗忘曲线
- 🔄 跨wiki知识同步
- 🔄 主动知识维护
- 🔄 预测性内容生成
---
## 📚 相关文档
- [[automation-hooks.md]] - 触发置信度衰减的自动化事件
- [[knowledge-management/knowledge-graph.md]] - 整合过程中的关系更新
- [[hybrid-search.md]] - 置信度驱动的搜索排名
- [[quality-control.md]] - 质量评估和归档决策
- [[wiki-backup-recovery.md]] - 归档内容的备份管理
---
> **状态**: 基础置信度衰减已实现。下一步：集成智能冲突检测和整合算法。最后更新：2026-04-13。
airport-wiki/concepts/knowledge-management/llm-wiki-v2-reference.md
-584
View File
@@ -1,584 +0,0 @@
---
title: LLM Wiki v2 参考文档
created: 2026-04-13
updated: 2026-04-13
type: meta
tags: [llm-wiki, v2, reference, architecture]
confidence: 0.9
sources_count: 5
last_confirmed: 2026-04-13
status: active
relationships:
- target: SCHEMA.md
type: implements
detail: "v2 架构实现"
confidence: 0.95
- target: concepts/knowledge-management/automation-hooks.md
type: core-component
detail: "自动化钩子系统"
confidence: 0.9
- target: concepts/knowledge-management/knowledge-lifecycle.md
type: core-component
detail: "知识生命周期"
confidence: 0.9
- target: concepts/knowledge-management/quality-control.md
type: core-component
detail: "质量控制机制"
confidence: 0.9
- target: concepts/knowledge-management/knowledge-graph.md
type: core-component
detail: "实体图管理"
confidence: 0.85
- target: concepts/knowledge-management/hybrid-search.md
type: core-component
detail: "混合搜索系统"
confidence: 0.85
---
# 📚 LLM Wiki v2 参考文档
**机场智能化工程知识库的架构与技术实现指南**
基于 Karpathy 的 LLM Wiki 理念，v2 版本引入了**动态知识管理**、**智能检索**和**自动化维护**三大核心能力。本文档详细说明架构设计、实现原理和配置方法。
> **v2 核心理念**：知识是动态的有机体，需要随时间衰减、冲突整合和持续验证，而非静态的文档集合。
---
## 🏗️ 架构总览
### 系统分层架构
```
应用层 (Application Layer)
├── 搜索引擎 (Hybrid Search Engine)
├── 关系图谱 (Knowledge Graph Browser)
└── 质量看板 (Quality Dashboard)
核心层 (Core Layer)
├── 自动化钩子系统 (Automation Hooks)
├── 置信度衰减引擎 (Confidence Decay Engine)
├── 冲突检测处理器 (Conflict Detection Processor)
└── 自我纠正机制 (Self-correction Mechanism)
存储层 (Storage Layer)
├── 向量数据库 (Vector Database) # 嵌入存储
├── 文档存储 (Document Store) # Markdown/YAML
└── 关系数据库 (Relational Database) # 实体关系
```
### 数据流向
```
新来源 → 解析 → 实体提取 → 事实提取 → 冲突检测 → 置信度评估 → 存储
↓ ↓ ↓ ↓ ↓
现有知识 ← 整合 ← 关系更新 ← 冲突解决 ← 置信度衰减 ← 质量验证 ← 定期任务
```
---
## 🔧 核心组件详解
### 1. **置信度系统 (Confidence System)**
#### 置信度字段结构
```yaml
---
confidence: 0.85 # 当前置信度 (0.1-1.0)
sources_count: 3 # 引用来源数量
last_confirmed: 2026-04-13 # 最后一次确认/更新
confidence_history: # 置信度变化历史
- date: 2026-04-10
value: 0.80
reason: "new_source_added"
- date: 2026-04-12
value: 0.83
reason: "conflict_resolved"
- date: 2026-04-13
value: 0.85
reason: "weekly_decay_applied"
decay_factors: # 衰减因子权重
time: 0.60
usage: 0.20
sources: 0.15
conflicts: 0.05
---
```
#### 衰减算法
```python
def decay_confidence(current, age_days, usage_freq, sources_cnt, conflicts_cnt):
# 基础时间衰减（每月5%）
base_decay = 0.95 ** (age_days / 30)
# 强化因子（使用频率和来源数量）
reinforcement = (usage_freq * 0.3) + (min(sources_cnt, 5) * 0.05)
# 应用衰减
new_confidence = current * base_decay + (1 - base_decay) * reinforcement
# 冲突惩罚
new_confidence -= 0.05 * conflicts_cnt
# 边界处理
return max(0.05, min(1.0, new_confidence))
```
### 2. **实体图管理系统 (Entity Graph Management)**
#### 实体类型定义
```python
ENTITY_TYPES = {
"airport": {
"attributes": ["code", "name", "location", "capacity", "status"],
"relationships": {
"uses": ["technology", "system", "vendor"],
"located_in": ["region", "country"],
"implements": ["standard", "certification"]
}
},
"technology": {
"attributes": ["category", "vendor", "version", "specs"],
"relationships": {
"used_by": ["airport", "system"],
"compatible_with": ["technology"],
"replaces": ["technology"]
}
},
"vendor": {
"attributes": ["name", "country", "specialization", "market_share"],
"relationships": {
"provides": ["technology", "service"],
"competes_with": ["vendor"],
"partners_with": ["vendor"]
}
}
}
```
#### 关系类型
| 关系类型 | 语义 | 反向关系 | 示例 |
|----------|------|----------|------|
| **uses** | 使用 | used_by | 深圳机场 uses SITA AODB |
| **implements** | 实现 | implemented_by | JFK implements ACI EUROPE 2020 |
| **replaces** | 替换 | replaced_by | H100 replaces A100 |
| **based_on** | 基于 | basis_for | 数字孿生 based_on BIM 模型 |
| **compatible_with** | 兼容 | compatible_with | RoCE compatible_with InfiniBand |
| **partners_with** | 合作 | partners_with | SITA partners_with Huawei |
### 3. **自动化钩子系统 (Automation Hooks)**
#### 事件注册表
```python
HOOK_REGISTRY = {
"source_added": [
{"callback": "parse_source", "priority": 10},
{"callback": "extract_entities", "priority": 9},
{"callback": "detect_conflicts", "priority": 8},
{"callback": "update_confidence", "priority": 7}
],
"page_updated": [
{"callback": "check_semantic_change", "priority": 10},
{"callback": "update_embeddings", "priority": 9},
{"callback": "propagate_relations", "priority": 8},
{"callback": "log_change", "priority": 5}
],
"query_executed": [
{"callback": "record_query_pattern", "priority": 10},
{"callback": "evaluate_results", "priority": 8},
{"callback": "generate_suggestions", "priority": 5}
]
}
```
#### 定时任务调度
```python
SCHEDULE_CONFIG = {
"daily": {
"time": "02:30",
"tasks": [
"verify_recent_changes",
"update_recommendations",
"clean_temp_files",
"backup_incremental"
]
},
"weekly": {
"time": "03:00",
"day": "sunday",
"tasks": [
"run_lint_check",
"decay_confidence_scores",
"regenerate_embeddings",
"rebuild_search_index"
]
},
"monthly": {
"time": "04:00",
"day": 1, # 每月1日
"tasks": [
"archive_stale_content",
"evaluate_embedding_models",
"analyze_growth_trends",
"run_security_audit"
]
}
}
```
### 4. **混合搜索系统 (Hybrid Search System)**
#### 搜索评分算法
```python
def calculate_search_score(page, query, user_context):
# 1. 文本相关性 (BM25)
text_relevance = bm25_score(page.content, query)
# 2. 语义相关性 (嵌入相似度)
semantic_relevance = embedding_similarity(page.embedding, query_embedding)
# 3. 置信度调整
confidence_adjustment = page.confidence ** 2
# 4. 时效性调整
recency_adjustment = 1.0 / (1 + page.age_days / 180)
# 5. 个性化调整
personalization = calculate_personalization_score(page, user_context)
# 综合评分 (加权)
score = (
text_relevance * 0.4 +
semantic_relevance * 0.4 +
confidence_adjustment * 0.15 +
recency_adjustment * 0.05 +
personalization * 0.1
)
return score
```
#### 查询重写策略
```python
QUERY_REWRITE_RULES = [
# 同义词扩展
{"pattern": r"\bgpu\b", "expansion": "gpu OR graphics processing unit OR ai accelerator"},
# 技术缩写扩展
{"pattern": r"\baodb\b", "expansion": "aodb OR airport operational database"},
# 机场代码映射
{"pattern": r"\bSZX\b", "expansion": "SZX OR Shenzhen Bao'an International Airport"},
{"pattern": r"\bJFK\b", "expansion": "JFK OR New York John F. Kennedy Airport"},
# 单位标准化
{"pattern": r"(\d+)\s*kw", "expansion": "$1 kW OR $1 kilowatt"},
{"pattern": r"(\d+)\s*MW", "expansion": "$1 MW OR $1 megawatt"},
]
```
---
## ⚙️ 配置与部署
### 配置文件结构
```yaml
# ~/.hermes/ObsidianVault/airport-wiki/config.yaml
llm_wiki:
version: "2.1.0"
confidence:
decay_rate: 0.05 # 每月衰减率
min_confidence: 0.05
max_confidence: 1.0
usage_weight: 0.2
sources_weight: 0.15
automation:
enabled: true
check_interval_seconds: 15 # 文件监视间隔
max_workers: 3
search:
hybrid_enabled: true
vector_weight: 0.4
keyword_weight: 0.4
confidence_weight: 0.15
recency_weight: 0.05
query_expansion: true
entities:
types: ["airport", "technology", "vendor", "standard", "system"]
relation_types: ["uses", "implements", "replaces", "based_on", "compatible_with"]
storage:
vector_db: "chromadb"
doc_store: "filesystem"
graph_db: "sqlite"
monitoring:
metrics_enabled: true
alerting_enabled: true
log_level: "info"
```
### 环境变量
```bash
# LLM Wiki 核心配置
export LLM_WIKI_HOME="/home/windy/.hermes/ObsidianVault/airport-wiki"
export EMBEDDING_MODEL="all-MiniLM-L6-v2"
export VECTOR_DB_HOST="localhost"
export VECTOR_DB_PORT=8000
# 自动化钩子
export HOOKS_ENABLED="true"
export HOOKS_CHECK_INTERVAL="15"
export HOOKS_MAX_WORKERS="3"
# 监控和日志
export LOG_LEVEL="info"
export METRICS_PORT="9090"
export ALERT_WEBHOOK="https://hooks.slack.com/services/..."
```
### 初始化脚本
```bash
#!/bin/bash
# init_llm_wiki_v2.sh
# 1. 检查依赖
check_dependencies() {
echo "检查依赖..."
python3 --version >/dev/null 2>&1 || { echo "需要 Python 3.8+"; exit 1; }
pip --version >/dev/null 2>&1 || { echo "需要 pip"; exit 1; }
}
# 2. 安装 Python 包
install_packages() {
echo "安装 Python 包..."
pip install -r requirements.txt
}
# 3. 初始化数据库
init_databases() {
echo "初始化数据库..."
python -c "from storage import init_db; init_db()"
}
# 4. 生成初始嵌入
generate_initial_embeddings() {
echo "生成初始嵌入..."
python -c "from embeddings import generate_all_embeddings; generate_all_embeddings()"
}
# 5. 启动服务
start_services() {
echo "启动服务..."
# 启动文件监视服务
python -m hooks.file_watcher &
# 启动定时任务调度器
python -m hooks.scheduler &
# 启动监控服务
python -m monitoring.metrics_server &
}
main() {
echo "=== LLM Wiki v2 初始化 ==="
check_dependencies
install_packages
init_databases
generate_initial_embeddings
start_services
echo "✅ 初始化完成"
echo "监控面板: http://localhost:9090"
echo "搜索端点: http://localhost:8000/search"
}
main "$@"
```
---
## 🔄 升级与迁移
### 从 v1 升级到 v2
#### 步骤 1: 备份 v1 数据
```bash
# 备份整个 wiki 目录
tar -czf wiki_v1_backup_$(date +%Y%m%d).tar.gz airport-wiki/
# 导出实体关系
python -c "from v1_exporter import export_all; export_all('v1_export.json')"
```
#### 步骤 2: 安装 v2 组件
```bash
# 创建新配置目录
mkdir -p ~/.hermes/ObsidianVault/airport-wiki/concepts/knowledge-management
# 安装 v2 Python 包
pip install llm-wiki-v2
# 初始化 v2 数据库
python -m llm_wiki_v2.init --config config.yaml
```
#### 步骤 3: 迁移数据
```bash
# 运行迁移脚本
python -m llm_wiki_v2.migrate \
--v1_path ./airport-wiki \
--v2_path ./airport-wiki-v2 \
--mode incremental
```
#### 步骤 4: 验证迁移
```bash
# 检查置信度字段
python -c "from validation import check_migration; check_migration('airport-wiki-v2')"
# 测试搜索功能
curl -X POST "http://localhost:8000/search" \
-H "Content-Type: application/json" \
-d '{"query": "GPU cluster power consumption", "limit": 5}'
```
### 数据迁移策略
| 数据类型 | v1 格式 | v2 格式 | 迁移方法 |
|----------|---------|---------|----------|
| **页面内容** | 纯 Markdown | Markdown + YAML frontmatter | 解析并添加置信度字段 |
| **实体关系** | 链接（无类型） | 类型化关系 | 提取文本关系并分类 |
| **嵌入向量** | 无 | 向量数据库 | 重新生成所有嵌入 |
| **搜索索引** | 文件搜索 | 混合搜索索引 | 重建索引 |
---
## 📊 监控与告警
### 关键性能指标 (KPIs)
```python
KPI_CONFIG = {
"search": {
"response_time_p95": {"threshold": 3000, "unit": "ms"},
"success_rate": {"threshold": 0.95, "unit": "%"},
"recall_at_5": {"threshold": 0.85, "unit": "%"}
},
"confidence": {
"average_confidence": {"threshold": 0.7, "unit": "score"},
"decay_rate": {"threshold": 0.1, "unit": "/month"},
"conflict_resolution_rate": {"threshold": 0.9, "unit": "%"}
},
"automation": {
"hook_success_rate": {"threshold": 0.95, "unit": "%"},
"processing_time_p95": {"threshold": 5000, "unit": "ms"},
"backlog_size": {"threshold": 100, "unit": "items"}
}
}
```
### 告警规则
```yaml
alerts:
- name: "search_degradation"
condition: "search_response_time_p95 > 3000 OR search_success_rate < 0.95"
severity: "critical"
actions: ["page_oncall", "rollback_search_config"]
- name: "confidence_anomaly"
condition: "average_confidence < 0.6 OR decay_rate > 0.15"
severity: "high"
actions: ["notify_maintainer", "run_verification"]
- name: "automation_failure"
condition: "hook_success_rate < 0.9 OR backlog_size > 200"
severity: "medium"
actions: ["log_incident", "restart_workers"]
```
### 监控仪表板
- **搜索性能仪表板**：响应时间、命中率、用户满意度
- **知识质量仪表板**：平均置信度、冲突数量、更新频率
- **系统健康仪表板**：自动化成功率、存储使用率、错误率
---
## 🛠️ 故障排除
### 常见问题及解决方法
| 问题 | 症状 | 解决方案 |
|------|------|----------|
| **置信度不衰减** | 页面置信度长期不变 | 检查定时任务是否运行；验证衰减算法参数 |
| **搜索结果差** | 相关页面排名靠后 | 调整搜索权重；重新生成嵌入；检查索引 |
| **自动化钩子失败** | 文件变更未触发处理 | 验证文件监视配置；检查权限；查看日志 |
| **实体关系缺失** | 页面无关系链接 | 运行实体提取；检查关系检测规则 |
| **嵌入生成失败** | 页面无嵌入向量 | 检查模型加载；验证文本编码；查看错误日志 |
### 诊断命令
```bash
# 检查系统状态
python -m llm_wiki_v2.status --full
# 查看日志
tail -f ~/.hermes/logs/llm_wiki.log
# 手动触发维护任务
python -m hooks.runner --task weekly_maintenance
# 检查数据库完整性
python -c "from storage import verify_integrity; verify_integrity()"
# 重置错误状态
python -m llm_wiki_v2.reset --component hooks
```
---
## 🔮 未来发展方向
### 近期计划 (1-3个月)
- **智能答案生成**：基于查询自动生成综合答案
- **预测性维护**：基于历史模式预测知识老化
- **多模态支持**：图像、图表等非文本内容处理
- **用户行为分析**：优化搜索和推荐系统
### 中期计划 (3-12个月)
- **跨wiki知识同步**：多个wiki之间的知识共享
- **自适应学习**：系统自动调整参数和规则
- **自然语言更新**：用户用自然语言编辑知识
- **实时协作**：多用户同时编辑和注释
### 长期愿景 (1年以上)
- **自主知识管理**：系统完全自主维护和优化知识库
- **预测性内容创建**：基于趋势预测自动创建新内容
- **智能决策支持**：基于知识库提供决策建议
- **认知增强**：与人类思维深度协同的知识系统
---
## 📚 相关资源
### 官方文档
- [[SCHEMA.md]] - 架构定义和设计规范
- [[concepts/knowledge-management/automation-hooks.md]] - 自动化钩子详细实现
- [[concepts/knowledge-management/knowledge-lifecycle.md]] - 知识生命周期管理
- [[concepts/knowledge-management/quality-control.md]] - 质量控制机制
- [[concepts/knowledge-management/knowledge-graph.md]] - 实体图管理
- [[concepts/knowledge-management/hybrid-search.md]] - 混合搜索系统
### 工具和库
- **向量数据库**: ChromaDB, Qdrant, Weaviate
- **嵌入模型**: all-MiniLM-L6-v2, BGE, OpenAI embeddings
- **搜索引擎**: Elasticsearch, Meilisearch, Typesense
- **监控**: Prometheus, Grafana, OpenTelemetry
### 参考文献
1. Karpathy, A. "LLM: A Personal Knowledge Base"
2. Luhmann, N. "Zettelkasten Method"
3. Ahrens, S. "How to Take Smart Notes"
4. Vannevar Bush, "As We May Think"
---
> **版本**: v2.1.0 | **最后更新**: 2026-04-13
> **维护状态**: 活跃 | **支持**: 用户文档 + 技术支持论坛
> **注意**: 本系统持续演进，建议定期查看相关文档获取最新信息。
airport-wiki/concepts/knowledge-management/memory-lifecycle.md
-197
View File
@@ -1,197 +0,0 @@
---
title: 记忆生命周期
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, confidence, supersession, forgetting, consolidation-tier]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# 记忆生命周期
## 概述
Wiki 内容不是平等有效的。原始 LLM Wiki 模式将所有知识视为永久有效，而实践中知识有生命周期。本页阐述四层生命周期管理机制，让 wiki 从"平等声明的平面集合"变为"可判断置信度的动态模型"。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)（agentmemory 项目实战经验）。
## 置信度评分（Confidence Scoring）
每条 wiki 事实应携带置信度分数，声明其可靠性。
### 评分维度
| 维度 | 说明 |
|------|------|
| **来源数量** | 有多少独立来源支持该声明 |
| **时效性** | 最近一次确认的时间 |
| **矛盾检测** | 是否有其他来源否定该声明 |
### 置信度表示法
在 frontmatter 或行内元数据中标注：
```yaml
confidence: 0.85
sources_count: 2
last_confirmed: 2026-04-01
superseded_by: null
```
**示例：**
> "郑州航空港当前算力 10,000P" — confidence: 0.9（官方新闻稿，2026-03）
> "GB200 NVL72 HBM3e 带宽 16 TB/s" — confidence: 0.95（NVIDIA 官方白皮书）
> "某供应商报价 2026 Q4 交付" — confidence: 0.4（单一非官方来源，未经交叉验证）
### 置信度衰减与强化
- **时间衰减**：事实的置信度随时间自然下降（架构决策衰减慢，bug/价格信息衰减快）
- **强化机制**：新来源确认 → 置信度上升；被新来源否定 → 触发 supersession
衰减率可参考 Ebbinghaus 遗忘曲线模型：
- 首次学习后 24 小时：保留约 40%
- 1 周后：保留约 25%
- 每个"访问/确认"事件重置衰减时钟
**实践建议：**
- `confidence > 0.8`：稳定知识，优先检索
- `confidence 0.5–0.8`：参考知识，标注不确定性
- `confidence < 0.5`：草稿或待验证，不用于关键结论
---
## 替代机制（Supersession）
当新信息推翻或更新现有声明时，使用 supersession 而非静默覆盖。
### 规则
1. 旧版本**不删除**，保留完整内容
2. 旧版本 frontmatter 标记 `superseded_by: [new-page-name]`，`superseded_date: YYYY-MM-DD`
3. 新版本 frontmatter 记录 `supersedes: [old-page-name]`，`supersedes_date: YYYY-MM-DD`
4. 旧页面添加 `status: stale` 标签，归档到 `_archive/`
### 示例
**旧版本（归档）：**
```yaml
---
title: 福州长乐机场智算中心
created: 2026-01-22
updated: 2026-01-22
status: stale
superseded_by: fuzhou-changle-airport-bsj
superseded_date: 2026-04-13
confidence: 0.7
---
# 福州长乐机场智算中心（已过时）
原报道：2026 年 Q4 投产，投资 11 亿元。
（此版本已被新版本替代，内容已更新）
```
**新版本：**
```yaml
---
title: 福州长乐机场智算中心
created: 2026-01-22
updated: 2026-04-13
type: entity
supersedes: _archive/fuzhou-changle-airport-old
supersedes_date: 2026-04-13
confidence: 0.9
sources_count: 3
---
```
### 触发条件
- 同一实体的新来源比旧来源更权威或更新
- 供应商方案更新、型号参数变化
- 项目时间节点变化（如投产日期推迟）
---
## 遗忘机制（Forgetting）
Wiki 不应该记住所有事情。没有遗忘机制的 wiki 会变得嘈杂，降低检索效率。
### 保留策略
| 知识类型 | 衰减速度 | 说明 |
|----------|----------|------|
| 架构决策 | 极慢 | 长期有效，少量衰减 |
| 硬件规格 | 慢 | 以年计，需等新一代产品 |
| 供应商方案 | 中 | 以季度计 |
| 项目进度/节点 | 快 | 月度变化，不重要后快速衰减 |
| Bug/问题记录 | 最快 | 解决后快速降权 |
### 实践方式
- **软删除**：不真正删除，frontmatter 标记 `status: dormant`
- **降权**：降低 `confidence`，不用于主要结论
- **归档转移**：移动至 `_archive/`，不纳入主要检索
### Ebbinghaus 遗忘曲线应用
- 每次**访问**或**来源确认**事件重置衰减时钟
- 长期未访问的事实自动降权
- `log.md` 中的历史记录本身也是一种衰减信号
---
## 整合层次（Consolidation Tiers）
原始观察需要经过管道处理才能成为可靠知识。建立以下层次：
| 层次 | 名称 | 内容 | 特征 |
|------|------|------|------|
| Tier 0 | **Working Memory** | 最近一次会话的观察，尚未处理 | 存于 session 上下文，不持久化 |
| Tier 1 | **Episodic Memory** | 会话摘要，从 raw sources 压缩而来 | `log.md` 中的 session 条目 |
| Tier 2 | **Semantic Memory** | 跨会话事实，从 episodes 整合 | `concepts/` 和 `entities/` 中的稳定页面 |
| Tier 3 | **Procedural Memory** | 工作流和模式，从重复的 semantics 提取 | `SCHEMA.md`、操作规程、schema |
### 升级规则
- **Working → Episodic**：session 结束时自动压缩为 `log.md` 条目
- **Episodic → Semantic**：同一实体/概念出现 2+ 次后，创建或更新 `entities/`/`concepts/` 页面
- **Semantic → Procedural**：跨 wiki 的模式被识别后，更新 `SCHEMA.md`
### 本 wiki 中的对应关系
```
Session / Chat
↓ session end
log.md (Episodic Memory — session summaries)
↓ 2+ mentions / important update
concepts/ entities/ (Semantic Memory — cross-session facts)
↓ schema-level pattern recognized
SCHEMA.md (Procedural Memory — workflows and conventions)
```
---
## 与现有 Wiki 的集成
### 当前缺口
1. `entities/` 目前只有 7 个机场实体，**无置信度字段**
2. `concepts/` 页面无 `confidence` / `superseded_by` / `status` 标记
3. `log.md` 是 episodic layer，但**未向上整合到 semantic memory**
4. 无 supersession 机制，旧版本被静默覆盖
### 近期改进
- [ ] 为所有 `entities/` 页面添加 `confidence` 和 `sources_count` 字段
- [ ] 建立 `_archive/` 目录，存放被 supersede 的旧版本
- [ ] 制定 wiki auto-lint 脚本，自动检测矛盾并触发 supersession
- [ ] 评估是否引入 `status: stale` / `status: dormant` 标记
---
## 相关页面
- [[knowledge-graph]] — 超越平面页面的结构化知识表示
- [[wiki-operations]] — ingest/query/lint 操作的自动化钩子
- [[glossary]] — 术语表（其中包含 confidence 相关的量化指标）
airport-wiki/concepts/knowledge-management/quality-control.md
-616
View File
@@ -1,616 +0,0 @@
---
title: 质量控制与自我纠正机制
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, quality-control, self-correction, validation]
confidence: 0.9
sources_count: 4
last_confirmed: 2026-04-13
status: active
relationships:
- target: automation-hooks.md
type: integrates-with
detail: "质量检查触发事件"
confidence: 0.95
- target: knowledge-management/knowledge-lifecycle.md
type: informs
detail: "置信度评估依据"
confidence: 0.9
- target: knowledge-management/knowledge-graph.md
type: validates
detail: "关系一致性检查"
confidence: 0.85
- target: hybrid-search.md
type: improves
detail: "搜索结果质量提升"
confidence: 0.8
---
# 🔍 质量控制与自我纠正机制
为机场智能化 wiki 建立**多层次质量验证**和**自动纠错**系统，确保技术参数准确、内容一致、关系完整。通过规则检查、语义验证和用户反馈，实现持续质量改进。
> **质量目标**：零技术参数错误，内容一致性 >95%，关系完整性 >90%，用户满意度 >85%。
---
## 🏗️ 质量框架层次
### 层次 1: **语法与格式检查** (Syntax & Format)
| 检查项 | 规则 | 自动修复 | 严重性 |
|--------|------|----------|--------|
| **Markdown 语法** | 链接格式、标题层级、列表 | ✅ 自动修复 | 低 |
| **YAML 前端元数据** | 必需字段、类型验证 | ✅ 自动修复 | 中 |
| **文件命名规范** | 小写、连字符、无空格 | ✅ 自动修复 | 低 |
| **编码与换行** | UTF-8, LF 换行 | ✅ 自动修复 | 低 |
### 层次 2: **内容一致性检查** (Content Consistency)
| 检查项 | 规则 | 自动修复 | 严重性 |
|--------|------|----------|--------|
| **技术参数一致性** | 同一参数多源一致 | ⚠️ 标记冲突 | 高 |
| **单位统一性** | kW vs MW, GB vs GiB | ✅ 自动转换 | 中 |
| **术语标准化** | 统一技术术语 | ✅ 建议替换 | 中 |
| **日期格式** | ISO 8601 标准 | ✅ 自动转换 | 低 |
### 层次 3: **语义与逻辑检查** (Semantic & Logic)
| 检查项 | 规则 | 自动修复 | 严重性 |
|--------|------|----------|--------|
| **事实冲突检测** | 矛盾陈述识别 | ❌ 人工审核 | 高 |
| **因果关系验证** | 逻辑链完整性 | ⚠️ 标记缺失 | 中 |
| **数值合理性** | 功率/容量范围检查 | ⚠️ 标记异常 | 高 |
| **时间线一致性** | 事件顺序验证 | ⚠️ 标记矛盾 | 中 |
### 层次 4: **关系完整性检查** (Relationship Integrity)
| 检查项 | 规则 | 自动修复 | 严重性 |
|--------|------|----------|--------|
| **死链检测** | 内部链接有效性 | ✅ 自动修复 | 中 |
| **孤立页面** | 无入链页面识别 | ⚠️ 标记孤立 | 低 |
| **循环引用** | 循环依赖检测 | ⚠️ 标记循环 | 中 |
| **关系对称性** | 双向关系验证 | ✅ 自动修复 | 中 |
---
## 🔧 自动检查规则库
### 技术参数验证规则
```python
TECHNICAL_RULES = {
"power_consumption": {
"pattern": r"(\d+(?:\.\d+)?)\s*(kW|MW|W)",
"validation": lambda value, unit: (
# 数据中心功率范围检查
if unit == "MW" and value > 100:
return False, "数据中心功率超过100MW需验证"
elif unit == "kW" and value < 1:
return False, "功率低于1kW可能错误"
else:
return True, ""
),
"auto_correct": lambda value, unit: (
# 自动单位转换 kW → MW
if unit == "kW" and value >= 1000:
return f"{value/1000:.2f} MW"
else:
return None
)
},
"temperature_range": {
"pattern": r"(\d+(?:\.\d+)?)\s*°?[CF]",
"validation": lambda value, unit: (
# 数据中心温度范围检查
if unit == "C" and (value < 18 or value > 27):
return False, "数据中心温度超出推荐范围 (18-27°C)"
elif unit == "F" and (value < 64 or value > 81):
return False, "数据中心温度超出推荐范围 (64-81°F)"
else:
return True, ""
),
"auto_correct": lambda value, unit: (
# 温度单位转换
if unit == "F":
return f"{(value-32)*5/9:.1f}°C"
else:
return None
)
},
"rack_power_density": {
"pattern": r"(\d+(?:\.\d+)?)\s*(kW/rack|kW per rack)",
"validation": lambda value, unit: (
# 机架功率密度检查
if value > 50:
return False, "机架功率密度超过50kW/rack需液冷"
elif value < 1:
return False, "机架功率密度低于1kW/rack可能错误"
else:
return True, ""
)
}
}
```
### 一致性检查规则
```python
CONSISTENCY_RULES = {
"vendor_product_names": {
"mappings": {
"NVIDIA": ["nvidia", "Nvidia", "NVIDIA Corporation"],
"Intel": ["intel", "Intel Corporation", "Intel Corp"],
"华为": ["Huawei", "huawei", "华为技术有限公司"],
"曙光": ["Sugon", "曙光信息", "中科曙光"]
},
"action": "standardize" # 标准化为规范名称
},
"date_formats": {
"patterns": [
r"\d{4}-\d{2}-\d{2}", # ISO 8601
r"\d{2}/\d{2}/\d{4}", # MM/DD/YYYY
r"\d{4}年\d{1,2}月\d{1,2}日" # 中文日期
],
"target_format": "%Y-%m-%d", # 统一为 ISO 8601
"action": "convert"
},
"capacity_units": {
"mappings": {
"GB": ["gb", "gigabyte", "gigabytes"],
"TB": ["tb", "terabyte", "terabytes"],
"PB": ["pb", "petabyte", "petabytes"],
"GiB": ["gib", "gibibyte"],
"TiB": ["tib", "tebibyte"]
},
"action": "standardize"
}
}
```
---
## 🛠️ 自我纠正机制
### 1. **自动修复流程**
```python
def auto_correction_pipeline(content: str) -> Tuple[str, List[Correction]]:
"""
自动纠正管道：多层修复策略
返回: (修正后内容, 修正记录列表)
"""
corrections = []
# 第1层：语法修复
content, syntax_fixes = fix_markdown_syntax(content)
corrections.extend(syntax_fixes)
# 第2层：格式修复
content, format_fixes = fix_yaml_frontmatter(content)
corrections.extend(format_fixes)
# 第3层：单位标准化
content, unit_fixes = standardize_units(content)
corrections.extend(unit_fixes)
# 第4层：术语标准化
content, term_fixes = standardize_terminology(content)
corrections.extend(term_fixes)
# 第5层：链接修复
content, link_fixes = fix_broken_links(content)
corrections.extend(link_fixes)
return content, corrections
```
### 2. **冲突解决策略**
```python
def resolve_content_conflict(existing_content: str,
new_content: str,
conflict_type: str) -> ResolutionResult:
"""
解决内容冲突的策略
"""
if conflict_type == "factual_conflict":
# 事实冲突：基于置信度选择
existing_confidence = calculate_confidence(existing_content)
new_confidence = calculate_confidence(new_content)
if new_confidence > existing_confidence * 1.2:
# 新内容置信度显著更高
return ResolutionResult.REPLACE
elif existing_confidence > new_confidence * 1.2:
# 现有内容置信度显著更高
return ResolutionResult.KEEP
else:
# 置信度相近：标记为待审核
return ResolutionResult.FLAG_FOR_REVIEW
elif conflict_type == "complementary_info":
# 互补信息：合并
return ResolutionResult.MERGE
elif conflict_type == "version_update":
# 版本更新：建立 superseded_by 关系
return ResolutionResult.SUPERSEDE
elif conflict_type == "formatting_only":
# 仅格式差异：保留更好格式
return ResolutionResult.KEEP_BETTER_FORMAT
else:
# 未知冲突类型：人工审核
return ResolutionResult.MANUAL_REVIEW
```
### 3. **质量评分系统**
```python
class QualityScorer:
"""质量评分系统"""
def __init__(self):
self.weights = {
"technical_accuracy": 0.30,
"consistency": 0.25,
"completeness": 0.20,
"recency": 0.15,
"source_credibility": 0.10
}
def score_page(self, page: Page) -> QualityScore:
"""计算页面质量分数 (0-100)"""
scores = {}
# 1. 技术准确性
scores["technical_accuracy"] = self._score_technical_accuracy(page)
# 2. 一致性
scores["consistency"] = self._score_consistency(page)
# 3. 完整性
scores["completeness"] = self._score_completeness(page)
# 4. 时效性
scores["recency"] = self._score_recency(page)
# 5. 来源可信度
scores["source_credibility"] = self._score_source_credibility(page)
# 加权总分
total_score = sum(
score * self.weights[metric]
for metric, score in scores.items()
)
return QualityScore(
total=total_score,
breakdown=scores,
grade=self._assign_grade(total_score)
)
def _assign_grade(self, score: float) -> str:
"""分配质量等级"""
if score >= 90:
return "A+"
elif score >= 80:
return "A"
elif score >= 70:
return "B"
elif score >= 60:
return "C"
elif score >= 50:
return "D"
else:
return "F"
```
---
## 📊 质量监控仪表板
### 关键质量指标 (KQIs)
```python
KQI_METRICS = {
"technical_accuracy_rate": {
"description": "技术参数准确率",
"calculation": "accurate_params / total_params",
"target": ">98%",
"weight": 0.35
},
"consistency_score": {
"description": "内容一致性评分",
"calculation": "average_consistency_score",
"target": ">95",
"weight": 0.25
},
"completeness_index": {
"description": "页面完整性指数",
"calculation": "filled_sections / total_sections",
"target": ">90%",
"weight": 0.20
},
"freshness_score": {
"description": "内容新鲜度评分",
"calculation": "weighted_average(recency)",
"target": ">85",
"weight": 0.10
},
"user_satisfaction": {
"description": "用户满意度",
"calculation": "positive_feedback / total_feedback",
"target": ">85%",
"weight": 0.10
}
}
```
### 质量趋势分析
```python
def analyze_quality_trends(time_period: str = "monthly"):
"""
分析质量趋势
"""
# 获取历史数据
history = get_quality_history(time_period)
trends = {}
for metric in KQI_METRICS:
values = [h[metric] for h in history]
# 计算趋势
if len(values) >= 2:
slope = calculate_slope(values)
trend = "improving" if slope > 0.01 else "declining" if slope < -0.01 else "stable"
# 检测异常点
anomalies = detect_anomalies(values)
trends[metric] = {
"current": values[-1],
"trend": trend,
"slope": slope,
"anomalies": anomalies,
"target": KQI_METRICS[metric]["target"]
}
# 综合质量指数
composite_score = calculate_composite_quality_index(trends)
return {
"period": time_period,
"composite_score": composite_score,
"trends": trends,
"recommendations": generate_quality_recommendations(trends)
}
```
---
## 🚨 异常检测与告警
### 异常检测规则
```python
ANOMALY_RULES = {
"sudden_confidence_drop": {
"condition": "confidence_change < -0.2",
"severity": "high",
"action": "investigate_source_changes"
},
"technical_parameter_outlier": {
"condition": "parameter_value outside 3σ",
"severity": "critical",
"action": "verify_with_primary_source"
},
"multiple_conflicts_detected": {
"condition": "conflict_count > 3",
"severity": "medium",
"action": "initiate_review_process"
},
"orphaned_page_created": {
"condition": "incoming_links == 0 AND outgoing_links > 5",
"severity": "low",
"action": "suggest_relationships"
},
"stale_content_alert": {
"condition": "last_updated > 180 days AND confidence > 0.7",
"severity": "medium",
"action": "schedule_refresh"
}
}
```
### 告警处理流程
```python
def handle_quality_alert(alert: Alert):
"""
处理质量告警
"""
# 1. 记录告警
log_alert(alert)
# 2. 根据严重性采取行动
if alert.severity == "critical":
# 立即处理：暂停相关页面，通知维护者
suspend_page(alert.page_id)
notify_maintainer(alert, priority="high")
# 启动调查
investigation = investigate_alert(alert)
# 根据调查结果采取行动
if investigation["requires_manual_fix"]:
create_maintenance_task(alert)
else:
apply_auto_fix(alert, investigation)
elif alert.severity == "high":
# 高优先级：标记为待处理，24小时内处理
create_maintenance_task(alert, due_in_hours=24)
notify_maintainer(alert, priority="medium")
elif alert.severity == "medium":
# 中优先级：加入待办队列，72小时内处理
create_maintenance_task(alert, due_in_hours=72)
elif alert.severity == "low":
# 低优先级：批量处理，每周统一处理
queue_for_batch_processing(alert)
# 3. 更新告警状态
update_alert_status(alert, "handled")
```
---
## 🔄 持续改进循环
### PDCA 循环 (Plan-Do-Check-Act)
```python
def quality_improvement_cycle():
"""
质量持续改进循环
"""
while True:
# 1. PLAN: 分析质量数据，制定改进计划
quality_report = analyze_quality_trends("weekly")
improvement_plan = create_improvement_plan(quality_report)
# 2. DO: 执行改进措施
implemented_changes = execute_improvement_plan(improvement_plan)
# 3. CHECK: 评估改进效果
effect_measurement = measure_improvement_effect(implemented_changes)
# 4. ACT: 标准化成功措施，调整失败措施
if effect_measurement["successful"]:
standardize_successful_changes(implemented_changes)
else:
adjust_failed_changes(implemented_changes, effect_measurement)
# 等待下一周期
time.sleep(7 * 24 * 3600) # 每周一次
```
### A/B 测试框架
```python
def run_quality_ab_test(test_name: str, variant_a: Dict, variant_b: Dict):
"""
运行质量改进A/B测试
"""
# 1. 随机分配页面到测试组
group_a, group_b = random_split_pages(test_name, 50)
# 2. 应用不同变体
apply_variant(group_a, variant_a)
apply_variant(group_b, variant_b)
# 3. 收集指标
metrics_a = collect_metrics(group_a, duration_days=14)
metrics_b = collect_metrics(group_b, duration_days=14)
# 4. 统计分析
result = statistical_analysis(metrics_a, metrics_b)
# 5. 决定获胜变体
if result["significant"] and result["winner"] == "A":
winning_variant = variant_a
elif result["significant"] and result["winner"] == "B":
winning_variant = variant_b
else:
winning_variant = None # 无显著差异
# 6. 记录测试结果
log_ab_test_result(test_name, result, winning_variant)
return {
"test_name": test_name,
"result": result,
"winning_variant": winning_variant,
"recommendation": "implement" if winning_variant else "no_change"
}
```
---
## 📋 质量检查清单
### 每日检查
- [ ] 语法检查报告（自动）
- [ ] 新内容质量评分（自动）
- [ ] 冲突检测（自动）
- [ ] 链接有效性检查（自动）
### 每周检查
- [ ] 技术参数一致性验证（半自动）
- [ ] 关系完整性检查（自动）
- [ ] 质量趋势分析（自动）
- [ ] 用户反馈分析（半自动）
### 每月检查
- [ ] 全面质量审计（手动）
- [ ] 规则库更新评估（手动）
- [ ] 自我纠正效果评估（半自动）
- [ ] 质量改进计划制定（手动）
### 季度检查
- [ ] 质量框架评估（手动）
- [ ] 用户满意度调查（手动）
- [ ] 基准对比分析（半自动）
- [ ] 战略调整（手动）
---
## 🚀 实施路线图
### 阶段 1：基础检查（当前）
- ✅ 语法和格式检查
- ✅ 基本一致性验证
- 🔄 自动修复简单问题
- 🔄 质量评分基础框架
### 阶段 2：智能验证（2-4周）
- 🔄 技术参数验证规则
- 🔄 语义冲突检测
- 🔄 自动冲突解决策略
- 🔄 质量监控仪表板
### 阶段 3：自我纠正（1-2月）
- 🔄 多层修复管道
- 🔄 异常检测和告警
- 🔄 用户反馈集成
- 🔄 A/B测试框架
### 阶段 4：持续改进（未来）
- 🔄 自适应质量规则
- 🔄 预测性质量维护
- 🔄 跨wiki质量同步
- 🔄 自主质量优化
---
## 📚 相关文档
- [[automation-hooks.md]] - 质量检查触发事件
- [[knowledge-management/knowledge-lifecycle.md]] - 置信度评估依据
- [[knowledge-management/knowledge-graph.md]] - 关系一致性检查
- [[hybrid-search.md]] - 搜索结果质量提升
- [[wiki-backup-recovery.md]] - 质量问题的回滚机制
---
> **状态**: 基础语法检查和一致性验证已实现。下一步：集成技术参数验证和冲突检测。最后更新：2026-04-13。
airport-wiki/concepts/knowledge-management/wiki-operations.md
-186
View File
@@ -1,186 +0,0 @@
---
title: Wiki 操作与自动化
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, automation, ingestion, lint, event-hooks]
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
---
# Wiki 操作与自动化
## 概述
原始 LLM Wiki 定义了三个基础操作：ingest（摄入）、query（查询）、lint（清理）。在规模化运营中，这三个操作需要扩展为事件驱动架构：每个事件类型触发预定义的自动化钩子，人只做 curation，bookkeeping 全自动化。
本页描述扩展后的操作模型及其在本 wiki 中的实践。
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
---
## 三层操作模型
### Layer 1：原始来源层（Raw Sources）
`raw/` 目录，保存未处理的原始文档：
- 新闻报道、白皮书、官方文档
- 每次摄入注明来源、日期、URL
### Layer 2：Wiki 层（Semantic Memory）
`concepts/`、`entities/`、`comparisons/` 中的页面：
- 经过处理的结构化知识
- 从 raw sources 提取、整合、标注关系
### Layer 3：Schema 层（Procedural Memory）
`SCHEMA.md` 和 `log.md`：
- 元知识、工作流、命名规范
- 从 wiki 操作中积累的模式
---
## 事件钩子（Event Hooks）
### 标准钩子矩阵
| 事件 | 自动触发动作 |
|------|-------------|
| **On new source** | 存档至 `raw/` → 运行 entity extraction → 更新 `entities/index.md` → 检查 supersession → 更新 index.md |
| **On session start** | 根据最近 `log.md` 条目加载相关上下文 |
| **On session end** | 将会话压缩为 episodic 条目写入 `log.md` |
| **On query** | 检索时检查答案是否值得写回 wiki（quality score > threshold） |
| **On memory write** | 检查矛盾，触发 supersession，更新 confidence |
| **On schedule**（定时） | 全量 lint、consolidation tier 检查、confidence decay、遗忘处理 |
### On New Source — 完整流程
```
收到新来源（用户提供 URL / Gist / 文件）
↓
1. 下载并保存至 raw/articles/[slug]-[date].md
↓
2. 自动 entity extraction
- 识别：机场名、供应商、硬件型号、系统名
- 提取 Typed Relationships
- 分配 confidence 初值（来源权威性 × 时效性）
↓
3. 矛盾检测
- 与现有 entities 比较
- 若发现矛盾 → 触发 supersession 流程
- 旧版本 → _archive/，标记 status: stale
↓
4. 更新目录
- 新增 entities → entities/index.md
- 新增 concepts → index.md 对应 section
- 更新 log.md
↓
5. 通知（如有重大矛盾）
- 标记待用户审核
```
### On Session End — 压缩流程
```
会话结束信号
↓
1. 提取本次会话的关键结论
- "新了解到 …"
- "已验证 …"
- "仍有疑问 …"
↓
2. 写入 log.md（Episodic Memory）
条目格式：
- 日期 + session id
- 来源：本次对话
- 新知识：<压缩后的结论>
- 开放问题：<下次需验证>
↓
3. 评估是否升级至 Semantic Memory
- 同一实体在 2+ session 中出现？
- 是 → 创建/更新 entities/ 或 concepts/ 页面
```
### On Schedule — 定期维护
```
每日/每周定时任务
↓
1. Confidence decay
- 所有 entities/concepts 按时间衰减
- 衰减率：架构决策 0.1%/月，供应商信息 1%/月，进度信息 5%/月
↓
2. Orphan check
- 没有入站链接的页面 → 标记 review
- 入站链接多但内容少的"薄页" → 合并或扩展
↓
3. Broken link scan
- 检查所有 wikilink 有效性
- 检查所有 raw source 文件是否存在
↓
4. Supersession review
- 标记为 stale > 3 个月且无访问 → 移至 _archive/
```
---
## 自动化实现方案
### 当前状态 vs 目标状态
| 操作 | 当前（手动） | 目标（自动） |
|------|-------------|-------------|
| 来源摄入 | 用户触发 | On new source hook |
| Session 摘要 | 无 | On session end → log.md |
| 矛盾检测 | 无 | On memory write → supersession |
| 定期 lint | 偶尔手动 | On schedule cron |
| 置信度衰减 | 无 | On schedule cron |
### 近期可实现步骤
1. **会话结束自动写 log**
- 在 `hermes-agent` 中增加 post-session hook
- 自动压缩本次对话结论写入 `log.md`
2. **建立 supersession 工作流**
- ingestion 时检测矛盾
- 自动创建旧版本 archive + 链接新版本
3. **Cron 定期 lint**
- 使用 `hermes cron` 每日运行 lint 脚本
- 检测断链、orphaned pages、confidence decay
### 实施优先级
1. **P0（立即）**：建立 `_archive/` 目录 + supersession 流程
2. **P1（本周）**：entity extraction 脚本（基于正则/NER）
3. **P2（本月）**：session end hook → log.md
4. **P3（下月）**：定时 cron lint + confidence decay
---
## 质量评分（Quality Scoring）
每次 LLM 生成内容时，给出质量分数：
| 分数 | 含义 | 行动 |
|------|------|------|
| `quality > 0.9` | 高质量，直接写入 wiki | 自动写入 |
| `quality 0.7–0.9` | 可接受，需人工审核 | 写入草稿，待 review |
| `quality < 0.7` | 低质量，不写入 | 记录但不持久化 |
**质量维度：**
- 结构化程度（是否遵循 frontmatter 规范）
- 来源引用（是否有 `sources` 字段）
- wikilink 密度（是否有足够的交叉引用）
- 长度合理性（不过短/不过长）
- 事实一致性（与已知知识不矛盾）
---
## 相关页面
- [[memory-lifecycle]] — confidence scoring、supersession、forgetting 机制
- [[knowledge-graph]] — entity extraction、typed relationships
- [[SCHEMA]] — wiki 结构规范（Procedural Memory）
airport-wiki/concepts/tech-infrastructure/airport-data-center-overview.md
-59
View File
@@ -1,59 +0,0 @@
---
title: 机场数据中心概述
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [glossary, planning]
sources: []
---
# 机场数据中心概述
## 定义
机场数据中心（Airport Data Center）是支撑民用航空运输业务运营的核心 IT 基础设施，为航班信息系统（AIDS/FIDS）、行李分拣系统、离港系统（DCS）、空管通信、乘客服务等关键系统提供计算、存储和网络服务。
## 核心特征
- **高可用性要求**：通常需满足 Tier III 或 Tier IV 等级
- **业务连续性**：7×24 小时不间断运行，航班延误成本极高
- **多系统集成**：数十个子系统需要互联互通
- **安全等级高**：涉及航空安全，合规要求严格
- **地理位置分散**：航站楼、塔台、行李中心通常各自有小机房
## 关键子系统
- 航班信息显示系统（FIDS）
- 离港控制系统（DCS）
- 行李处理系统（BHS）
- 安检信息系统
- 地面通信网络
- 楼宇自控系统（BAS）
- 视频监控系统（CCTV）
- 应急指挥中心
## 数据中心等级参考
| 等级 | 可用性 | 年停机时间 | 适用场景 |
|------|--------|-----------|---------|
| Tier I | 99.67% | >31.5h | 基础，非关键系统 |
| Tier II | 99.75% | 22h | 冗余组件，非关键业务 |
| Tier III | 99.98% | 1.6h | 主机房，推荐等级 |
| Tier IV | 99.99% | 0.8h | 最高等级，关键业务 |
> 参考：[[tier-iii-design]] | [[tier-iv-design]]
## 建设阶段
1. **选址与可行性分析** — 航空限制净空要求、地质条件、网络延迟至航站楼
2. **方案设计** — 等级确定（Tier III/IV）、分区规划、电力容量
3. **招标与供应商选择** — Uptime Tier认证要求、设备品牌（华为/维谛/伊顿）
4. **施工管理** — BIM协同、航空禁区作业窗口、航站楼不停航施工
5. **调试验收** — 满载测试、PUE实测、N+x冗余验证
6. **运维阶段** — 7×24值守、Uptime Tier M&O认证、生命周期管理
## 相关概念
- [[glossary]] — 术语表
- [[network-architecture]] — 网络架构
- [[power-and-cooling]] — 供配电与制冷
airport-wiki/concepts/tech-infrastructure/commissioning.md
-88
View File
@@ -1,88 +0,0 @@
---
title: 调试验收
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [commissioning, testing, pue, tier]
sources: []
---
# 调试验收
## 调试阶段定义
调试验收（Commissioning）是数据中心建设完成后的系统性验证阶段，确保所有系统按设计规格运行。新建机场数据中心的调试周期通常 1-3 个月。
## 调试阶段划分
```
设备单体调试 → 系统联调 → 综合联调 → 满载验证 → 性能调优 → 竣工验收
```
### 阶段一：设备单体调试
各设备制造商工程师到场，对各自设备进行通电、功能测试：
| 系统 | 调试内容 | 验收标准 |
|------|---------|---------|
| UPS | 切换测试（主路→旁路→电池） | 切换时间 < 5ms，零切换 |
| 发电机 | 自动投切测试、带载测试 | 10s 内完成投切，带载 > 100% 额定 1h |
| 冷冻机 | 冷量调节、冷却能力测试 | 在设计工况下达到额定冷量 |
| 精密空调 | 温湿度控制精度 | 温度 ±1°C，湿度 ±5% RH |
| 行级空调/液冷 | 制冷量调节、进出水温度 | 冷板供水平均温度 40-50°C |
### 阶段二：系统联调
多设备组成子系统后的协同测试：
- **电力系统联调**：市电切换 → UPS 供电 → 发电机接管，全链路验证
- **制冷系统联调**：冷冻水泵-冷冻机-末端联动，冷却水系统联调
- **消防系统联调**：火灾报警→确认→气体释放，全链路联动测试
- **BA/楼控联调**：各子系统纳入楼宇自控，场景模式测试（正常/夜间/节能/火灾）
### 阶段三：综合联调（切负荷测试）
模拟数据中心整体运行的所有典型场景：
| 测试场景 | 测试内容 | 合格标准 |
|---------|---------|---------|
| 单路市电中断 | 一路市电断电，发电机接管 | < 10s 内完成，IT 设备不掉电 |
| 单台 UPS 故障 | 单台 UPS 退出，余量 UPS 承接 | 所有回路供电不中断 |
| 冷源中断 | 冷冻机故障，备用冷机启动 | 供水温度不超过设计值 |
| 人员误操作 | 模拟常见误操作场景 | 系统有保护，不产生事故 |
### 阶段四：满载验证（PUE 实测）
**100% IT 负荷满载测试**是 Tier 认证的必要条件，也是性能验收的核心：
```
满载测试流程
Day 1: 50% 负荷运行 4h → 检查温升
Day 2: 75% 负荷运行 8h → 监控温湿度场
Day 3: 100% 负荷运行 24h
├── 测试 UPS 备电时长
├── 测量 PUE（数据中心总能耗 / IT 设备能耗）
└── 验证制冷系统在高负荷下的制冷量
Day 4: 逐步减载至正常负荷
```
| PUE 实测参考 | 指标 |
|------------|------|
| 优秀（液冷） | PUE < 1.15 |
| 良好（风液融合） | PUE 1.15-1.30 |
| 合格（风冷） | PUE 1.30-1.50 |
> 参考：[[power-and-cooling]]
## Uptime Tier 认证现场验证
Uptime Institute Tier Constructed Facility（TCF）现场认证测试内容：
| 测试项目 | 测试方法 | 允许失败次数 |
|---------|---------|------------|
| 电力故障响应 | 主动切断市电，观察系统切换 | **0次**（TCF 必须零失败） |
| 制冷故障响应 | 模拟冷冻机故障 | **0次** |
| 通信链路冗余 | 断开主用网络链路 | **0次** |
| 满载连续运行 | 100% 负荷运行 24h | 可接受可恢复的小故障 |
> 相关：[[tier-iii-design]] | [[tier-iv-design]] | [[construction-management]] | [[operation-maintenance]]
airport-wiki/concepts/tech-infrastructure/construction-management.md
-82
View File
@@ -1,82 +0,0 @@
---
title: 施工管理
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [construction, bim, project-management, airside]
sources: []
---
# 施工管理
## 机场施工管理特殊性
机场内施工面临三大特殊约束：
1. **不停航施工**：航站楼/跑道不停运，施工时间窗口受限
2. **航空禁区准入**：施工人员/车辆需办理机场禁区证（AZAL）
3. **电磁干扰控制**：施工活动不得干扰空管通信、导航、监视系统
## 施工准入管理
### 人员与车辆准入
| 类型 | 准入要求 | 有效期 |
|------|---------|-------|
| 长期施工人员 | 机场通行证（需无犯罪记录+体检） | 6-12 个月 |
| 临时施工人员 | 当日临时通行证 + 安检 | 当日有效 |
| 施工车辆 | 机场通行证 + 灭火器 | 按施工期 |
| 特种设备（吊车等） | 需单独申请 + 空管评估 | 按作业审批 |
### 禁区施工时间窗口
- **航后施工**（深夜 01:00-05:00）：仅允许不影响目视助航灯光的作业
- **航班间隙施工**：每次申请 10-30 分钟窗口，需提前 48h 申请
- **长期占用**：需关闭部分机位或滑行道，需航行影响评估（OPI）
## BIM 在施工管理中的应用
### 4D 进度模拟
将 BIM 模型与项目进度计划（Project Schedule）关联，实现可视化的施工进度管理：
```
BIM 4D 应用流程
设计模型 (LOD400)
↓ 深化 + 编码
施工模型 + WBS 编码
↓ 关联 Project
4D 模拟（时间轴动画）
↓ 现场应用
BIM 巡检 App（手机端实时更新）
```
### 碰撞检查与现场核实
- 在施工前通过 BIM 协调会解决所有管线碰撞
- 现场施工员使用移动端 BIM 核对安装位置
- 重要节点（隐蔽工程封闭前）需拍照留档
## 关键施工质量控制点（ITP）
### 隐蔽工程验收
| 隐蔽工程 | 验收要点 | 见证文件 |
|---------|---------|---------|
| 基础/结构 | 地基承载力检测、钢筋绑扎 | 地质勘查报告 |
| 机电管线 | 打压测试、保温验收 | 压力测试报告 |
| 防雷接地 | 接地电阻 < 10Ω | 接地测试报告 |
| 钢筋网架 | 防雷等电位连接 | 等电位测试记录 |
| 楼板/墙体防火 | 防火封堵、耐火极限 | 型式检验报告 |
### 机房移交前的关键检查
- [ ] 机柜配电与 UPS 供电路径标识清晰
- [ ] 冷通道封闭安装完成，气流密封有效
- [ ] 消防系统（气体灭火）联动测试通过
- [ ] DCIM 系统与现场设备通信正常
- [ ] 满载测试（带载 100% IT 负荷）完成
## 相关页面
> 相关：[[design-phase]] | [[rfp-and-vendor-selection]] | [[commissioning]] | [[operation-maintenance]]
airport-wiki/concepts/tech-infrastructure/design-phase.md
-79
View File
@@ -1,79 +0,0 @@
---
title: 机场数据中心方案设计
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [design, tier, planning, bpa]
sources: []
---
# 机场数据中心方案设计
## 设计阶段划分
机场数据中心设计分为四个主要阶段，贯穿整个建设周期：
```
可行性研究 → 初步设计 → 施工图设计 → 设计变更管理
```
## 等级确定（Tier Selection）
等级选择是设计阶段最重要的决策，决定了所有后续设计的冗余配置基准。
### 机场场景等级推荐
| 应用场景 | 推荐等级 | 年可用性 | 适用系统 |
|---------|---------|---------|---------|
| 航班信息核心系统（FIDS/DCS） | Tier IV | 99.995% | AODB, FIDS, DCS |
| 应急指挥中心 | Tier IV | 99.995% | 应急指挥、视频监控 |
| 行李处理系统（BHS） | Tier III+ | 99.99% | BHS 控制中心 |
| 办公与后勤系统 | Tier II | 99.75% | 办公网络 |
| 智算算力集群 | Tier III | 99.98% | GPU 集群 |
> 参考：[[tier-iii-design]] | [[tier-iv-design]]
## 功能分区规划
### 典型机场数据中心分区
```
┌──────────────────────────────────────────────────┐
│ 机场数据中心功能分区 │
├──────────┬──────────┬──────────┬──────────────────┤
│ IT 主机房 │ 电力机房 │ 冷冻站 │ 监控中心 ECC │
│ (ICT Room)│ (UPS/发电机)│(Chiller) │ (有人值守) │
├──────────┴──────────┴──────────┴──────────────────┤
│ 运营商接入 / 网络间 (Telecom Room) │
└──────────────────────────────────────────────────┘
```
### 分区设计要点
- **IT 主机房**：单机柜功率密度 5-50kW，高密区优先布置在冷通道两侧
- **电力机房**：UPS 电池间需满足气体灭火覆盖，发电机需独立油罐（消防审批）
- **冷冻站**：优先靠近 IT 主机房，减少管路长度；优先选择自然冷源（蒸发冷却）
- **网络间**：MDF/IDF 需满足电信运营商进入条件，室外光缆引入井
## BIM 协同设计
机场项目强制使用 BIM（Building Information Modeling）进行设计协同，是数字化交付的核心：
### BIM 应用层级
| 阶段 | BIM 深度 | 应用点 |
|------|---------|-------|
| 初步设计 | LOD 200-300 | 方案比选、指标统计 |
| 施工图 | LOD 400 | 管线综合碰撞检查、深化设计 |
| 施工阶段 | LOD 400+ | 4D 进度模拟、现场 BIM 巡检 |
| 运维阶段 | LOD 500 | 数字孪生、设施管理 |
### 关键碰撞检查
- 电力桥架与冷冻水管交叉（电力管廊与冷冻水管需保持 > 500mm 间距）
- 结构梁底净空与机柜顶部间距
- 气体灭火管道与 HVAC 送回风管道
## 相关页面
> 相关：[[airport-data-center-overview]] | [[site-planning]] | [[network-architecture]] | [[power-and-cooling]] | [[tier-iii-design]]
airport-wiki/concepts/tech-infrastructure/glossary.md
-335
View File
@@ -1,335 +0,0 @@
---
title: 术语表
created: 2026-04-08
updated: 2026-04-10
type: concept
tags: [glossary]
sources: []
---
# 术语表
> 機場智算中心 + 航班運營 wiki 全部專有縮寫與名詞解釋
> 整理自：機場數據中心、GPU 集群、網絡架構、供配電、A-CDM、AODB、SMGCS、BHS、開放架構、未來信息中心等所有頁面
---
## 一、數據中心基礎設施
### 能耗與效率指標
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| PUE | Power Usage Effectiveness | 電能使用效率（= 總設施能耗 / IT 設備能耗，理想值 ≤ 1.22）|
| WUE | Water Usage Effectiveness | 水資源使用效率（上海智算導則：≤ 2.0 L/kWh）|
| CUE | Carbon Usage Effectiveness | 碳使用效率（上海智算導則：≤ 1.0 gCO₂/kWh）|
| DCiE | Data Center infrastructure Efficiency | 數據中心基礎設施效率（= IT 設備能耗 / 總設施能耗，理想值 60-80%）|
### 供配電
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| UPS | Uninterruptible Power Supply | 不間斷電源 |
| ATS | Automatic Transfer Switch | 自動轉換開關 |
| PDU | Power Distribution Unit | 配電單元 |
| PSU | Power Supply Unit | 電源供應單元（服務器內）|
| CDU | Coolant Distribution Unit | 冷卻液分配單元（液冷系統）|
| SCALE-UP | Scalable UPS | 可擴展 UPS 架構 |
### 制冷與 HVAC
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| HVAC | Heating, Ventilation, Air Conditioning | 暖通空調系統 |
| BAS / BMS | Building Automation System / Building Management System | 樓宇自控系統 |
| PEX | Precision Environmental Equipment | 精密恆溫恆濕空調 |
| RH | Relative Humidity | 相對濕度 |
### 可用性與可靠性
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| MTTF | Mean Time To Failure | 平均故障前時間 |
| MTTR | Mean Time To Repair | 平均修復時間 |
| MTBF | Mean Time Between Failures | 平均故障間隔時間 |
| RTO | Recovery Time Objective | 恢復時間目標 |
| RPO | Recovery Point Objective | 恢復點目標 |
| SLA | Service Level Agreement | 服務水平協議 |
### 標準與認證
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| ANSI | American National Standards Institute | 美國國家標準協會 |
| TIA | Telecommunications Industry Association | 電信工業協會 |
| ISO | International Organization for Standardization | 國際標準化組織 |
| Uptime | Uptime Institute（Tier I/II/III/IV 認證機構）| Uptime 機構分級 |
| TCF | Tier Certified Facility | Uptime 建造認證 |
| ATD | Accredited Tier Designer | Uptime 設計師認證 |
| ATS | Accredited Tier Specialist | Uptime 專家認證 |
| AME | Accredited Tier Maintainer | Uptime 運維商認證 |
| GB | Guobiao Standard | 中國國家標準（如 GB 50174-2017 數據中心設計規範）|
---
## 二、智算中心與 GPU 集群
### 算力單位
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| TFLOPS | Tera Floating-Point Operations Per Second | 萬億次浮點運算/秒 |
| PFLOPS | Peta FLOPS | 千萬億次浮點運算/秒 |
| EFLOPS | Exa FLOPS | 百億億次浮點運算/秒 |
| TOPS | Tera Operations Per Second | 萬億次操作/秒 |
| QPS | Queries Per Second | 每秒查詢數 |
| IOPS | Input/Output Operations Per Second | 每秒輸入/輸出操作數 |
### GPU 與芯片
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| GPU | Graphics Processing Unit | 圖形處理器（NVIDIA H100/H200/B200 等）|
| NPU | Neural-network Processing Unit | 神经网络处理器（昇腾 910 系列）|
| TPU | Tensor Processing Unit | Google 張量處理單元 |
| ASIC | Application-Specific Integrated Circuit | 專用集成電路 |
| HBM | High Bandwidth Memory | 高帶寬內存（GPU 顯存標準）|
| SXM | SXM (Sonnet) Form Factor | NVIDIA 另一種 GPU 形態（對比 PCIe）|
| HGX | NVIDIA HGX Baseboard | NVIDIA 官方服務器基板（8-GPU）|
| DGX | NVIDIA DGX System | NVIDIA 整機系統品牌 |
### 集群與訓練框架
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| TP | Tensor Parallelism | 張量並行 |
| PP | Pipeline Parallelism | 流 水線並行 |
| DP | Data Parallelism | 數據並行 |
| DDP | Distributed Data Parallel | 分布式數據並行 |
| FSDP | Fully Sharded Data Parallel | 完全分片數據並行 |
| NCCL | NVIDIA Collective Communications Library | NVIDIA 集合通信庫 |
| RDMA | Remote Direct Memory Access | 遠程直接內存訪問（InfiniBand 核心）|
| SHARP | Scalable Hierarchical Aggregation and Reduction Protocol | NVIDIA 網內計算協議 |
| UFM | Unified Fabric Manager | InfiniBand 監控管理工具 |
| DCGM | Data Center GPU Manager | NVIDIA GPU 監控工具 |
### 推理引擎
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| vLLM | Virtual Large Language Model Server | 伯克利 LMSYS 推理引擎，擅長 PagedAttention |
| TGI | Text Generation Inference | Hugging Face 推理引擎 |
| LM | Large Model | 大模型訓練框架（如 Megatron-LM、ColossalAI）|
| KV | Key-Value（Cache）| KV 緩存，推斷引擎核心優化點 |
---
## 三、網絡架構
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| LAN | Local Area Network | 局域網 |
| WAN | Wide Area Network | 廣域網 |
| DCI | Data Center Interconnect | 數據中心互聯 |
| Spine-Leaf | Spine-Leaf Architecture | 脊葉架構（數據中心網絡拓撲）|
| IB / HDR / NDR | InfiniBand / HDR / NDR | 高性能計算網絡標準（400G/800G）|
| RoCE | RDMA over Converged Ethernet | 以太網 RDMA 協議 |
| eRoCE | enhanced RoCE | 增強型 RoCE，支持可變 MTU |
| LACP | Link Aggregation Control Protocol | 鏈路聚合控制協議 |
| SDN | Software-Defined Networking | 軟件定義網絡 |
| NAC | Network Access Control | 網絡准入控制 |
| IDS / IPS | Intrusion Detection/Prevention System | 入侵檢測/防禦系統 |
| FW | Firewall | 防火牆 |
| DMZ | Demilitarized Zone | 隔離區 |
| VPN | Virtual Private Network | 虛擬專用網絡 |
| ZTNA | Zero Trust Network Architecture | 零信任網絡架構 |
| APT | Advanced Persistent Threat | 高級持續性威脅 |
| DDoS | Distributed Denial of Service | 分布式拒絕服務攻擊 |
| MTU | Maximum Transmission Unit | 最大傳輸單元 |
| IMIX | Internet Mix | 混合包大小測試標準 |
| QoS | Quality of Service | 服務質量 |
| L3 | Layer 3（Network Layer）| 網絡層 |
| VLAN | Virtual Local Area Network | 虛擬局域網 |
---
## 四、機場運營系統
### 核心機場系統
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| AODB | Airport Operational Database | 機場運營數據庫（SSOT 單一數據源）|
| A-CDM | Airport Collaborative Decision Making | 機場協同決策 |
| BHS | Baggage Handling System | 行李處理系統 |
| FIDS | Flight Information Display System | 航班信息顯示系統 |
| AIDS | Airport Information Display System | 機場信息顯示系統 |
| DCS | Departure Control System | 離港控制系統（航空公司）|
| RMS | Resource Management System | 資源管理系統（機位/登機口/設備）|
| SMGCS | Surface Movement Guidance and Control System | 場面活動引導與控制系統 |
| A-SMGCS | Advanced SMGCS | 高級場面活動引導與控制系統（L1-L4 功能層級）|
| DCB | Departure Control Board / Docking Board | 登機口協調板 |
| VDGS | Visual Docking Guidance System | 目視停機位引導系統 |
| VDGS | Visual Docking Guidance System | 目視停機位引導系統 |
| ADS-B | Automatic Dependent Surveillance-Broadcast | 廣播式自動相關監視 |
| SMR | Surface Movement Radar | 場面活動雷達 |
| ASDE-X | Airport Surface Detection Equipment | 場面探測設備 |
| SSR | Secondary Surveillance Radar | 二次監視雷達 |
| TDOA | Time Difference of Arrival | 到達時間差（多點定位）|
| MSS | Movement Surveillance System | 活動監視系統 |
| VSLS | Variable Spacing Lighting System | 可變間距燈光系統 |
| RVR | Runway Visual Range | 跑道視程 |
| LVP | Low Visibility Procedures | 低能見度運營程序 |
### A-CDM 關鍵節點
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| TOBT | Target Off-Block Time | 目標擋輪檔時間 |
| TSAT | Target Start-Up Approval Time | 目標起動批准時間 |
| TTOT | Target Take-Off Time | 目標起飛時間 |
| CTOT | Calculated Take-Off Time | 計算起飛時間（ATFM 發布）|
| ASAT | Actual Start-Up Approval Time | 實際起動批准時間 |
| EIBT | Estimated In-Block Time | 預計靠廊橋時間 |
| AOBT | Actual Off-Block Time | 實際擋輪檔時間 |
| ATOT | Actual Take-Off Time | 實際起飛時間 |
| ALDT | Actual Landing Time | 實際落地時間 |
| ELDT | Estimated Landing Time | 預計落地時間 |
| EXOT | Expected Taxi-Out Time | 預期滑出時間 |
| EXIT | Expected Taxi-In Time | 預期滑入時間 |
| MCT | Minimum Connection Time | 最小銜接時間 |
| ACISP | A-CDM Information Sharing Platform | A-CDM 信息共享平台 |
| PDS | Pre-Departure Sequencing | 起飛前排序 |
---
## 五、航班數據交換
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| SSIM | Standard Schedules Information Manual | IATA 航班計劃信息手冊（SSIM/AHM 格式）|
| AIRIMP | Airport Interchange Implementation | IATA 航班數據交換實現標準 |
| AHM | Airport Handling Manual | 機場操作手冊（IATA）|
| CIDX | Cockpit Interactive Data Exchange | 駕駛艙交互數據交換 |
| ARINC | Aeronautical Radio Incorporated | 航空電子設備與地面系統接口標準 |
| AEA | Airlines Electronic Engineering Committee | 國際航空電子企業協會 |
| IATA | International Air Transport Association | 國際航空運輸協會 |
| ICAO | International Civil Aviation Organization | 國際民用航空組織 |
| FAA | Federal Aviation Administration | 美國聯邦航空管理局 |
| EASA | European Union Aviation Safety Agency | 歐盟航空安全局 |
| ANSP | Air Navigation Service Provider | 空中交通服務提供商 |
---
## 六、行李系統
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| RFID | Radio-Frequency Identification | 射頻識別 |
| EBS | Early Bag Storage | 提前行李儲存（早到行李緩存區）|
| IBS | Individual Baggage Sorting | 行李分揀系統 |
| BRS | Baggage Reconciliation System | 行李核對系統 |
| Tote | Transport Orthogonal TErminal | 轉盤載行李車（IATA 標準載體）|
| BSM | Bag Service Message | 行李服務消息（IATA）|
| CRS | Computer Reservation System | 計算機訂座系統 |
---
## 七、供應商與解決方案
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| SITA | Société Internationale de Télécommunications Aéronautiques | 國際航空電信公司 |
| Amadeus | （公司名）| 旅遊科技巨頭（Altéa DCS/RMS）|
| ADB SAFEGATE | （公司名）| 停機位/場面解決方案供應商 |
| Indra | （公司名）| 西班牙航空科技公司（AODB/RMS）|
| Vanderlande | （公司名）| 荷蘭行李處理系統廠商 |
| Smiths Detection | （公司名）| 安檢設備（X光機/CT 掃描儀）|
| TAV Technologies | （公司名）| 土耳其中東機場技術供應商 |
| Huawei | （公司名）| 華為（智算/網絡/AOCC）|
| NVIDIA | （公司名）| 英偉達（GPU/網絡）|
| Bentley Systems | （公司名）| 數字孿生基礎設施軟件 |
| CCMA | 中科曙光（Computers）| 曙光信息技術有限公司 |
| VERTIV | 維諦技術（Liebert PEX）| 關鍵基礎設施供應商 |
| CII | Critical Information Infrastructure | 關鍵信息基礎設施 |
---
## 八、開放架構與標準
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| DICOS | Dubai International Airport Open Architecture Standard | 迪拜機場開放架構標準 |
| ACRIS | Airport Core Reference Information Set | 機場核心信息集（ACI 標準）|
| ICDM | IATA-OS Conceptual Data Model | IATA 開放服務概念數據模型 |
| CDD | Core Data Dictionary | 核心數據字典 |
| DDS | Direct Data Solutions | 直接數據解決方案（IATA）|
| IATA-OS | IATA Open Platform | IATA 開放平台 |
| OPSL | Open Platform Software Library | 開放平台軟件庫 |
| DHS | Department of Homeland Security | 美國國土安全部 |
| CBP | Customs and Border Protection | 美國海關與邊境保護局 |
| TSA | Transportation Security Administration | 美國運輸安全管理局 |
---
## 九、未來信息中心與 AI
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| AOCC | Airport Operations Control Center | 機場運行控制中心 |
| IOC | Integrated Operations Center | 綜合運營中心 |
| AI | Artificial Intelligence | 人工智能 |
| AGI | Artificial General Intelligence | 通用人工智能 |
| LLM | Large Language Model | 大語言模型 |
| NLP | Natural Language Processing | 自然語言處理 |
| Agentic AI | Agentic Artificial Intelligence | 人工智能智能體（具備自主決策能力）|
| Hyper-Personalization | 超級個性化 | 主動預測式旅客服務 |
| Biometric Corridor | 生物特徵走廊 | 一次認證全流程通行（出行一張臉）|
| Digital Twin | 數字孿生 | 物理環境的高精度虛擬副本 |
| Universal Design | 通用設計 | 對所有人群（包括殘障人士）無障礙的設計理念 |
| HCD / HCI | Human-Centered Design / Human-Computer Interaction | 人本設計 / 人機交互 |
| ADA | Americans with Disabilities Act | 美國殘疾人法案 |
---
## 十、建設與項目管理
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| BIM | Building Information Modeling | 建築信息模型 |
| LOD | Level of Development / Level of Detail | 設計開工深度 / 細節層級 |
| WBS | Work Breakdown Structure | 工作分解結構 |
| ITP | Inspection and Test Plan | 檢驗測試計劃 |
| AZAL | Airport Zone Access Permit | 航空禁區准入證 |
| RFP | Request for Proposal | 需求建議書（招標文件）|
| BOD | Bid Opening Date | 開標日期 |
| FAT | Factory Acceptance Test | 工廠驗收測試 |
| SAT | Site Acceptance Test | 現場驗收測試 |
| EPC | Engineering, Procurement, Construction | 設計-採購-施工一體化總承包 |
| TCO | Total Cost of Ownership | 總擁有成本 |
| OPI | Operational Impact Assessment | 運營影響評估 |
---
## 十一、存儲與雲原生
| 縮寫 | 全稱 | 中文 |
|------|------|------|
| CEPH | Ceph Distributed Storage | 分佈式統一存儲系統 |
| GPFS | General Parallel File System（IBM Spectrum Scale）| IBM 並行文件系統 |
| NFS | Network File System | 網絡文件系統 |
| S3 | Simple Storage Service | 對象存儲協議（Amazon）|
| RGW | Rados Gateway | CEPH 對象存儲接口 |
| MinIO | MinIO Object Storage | S3 兼容輕量對象存儲 |
| FUSE | Filesystem in Userspace | 用戶態文件系統 |
| CSI | Container Storage Interface | 容器存儲接口 |
| JuiceFS | （開源並向文件系統）| 雲原生高性能共享文件系統 |
| POSIX | Portable Operating System Interface | 可移植操作系統接口標準 |
| MPI | Message Passing Interface | 消息傳遞接口 |
| ACK | Alibaba Cloud Kubernetes | 阿里雲 Kubernetes 服務 |
| CCI | Huawei Cloud Container Instance | 華為雲容器實例 |
| GPU Direct Storage | GPU Direct Storage | NVIDIA GPU 直接訪問存儲技術 |
---
> 相關：[[airport-data-center-overview]]（數據中心子系統全圖）
airport-wiki/concepts/tech-infrastructure/gpu-cluster.md
-139
View File
@@ -1,139 +0,0 @@
---
title: GPU 集群
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [server, cooling]
sources: [raw/articles/2025-airport-construction-summit.md, raw/articles/keydak-airport-expo-2025.md, raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md, raw/articles/上海市-智算中心建设导则2025版-2025-01.md]
---
# GPU 集群
## 定义
GPU 集群是由多台搭载 GPU（图形处理器）的服务器通过高速网络互联组成的计算单元，专门用于并行处理 AI 训练、推理、科学计算等高密度算力负载。
在机场智算中心场景下，GPU 集群是核心算力载体，支撑大模型训练、视频分析、智能决策等应用。
---
## 核心组成
### 算力芯片选型
|| 芯片 | 生产厂商 | FP16 算力 | 显存带宽 | NVLink带宽 | 功耗 | 机场适用场景 |
||------|---------|----------|----------|------------|------|-------------|
|| A100 SXM | NVIDIA | 312 TFLOPS | 2TB/s | 600GB/s | 400W | 训练/推理（当前主流） |
|| H100 SXM | NVIDIA | 1P | 3.35TB/s | 900GB/s | 700W | 大模型训练 |
|| H200 SXM | NVIDIA | 1P | 4.8TB/s | 900GB/s | 700W | 大规模训练/推理（HBM3e升级） |
|| B100 | NVIDIA | 1.75P | 8TB/s | 1.8TB/s | 1,000W | 超大规模智算中心 |
|| B200 | NVIDIA | 2.25P | 8TB/s | 1.8TB/s | 1,200W | 超大规模智算中心 |
|| **GB200 NVL72** | NVIDIA | **5P** | **16TB/s** | **3.6TB/s** | **2,700W** | 万卡集群（整机柜方案） |
|| 昇腾 910B | 华为 | 320 TFLOPS | — | — | 400W | 国产替代/推理 |
> 数据来源：头豹研究院《中国AIDC产业发展白皮书2025》
### 服务器形态（基于NVIDIA HGX架构）
|| 形态 | GPU算力 | GPU功耗 | 总功耗 | 适用场景 |
||------|---------|---------|--------|---------|
|| HGX A100 | 2.4P | 3.2kW | 6.5kW | 训练/推理（存量主流） |
|| HGX H100 | 8P | 5.6kW | 10.2kW | 训练集群主体 |
|| HGX B100 | 14P | 5.6kW | 10.2kW | 超大规模部署 |
|| **HGX B200** | **18P** | **8kW** | **14.3kW** | 万卡集群核心节点 |
> GB200 NVL72 为整机柜方案（72 GPU + 36 Grace CPU），单柜总功耗可达**2700W GPU芯片**，整柜更高。机场智算中心液冷需按**单柜15-30kW**设计。
> 数据来源：头豹研究院《中国AIDC产业发展白皮书2025》
### 网络架构
GPU 集群内网络是性能瓶颈，业界通常采用以下三层：
|| 网络层 | 带宽需求 | 协议/技术 |
||--------|---------|---------|
|| **计算网络**（GPU 间通信）| 800Gbps-1.6Tbps | InfiniBand HDR/NDR, RoCEv2 |
|| **存储网络** | 100-400Gbps | NVMe-oF, RoCEv2 |
|| **管理网络** | 1-10Gbps | 以太网 |
> 上海《智算中心建设导则2025》要求大规模训练场景下采用**智能无损网络**，计算网宜达**200Gbps**。
> 关键参数：GPU_PCIe_带宽需与网络带宽匹配（H100 SXM5 支持 900GB/s 双向 NVLink）
---
## 机场智算集群规划参数
基于行业实践，机场智算中心典型规模参考：
| 机场规模 | 推荐 GPU 集群规模 | 机柜数 | 典型功率密度 |
|---------|-----------------|--------|-------------|
| 年旅客量 < 1000万 | 32-64 卡 | 8-16 柜 | 50-80kW/柜 |
| 年旅客量 1000-5000万 | 64-256 卡 | 16-32 柜 | 60-100kW/柜 |
| 年旅客量 > 5000万 | 256-1024+ 卡 | 32-128+ 柜 | 80-120kW/柜 |
---
## 液冷配合（GPU 集群必选散热方案）
GPU 集群单机柜功率 50-120kW，传统风冷无法满足散热需求。
### 液冷方案对比
| 方案 | 散热能力 | 建设成本 | 运维复杂度 | 适用规模 |
|------|---------|---------|-----------|---------|
| **冷板式液冷** | ~120kW/柜 | 中 | 中 | 主流方案 |
| **浸没式液冷** | >200kW/柜 | 高 | 低（长期） | 超大规模 |
| **风液融合**（冷板+高效风冷）| 60-150kW/柜 | 中低 | 低 | 快速部署 |
> 华为自有冷板液冷技术已实现单柜 120kW 散热能力，详见 [[prefab-modular-dc]]
---
## 调度与运维
| 层面 | 技术选型 |
|------|---------|
| 集群管理 | Kubernetes + GPU Operator, Slurm |
| 分布式训练框架 | PyTorch DDP, Megatron-LM, DeepSpeed |
| 推理服务 | vLLM, TensorRT-LLM, Triton |
| 监控 | DCIM + Prometheus + Grafana |
| 算力调度 | 阿里云 ACK, 华为 CCI, 自研调度器 |
---
## 与现有页面的关联
- **[[modern-airport-trends]]** — 智算集群是四型机场趋势的技术驱动力
- **[[prefab-modular-dc]]** — 预制模块化 DC 是 GPU 集群的物理载体
- **[[power-and-cooling]]** — GPU 集群高功率密度决定液冷必选
- **[[network-architecture]]** — 计算网络（InfiniBand/RoCE）是集群性能关键
- **[[airport-data-center-overview]]** — GPU 集群是智算中心的核心子系统
---
## 机场集群投入参考
基于行业数据（千卡H100集群，头豹研究院2025白皮书）：
| 组成 | 费用 |
|------|------|
| 算力设备 | 约3亿元 |
| 网络设备 | 约2,500万元 |
| 存储/安全 | 约1,000万元 |
| 平台软件/液冷改造 | 约1,000万元 |
| **总计** | **约3.5亿元** |
**年运营支出**: 约5,000万元（电力占主导）
1. **国产替代路径** — 昇腾 910B 与 NVIDIA H100 的软件生态差距（CUDA 迁移成本）
2. **GPU 虚机化** — vGPU/算力切分技术尚不成熟，多租户场景受限
3. **能效指标** — 智算中心如何定义适合机场场景的 PUE 基准（传统 DC PUE<1.3 目标不适用）
4. **运维人才** — 机场 IT 团队普遍缺乏 GPU 集群运维能力
---
## 延伸阅读
- 机场智算中心技术方案：根目录 `机场智算中心技术方案.md`
- Keydak 风液融合方案：`raw/articles/keydak-airport-expo-2025.md`
airport-wiki/concepts/tech-infrastructure/modern-airport-trends.md
-66
View File
@@ -1,66 +0,0 @@
---
title: 现代化机场数据中心趋势
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [planning, design, network, cooling]
sources: [raw/articles/2025-airport-construction-summit.md, raw/articles/keydak-airport-expo-2025.md, raw/articles/dubai-airport-huawei-dc.md, raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md, raw/articles/IBM-Building-intelligent-airport-future-2025.md, raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md]
---
# 现代化机场数据中心趋势
## 2025-2026 行业方向
### 四型机场理念
中国民航"十四五"期间全面推行"四型机场"标准：
| 类型 | 含义 |
|------|------|
| 平安机场 | 安全生产、安全可控 |
| 绿色机场 | 低碳节能、双碳目标 |
| 智慧机场 | 数字化、智能化 |
| 人文机场 | 乘客体验优先 |
### 核心趋势
**1. 智算中心兴起**
- AI/AGI 驱动算力需求爆发
- 传统单机柜 5-15kW → 算力中心单机柜 50-120kW
- 传统风冷无法满足高功率散热，液冷成为必选
**2. 风液融合冷却**
- 支持 40kW 风冷 + 150kW 液冷混合部署
- 风液同源、动态平衡
- 适配单机柜功率密度持续上升趋势
- PUE 可降至 1.2 以下
**3. 预制模块化数据中心**
- 工厂预制、集装箱式交付
- 工期缩短 50%，建设成本大幅降低
- 适合机场空间有限、快速扩容的场景
**4. 建设运营一体化（BIM+数字孪生）**
- BIM 管理平台覆盖设计、施工、运维全周期
- 数字化施工监管系统
- 工程质量验评可回溯
- 无人值守运维逐步推广
**5. 网络架构升级**
- SDN 软件定义网络
- 多路由冗余接入
- 边缘计算节点下沉至航站楼
**6. AI 智能体矩阵落地**（2025-2026实践）
- 深圳机场率先完成 DeepSeek R1-671B 满血版部署（华为昇腾集群），42家千万级机场综合评价**第二名**
- IBM提出机场作为"Ecosystem Orchestrator"三层演进路径（规则执行→AI agent开发→复杂目标导向代理）
- AI安全助手（融合1,500份安全文档）、机位智能分配（4小时→1分钟）、AGV无人驾驶牵引车等10余个专属智能体已规模落地
**7. 航空物流智能化**
- 深圳机场深畅国际货站：AGV机器人+智能卡口，全国首个24小时智慧远程监管货站
- 进出口货物库内停留时间缩短82%、33%；无人接驳7×24小时不间断
**8. 万卡级智算集群选址逻辑**
- 郑州航空港：2小时高铁圈覆盖4亿人口，2小时航空圈覆盖全国90%人口/市场
- 福州长乐机场综保区：综保区政策红利，闽港数字协作，填补东南沿海高端智算缺口
> 相关：[[airport-data-center-overview]] | [[glossary]] | [[network-architecture]] | [[power-and-cooling]] | [[gpu-cluster]]
airport-wiki/concepts/tech-infrastructure/network-architecture.md
-36
View File
@@ -1,36 +0,0 @@
---
title: 网络架构
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [network, architecture]
sources: []
---
# 网络架构
## 机场数据中心网络特点
- 多业务分区：航站网、行李网、安防网、办公网相互隔离
- 高带宽需求：视频监控、行李分拣数据传输量大
- 低延迟要求：空管通信、航班信息显示对延迟敏感
- 多冗余路径：网络链路故障不能影响业务
## 常用架构
### Spine-Leaf 架构
- 适用于叶脊交换结构，东西向流量优化
- 推荐用于大型机场核心网络
### 三层网络架构
- 核心层 / 汇聚层 / 接入层
- 传统架构，适合中小型机房
## 网络安全
- 防火墙分区隔离
- 入侵检测/防御系统（IDS/IPS）
- 网络准入控制（NAC）
- DDoS 防护
> 相关：[[tier-iii-design]] | [[glossary]]
airport-wiki/concepts/tech-infrastructure/operation-maintenance.md
-107
View File
@@ -1,107 +0,0 @@
---
title: 运维管理
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [operations, maintenance, dcim, uptime, m&o]
sources: []
---
# 运维管理
## 运维目标与指标体系
机场数据中心运维的核心目标是保障业务连续性，衡量指标分三级：
### 一级指标（业务影响）
| 指标 | 定义 | 目标值 |
|------|------|-------|
| 可用性 | 运行时间 / 总时间 | Tier III: 99.982% / Tier IV: 99.995% |
| MTBF | 平均故障间隔时间 | > 8,760h（一年无计划外停机） |
| MTTR | 平均修复时间 | < 4h（关键系统）/ < 24h（非关键） |
| 年停机时间 | 计划+非计划停机总和 | Tier III: < 1.6h / Tier IV: < 0.8h |
### 二级指标（运维过程）
| 指标 | 说明 |
|------|------|
| 变更成功率 | 计划变更成功率目标 > 99% |
| 巡检完成率 | 关键设备每日巡检覆盖率 100% |
| 工单闭环率 | 缺陷工单 24h 内处理完成 |
| 备件可用率 | 关键备件库存可用率 > 95% |
### 三级指标（能效）
| 指标 | 定义 | 目标值 |
|------|------|-------|
| PUE | 数据中心总能耗 / IT 设备能耗 | < 1.4（新建智算中心） |
| WUE | 水分利用率（仅水冷/液冷） | < 0.5 L/kWh |
| CUE | 碳排放因子（外购电力） | 逐步降低（随电网绿电比例） |
## 运维组织架构
### 典型机场 DC 运维团队配置
```
运维总监（1人）
├── 值班工程师（7×24，每班 2-3 人）
├── 系统管理员（ICT/服务器，2-3 人）
├── 电力工程师（高压/低压/ UPS，2 人）
├── 制冷工程师（暖通/液冷，1-2 人）
├── 网络工程师（安全/交换，1-2 人）
└── 客户接口（对接航司/空管，1 人）
```
## DCIM 统一管理平台
DCIM（Data Center Infrastructure Management）是运维的核心工具平台：
### DCIM 功能模块
| 模块 | 功能 |
|------|------|
| 资产管理 | 机柜 U 位、资产标签、生命周期管理 |
| 容量管理 | 电力容量、制冷容量、空间利用率实时监控 |
| 能源管理 | PUE/WUE/CUE 实时计算，分项能耗分析 |
| 告警管理 | 阈值告警、告警升级、工单触发 |
| 变更管理 | 发布计划、变更审批、变更验证 |
| 报表管理 | 可用性报告、能耗报告、容量趋势 |
### 与 BA/楼控集成
DCIM 需与楼宇自控（BMS）集成，实现：
- 冷冻机运行状态纳入 DCIM 统一监控
- 电力系统（发电机、UPS）与 BMS 告警联动
- 能耗数据统一采集（电力 + 制冷 +照明）
## Uptime Tier M&O 运维认证
Uptime Institute 提供运维管理认证（Management & Operations），是运维质量的专业背书：
| 认证等级 | 要求 | 适用场景 |
|---------|------|---------|
| M&O 认证 | 通过书面审查 + 现场评估 | 业主自维或委托第三方 |
| M&O 金牌 | 额外要求运维绩效指标达标 | 大型机场/智算中心 |
### M&O 认证关键评审要素
1. **运维组织**：岗位职责清晰，7×24 值班安排合理
2. **运维流程**：变更管理、问题管理、供应商管理流程完善
3. **监控与告警**：告警阈值设置合理，升级路径清晰
4. **人员能力**：关键岗位持证上岗，继续教育计划
5. **设施维护**：预防性维护计划执行率 > 95%
## 生命周期管理
### 设备典型生命周期（机场环境）
| 设备类型 | 设计寿命 | 更换周期 | 备注 |
|---------|---------|---------|------|
| UPS 主机 | 15 年 | 10-15 年 | 电池 5 年强制更换 |
| 冷冻机 | 20 年 | 15-20 年 | 磁悬浮可达 25 年 |
| 精密空调 | 15 年 | 10-15 年 | 压缩机是关键部件 |
| 服务器 | 5-7 年 | 5 年 | 智算 GPU 服务器 3-5 年 |
| 网络设备 | 7-10 年 | 7 年 | 光模块 5 年需更换 |
> 相关：[[airport-data-center-overview]] | [[tier-iii-design]] | [[power-and-cooling]] | [[commissioning]]
airport-wiki/concepts/tech-infrastructure/power-and-cooling.md
-83
View File
@@ -1,83 +0,0 @@
---
title: 供配电与制冷
created: 2026-04-08
updated: 2026-04-09
type: concept
tags: [power, cooling, design]
sources: [raw/articles/上海市-智算中心建设导则2025版-2025-01.md, raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md]
---
# 供配电与制冷
## 供配电系统
### 典型架构
```
市电 → ATS → UPS → PDU → 服务器
↑ ↑
柴油发电机 蓄电池
```
### 关键指标
- **IT 负载功率密度**：通常 4-10 kW/机柜（传统DC）；智算中心单柜 **12-30kW**
- **PUE 目标值**：1.3-1.5（传统机场DC）；智算中心需达 **≤1.22**（上海导则先进值≤1.18）
- **市电引入**：双路 10kV 或 35kV
- **UPS 容量**：N+1 或 2N 冗余
- **上海导则选址供电要求**：市电平均每月停电次数 ≤ 1次；平均每次故障时间 ≤ 0.5小时；宜引入一类市电
### 柴油发电机
- 常用功率：1000-3000 kVA
- 启动时间：< 10 秒（自动启动）
- 储油量：满足 8-24 小时连续运行
## 制冷系统
### 冷却方式
| 方式 | PUE范围 | 适用场景 |
|------|---------|---------|
| **液冷(相变浸没式)** | **1.00** | >30kW/机柜，超大规模智算 |
| **液冷(冷板式)** | **~1.10** | 高密度智算中心（主流方案） |
| 自然冷(间接蒸发冷) | 1.10-1.20 | 北方气候区 |
| 冷冻水系统 | 1.30+ | 传统数据中心 |
| 风冷 | 1.40+ | 面临淘汰 |
> 数据来源：头豹研究院《中国AIDC产业发展白皮书2025》——液冷已成PUE<1.10核心路径，传统风冷进入结构性瓶颈
### 上海智算中心2025 PUE要求（全国最严）
| 指标 | 新建准入值 | 运营先进值 | 长三角集群 |
|------|------------|------------|------------|
| **基准PUE** | ≤ 1.25 | — | — |
| **综合PUE** | ≤ 1.22 | ≤ 1.18 | ≤ 1.20 |
| **WUE** | ≤ 2.2 L/kWh | ≤ 2.0 L/kWh | — |
| **CUE** | ≤ 1.2 gCO2/kWh | ≤ 1.0 gCO2/kWh | — |
> 来源：上海市《智算中心建设导则（2025年版）》
### 液冷技术类型
| 类型 | PUE | 单柜散热能力 | 建设成本 | 适用 |
|------|-----|------------|---------|------|
| **冷板式液冷** | ~1.10 | ~120kW/柜 | 中 | 主流，新建智算中心首选 |
| **浸没式液冷（相变）** | **1.00** | >200kW/柜 | 高 | 超大规模（GB200 NVL72等） |
| **风液混合** | 1.10-1.15 | 60-150kW/柜 | 中低 | 快速部署/改造场景 |
国产液冷供应商参考：
- **英维克**：冷板式液冷，单机柜功率密度24kW，散热效率提升40%
- **中科曙光**：浸没式液冷，PUE低至1.04，年减碳量超万吨
### 机场数据中心推荐
- 航站楼主数据中心：液冷（冷板式）成为新建首选，液冷渗透率已达64%（工业智算场景）
- 边缘小机房：风冷精密空调（过渡方案，逐步被边缘液冷替代）
- **强制要求**：新建智算中心**宜采用液冷技术**（上海导则）
## PUE 优化建议
- 冷热通道封闭
- 自然冷却（冬季）
- 精确制冷（行级空调）
- 高效 UPS（模块化效率 ≥ 96%）
> 相关：[[tier-iii-design]] | [[tier-iv-design]] | [[glossary]]
airport-wiki/concepts/tech-infrastructure/prefab-modular-dc.md
-49
View File
@@ -1,49 +0,0 @@
---
title: 预制模块化数据中心
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [design, construction, cooling]
sources: [raw/articles/dubai-airport-huawei-dc.md]
---
# 预制模块化数据中心
## 定义
预制模块化数据中心（Prefabricated Modular Data Center）是将数据中心各子系统在工厂预制为独立模块（集装箱或箱体），现场快速组装交付的建设模式。相比传统现场建设，建设周期缩短 40-60%。
## 核心优势
- **快速部署**：工厂预制 + 现场组装，建设周期显著缩短
- **弹性扩容**：增加模块即可扩展，按需建设
- **质量可控**：工厂环境生产，质量一致性高
- **成本优化**：减少现场施工成本和占地
- **适应性强**：适用于空间有限、工期紧张或临时扩容场景
## 典型方案（华为 FusionModule1000B）
| 参数 | 数值 |
|------|------|
| 模块类型 | 集装箱（23个模块组成） |
| 总功率 | 1MW |
| 业务柜数 | 100柜 |
| 单柜密度 | 10kW/rack |
| PUE | <1.6 |
| 认证 | Tier III 设计+建造双认证 |
## 适用场景
- 机场快速扩容
- 临时数据中心
- 边缘计算节点
- 海外/远程站点
## 在机场的适用性
迪拜机场案例（华为 DXB 项目）证明，预制模块化可解决：
- 机场空间有限、无现成楼宇
- 需快速交付（10个月 vs 传统2年）
- 单柜功率密度高（10kW）带来散热挑战
> 相关：[[tier-iii-design]] | [[power-and-cooling]] | [[modern-airport-trends]]
airport-wiki/concepts/tech-infrastructure/rfp-and-vendor-selection.md
-78
View File
@@ -1,78 +0,0 @@
---
title: 招标与供应商选择
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [procurement, vendor, rfp, tender]
sources: []
---
# 招标与供应商选择
## 机场数据中心采购特殊性
机场数据中心的设备采购比普通商业数据中心更复杂，主要约束：
- **航空安全认证**：部分设备（特别是涉及电磁干扰的）需通过民航适航论证
- **不停航施工**：在运营中的机场内施工，承包商需具备机场准入资质
- **多系统集成**：涉及 ICT、楼宇自控、电力、制冷等多个系统接口协调
- **国产化要求**：民航关键系统国产化率要求（近年逐步提高）
## 招标模式
### 传统模式 vs. 一体化模式
| 模式 | 描述 | 适用场景 | 优缺点 |
|------|------|---------|-------|
| 传统平行发包 | 建筑/电力/ICT/制冷分别招标 | 大型新建机场 | 接口多，管理复杂 |
| EPC 总承包 | 设计-采购-施工一体化 | 预制模块化、智算中心 | 责任清晰，周期短 |
| 交钥匙工程 | 包含运维移交 | 应急/临时数据中心 | 快速交付 |
### 推荐招标文件结构（EPC 模式）
```
招标文件结构
├── 第一卷：投标须知 + 合同条款
├── 第二卷：技术规格书
│ ├── 建筑与结构（装修、防火）
│ ├── 电力系统（UPS/发电机/低压配电）
│ ├── 制冷系统（冷源/末端/液冷）
│ ├── ICT 系统（服务器/网络/布线）
│ ├── 消防与安防
│ └── 智能化与监控（DCIM）
├── 第三卷：图纸与技术要求
└── 第四卷：投标报价表
```
## 关键设备品牌参考
### 主流品牌矩阵
| 系统 | 一线品牌 | 二线品牌 | 备注 |
|------|---------|---------|------|
| UPS | 维谛技术（Vertiv）、伊顿（Eaton）、施耐德 | 华为、艾默生 | 机场优先选维谛/伊顿（国内机场案例多） |
| 发电机 | 康明斯（Cummins）、卡特彼勒（CAT） | 潍柴、MTU | 需支持自动投切 < 10s |
| 冷冻机 | 特灵（Trane）、约克（York）、开利 | 麦克维尔 | 优先选磁悬浮变频离心机 |
| 服务器 | 华为、浪潮、联想 | DELL/HPE | GPU 服务器认 NVIDIA HGX 认证 |
| 网络 | 华为、华三、新华三 | Arista、Cisco | Spine-Leaf 架构优先 |
| DCIM | 华为 DCIM、维谛 DCIM、施耐德 StruxureOn | — | 与楼控（BMS）集成 |
### 供应商资格审查要点
- [ ] 近 5 年内机场或同等规模数据中心案例
- [ ] 在当地（机场所在城市）有服务网点和备件库
- [ ] Uptime Tier 认证合作经验（设计/建造/运维）
- [ ] 设备生产工厂的 ISO 9001 / ISO 14001 认证
- [ ] 项目经理持有 Uptime ATD/ATS/AME 认证
## Uptime Tier 认证在招标中的处理
Uptime Institute Tier 认证是机场数据中心常见的合规要求，通常在招标技术规格中明确：
| 认证类型 | 适用阶段 | 招标要求 |
|---------|---------|---------|
| Tier Design | 设计阶段 | 提交 Uptime 设计审查（TDP） |
| Tier Constructed | 建造阶段 | 现场验证测试（TCF） |
| Tier M&O | 运维阶段 | 运维管理认证（可选） |
> 相关：[[tier-iii-design]] | [[tier-iv-design]] | [[construction-management]]
airport-wiki/concepts/tech-infrastructure/security-design.md
-95
View File
@@ -1,95 +0,0 @@
---
title: 网络安全设计
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [security, network, cybersecurity, airport]
sources: []
---
# 网络安全设计
## 机场网络安全特殊性
机场数据中心网络安全具有特殊的合规要求和威胁模型：
- **关键基础设施（CII）定位**：机场属于关键信息基础设施，受《关键信息基础设施安全保护条例》约束
- **多级安全域**：连接内网（业务）、外网（互联网服务）、OT 网络（楼宇自控），以及与空管系统的高安全隔离要求
- **航空数据敏感性**：航班计划、旅客信息（涉及 GDPR/个人信息保护法）、行李数据均需加密
- **实时性要求**：安全措施不能引入明显延迟，影响实时业务（停机位分配、航班信息显示）
## 安全域架构
### 分域原则（等级保护 + 机场分级）
```
互联网 ──────────────────────────────────────────────────┐
│
┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ DMZ │───▶│ 业务网 │───▶│ 生产网（SSN） │ │
│ (Web/FW) │ │(内网) │ │ AODB/FIDS/BHS核心 │ │
└──────────┘ └──────────┘ └──────────────────────┘ │
│
┌─────────────────────────────────────────────┘
│
┌───────┴───────┐ ┌──────────────┐
│ 办公网（OA） │───▶│ 智算算力网 │
│ (Internet) │ │ (GPU 集群) │
└───────────────┘ └──────────────┘
Legend: ─── 高安全 │ ⇢ 单向数据流 │ ──▶ 双向访问
```
### 分域说明
| 安全域 | 安全等级 | 与其他域关系 | 典型系统 |
|-------|---------|-------------|---------|
| 生产网（SSN） | L4（最高） | 通过数据交换前置机单向传输 | AODB, FIDS, DCS, SMGCS |
| 业务网 | L3 | 受控访问，需 MFA | 办公自动化，Web 服务 |
| 智算算力网 | L3 | 训练数据单向进，算力服务输出 | GPU 集群，模型推理 |
| 办公网 | L2 | Internet 访问，员工终端 | OA, Email, 互联网访问 |
| DMZ | L2 | 互联网可访问，内网受控访问 | 公开航班信息 Web |
## 网络安全防护措施
### 分域隔离设备
| 隔离方式 | 部署位置 | 适用场景 |
|---------|---------|---------|
| 防火墙（FW） | 各安全域边界 | 域间访问控制 |
| 单向光闸（Data Diode） | 生产网 ↔ 外网 | 航班数据单向传输，防渗透 |
| 工业防火墙 | 楼宇自控网络边界 | BMS/SCADA 系统保护 |
| 网闸（Air Gap） | 空管核心系统边界 | 最高等级隔离（物理断开） |
### 智算算力网络安全
GPU 集群的网络安全有别于传统 IT：
- **训推分离**：训练网络（内网）与推理服务网络（业务网）物理隔离
- **模型防泄漏**：推理 API 网关，加 API Key + 流量审计
- **GPU 资源隔离**：vGPU/多租户技术防止跨租户数据渗透
- **数据脱敏**：进入训练集群的数据自动脱敏（旅客隐私字段）
## 安全合规要求
### 等级保护 2.0（GB/T 22239-2019）
机场数据中心核心系统应至少满足**三级等保**要求：
| 安全防护层 | 要求 |
|----------|------|
| 安全物理环境 | 电子门禁（CCTV 90天存储）、温湿度监控 |
| 安全通信网络 | 网络分区、加密传输（TLS 1.3）、VPN 接入 |
| 安全区域边界 | 防火墙、入侵检测（IDS）、APT 防护 |
| 安全计算环境 | 终端准入、补丁管理、主机审计 |
| 安全管理中心 | 日志集中（留存 ≥ 6 个月）、态势感知平台 |
### 数据安全
| 法规 | 要求 | 适用数据 |
|------|------|---------|
| 《个人信息保护法》 | 旅客数据加密、授权访问、删除权 | 旅客 PNR、护照信息 |
| 《数据安全法》 | 数据分类分级、重要数据出境审查 | 航班计划、运营数据 |
| IATA Res.1300 | 航空数据安全框架 | 航班数据交换 |
> 相关：[[network-architecture]] | [[tier-iii-design]] | [[tier-iv-design]]
airport-wiki/concepts/tech-infrastructure/site-planning.md
-54
View File
@@ -1,54 +0,0 @@
---
title: 机场数据中心选址规划
created: 2026-04-10
updated: 2026-04-10
type: concept
tags: [planning, site, airspace, civil-aviation]
sources: []
---
# 机场数据中心选址规划
## 航空限制条件
机场数据中心的选址比普通商业数据中心复杂得多，首要约束来自民用航空的净空要求（Obstacle Restriction Surfaces）。
### 净空限制分区
| 分区 | 描述 | 对数据中心建设的影响 |
|------|------|---------------------|
| 限制面（Limitation Surface） | 跑道两端延伸的进近/起飞净空面 | 建筑高度严格受限 |
| 旋转面（Horizontal Surface） | 以跑道入口为圆心，半径 15km | 机场周边区域高度受限 |
| 锥形面（Cone Surface） | 向上外扩至 60m 高度 | 边缘区域同样受限 |
### 选址可行模式
- **航站楼附属建筑**：利用已有建筑结构，净空问题由原建筑解决
- **机场工作区（Airside Operation Area）以外的独立地块**：需通过机场净空审批
- **综保区/货运区**：距跑道足够远，无净空限制，是智算中心选址的理想区域
## 地质与基础设施
### 地质条件
- **地基承载力**：数据中心建筑荷载通常 10-20 kN/m²，需避开软弱地基
- **地震液化**：沿海/沿江机场需做地震液化评估（参考 GB 50011）
- **防洪排涝**：机场通常地势开阔，但低洼区域需做百年一遇防洪评估
### 网络基础设施
- **至航站楼延迟**：核心系统（安检、航班信息）要求 < 1ms 延迟，物理距离 < 5km
- **运营商接入**：需至少 2 家运营商路由进入，预留多路由光缆管廊
- **光纤冗余**：双路由至最近运营商 PoP，物理路径互不重叠
## 机场选址决策矩阵
| 因素 | 权重 | 航站楼附属 | 工作区独立地块 | 综保区/货运区 |
|------|------|-----------|--------------|-------------|
| 净空限制 | 25% | ★★★ 已有建筑无限制 | ★★ 需专项审批 | ★★★ 无限制 |
| 网络延迟 | 25% | ★★★ < 1km | ★★★ 2-5km | ★★ 5-15km |
| 电力引入 | 20% | ★★★ 依托现有 | ★★★ 依托现有 | ★★ 需专线引入 |
| 扩容空间 | 15% | ★ 空间有限 | ★★★ 充足 | ★★★ 极充足 |
| 建设周期 | 15% | ★★★ 已有建筑 | ★★ 需新建 | ★★ 需新建 |
> 相关：[[airport-data-center-overview]] | [[tier-iii-design]] | [[power-and-cooling]]
airport-wiki/concepts/tech-infrastructure/tier-iii-design.md
-29
View File
@@ -1,29 +0,0 @@
---
title: Tier III 数据中心设计
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [tier-iii, design]
sources: []
---
# Tier III 数据中心设计
## 标准参考
- **ANSI/TIA-942-B**: 数据中心电信基础设施标准
- **Uptime Institute Tier Standard**: 分为 Tier I/II/III/IV 四个等级
## Tier III 核心要求
- **可用性**: 99.98%（年停机 ≤ 1.6 小时）
- **冗余等级**: N+1（可并行维护）
- **电力路径**: 2N UPS 或 N+1 UPS 配置
- **冷却系统**: N+1 冗余冷冻水系统或风冷系统
- **网络接入**: 多运营商、多路由接入
## 机场适用性
机场主数据中心推荐采用 Tier III 级别，兼顾建设成本与业务连续性需求。
> 相关：[[tier-iv-design]] | [[power-and-cooling]] | [[network-architecture]]
airport-wiki/concepts/tech-infrastructure/tier-iv-design.md
-30
View File
@@ -1,30 +0,0 @@
---
title: Tier IV 数据中心设计
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [tier-iv, design]
sources: []
---
# Tier IV 数据中心设计
## 标准参考
- **ANSI/TIA-942-B**: 数据中心电信基础设施标准
- **Uptime Institute Tier Standard**: Tier IV 为最高等级
## Tier IV 核心要求
- **可用性**: 99.99%（年停机 ≤ 0.8 小时）
- **冗余等级**: 2N（完全冗余，任何单点故障不影响运行）
- **容错能力**: 任意单一故障不影响 IT 负载
- **电力路径**: 2N UPS，双市电引入
- **冷却系统**: 2N 冗余，确保任何故障下制冷不中断
- **物理安全**: 生物识别门禁、全区域 CCTV
## 机场适用性
适用于机场应急指挥中心、空管核心系统等不允许停机的关键设施。建设成本约为 Tier III 的 1.5-2 倍。
> 相关：[[tier-iii-design]] | [[power-and-cooling]] | [[security-design]]
airport-wiki/entities/fuzhou-changle-airport-bsj.md
-55
View File
@@ -1,55 +0,0 @@
---
title: 福州长乐机场综合保税区人工智能智算中心
created: 2026-04-09
updated: 2026-04-09
type: entity
tags: [airport, computing-cluster, in-construction, liquid-cooling]
sources: [raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md]
---
# 福州长乐机场综合保税区人工智能智算中心
## 基本信息
| 参数 | 数值 |
|------|------|
| 投资方 | 福建智算方舟科技有限公司 |
| 总投资 | **11亿元**（一期3.3亿元） |
| 用地面积 | **33,347平方米**（50.02亩） |
| 规划算力 | **15,000P** |
| 预计投产 | **2026年10月** |
| 年营收目标 | **超1.5亿元** |
| 年税收目标 | **超1,000万元** |
## 建设进度
| 时间 | 里程碑 |
|------|--------|
| 2025年7月 | 完成工程勘察、施工图审查、设备进场 |
| 2025年9月 | 正式启动装机和土建施工 |
| 2026年6月 | 主体建筑封顶 |
| 2026年6-10月 | 设备安装、系统集成、调试 |
| **2026年10月** | **验收合格，正式投产** |
## 技术方案
- **液冷机柜矩阵**：规模化智算液冷机柜
- **网络存储机柜阵列**：体系化网络存储机柜阵列
- **AI服务器**：国际领先高性能AI服务器（型号未披露）
## 选址优势
- **位置**：福州滨海新城临空经济区，综保一路东侧、综保三街南侧
- **政策**：长乐机场综保区多重政策优势
- **定位**：填补东南沿海高端智算缺口，深化闽港、闽台数字协作
## 二期规划
- 高性能人工智能服务器及**边缘/云端推理一体机**的设计、组装与制造
- "研发测试-生产制造-部署应用"产业闭环
## 技术备注
- 液冷技术类型（冷板/浸没）未明确
- "国际领先高性能AI服务器"表述模糊
- 目前处于在建状态，核心硬件配置待投产时披露
airport-wiki/entities/index.md
-224
View File
@@ -1,224 +0,0 @@
---
title: 机场实体与知识图谱
created: 2026-04-10
updated: 2026-04-13
type: meta
tags: [entity, index, knowledge-graph, typed-relationship]
confidence: 0.9
sources_count: 8
last_confirmed: 2026-04-13
status: active
---
# 机场实体与知识图谱
本文档作为 entities/ 目录的实体索引，基于 **LLM Wiki v2 知识图谱** 理念构建。每个实体通过 Typed Relationships 定义语义连接，支持图遍历查询。
---
## 实体概览统计
| 类型 | 数量 | 置信度分布 | 平均关系数 |
|------|------|------------|------------|
| **机场实体** | 7 | 0.75-0.95 | 3.1 |
| **供应商实体** | 5 | 0.85-0.98 | 2.4 |
| **系统实体** | 12 | 0.7-0.95 | 4.7 |
| **总计** | **24** | **0.75-0.98** | **3.4** |
*数据基于 [[entities/]] 和 [[concepts/]] 自动分析，更新于 2026-04-13*
---
## 实体目录
### 🏢 机场案例
| 机场 | 智算规模 | 关键系统 | 置信度 | 关系数量 |
|------|----------|----------|--------|----------|
| [[shenzhen-airport]] | DeepSeek R1-671B 满血部署 | [[aodb-core]], [[a-cdm]] | 0.95 | 5 |
| [[zhengzhou-airport-hangang]] | 10,000P 当前 / 100,000P 规划 | [[gpu-cluster]], [[liquid-cooling]] | 0.9 | 4 |
| [[fuzhou-changle-airport-bsj]] | 15,000P，11亿元，2026.10投产 | [[prefab-modular-dc]], [[tier-iv-design]] | 0.85 | 3 |
| [[jfk-airport]] | T6 + New T1 SITA-CCM | [[aodb-core]], [[ioc-aocc]] | 0.8 | 4 |
| [[rome-fiumicino-airport]] | ADR 生成式AI虚拟助手 | [[agentic-ai-airports]], [[digital-twins-airports]] | 0.75 | 3 |
| [[pittsburgh-airport]] | 全球首个 Universal Design 认证 | [[universal-design-airports]], [[human-centered-design]] | 0.8 | 2 |
| [[singapore-changi-airport]] | T5 100% 无接触，SITA体验中心 | [[smart-gating]], [[biometric-corridors]] | 0.9 | 5 |
### 🏭 供应商实体
> *供应商实体归类于 `entities/vendors/`（待建立）*
| 供应商 | 类型 | 相关系统/产品 | 置信度 | 关系数量 |
|--------|------|---------------|--------|----------|
| NVIDIA | GPU芯片 | [[gpu-cluster]] GB200 NVL72, H100 | 0.98 | 3 |
| ADB SAFEGATE | 机场系统 | [[aodb-core]], [[vdgs-system]] | 0.9 | 4 |
| Amadeus | 机场系统 | [[aodb-core]], [[fids-system]] | 0.9 | 4 |
| 华为 | 全栈方案 | [[prefab-modular-dc]], [[network-architecture]] | 0.95 | 6 |
| Vertiv | 基础设施 | [[liquid-cooling]], [[ups-systems]], [[pdu-systems]] | 0.9 | 5 |
| SITA | 通讯与体验 | [[smart-gating]], [[biometric-corridors]] | 0.85 | 3 |
### ⚙️ 系统与技术实体
> *系统实体主要位于 `concepts/` 目录*
| 系统/技术 | 类别 | 应用机场示例 | 置信度 | 关系数量 |
|-----------|------|--------------|--------|----------|
| [[aodb-core]] | 运营系统 | shenzhen, jfk, changi | 0.95 | 8 |
| [[gpu-cluster]] | 智算中心 | zhengzhou, fuzhou | 0.9 | 6 |
| [[liquid-cooling]] | 基础设施 | zhengzhou, shenzhen | 0.85 | 5 |
| [[prefab-modular-dc]] | 建筑模式 | fuzhou, huawei-case | 0.9 | 4 |
| [[agentic-ai-airports]] | AI应用 | rome-fiumicino, singapore | 0.75 | 4 |
| [[smart-gating]] | 旅客服务 | singapore, shenzhen | 0.8 | 3 |
| [[digital-twins-airports]] | 数字孪生 | rome, future-airports | 0.7 | 3 |
| [[network-architecture]] | 网络架构 | huawei, tier-iv-design | 0.85 | 5 |
| [[tier-iv-design]] | 等级标准 | fuzhou, shenzhen | 0.9 | 4 |
| [[a-cdm]] | 协同决策 | shenzhen, jfk | 0.85 | 3 |
| [[universal-design-airports]] | 无障碍设计 | pittsburgh | 0.8 | 2 |
| [[biometric-corridors]] | 生物识别 | singapore, future-airports | 0.75 | 3 |
---
## 🔗 知识图谱（Typed Relationships）
### 图结构概览
```
机场实体 (7)
├── uses → 系统实体 (平均 3.1)
├── deploys → 供应商实体 (平均 2.4)
└── depends_on → 基础设施 (平均 1.8)
系统实体 (12)
├── depends_on → 其他系统 (平均 2.3)
├── supersedes → 旧系统 (平均 0.7)
└── compatible_with → 供应商 (平均 1.9)
供应商实体 (5)
├── provides → 系统/产品 (平均 3.2)
└── partners_with → 其他供应商 (平均 1.4)
```
### 关键关系路径示例
#### 1. 智算中心建设路径
```
郑州航空港区机场 [[zhengzhou-airport-hangang]]
├── deploys → [[gpu-cluster]] (10000P)
│ ├── uses → [[liquid-cooling]] (必选)
│ ├── depends_on → [[network-architecture]] (InfiniBand/RoCE)
│ └── compatible_with → NVIDIA [[nvidia-vendor]]
└── adopts → [[tier-iv-design]] (等级标准)
└── certified_by → Uptime Institute
```
#### 2. 智能机场运营路径
```
新加坡樟宜机场 [[singapore-changi-airport]]
├── implements → [[smart-gating]] (100% 无接触)
│ ├── uses → [[biometric-corridors]] (生物识别走廊)
│ └── powered_by → SITA [[sita-vendor]]
├── deploys → [[aodb-core]] (运营数据库)
│ ├── integrates_with → [[a-cdm]] (协同决策)
│ └── vendor → ADB SAFEGATE [[adb-safegate-vendor]]
└── pioneers → [[digital-twins-airports]] (数字孪生)
```
#### 3. 供应商生态系统
```
华为 [[huawei-vendor]]
├── provides → [[prefab-modular-dc]] (预制模块化)
│ └── deployed_at → 迪拜机场案例
├── provides → [[network-architecture]] (全光网络)
│ └── compatible_with → [[gpu-cluster]]
└── partners_with → NVIDIA [[nvidia-vendor]]
└── joint_solution → AI 训练一体机
```
---
## 🧠 知识图谱查询示例
### 图遍历查询（伪代码）
```python
# 1. 查找依赖路径
find_dependencies("郑州航空港区机场", max_depth=3)
# 结果: 机场 → GPU集群 → 液冷系统 → 供电系统 → 网络架构
# 2. 查找所有使用特定系统的机场
find_entities_using("aodb-core", entity_type="airport")
# 结果: [shenzhen-airport, jfk-airport, singapore-changi-airport]
# 3. 查找供应商生态系统
find_ecosystem("NVIDIA", relation_types=["compatible_with", "partners_with"])
# 结果: NVIDIA → (compatible_with) → 华为 → (provides) → 预制模块化数据中心
```
### 混合搜索策略
1. **关键词搜索 (BM25)**：`机场 AND 智算中心` → 返回包含关键词的页面
2. **向量搜索**：`"大规模AI训练基础设施"` → 返回语义相似的页面
3. **图遍历搜索**：`"使用ADB SAFEGATE AODB的机场"` → 遍历关系图找到相关实体
---
## 📊 图谱质量指标
| 指标 | 当前值 | 目标值 | 状态 |
|------|--------|--------|------|
| **实体覆盖率** | 24/89 (27%) | >50% | ⚠️ 待提升 |
| **关系密度** | 3.4 平均关系数 | >5.0 | ⚠️ 待提升 |
| **置信度加权** | 0.85 平均置信度 | >0.9 | ✅ 良好 |
| **图连通性** | 92% 实体连通 | >95% | ✅ 良好 |
| **孤立实体** | 2/24 (8%) | <5% | ⚠️ 待改善 |
**改进计划**：
1. 为所有 `concepts/` 页面添加 `entity_type` 和 `relationships` 字段
2. 创建 `entities/vendors/` 目录，迁移供应商信息
3. 实现自动关系提取脚本
4. 添加图谱可视化工具（如 Mermaid.js）
---
## 🛠️ 图谱维护指南
### 新增实体
1. 创建实体页面（`entities/` 或 `concepts/`）
2. 添加 frontmatter：`type: entity` 或 `type: concept`
3. 定义 `entity_type`：`airport`, `vendor`, `system`, `technology`, `standard`
4. 添加 `relationships` 数组，连接相关实体
5. 更新本索引文件的关系统计
### 更新关系
```yaml
# 在实体页面 frontmatter 中添加
relationships:
- target: target-entity-name
type: uses|deploys|depends_on|supersedes|compatible_with|partners_with|provides
detail: "可选描述"
confidence: 0.0-1.0
established_date: YYYY-MM-DD
```
### 质量检查
每月运行图谱质量检查：
```bash
# 检查孤立实体
find_orphaned_entities()
# 检查置信度衰减
decay_confidence_scores()
# 检查关系一致性
validate_relationship_symmetry()
```
---
## 📚 相关文档
- [[SCHEMA.md]] - Wiki 架构与 v2 扩展说明
- [[knowledge-management/knowledge-graph.md]] - 知识图谱详细实现指南
- [[hybrid-search.md]] - 混合搜索系统文档
- [[concepts/tech-infrastructure/glossary.md]] - 术语定义
---
> **更新记录**：本文件基于 LLM Wiki v2 知识图谱理念重构，2026-04-13。下一次图谱质量检查：2026-05-13。
airport-wiki/entities/jfk-airport.md
-37
View File
@@ -1,37 +0,0 @@
---
title: 紐約肯尼迪國際機場（JFK）
created: 2026-04-10
updated: 2026-04-10
type: entity
tags: [airport, passenger, smart-gating, biometric]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 紐約肯尼迪國際機場（JFK）
## 概述
**JFK** 是美國紐約都會區的主要國際機場，位於皇后區。正在經歷大規模現代化改造，多個新航站樓於 2026 年陸續投入營運。
## 未來信息中心案例：T6 + New Terminal One
在 2026 年即將投入使用的 JFK 6 號航站樓（Terminal 6）和新一號航站樓（New Terminal One）中，航空技術巨頭 **SITA** 聯合義大利設計公司 **CCM**，打造了全新的旅客信息中心。
### 核心特點
- **數字標牌**：整合信息發布與尋路功能
- **智能尋路系統**：實時路徑規劃與人流疏導
- **無障礙服務**：完全符合 ADA（美國殘疾人法案）要求
- **沉浸式設計**：將冰冷的技術隐藏在温暖的建築與家具設計中
- **情感體驗提升**：不只是功能性的服務台，而是旅客體驗的一部分
### 創新意義
該項目打破了傳統 IT 系統與建築設計的界限——數字系統不再是外掛設施，而是與高端室內設計融為一體的組成部分。
## 相關概念
- [[smart-gating]] — JFK 的智能尋路系統與停機位調度密切相關
- [[biometric-corridors]] — JFK 未來將引入生物特徵走廊
- [[future-airport-info-center]] — T6/New T1 的信息中心是全球未來機場的標杆案例
- [[human-centered-design-airports]] — SITA-CCM 的沉浸式設計體現人本設計理念
airport-wiki/entities/pittsburgh-airport.md
-35
View File
@@ -1,35 +0,0 @@
---
title: 匹茲堡國際機場（PIT）
created: 2026-04-10
updated: 2026-04-10
type: entity
tags: [airport, passenger, universal-design]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 匹茲堡國際機場（PIT）
## 概述
**匹茲堡國際機場（Pittsburgh International Airport, PIT）** 位於美國賓夕法尼亞州，是匹茲堡都會區的主要航空樞紐。
## 未來信息中心案例：全球首個通用設計認證（2026.02）
2026 年 2 月，PIT 成為**全球首個獲得「通用設計」（Universal Design）認證**的機場，其信息中心與航站樓設計深度融合了包容性理念。
### 核心特點
- **直觀數字尋路系統**：清晰的路線引導，無需依賴工作人員協助
- **高可見度信息顯示屏**：大字體、高對比度，適合視障旅客
- **適應性交互終端**：高度可調節，支援輪椅使用者
- **多感官反饋**：視覺 + 聽覺 + 觸覺三種交互模式，適配不同身體條件的旅客
### 認證意義
通用設計認證代表機場信息系統不僅服務於「標準旅客」，而是為所有人群（老年人、殘障人士、語言障礙旅客）提供平等的體驗。
## 相關概念
- [[future-airport-info-center]] — PIT 信息中心是通用設計理念的標杆實踐
- [[universal-design-airports]] — PIT 是全球首個獲得通用設計認證的機場
- [[human-centered-design-airports]] — 通用設計是人本設計在身體無障礙維度的具體落地
airport-wiki/entities/rome-fiumicino-airport.md
-40
View File
@@ -1,40 +0,0 @@
---
title: 羅馬菲烏米奇諾機場（ADR）
created: 2026-04-10
updated: 2026-04-10
type: entity
tags: [airport, passenger, ai-ml]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 羅馬菲烏米奇諾機場（ADR / Fiumicino）
## 概述
**羅馬菲烏米奇諾機場（Aeroporti di Roma, ADR）** 是義大利最大的機場，服務羅馬都會區。隸屬於 ADR（Aeroporti di Roma）集團，是歐洲重要的樞紐機場之一。
## 未來信息中心案例：生成式 AI 虛擬助手（2025）
2025 年底，ADR 引入了由**生成式 AI 驅動的虛擬助手**，這是歐洲主要機場中 AI 應用的標杆案例。
### 核心功能
- **文本交互**：旅客通過手機或機場終端輸入問題
- **語音交互**：支持自然對話，無需打字
- **全流程覆蓋**：
- 停車信息與預訂
- 地面交通選擇（地鐵、火車、巴士）
- 實時航班狀態
- 行李追蹤
- 餐飲與零售推薦
### 技術特點
- 基於大語言模型（LLM）的對話引擎
- 上下文記憶：理解對話歷史，提供連貫回復
- 多語言支持：義大利語、英語及主要旅客語言
## 相關概念
- [[future-airport-info-center]] — ADR AI 助手是未來信息中心在歐洲的首批大規模落地案例
- [[agentic-ai-airports]] — 生成式 AI 虛擬助手是 Agentic AI 的典型應用形式
airport-wiki/entities/shenzhen-airport.md
-56
View File
@@ -1,56 +0,0 @@
---
title: 深圳宝安国际机场
created: 2026-04-09
updated: 2026-04-09
type: entity
tags: [airport, case-study, ai-deployment]
sources: [raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md]
---
# 深圳宝安国际机场（ZGSZ）
## 基本信息
| 参数 | 数值 |
|------|------|
| IATA | SZX |
| 定位 | 超大型枢纽机场（年旅客量5,000万+） |
| 数智化排名 | 42家千万级机场综合评价**第二名**（2024年） |
## AI基础设施
- **DeepSeek R1-671B 满血版**：千亿参数大模型，华为昇腾算力集群全栈本地化部署
- **算力底座**：华为昇腾算力服务器（具体规格未披露）
- **数据整合**：打通航班运行、物流服务、设备物联日志等**18类**核心业务数据
## 核心智能体矩阵
| 智能体 | 效果 |
|--------|------|
| 机位智能分配 | 每日分配：4小时→**1分钟**，靠桥率：**85.44%** |
| AI安全助手 | 融合1,500份安全文档，检索效率提升**60倍** |
| AI辅助判图 | 三维图像深度学习，安检效率提升**30%以上** |
| 一体化主动运控 | 提前**20分钟**预判保障节点，正常率提升约**4个百分点** |
| 综合交通全域一张图 | 处置响应时间 **<1分钟**（获"兴智杯"一等奖） |
## 物流智能化
- **深畅国际货站**：AGV机器人+智能卡口，全国首个24小时智慧远程监管货站
- 进口货物库内停留时间缩短 **82%**
- 出口货物库内停留时间缩短 **33%**
- **快件中心**：机械臂+单件分离器+六面扫描仪三合一全自动作业
- **无人驾驶牵引车**：无人接驳7×24小时不间断
- **巡逻监管机器人**：海关查验平台货物自动收取
## 旅客服务
- **"小黄蜂"配送机器人**：卫星厅38个登机口餐饮直达
- **旅客自弃物品回收机器人**：全国首个，日均收集禁限带物品**25公斤**
- **AI翻译设备**：支持100余种语言，录入时间缩短**80%**
- **网约车全链条管理体系**：服务车次超**854万**、旅客约**1,276万**，地面交通测评全国第一
## 技术备注
- 华为昇腾集群具体规模（服务器数量、GPU卡数）未披露
- 液冷技术是否使用未提及
- 属于"国产算力+开源大模型"标杆案例
airport-wiki/entities/singapore-changi-airport.md
-43
View File
@@ -1,43 +0,0 @@
---
title: 新加坡樟宜機場（SIN）
created: 2026-04-10
updated: 2026-04-10
type: entity
tags: [airport, passenger, biometric, smart-gating]
sources: [raw/articles/manus-future-airport-info-center-2026.md]
---
# 新加坡樟宜機場（SIN / Changi）
## 概述
**新加坡樟宜機場（Singapore Changi Airport, SIN）** 連續多年被評為全球最佳機場，是亞太地區智慧機場的標杆。正在建設的 T5 航站樓將進一步強化其數字化領導地位。
## 未來信息中心案例：T5 + SITA 體驗中心
### T5 無接觸服務規劃
樟宜機場在 T5 航站樓的規劃中全面擁抱 **100% 無接觸服務**：
- 全流程生物識別：從值機到登機，無需出示任何證件
- 智能尋路：基於位置的信息推送與導航
- 個性化服務：AI 根據旅客偏好主動推薦餐飲、零售、休閒設施
### SITA 新加坡體驗中心
SITA 在新加坡設立了全新的**體驗中心**，集中展示未來機場信息處理的最新技術：
- 生物識別解決方案
- 數字身份管理
- AI 驅動的旅客處理系統
為亞太地區的機場數字化轉型提供示範與參考。
## 與樟宜星耀項目的關係
樟宜機場的「星耀」（Jewel）項目以室內瀑布聞名，而 T5 和 SITA 體驗中心則代表其數字化轉型的軟實力。
## 相關概念
- [[future-airport-info-center]] — 樟宜是亞太區未來機場信息中心的標杆
- [[biometric-corridors]] — T5 的 100% 無接觸服務依賴生物特徵走廊技術
- [[smart-gating]] — 智能登機口是 T5 無縫出行體驗的關鍵節點
- [[human-centered-design-airports]] — 樟宜以旅客為中心的設計聞名，T5 進一步強化
airport-wiki/entities/zhengzhou-airport-hangang.md
-46
View File
@@ -1,46 +0,0 @@
---
title: 郑州航空港经济综合实验区
created: 2026-04-09
updated: 2026-04-09
type: entity
tags: [airport, wang-card, computing-cluster, case-study]
sources: [raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md]
---
# 郑州航空港经济综合实验区
## 基本信息
| 参数 | 数值 |
|------|------|
| 定位 | 中部最大、国内领先的万卡算力集群 |
| 当前算力 | **10,000P** |
| 规划总规模 | **100,000P+**（三中心：训练/推理/推训一体） |
| DeepSeek部署 | 2025年1月全量接入DeepSeek-R1（中部首个） |
## 三中心规划
| 中心 | 定位 |
|------|------|
| 一中心 | 主攻高端训练算力 |
| 二中心 | 聚焦推理算力 |
| 三中心 | 面向未来规划十万卡推训一体算力集群 |
## 配套项目
- **AI+智能人才公共实训基地**：总投资1.2亿元，2025年11月揭牌
## 区位优势
| 指标 | 数值 |
|------|------|
| 2小时高铁圈人口 | 覆盖**4亿**人口 |
| 2小时航空圈 | 覆盖全国**90%**人口和市场 |
| 2025年货邮吞吐量 | 首破**100万吨**（全国第五、中部首个"百万吨级"） |
| 2025年外贸进出口 | **4,935亿元**，占河南全省**52.7%** |
## 技术备注
- 10,000P具体硬件配置（GPU型号、机柜数、功率）未披露
- 三中心"十万卡"仍为规划阶段
- 适合作为机场临空经济区智算集群选址对标
airport-wiki/hybrid-search.md
-435
View File
@@ -1,435 +0,0 @@
---
title: 混合搜索系统
created: 2026-04-13
updated: 2026-04-13
type: concept
tags: [knowledge-management, hybrid-search, bm25, vector-search, knowledge-graph]
confidence: 0.9
sources_count: 3
last_confirmed: 2026-04-13
status: active
relationships:
- target: SCHEMA.md
type: defines
detail: "LLM Wiki v2 搜索架构"
confidence: 0.95
- target: entities/index.md
type: uses
detail: "知识图谱遍历"
confidence: 0.9
- target: knowledge-management/wiki-operations.md
type: integrates_with
detail: "自动化搜索触发"
confidence: 0.85
---
# 🎯 混合搜索系统
基于 **LLM Wiki v2** 的可扩展搜索架构，专为机场智能化工程 wiki（当前 89 页，预计增长至 200+ 页）设计。当传统 `index.md` 目录变得不可行时，混合搜索提供三层次检索融合。
> **核心理念**：单一检索方法无法覆盖所有查询场景。关键词匹配精准但缺乏语义理解，向量搜索理解语义但可能缺乏精确匹配，图谱遍历发现隐含关系但需要结构化数据。
---
## 🏗️ 三层检索架构
### 1️⃣ BM25 关键词检索
**算法**：Okapi BM25（TF-IDF 的现代改进版）
**用途**：精确术语匹配、技术参数查找、缩写搜索
```python
# 伪代码实现
def bm25_search(query: str, documents: List[str], k1=1.5, b=0.75):
"""
参数:
- k1: 术语频率饱和度 (通常 1.2-2.0)
- b: 文档长度归一化 (0-1, 通常 0.75)
"""
# 1. 分词 + 词干提取
terms = stem(tokenize(query))
# 2. 计算每个文档的 BM25 分数
scores = []
for doc in documents:
score = sum(
idf(term) * (tf(term, doc) * (k1 + 1)) /
(tf(term, doc) + k1 * (1 - b + b * len(doc)/avg_doc_len))
for term in terms
)
scores.append(score)
return ranked_documents(scores)
```
**优势**：
- ✅ 精确匹配技术术语（如 "InfiniBand NDR 400G"）
- ✅ 支持同义词扩展（如 "GPU" → "图形处理器"）
- ✅ 快速响应（毫秒级）
- ✅ 可解释性强（高亮匹配术语）
**局限**：
- ❌ 无法理解语义相似性（"智算中心" ≠ "数据中心"）
- ❌ 对拼写错误敏感
- ❌ 无法处理复杂概念组合
**机场场景示例**：
```
查询: "Tier IV 数据中心 PUE"
BM25 匹配:
- tier-iv-design.md (PUE < 1.2)
- power-and-cooling.md (PUE 计算方式)
- 机场智算中心技术方案.md (Tier IV 章节)
```
### 2️⃣ 向量语义检索
**模型**：`text-embedding-3-small` (OpenAI) 或 `BGE-M3` (开源)
**维度**：1536 维向量空间
**用途**：概念搜索、相似文档发现、跨语言检索
```python
# 伪代码实现
def vector_search(query: str, embeddings: Dict[str, List[float]], top_k=10):
"""
参数:
- embeddings: {page_path: [vector]}
- top_k: 返回 top K 结果
"""
# 1. 查询编码
query_vec = embed_model.encode(query)
# 2. 计算余弦相似度
similarities = []
for page_path, page_vec in embeddings.items():
sim = cosine_similarity(query_vec, page_vec)
similarities.append((page_path, sim))
# 3. 返回 top K
return sorted(similarities, key=lambda x: x[1], reverse=True)[:top_k]
```
**嵌入生成策略**：
```python
# 页面内容预处理
def prepare_for_embedding(page_content: str) -> str:
"""
优化嵌入质量的预处理：
1. 提取 frontmatter 关键字段 (title, tags, type)
2. 保留正文前 2000 tokens（最重要的内容）
3. 移除代码块、表格格式（保留纯文本）
4. 标准化术语（统一缩写/全称）
"""
return processed_text
# 批量嵌入生成（每周更新）
def regenerate_embeddings():
for page in all_wiki_pages:
content = read_page(page)
text = prepare_for_embedding(content)
embedding = embed_model.encode(text)
save_embedding(page, embedding)
log("嵌入更新完成", timestamp=now())
```
**优势**：
- ✅ 理解语义相似性（"AI训练集群" ≈ "GPU计算农场"）
- ✅ 支持模糊查询（拼写容错）
- ✅ 发现相关但无关键词重叠的内容
- ✅ 跨语言检索潜力
**局限**：
- ❌ 无法精确匹配特定参数（如 "H100 功耗 700W"）
- ❌ 需要定期重新计算嵌入（内容更新时）
- ❌ 计算成本较高（API 调用或本地推理）
**机场场景示例**：
```
查询: "如何降低数据中心能耗"
向量匹配:
- liquid-cooling.md (液冷节能 40%)
- tier-iv-design.md (PUE 优化)
- modern-airport-trends.md (绿色机场趋势)
- prefab-modular-dc.md (模块化节能)
```
### 3️⃣ 知识图谱遍历检索
**数据源**：`entities/index.md` + 页面 `relationships` 字段
**算法**：图遍历（BFS/DFS）、路径查询、社区发现
**用途**：关系发现、影响分析、生态系统查询
```python
# 伪代码实现
def graph_traversal_search(start_entity: str,
relation_type: Optional[str] = None,
max_depth: int = 3):
"""
从起点实体开始遍历知识图谱
"""
visited = set()
results = []
def dfs(entity: str, depth: int, path: List[str]):
if depth > max_depth or entity in visited:
return
visited.add(entity)
path.append(entity)
# 获取实体的所有关系
relationships = get_relationships(entity)
for rel in relationships:
if relation_type and rel.type != relation_type:
continue
# 记录发现的关系路径
results.append({
"path": path.copy() + [rel.target],
"relation": rel.type,
"confidence": rel.confidence,
"depth": depth + 1
})
# 递归遍历
dfs(rel.target, depth + 1, path.copy() + [rel.target])
dfs(start_entity, 0, [])
return results
```
**图谱查询类型**：
1. **直接关系查询**：`find_related("郑州航空港区机场", relation_type="deploys")`
2. **路径查找**：`find_path("NVIDIA", "华为", max_depth=3)`
3. **社区发现**：`find_community("aodb-core", min_confidence=0.8)`
4. **影响力分析**：`find_influencers("liquid-cooling", direction="upstream")`
**优势**：
- ✅ 发现隐含关系（间接连接）
- ✅ 理解系统依赖和影响链
- ✅ 支持推理查询（"如果X故障，影响什么？"）
- ✅ 可视化展示（关系图）
**局限**：
- ❌ 依赖结构化数据质量
- ❌ 需要手动维护关系（或自动提取）
- ❌ 无法处理非实体内容（概念解释）
**机场场景示例**：
```
查询: "哪些机场使用ADB SAFEGATE的AODB"
图谱遍历:
起点: ADB SAFEGATE → provides → aodb-core
遍历: aodb-core ← deploys ← [shenzhen-airport, jfk-airport, ...]
结果: [深圳机场, 纽约肯尼迪机场, ...]
```
---
## 🔄 结果融合策略
### 倒数排名融合（RRF）
```python
def reciprocal_rank_fusion(bm25_results: List[str],
vector_results: List[str],
graph_results: List[str],
k: int = 60):
"""
RRF 公式: score = Σ(1 / (k + rank))
- k: 平滑参数，通常 60
- rank: 在单个列表中的排名 (1-based)
"""
# 初始化得分字典
scores = defaultdict(float)
# 处理 BM25 结果
for rank, doc in enumerate(bm25_results, 1):
scores[doc] += 1 / (k + rank)
# 处理向量结果
for rank, doc in enumerate(vector_results, 1):
scores[doc] += 1 / (k + rank)
# 处理图谱结果（可能需要转换实体→页面）
for rank, entity_path in enumerate(graph_results, 1):
# 将实体路径转换为相关页面
pages = entity_path_to_pages(entity_path)
for page in pages:
scores[page] += 1 / (k + rank) / len(pages)
# 按总得分排序
return sorted(scores.items(), key=lambda x: x[1], reverse=True)
```
### 查询类型自适应权重
| 查询类型 | BM25权重 | 向量权重 | 图谱权重 | 说明 |
|----------|----------|----------|----------|------|
| **技术参数** | 0.6 | 0.3 | 0.1 | 精确数字、规格、型号 |
| **概念解释** | 0.3 | 0.6 | 0.1 | 定义、原理、背景 |
| **关系查询** | 0.1 | 0.2 | 0.7 | 依赖、影响、连接 |
| **综合搜索** | 0.4 | 0.4 | 0.2 | 默认权重分配 |
### 去重与多样化
```python
def diversify_results(merged_results: List[Tuple[str, float]],
max_similar: float = 0.8):
"""
确保结果多样性，避免同质化
"""
diversified = []
seen_content = set()
for doc, score in merged_results:
# 计算与已选结果的相似度
max_sim = 0
for selected in diversified[:5]: # 与前5个比较
sim = content_similarity(doc, selected)
max_sim = max(max_sim, sim)
# 如果太相似，降低权重
if max_sim > max_similar:
adjusted_score = score * (1 - max_sim)
else:
adjusted_score = score
diversified.append((doc, adjusted_score))
return sorted(diversified, key=lambda x: x[1], reverse=True)
```
---
## 🚀 实施路线图
### 阶段 1：基础 BM25 + 简易向量（当前）
- ✅ Ripgrep 实现关键词搜索
- ✅ 同义词词典扩展（`search/synonyms.txt`）
- 🔄 OpenAI embeddings API 调用（按需）
- 📊 搜索日志记录与分析
### 阶段 2：本地向量库 + 基础图谱（1-2周）
- 🔄 本地嵌入模型部署（`BGE-M3` 或 `text-embedding-3-small`）
- 🔄 每周批量嵌入更新
- 🔄 实体关系图谱基础遍历
- 📊 搜索结果质量评估框架
### 阶段 3：完整混合搜索 + 自动化（1个月）
- 🔄 RRF 融合算法实现
- 🔄 查询分类器（自动识别查询类型）
- 🔄 图谱嵌入（Node2Vec 或 GraphSAGE）
- 🔄 自动化搜索优化（基于用户反馈）
### 阶段 4：高级功能（未来）
- 🔄 多语言检索支持
- 🔄 时序搜索（基于 `updated` 日期）
- 🔄 个性化排名（基于用户历史）
- 🔄 可视化搜索界面
---
## 📋 技术栈建议
### 轻量级方案（Python 优先）
```yaml
bm25:
- whoosh 或 tantivy (Python)
- 同义词: pywsd 或 nltk.wordnet
vector:
- sentence-transformers (BGE-M3)
- 或 OpenAI API (text-embedding-3-small)
graph:
- networkx (内存图)
- 或 redisgraph (持久化)
fusion:
- 自定义 RRF 实现
```
### 生产级方案
```yaml
bm25:
- Elasticsearch 或 Typesense
vector:
- Qdrant 或 Weaviate (向量数据库)
graph:
- Neo4j 或 Amazon Neptune
fusion:
- 自定义微服务或 LangChain
```
---
## 📊 性能指标与监控
### 搜索质量指标
| 指标 | 计算方法 | 目标值 |
|------|----------|--------|
| **MRR** | Mean Reciprocal Rank | >0.6 |
| **NDCG@10** | 归一化折损累计增益 | >0.7 |
| **点击率** | 结果点击/展示 | >25% |
| **查询分类准确率** | 自动分类准确率 | >85% |
### 性能指标
| 指标 | 计算方法 | 目标值 |
|------|----------|--------|
| **P95 延迟** | 95% 查询响应时间 | <2s |
| **吞吐量** | QPS (查询/秒) | >10 |
| **缓存命中率** | 缓存结果/总查询 | >40% |
| **嵌入新鲜度** | 嵌入更新延迟 | <7天 |
### 监控仪表板
```python
# 搜索日志格式
search_log = {
"query": "Tier IV PUE 标准",
"query_type": "technical", # 自动分类
"results_count": 15,
"fusion_method": "rrf_k60",
"response_time_ms": 1240,
"components_timing": {
"bm25": 120,
"vector": 980,
"graph": 140
},
"user_feedback": None, # 点击或评分
"timestamp": "2026-04-13T10:30:00Z"
}
```
---
## 🔧 维护指南
### 每周维护任务
1. **嵌入更新**：重新计算所有页面的向量嵌入
2. **同义词更新**：根据搜索日志添加新同义词
3. **图谱验证**：检查关系一致性和置信度衰减
4. **性能分析**：分析慢查询，优化索引
### 每月优化任务
1. **权重调整**：基于用户反馈调整融合权重
2. **模型评估**：评估嵌入模型效果，考虑升级
3. **查询分析**：识别常见查询模式，优化处理
4. **容量规划**：预测增长，规划扩容
### 故障恢复
```bash
# 搜索系统故障恢复流程
1. 降级到纯 BM25 搜索
2. 禁用向量和图谱组件
3. 检查嵌入存储完整性
4. 逐步恢复各组件
5. 验证搜索结果质量
```
---
## 📚 相关文档
- [[SCHEMA.md]] - LLM Wiki v2 架构定义
- [[entities/index.md]] - 知识图谱数据源
- [[knowledge-management/wiki-operations.md]] - 自动化维护
- [[search-logs-analysis.md]] - 搜索日志分析报告
---
> **实施状态**：当前处于阶段 1（基础 BM25 + API 向量）。下一步：部署本地嵌入模型，实现每周批量更新。最后更新：2026-04-13。
airport-wiki/index.md
-173
View File
@@ -1,173 +0,0 @@
---
title: Wiki Index
created: 2026-04-08
updated: 2026-04-10
type: meta
tags: [meta, index]
---
# 🏗️ Airport Wiki 入口
> **機場智能化工程知識庫** — 基於 LLM Wiki v2 架構的動態知識系統
> 📊 總頁數: 43 | 📅 最後更新: 2026-04-13 | 🔗 版本: v2.1.0
---
## 🧭 快速導航
### 按領域探索
- **🧠 智算中心技術** — GPU集群、液冷供電、網絡架構、Tier等級標準
- **✈️ 航班運營管理** — AODB/A-CDM/SMGCS/BHS、數據交換、供應商分析
- **🏢 機場實體案例** — 深圳/鄭州/福州/樟宜等標杆機場技術方案
- **⚙️ 知識管理系統** — 置信度衰減、實體圖譜、自動化鉤子、質量控制
### 按用途查找
- **技術選型** → [[gpu-cluster]] | [[aodb-vendors]] | [[power-and-cooling]]
- **系統設計** → [[network-architecture]] | [[airport-systems-landscape]] | [[open-architecture]]
- **前沿趨勢** → [[agentic-ai-airports]] | [[digital-twins-airports]] | [[modern-airport-trends]]
- **案例參考** → [[airport-dc-case-studies]] | [[airport-operations-systems]] | [[entities/index]]
### 搜索指南
1. **概念搜索** → `[[概念名稱]]` 雙括號鏈接
2. **關鍵詞搜索** → 在任意筆記中使用 `Cmd/Ctrl+F`
3. **關係探索** → 查看筆記底部的 `relationships` 部分
4. **實體導航** → 訪問 [[entities/index]] 查看機場實體圖譜
---
## 📁 目錄結構概覽
```
airport-wiki/
├── SCHEMA.md # 🏗️ 架構定義
├── index.md # 🏠 本入口頁
├── log.md # 📝 操作日誌
│
├── 机场智算中心技术方案.md # 💾 智算中心完整技術方案
├── 机场航班数据管理运营方案.md # ✈️ 航班運營綜合方案
│
├── concepts/ # 📚 概念庫
│ ├── tech-infrastructure/ # 🔧 智算中心技術
│ ├── flight-operations/ # 🛫 航班運營系統
│ └── knowledge-management/ # ⚡ LLM Wiki v2 知識管理
│ ├── automation-hooks.md # 🔄 自動化鉤子與事件驅動
│ ├── knowledge-lifecycle.md # 📉 知識生命周期與遺忘曲線
│ ├── quality-control.md # 🔍 質量控制與自我糾正
│ ├── knowledge-graph.md # 🕸️ 實體圖譜與類型化關係
│ └── hybrid-search.md # 🔎 混合搜索與查詢重寫
│
├── comparisons/ # ⚖️ 對比分析
│ ├── airport-dc-case-studies.md # 數據中心案例
│ └── airport-operations-systems.md # 運營系統對比
│
├── entities/ # 🏢 機場實體
│ ├── index.md # 📊 實體索引與關係圖譜
│ ├── shenzhen-airport.md # 深圳寶安國際機場
│ ├── zhengzhou-airport-hangang.md # 鄭州航空港
│ ├── fuzhou-changle-airport-bsj.md # 福州長樂機場
│ ├── jfk-airport.md # 紐約 JFK 機場
│ ├── pittsburgh-airport.md # 匹茲堡國際機場
│ ├── rome-fiumicino-airport.md # 羅馬 Fiumicino 機場
│ └── singapore-changi-airport.md # 新加坡樟宜機場
│
├── _archive/ # 🗃️ 歸檔版本（被 supersede）
│
└── raw/ # 📄 原始資料
├── articles/ # 來源文章（LLM Wiki v2 攝入）
└── ... # 其他原始資料
```
---
## 🔄 LLM Wiki v2 特性
### 動態知識管理
- **置信度衰減** — 基於時間和使用頻率的知識老化機制
- **自動整合** — 新來源到現有知識的智能合併
- **衝突檢測** — 矛盾陳述的識別和解決
- **質量控制** — 多層次驗證和自我糾正
### 智能檢索
- **混合搜索** — 向量 + 關鍵詞 + 語義重寫
- **關係圖譜** — 實體之間的類型化關係
- **上下文感知** — 查詢意圖識別和結果排序
- **結果學習** — 查詢模式的記錄和優化
### 自動化維護
- **事件驅動** — 文件變更觸發自動處理
- **定期任務** — 每週/每月自動質量檢查
- **異常檢測** — 技術參數和邏輯異常告警
- **備份恢復** — 增量備份和版本管理
---
## 🚀 開始使用
### 1. 查看架構
閱讀 [[SCHEMA.md]] 了解 wiki 的整體設計理念和領域劃分。
### 2. 瀏覽核心概念
- **智算中心技術** → 訪問 `concepts/tech-infrastructure/` 目錄
- **航班運營系統** → 訪問 `concepts/flight-operations/` 目錄
- **知識管理** → 訪問 `concepts/knowledge-management/` 目錄
### 3. 探索實體案例
查看 [[entities/index]] 了解各機場的技術特點和相互關係。
### 4. 使用搜索功能
- 查找具體技術參數 → 搜索關鍵詞如 `GPU H100`、`PUE`、`Tier IV`
- 查找運營系統 → 搜索 `AODB`、`A-CDM`、`SMGCS`
- 查找廠商方案 → 搜索 `SITA`、`ADB SAFEGATE`、`華為`
### 5. 貢獻內容
- **新增來源** → 放置到 `raw/articles/` 目錄（自動觸發處理）
- **編輯頁面** → 直接修改 `.md` 文件（觸發自動質量檢查）
- **報告問題** → 在筆記中標記 `⚠️` 或 `❌` 問題
---
## 📊 系統狀態
| 指標 | 當前值 | 狀態 |
|------|--------|------|
| **總頁數** | 43 | ✅ 正常 |
| **知識覆蓋度** | 機場智算 + 航班運營 | 📈 擴展中 |
| **置信度均值** | 0.82 | 🟢 良好 |
| **衝突數量** | 2 | 🟡 低風險 |
| **最近更新** | 2026-04-13 | ✅ 活躍 |
| **自動化鉤子** | 基礎實現 | 🟡 部分啟用 |
---
## 📞 支持與反饋
### 常見問題
**Q: 如何查找某個具體技術參數？**
A: 使用雙向鏈接 `[[頁面名稱]]` 或搜索關鍵詞。技術參數通常在 `gpu-cluster.md`、`power-and-cooling.md` 等頁面。
**Q: 如何對比不同機場的方案？**
A: 訪問 [[airport-dc-case-studies.md]] 或 [[entities/index]] 查看橫向對比。
**Q: 新增的來源如何被處理？**
A: 放入 `raw/articles/` 後會自動觸發解析、實體提取和知識整合。
**Q: 如何查看頁面的置信度？**
A: 查看頁面的 YAML frontmatter 中的 `confidence` 字段。
### 問題報告
1. **內容錯誤** → 在頁面中添加 `⚠️` 標記和錯誤描述
2. **技術問題** → 檢查 `log.md` 中的自動化處理記錄
3. **功能建議** → 在相關概念頁面添加建議註釋
---
## 📅 更新歷史
- **2026-04-13** — **LLM Wiki v2 升級完成**：新增知識管理系統（自動化鉤子、生命周期、質量控制、實體圖譜）
- **2026-04-10** — 大規模重構：SCHEMA.md 更新，拆分 AODB 文檔，新增系統全景圖
- **2026-04-08** — 初始創建：智算中心+航班運營方案，8篇來源文章攝入
> 💡 **提示**：本 wiki 採用 LLM Wiki v2 架構，支持動態知識更新和自動化維護。所有內容都帶有置信度評分，並會隨時間衰減。查看 [[concepts/knowledge-management/]] 了解更多。
---
airport-wiki/log.md
-236
View File
@@ -1,236 +0,0 @@
---
title: Wiki Log
created: 2026-04-08
updated: 2026-04-10
type: meta
tags: [meta, log]
---
# Wiki Log
> 按时间顺序记录所有 wiki 操作。追加写入。
> 格式：`## [YYYY-MM-DD] action | subject`
> 操作类型：ingest, update, query, lint, create, archive, delete
> 本文件超过 500 条时轮转：重命名为 `log-YYYY.md`，重新开始。
## [2026-04-08] create | Wiki 初始化
- Domain: 机场数据中心建设方案
- Structure: SCHEMA.md, index.md, log.md, raw/{articles,papers,transcripts,assets}, entities/, concepts/, comparisons/, queries/
- Schema 定制：机场数据中心领域标签体系，8 大分类
- 说明：[[SCHEMA.md]] 定义了页面类型、标签体系、创建规则、更新政策
## [2026-04-08] ingest | 2025-2026 机场数据中心行业调研
- 来源1：2025第十一届中国机场建设年会（大连日报）
- 来源2：Keydak金盾 — 2025国际机场博览会风液融合方案
- 来源3：华为×迪拜机场预制模块化数据中心案例
- 来源4：维谛技术×北京大兴国际机场关键基础设施案例
- 创建/更新页面：
- concepts/modern-airport-trends.md（新建）
- concepts/prefab-modular-dc.md（新建）
- comparisons/airport-dc-case-studies.md（新建）
- raw/articles/2025-airport-construction-summit.md（新建）
- raw/articles/keydak-airport-expo-2025.md（新建）
- raw/articles/dubai-airport-huawei-dc.md（新建）
- raw/articles/daxing-airport-vertiv.md（新建）
- 更新：index.md（Total pages: 11）
## [2026-04-08] create | 生成《机场智算中心技术方案》综合文档
- 输出文件：机场智算中心技术方案.md
- 内容：10个章节，涵盖算力集群、液冷系统、网络架构、供电方案、运维平台
- 数据来源：信通院液冷报告、国信证券液冷专题、头豹AIDC白皮书、工业智算研究报告、临港算力实践
- 重大变更：推翻之前偏向建设/立项方向的《机场数据中心建设方案.md》，改为硬核技术参数
## [2026-04-08] create | GPU 集群概念页面
- 新建：concepts/gpu-cluster.md
- 内容：芯片选型（H100/H200/昇腾910B）、服务器形态、网络架构（InfiniBand/RoCE）、机场规模参数表、液冷方案对比、调度运维技术栈
- 关联：[[modern-airport-trends]]（智算趋势）、[[prefab-modular-dc]]（物理载体）、[[power-and-cooling]]（液冷必选）、[[network-architecture]]（计算网络）、[[airport-data-center-overview]]（核心子系统）
- 更新：index.md（Total pages: 12）
## [2026-04-10] merge | flight-wiki 合并入 airport-wiki
- Source: ~/.hermes/ObsidianVault/flight-wiki/
- 迁入内容：
- concepts/：7篇（a-cdm、aodb、baggage-handling、deicing-operations、flight-data-exchange、smart-gating、smgcs）
- comparisons/：1篇（airport-operations-systems.md）
- raw/：完整目录结构（articles、assets、papers、transcripts）
- 根目录：机场航班数据管理运营方案.md
- 更新：index.md（Total pages: 16→24）、log.md
- 说明：flight-wiki 已完成使命，内容完整迁移至 airport-wiki
## [2026-04-10] lint+fix | 重构整理 — 断链修复与归档
- 修复 `[[aodb]]` 断链（共7处）→ `[[aodb-core]]`：
- concepts/flight-operations/{baggage-handling,smgcs,smart-gating,a-cdm,flight-data-exchange,deicing-operations}.md
- 机场航班数据管理运营方案.md
- 移除 index.md 中的 `[[aodb]]` 重定向入口（内容已完全迁移）
- 归档 `concepts/flight-operations/aodb.md` → `_archive/aodb-redirect-stub.md`（无入站链接）
- 修复不存在的 wikilinks → 纯文本（无对应页面）：
- digital-twins-airports.md: `[[sustainability-airports]]` → plain text
- agentic-ai-airports.md: `[[hyper-personalization-airports]]` → plain text
- future-airport-info-center.md: `[[biometric-corridors]]`、`[[universal-design-airports]]` → plain text
- 重新统计 index.md Total pages: 实际 44（tech-infra:16 + flight-ops:16 + comparisons:2 + entities:7 + root:3）
- 备注：comparsions/ 目录已在 wiki 中但未被 index.md 收录（待处理）
## [2026-04-09] ingest | 机场智算中心第二轮调研（8篇来源）
- 抓取并保存至 raw/articles/：
1. 郑州航空港-中部最大万卡算力集群-2026-03-05.md
2. 福州长乐机场-15000P智算中心-2026-01-22.md
3. 深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md
4. IBM-Building-intelligent-airport-future-2025.md
5. 上海市-智算中心建设导则2025版-2025-01.md
6. 中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md
7. 头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md
8. AI-Driven-Smart-Gating-2025.md
- 更新/新建页面：
- concepts/gpu-cluster.md（大修正：GPU型号表、HGX服务器功耗、NVLink规格、GB200数据、千卡集群3.5亿参考）
- concepts/power-and-cooling.md（新增：上海PUE/WUE/CUE三级指标、液冷类型对比、英维克/中科曙光参数）
- concepts/modern-airport-trends.md（新增趋势6-8：AI智能体矩阵/物流智能化/万卡集群选址）
- entities/shenzhen-airport.md（新建）
- entities/zhengzhou-airport-hangang.md（新建）
- entities/fuzhou-changle-airport-bsj.md（新建）
- 更新：index.md（Total pages: 12→16）、log.md
## [2026-04-10] restructure | 大規模重構（SCHEMA + 結構 + aodb拆分）
- 原因：SCHEMA Domain 需覆蓋「智算中心+航班運營」兩大領域；aodb.md（380行）需拆分
- Domain 更新：SCHEMA.md 新增航班運營標籤體系（a-cdm/aodb/smgcs/bhs/fids/等）
- 目錄重構：concepts/ 拆分為 tech-infrastructure/ 和 flight-operations/ 兩子目錄
- aodb.md 拆分：
- 原：aodb.md（380行）
- 新：aodb-core.md（核心概念、Milestone、A-CDM架構、選型決策樹）
- 新：aodb-vendors.md（5大供應商深度分析、技術對比、AI能力梯隊）
- 改：aodb.md（重定向至 aodb-core + aodb-vendors）
- 新增頁面：
- concepts/flight-operations/airport-systems-landscape.md（系統全景圖：分層架構+數據流向+標準接口）
- index.md 重寫：新增目錄結構視覺化圖、兩大領域清晰分區、總頁面數更新
- 更新：SCHEMA.md、index.md、log.md
- 刪除：~/.hermes/ObsidianVault/flight-wiki/（已完成使命）
- 說明：原 flight-wiki 的內容已100%遷移至 airport-wiki/concepts/flight-operations/
## [2026-04-10] ingest | 機場開放架構（ACI EUROPE 2020 + TSA/ACI 2023 雙來源）
- 來源①：用戶提供的 NotebookLM 內容（ACI EUROPE 2020 開放架構規範）
- 來源②：用戶攝入 URL（aci-tsa-open-architecture-2023.md）— TSA 2023 路線圖 + ACI 2023 第二版
- 新增：TSA 正式定義、背景與發展時間線（2020 ACI → 2023 TSA/ACI 雙里程碑）
- 新增：SITA Common Use、DHS S&T、Smiths Detection、Vanderlande 等組織
- 新增：4 大應用場景（安檢/旅客處理/行李處理/機場運營管理）
- 新增：5 大發展趨勢（標準化/全球推廣/AI融合/數字身份/網路安全）
- 新增：真實參考來源 URL（TSA/ACI/Smiths Detection 官網）
- 源存檔：raw/articles/aci-tsa-open-architecture-2023.md（6968 bytes）
- 頁面更新：concepts/flight-operations/open-architecture.md（全面重寫，6761 bytes）
- 更新：SCHEMA.md（新增 `open-architecture`, `dicos`, `acris`, `vendor-lock-in`, `capability-multiplier` 標籤）
- 更新：index.md（Total pages: 24→25）
|## [2026-04-10] lint+create | Wiki 內部清理與強化
**Wikilink 修復（37 個失效鏈接全部修復）**
- comparisons/airport-dc-case-studies.md：引用路徑從根目錄改為 tech-infrastructure/
- concepts/tech-infrastructure/airport-data-center-overview.md：6個引用缺失頁面的 wikilink 替換為內聯描述（site-planning/design-phase/rfp-and-vendor-selection/construction-management/commissioning/operation-maintenance 頁面當時尚不存在）
- concepts/tech-infrastructure/tier-iv-design.md：移除不存在的 security-design 引用（已新建該頁面）
- concepts/flight-operations/{airport-systems-landscape,aodb-core,aodb-vendors}.md：airport-operations-systems 引用路徑改為 comparisons/
**新建頁面（7 個）**
- concepts/tech-infrastructure/site-planning.md（機場凈空限制、選址決策矩陣）
- concepts/tech-infrastructure/design-phase.md（BIM協同、等級選擇、功能分區）
- concepts/tech-infrastructure/rfp-and-vendor-selection.md（招標模式、品牌矩陣、Uptime認證）
- concepts/tech-infrastructure/construction-management.md（AZAL准入、BIM施工、ITP品質控制）
- concepts/tech-infrastructure/commissioning.md（滿載測試、PUE實測、Uptime TCF認證）
- concepts/tech-infrastructure/operation-maintenance.md（運維指標、DCIM、Uptime M&O認證）
- concepts/tech-infrastructure/security-design.md（分域架構、Data Diode、等保2.0）
**文件清理**
- .gitignore：新建機場wiki根目錄gitignore（忽視 node_modules/raw/.obsidian）
- 機場數據中心建設方案.md：從git跟蹤中移除，加入.gitignore（內容已被機場智算中心技術方案.md取代）
**Frontmatter 補充**
- index.md：新增 frontmatter（type: meta）
- 機場智算中心技術方案.md：新增 frontmatter（type: solution，含sources）
- 機場航班數據管理運營方案.md：新增 frontmatter（type: solution，含sources）
- log.md：新增 frontmatter（type: meta）
## [2026-04-10] ingest | 未來機場信息中心研究報告（Manus AI）
**來源**
- raw/articles/manus-future-airport-info-center-2026.md（9002 bytes）
- 主題：Future Airport Info Center 深度研究，含 Connected Intelligence 理論框架
**新建概念頁（6 個）**
- concepts/flight-operations/future-airport-info-center.md（5554 bytes）
- 核心理念：Connected Intelligence、AODB/RMS 深度融合
- 四大技術支柱：Agentic AI、數字孿生、生物識別走廊、AOCC/IOC
- 三大設計方向：人本設計、超級個性化、可持續性
- 市場數據：機場信息系統 37-42 億美元（3.5-4.0% CAGR）、智能機場 10.36% CAGR、AOCC 10.38% CAGR
- concepts/flight-operations/agentic-ai-airports.md（2280 bytes）
- Agentic AI vs 傳統規則引擎對比表、羅馬 ADR 案例、核心能力分析
- concepts/flight-operations/digital-twins-airports.md（1764 bytes）
- 數字孿生架構：物理層→IoT→數字孿生層→應用層、Bentley Systems
- concepts/flight-operations/biometric-corridors.md（2360 bytes）
- Biometric Corridor 技術棧：面部識別/數字身份/Kiosks、樟宜 T5/SITA 應用、數據隱私挑戰
- concepts/flight-operations/aocc-ioc.md（2507 bytes）
- 華為 AOCC 方案、TAV Technologies、10.38% CAGR 市場數據
- concepts/flight-operations/universal-design-airports.md（2262 bytes）
- PIT 全球首個 Universal Design 認證、ADA/ISO 21542 標準、信息中心無障礙設計清單
**新建實體頁（4 個）**
- entities/jfk-airport.md（1635 bytes）— T6 + New T1 SITA-CCM 信息中心
- entities/rome-fiumicino-airport.md（1384 bytes）— ADR 生成式 AI 虛擬助手
- entities/pittsburgh-airport.md（1514 bytes）— 全球首個 Universal Design 認證機場
- entities/singapore-changi-airport.md（1702 bytes）— T5 100% 無接觸 + SITA 體驗中心
**SCHEMA 更新**
- 新增標籤：digital-twins, agentic-ai, biometric, human-centered-design, hyper-personalization, sustainability, aocc, ioc
**更新：index.md（Total pages: 25→35）、log.md**
## [2026-04-10] restructure | 術語表（Glossary）全面重寫
- 原有術語表僅含 22 個縮寫（主要為數據中心基礎設施）
- 全面掃描 wiki 所有頁面（concepts/ 下所有 .md），自動識別全部專有縮寫
- 新術語表分為 11 個領域：
1. 數據中心基礎設施（PUE/WUE/CUE、UPS/PDU/ATS、MTTF/RTO/SLA 等）
2. 智算中心與 GPU 集群（PFLOPS/EFLOPS、NPU/TPU/HBM、NCCL/RDMA/FSDP、vLLM/TGI 等）
3. 網絡架構（Spine-Leaf/IB/RoCE/SDN/ZTNA/DDoS 等）
4. 機場運營系統（AODB/A-CDM/BHS/FIDS/SMGCS/A-SMGCS、ADS-B/SMR/RVR/LVP 等）
5. A-CDM 關鍵節點（TOBT/TSAT/TTOT/CTOT/ASAT/ALDT 等）
6. 航班數據交換（SSIM/AIRIMP/AHM/CIDX/ARINC/IATA/ICAO/FAA/EASA 等）
7. 行李系統（RFID/EBS/BRS/Tote/BSM/CRS 等）
8. 供應商與解決方案（SITA/Amadeus/ADB SAFEGATE/Indra/VERTIV/Huawei/NVIDIA 等）
9. 開放架構與標準（DICOS/ACRIS/ICDM/CDD/DDS/DHS/CBP/TSA 等）
10. 未來信息中心與 AI（AOCC/IOC/Agentic AI/Digital Twin/Biometric Corridor/Universal Design 等）
11. 建設與項目管理（BIM/LOD/WBS/ITP/AZAL/RFP/EPC/TCO 等）
12. 存儲與雲原生（CEPH/GPFS/MinIO/JuiceFS/NFS/CSI/ACK/CCI 等）
- 總計收錄約 200+ 縮寫，完整覆蓋智算中心 + 航班運營兩大領域
- 更新：glossary.md、index.md、log.md
## [2026-04-10] ingest | fast.ai Practical Deep Learning 課程文檔
- 來源：https://course.fast.ai/ 首頁 + L1/L9/part2 overview 頁面
- 新建：concepts/flight-operations/fast-ai-course.md
- Part 1（9 課時）：Getting Started / Deployment / Neural Net Foundations / NLP / From-scratch / Random Forests / Collaborative Filtering / CNNs / Data Ethics
- Part 2（17 課時）：Stable Diffusion 從零實現 / Backpropagation / Autoencoders / Attention & Transformers / Latent Diffusion 等
- **已移出**：文件移至 vault 根目錄 03_Resources/Development/fast-ai-course.md（不在 airport-wiki 內）
- 更新：index.md（Total pages: 36→35）、log.md
|## [2026-04-10] update | 重写 机场智算中心技术方案
|- 基于 wiki 最新内容全面重写：GPU 集群拓扑、液冷 PUE/WUE/CUE 三级指标、IB NDR 400G 组网、存储架构、国产化方案
|- 修正：GB200 NVL72 HBM3e 带宽 16 TB/s（原错误值已更正）、HGX H100 NVSwitch 6 芯片拓扑、昇腾 HCCS 392 GB/s（原误写 128 GB/s）
|- 新增三个机场案例：郑州航空港（10,000P 当前 / 100,000P 规划）、福州长乐（15,000P / 11 亿元 / 2026.10 投产）、深圳宝安（DeepSeek R1-671B 满血版，全国第二）
|- 新增三级规模配置方案（中等/大规模/旗舰）含功耗测算
|- 来源：上海智算导则、头豹 AIDC 白皮书、工业智算报告、Vertiv GB200 白皮书、郑州/福州/深圳机场案例
|- 更新：机场智算中心技术方案.md、log.md
## [2026-04-13] ingest | LLM Wiki v2 — 知识管理框架整合
|- 来源：https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2（rohitg00，agentmemory 项目）
|- 新建概念页（3篇）：
| - concepts/knowledge-management/memory-lifecycle.md（置信度/superset/遗忘机制/Ebbinghaus/整合层次）
| - concepts/knowledge-management/knowledge-graph.md（实体提取/typed relationships/图遍历/当前实施路径）
| - concepts/knowledge-management/wiki-operations.md（事件钩子矩阵/On new source流程/Quality scoring/实施优先级）
|- 新建 entities/index.md（实体索引+关系图谱/7个机场+供应商关系/Typed Relationships 示例）
|- 来源存档：raw/articles/llm-wiki-v2-rohitg00.md
|- SCHEMA.md 更新：
| - frontmatter 新增字段：confidence/sources_count/last_confirmed/superseded_by/supersedes/status/relationships
| - 新增标签体系：knowledge-management/confidence/supersession/forgetting/consolidation-tier/knowledge-graph/entity/typed-relationship/automation/event-hooks/stale/dormant
| - 新增 Supersession 机制（含流程步骤）
| - 新增 Confidence Decay 规则（按知识类型分层衰减率）
| - 扩展 Entity Pages frontmatter 格式
| - 目录结构更新（新增 knowledge-management/ + entities/index.md + _archive/）
|- index.md 更新：Total pages 35→39，目录结构同步更新
|- 实施优先级：P0=建立 _archive/+superset流程，P1=entity extraction脚本，P2=session end hook，P3=cron lint+decay
airport-wiki/package-lock.json
Generated
-1645
View File
File diff suppressed because it is too large Load Diff
airport-wiki/package.json
-10
View File
@@ -1,10 +0,0 @@
{
"devDependencies": {
"markdownlint": "^0.37.0",
"markdownlint-cli": "^0.32.2",
"markdownlint-cli2": "^0.22.0"
},
"scripts": {
"lint": "npx markdownlint-cli \"**/*.md\" --ignore \"node_modules/**\""
}
}
airport-wiki/raw/articles/2025-airport-construction-summit.md
-35
View File
@@ -1,35 +0,0 @@
# 2025第十一届中国机场建设年会
来源：大连日报（2025-06-16）
URL: https://dalian.runsky.com/2025-06/16/content_6257964.html
## 关键信息
- 时间：2025年6月12-13日
- 地点：大连世博广场
- 主题："发展低碳新民航 数智赋能民航新基建"
- 参与方：200余家民航机构、企业，千余名专家
- 主办：中国航空学会、大连国际机场集团等
## 四型机场
"平安、绿色、智慧、人文"四型机场是中国民航"十四五"核心方向。
## 大连金州湾国际机场（在建）
- 国家"十四五"重大建设项目
- 海域机场，高盐高湿环境是核心挑战
- 采用BIM+数字化施工监管平台
- 专家咨询会：软基沉降、混凝土耐久性、建运一体化
## 关键与会方观点
- **上海机场集团**：建设运营一体化贯穿设计、施工、移交、运营各阶段
- **重庆机场集团**：低碳转型+数字化融入全链条
- **中建三局**：BIM+云计算+大数据+物联网
## 展会技术亮点
- 四足机器人AI智能巡检
- BIM施工管理平台
- 风液融合算力解决方案
airport-wiki/raw/articles/AI-Driven-Smart-Gating-2025.md
-103
View File
@@ -1,103 +0,0 @@
# AI-Driven Smart Gating: Transforming Airline Operations
**来源**: European Journal of Computer Science and Information Technology, 13(50), 12-26, 2025
**作者**: Vinay Siva Kumar Bhemireddy, Independent Researcher, USA
**URL**: https://eajournals.org/ejcsit/wp-content/uploads/sites/21/2025/07/AI-Driven-Smart-Gating.pdf
---
## 核心问题
传统登机口分配依赖静态排程和人工干预，在全球航空交通增长背景下效率低下。
**现有挑战**:
| 挑战 | 影响 |
|------|------|
| 多维变量实时处理能力有限 | 无法快速适应变化 |
| 静态排程框架 | 无法跨系统优化 |
| 人工干预流程 | 资源分配低效 |
| 传统规则系统 | 难以处理优先级重平衡 |
**后果**: 飞机滑行时间增加、不必要燃油消耗、旅客延误、机场容量利用率下降
## 智能登机口解决方案
### AI驱动系统的核心能力
- **主动式**而非反应式扰断管理
- 实时优化，减少地面移动
- 提高飞机利用率
- 增强资源分配效率
- 改善旅客中转和减少步行距离
### 演进历程
```
Paper-based scheduling (1980s前)
↓
Computerized Systems (1980s) — rule-based logic
↓
Multi-parameter Resource Management (2000s) — deterministic approaches
↓
Stochastic/Scenario-based Robust Optimization (现在)
↓
AI/ML-Driven Smart Gating (未来)
```
## 系统架构
### 四层架构
```
┌─────────────────────────────────────────┐
│ Data Acquisition Layer │
│ 航班管理系统 / 旅客处理平台 / 行李处理系统 / 外部数据源(天气) │
├─────────────────────────────────────────┤
│ Advanced Analytical Engine │
│ ML算法(模式识别) / 实时预测模型 │
├─────────────────────────────────────────┤
│ Simulation & Optimization Module │
│ 场景评估 / 多目标优化 │
├─────────────────────────────────────────┤
│ Integration Interfaces │
│ 遗留系统通信 / API架构 │
└─────────────────────────────────────────┘
```
## 优化技术
| 技术 | 应用 |
|------|------|
| 混合整数线性规划(MILP) | 登机口分配数学建模 |
| 约束编程 | 复杂约束处理 |
| 随机规划 | 不确定性建模 |
| 监督学习 | 运营模式预测 |
| 无监督学习 | 数据隐藏结构发现 |
| 强化学习 | 不确定条件下的序列决策 |
| 深度学习 | 异构数据流处理 |
## 考量因素
- 登机口容量
- 飞机尺寸兼容性
- 最小过站时间
- 航空公司偏好
- 旅客步行距离
- 行李转运要求
## 业务价值
- **运营效率**: 登机口再分配自动化，减少周转延误
- **财务收益**: 减少航班延误燃油消耗
- **环境优势**: 减少碳排放
- **旅客体验**: 减少步行距离，改善中转
---
## 技术备注
- 本论文为学术研究性质，提供AI登机口优化的理论框架
- 对深圳机场"机位智能分配"实践有学术支撑作用
- 可作为机场AI运营系统的技术方案参考
- 论文未包含具体模型参数或商业实现细节
airport-wiki/raw/articles/IBM-Building-intelligent-airport-future-2025.md
-90
View File
@@ -1,90 +0,0 @@
# Building the Intelligent Airport of the Future: An AI-Powered Air Travel Ecosystem Orchestrator
**来源**: IBM Think
**日期**: 2025年（具体日期未标注）
**URL**: https://www.ibm.com/think/insights/implementing-intelligent-airport-future-ai-powered-ecosystem-orchestrator
---
## 核心概念：机场作为 Ecosystem Orchestrator
机场正在从"人类执行+技术辅助"进化为"智能系统自主运营核心功能+人类监督"的模式。
**演进路径**:
| 阶段 | 特征 | 例子 |
|------|------|------|
| 1. Rules-based execution | 自主服务流程，"反射代理" | 自助值机、自助行李托运 |
| 2. AI agent development | 系统具备感知-决策-行动能力 | 渐进式信任建立 |
| 3. Sophisticated AI agents | 目标导向代理，跨多系统智能编排 | 航班延误时的登机口再分配、周转优化 |
## 业务价值领域
### 旅客体验
- **Touchless processing**: 无停顿安检、被动身份识别
- **Biometric identification**: "无边界"旅客体验
- 全流程无摩擦通行
### 运营领域
| 领域 | 能力 |
|------|------|
| 空侧运营 | 智能资源分配 |
| 行李运营 | 动态优化处理能力 |
| 航站楼运营 | 基于占用率/天气/能源目标的自主环境控制（照明、温度、通风） |
| IT运营 | 自我修复基础设施（弹性、安全） |
## 数据基础设施要求
### 推荐架构: Data Mesh（数据网格）
- 联邦化、面向域的数据所有权
- 集中化治理
- 各机场功能维护专业化数据，同时贡献于统一生态系统
**核心能力**:
- 实时运营智能
- 预测性机场运营
- 旅客流动改善与管理
- 运营效率和客户体验提升
### 数据伙伴关系挑战
> "不是'有权'获取航空公司数据，而是关注'航空公司能从中获得什么'"
成功要素：向合作伙伴证明数据共享价值，建立机场作为数据治理者的信任
## 基础设施要求
### 适应性与可扩展性
- **预测并适应**数据量波动（旅客、行李、货物）
- 与生态系统伙伴的**安全数据共享**（延迟不变）
- **混合云技术**应对峰值负载弹性
- **智能自动化**持续一致性能
### 安全设计
- IT和OT系统高级网络安全框架
- 网络安全与物理安全无缝融合
- 内在设计（by design and default）
## 国际标准倡议
### CATS Global Council - Concept of Operations (CONOPS)
- **目标**: 到2045年实现完全集成、无缝、可扩展、可持续的空管系统
- 核心能力：**近实时数字信息共享**
### SESAR-JU (EU) - FASTNet Project
- 通过AI和改进的机场对机场协调，将机场运营整合进航空网络
- 开创性新数据服务
---
## 技术备注
- IBM文档偏重架构框架，缺少具体AI/ML技术细节（模型规模、硬件配置）
- 主要面向机场运营管理层，非技术规格文档
- 适合与国内具体机场案例对比参照
airport-wiki/raw/articles/aci-tsa-open-architecture-2023.md
-97
View File
@@ -1,97 +0,0 @@
# 机场开放架构（Airport Open Architecture）
## 一、定义与核心概念
**机场开放架构**（Open Architecture，简称 OA）是一种系统设计方法，其核心理念是采用**基于标准的、可互操作的**软硬件组件来构建机场的各类系统（尤其是安检系统）。与传统的封闭式、专有架构不同，开放架构强调技术基础设施的规格和接口是公开的、非专有的，从而允许不同厂商的设备和软件能够无缝协作。
根据美国运输安全管理局（TSA）的定义：
> Open Architecture (OA) is a design approach in which equipment components, such as software and hardware, are standards-based and interoperable.
简单来说，机场开放架构就是将机场中原本各自独立、互不兼容的系统（如安检设备、旅客处理系统、行李处理系统等）通过统一的标准和开放的接口连接起来，使其能够灵活组合、升级和替换。
## 二、背景与发展
机场开放架构的概念主要源于航空安全领域的需求。传统的机场安检系统高度依赖单一供应商的专有技术，存在以下问题：
- 不同厂商的设备之间缺乏数据和接口标准化，难以互联互通
- 系统升级和更换成本高昂，周期漫长
- 创新速度受限于单一供应商的研发节奏
- 安全威胁不断演变，但系统响应能力不足
为解决这些问题，美国 TSA 于 2023 年 8 月正式发布了《开放架构路线图》（Open Architecture Roadmap），明确了向开放架构转型的战略方向。同时，国际机场协会（ACI）也发布了《机场安全系统开放架构》文件（已更新至第二版，2023年8月），为全球机场提供了开放架构的定义和高层级要求，包括网络安全方面的规范。
## 三、主要特点与优势
| 特点 | 说明 |
|------|------|
| **互操作性** | 不同厂商的设备和软件可以通过标准化接口协同工作，打破供应商锁定 |
| **模块化设计** | 系统组件可以独立升级、替换或新增，无需整体更换 |
| **灵活性与可扩展性** | 机场可根据需求灵活选择最优组件，分阶段部署新设备 |
| **加速创新** | 开放竞争环境鼓励更多厂商参与，加快新技术的研发和应用 |
| **降低成本** | 减少对单一供应商的依赖，通过竞争降低采购和维护成本 |
| **提升安全性能** | 能够快速集成最新的威胁检测算法和技术，减少误报率 |
| **改善旅客体验** | 简化安检流程，缩短等待时间，提升通行效率 |
正如 ACI 所指出的：
> By adopting OA principles, airports can benefit from improved product warranty, integration, efficiency, extensibility, and flexibility in their security systems.
## 四、关键推动组织与标准
| 组织/标准 | 角色与贡献 |
|-----------|-----------|
| **TSA（美国运输安全管理局）** | 开放架构的主要推动者，发布了 OA 路线图，推动美国机场安检系统向开放架构转型 |
| **ACI（国际机场协会）** | 发布《机场安全系统开放架构》指南文件，为全球机场提供参考框架 |
| **SITA** | 全球领先的航空运输 IT 提供商，推动基于开放 API 的通用平台（Common Use），支持机场系统集成 |
| **DHS S&T（美国国土安全部科技局）** | 支持开放架构相关的研发项目，推动下一代安检成像技术的开放集成 |
| **Smiths Detection、Vanderlande 等设备商** | 积极响应开放架构理念，开发符合 OA 标准的安检和行李处理设备 |
## 五、主要应用场景
### 1. 安检系统
这是机场开放架构最核心的应用领域。通过 OA，机场可以：
- 将不同厂商的 X 光机、CT 扫描仪、人体扫描仪等设备集成到统一平台
- 独立升级威胁检测算法，而无需更换整套硬件
- 实现安检数据的标准化共享和分析
- TSA 已在美国多个机场开展开放架构试点项目，展示了不同厂商设备互操作的可行性
### 2. 旅客处理系统
SITA 推动的 Common Use 理念与开放架构密切相关：
- 基于开放 API 构建的通用旅客处理平台
- 支持自助值机、自助行李托运、生物识别通关等多种应用
- 不同航空公司可共享同一套设备和系统
### 3. 行李处理系统
Vanderlande 等厂商提出的开放软件架构方案：
- 行李分拣和追踪系统采用开放接口
- 支持与安检系统、航班信息系统的无缝对接
- 提高行李处理的可靠性和效率
### 4. 机场运营管理
- 基于开放架构的机场协同决策系统（A-CDM）
- 航班信息、资源分配、地面交通等数据的标准化集成
- 支持智慧机场的数字化转型
## 六、发展趋势
**标准化深化**：随着 TSA 路线图的推进和 ACI 指南的更新，开放架构的技术标准将更加完善和统一，覆盖更多机场子系统。
**全球推广**：从美国率先推动，逐步扩展到欧洲、亚太等地区的主要机场，成为全球机场建设和升级的主流方向。
**AI 与数据融合**：开放架构为人工智能算法的快速部署提供了基础，未来安检系统将更多地利用 AI 技术提升威胁识别能力。
**数字身份集成**：开放架构将支持物理和数字凭证的互认与互操作，推动无缝化旅客出行体验。
**网络安全强化**：随着系统开放程度的提高，网络安全将成为开放架构设计中的核心考量，ACI 的指南已将网络安全纳入高层级要求。
## 七、总结
机场开放架构是航空运输业数字化转型的重要方向，它通过采用标准化、模块化和可互操作的设计理念，打破了传统封闭系统的壁垒，为机场带来了更高的灵活性、更快的创新速度和更低的运营成本。在 TSA、ACI、SITA 等组织的共同推动下，机场开放架构正在从概念走向实践，有望在未来几年内深刻改变全球机场的技术生态。
---
**参考来源：**
- [TSA - What is Open Architecture?](https://www.tsa.gov/travel/frequently-asked-questions/what-open-architecture)
- [TSA - Open Architecture Roadmap (2023)](https://www.tsa.gov/sites/default/files/oa/_roadmap/_20230717/_508c-r1.pdf)
- [ACI - Open Architecture for Airport Security Systems (2nd Edition, 2023)](https://www.aci-europe.org/downloads/resources/TSA-230504-7/_4.1%20Attachment%201%20OA%20for%20Airport%20Security%20Systems%202nd%20Edition%20%20FINAL.pdf)
- [ACI Blog - Where Does Open Architecture Fit in Aviation Today?](https://blog.aci.aero/airport-it/where-does-open-architecture-fit-in-aviation-today/)
- [Smiths Detection - Moving towards Open Architecture](https://www.smithsdetection.com/insights/moving-towards-open-architecture/)
- [HSToday - How Open Architecture Can Enhance Airport Security](https://www.hstoday.us/subject-matter-areas/border-security/how-open-architecture-can-enhance-airport-security/)
airport-wiki/raw/articles/aodb-manus-2026.md
-288
View File
@@ -1,288 +0,0 @@
# 机场运维数据库 (AODB) 产品对比分析报告
**作者**: Manus AI
**时间**: 2026 年 4 月
**版本**: 2.0 (专业修订版)
---
## 目录
1. [执行摘要](#执行摘要)
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
3. [主流商业产品深度对比](#主流商业产品深度对比)
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
5. [报价与商业模式](#报价与商业模式)
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
8. [结论与建议](#结论与建议)
9. [参考文献](#参考文献)
---
## 执行摘要
机场运维数据库 (AODB, Airport Operational Database) 是现代机场运维的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理、分发和运维所有与航班运维相关的数据，为机场的协调决策提供实时数据支撑 [1]。
**当前市场现状**:
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多主要枢纽机场。
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
4. **技术升级要求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成已成为新一代 AODB 的核心特征 [5]。
**关键产品对比概览**:
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|------|------|------|---------|
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"认证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞥时刻表、云原生 | 全球 700+ 机场 [7] |
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
| **ADB Safegate** | Cortex AODB | Airside 4.0 只能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等等规模机场 [12] |
---
## AODB 概述与技术标准
### AODB 的定义与核心功能
机场运维数据库 (Airport Operational Database, AODB) 是机场运维的中枢数据仓库，负责集中存储、管理、分发和运维所有与航班运维相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运维数据，定义运维数据的关联关系和处理规则 [13]。
**核心功能模块**:
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、认证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
4. **费用与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或费用系统提供准确的原始凭证。
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
### 关键技术与数据交换标准
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
1. **AIDX (Aviation Information Data Exchange)**:
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运维数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
2. **SSIM (Standard Schedules Information Manual)**:
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
3. **传统报文标准**:
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
---
## 主流商业产品深度对比
### 1. SITA Operations Manager
**产品背景与定位**:
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
**核心技术特性**:
- **"最可信信源" (Most Confident Source) 引擎**: 不同于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运维（准点率、容量、环控指标）的动态优先级优化 [16]。
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS（不正常航班）的快速恢复。
**优劣势分析**:
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
### 2. Amadeus AODB
**产品背景与定位**:
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统冶地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
**核心技术特性**:
- **365天前瞥航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
**优劣势分析**:
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
### 3. Collins Aerospace AirDB (AirPlan)
**产品背景与定位**:
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
**核心技术特性**:
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
- **AirVue FIDS 原生协同**: 与市场领先的 AirVue 航显系统深度契合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
**优劣势分析**:
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施设施集成度高；界面现代化。
- **劣势**: 在亚太地区本地化支持团队相对较小。
### 4. ADB Safegate Cortex AODB
**产品背景与定位**:
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
**核心技术特性**:
- **空侧运维深度融合**: 不同于偏向航站楼的 AODB，Cortex 能够深度融合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
- **AI 资源优化**: 利用人工智能进行精准的资源分配和运维规划，支持"假设" (What-if) 场景模拟 [9]。
**优劣势分析**:
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
### 5. RESA INFOPAX AODB
**产品背景与定位**:
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
**核心技术特性**:
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
**优劣势分析**:
- **优势**: 实施快；成本效益高；移动端支持好。
- **劣势**: 应对超大型机场海量并发数据的能力未经认证。
---
## 产品技术架构与集成能力
### 现代 AODB 技术架构演进
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频率更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、费用规则解耦，支持独立扩展。
4. **展示与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
### A-CDM (机场协同决策) 集成
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运维效率 [19]。
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据跟踪，特别是：
- **TOBT (目标撤轮档时间)**: 接收地服或航司的更新。
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
---
## 报价与商业模式
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+运维"向 SaaS 订阅模式转变。
### 1. 传统许可费用模式 (On-Premise License)
适用于对数据绝对控制有要求的大型枢纽机场：
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
- **年度运维费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
### 2. SaaS 云订阅模式 (Cloud Subscription)
适用于中小型机场或寻求降低初期 CapEx 的机场：
- **实施与接入费**: 10 万 - 30 万美元。
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
---
## 中国市场现状与国产化替代
### 市场格局与政策导向
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
### 典型国产化案例：北京首都国际机场
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产到完全自主可控的"换心"手术。
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
- **解决方案**: 历时 14 个月，首都机场技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常运维工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
### 主要国内供应商
1. **中国民航信息集团 (TravelSky)**:
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
2. **万达信息股份有限公司**:
国内较早涉足机场信息化的上市公司。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运维管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
3. **中电科数字技术股份有限公司**:
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
---
## 选型指南与量化评估矩阵
### 选型量化评估矩阵
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|----------|------|--------------|--------------|
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商（如万达信息） |
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、运维费及定制开发费率 | RESA, 国内厂商 |
### 针对不同规模机场的建议
1. **超大型国际枢纽 (年客流 > 4000万)**:
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信息科）。
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
3. **中小型及支线机场 (年客流 < 1000万)**:
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
---
## 结论与建议
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是 一个被动的数据存储器，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的只能平台演进。
2. **云原生与 SaaS 成为主流**: 摆脱沉甸的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商迭代的主要方向。
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任一第三方系统无 对接。
---
## 参考文献
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
[20] 新浪财经. "喜报！中標民航机场建设"十四五"数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
[21] 国国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
[22] 上海市科学术委员会. "2024年上海市认定机构认定备案的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
airport-wiki/raw/articles/aodb.md
-285
View File
@@ -1,285 +0,0 @@
# 机场运行数据库 (AODB) 产品对比分析报告
**作者**: Manus AI
**时间**: 2026 年 4 月
**版本**: 2.0 (专业修订版)
---
## 目录
1. [执行摘要](#执行摘要)
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
3. [主流商业产品深度对比](#主流商业产品深度对比)
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
5. [报价与商业模式](#报价与商业模式)
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
8. [结论与建议](#结论与建议)
9. [参考文献](#参考文献)
---
## 执行摘要
机场运行数据库 (AODB, Airport Operational Database) 是现代机场运营的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理和分发航班、旅客、行李、资源等所有运营相关数据，为机场的协调决策提供实时数据支撑 [1]。
**当前市场现状**:
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多数主要枢纽机场。
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
4. **技术升级需求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成成为新一代 AODB 的核心特征 [5]。
**关键产品对比概览**:
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|------|------|------|---------|
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"验证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞻时刻表、云原生 | 全球 700+ 机场 [7] |
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
| **ADB Safegate** | Cortex AODB | Airside 4.0 智能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等规模机场 [12] |
---
## AODB 概述与技术标准
### AODB 的定义与核心功能
机场运行数据库 (Airport Operational Database, AODB) 是机场运营的中央数据仓库，负责集中存储、管理、分发和维护所有与航班运营相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运行数据，定义运行数据的关联关系和处理规则 [13]。
**核心功能模块**:
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、验证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
4. **计费与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或计费系统提供准确的原始凭证。
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
### 关键技术与数据交换标准
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
1. **AIDX (Aviation Information Data Exchange)**:
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运营数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
2. **SSIM (Standard Schedules Information Manual)**:
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
3. **传统报文标准**:
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
---
## 主流商业产品深度对比
### 1. SITA Operations Manager
**产品背景与定位**:
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
**核心技术特性**:
- **"最可信信源" (Most Confident Source) 引擎**: 区别于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运营（准点率、容量、环保指标）的动态优先级优化 [16]。
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS (不正常航班) 的快速恢复。
**优势与劣势**:
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
### 2. Amadeus AODB
**产品背景与定位**:
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统治地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
**核心技术特性**:
- **365 天前瞻航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
**优势与劣势**:
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
### 3. Collins Aerospace AirDB (AirPlan)
**产品背景与定位**:
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
**核心技术特性**:
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
- **AirVue FIDS 原生协同**: 与其市场领先的 AirVue 航显系统深度耦合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
**优势与劣势**:
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施集成度好；界面现代化。
- **劣势**: 在亚太地区本地化支持团队相对较小。
### 4. ADB Safegate Cortex AODB
**产品背景与定位**:
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
**核心技术特性**:
- **空侧运营深度融合**: 区别于偏向航站楼的 AODB，Cortex 能够深度整合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
- **AI 资源优化**: 利用人工智能进行准确的资源分配和运营规划，支持"假设" (What-if) 场景模拟 [9]。
**优势与劣势**:
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
### 5. RESA INFOPAX AODB
**产品背景与定位**:
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
**核心技术特性**:
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
**优势与劣势**:
- **优势**: 实施快；成本效益高；移动端支持好。
- **劣势**: 应对超大型机场海量并发数据的能力未经验证。
---
## 产品技术架构与集成能力
### 现代 AODB 技术架构演进
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、计费规则解耦，支持独立扩展。
4. **展现与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
### A-CDM (机场协同决策) 集成
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运营效率 [19]。
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据追踪，特别是：
- **TOBT (目标撤轮挡时间)**: 接收地服或航司的更新。
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
---
## 报价与商业模式
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+维保"向 SaaS 订阅模式转变。
### 1. 传统许可费模式 (On-Premise License)
适用于对数据绝对控制有要求的大型枢纽机场：
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
- **年度维保费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
### 2. SaaS 云订阅模式 (Cloud Subscription)
适用于中小型机场或寻求降低初期 CapEx 的机场：
- **实施与接入费**: 10 万 - 30 万美元。
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
---
## 中国市场现状与国产化替代
### 市场格局与政策导向
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
### 典型国产化案例：北京首都国际机场
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产品到完全自主可控的"换心"手术。
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
- **解决方案**: 历时 14 个月，首都机场信息技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常维护工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
### 主要国内供应商
1. **中国民航信息集团 (TravelSky)**:
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
2. **万达信息股份有限公司**:
国内较早涉足机场信息化的上市企业。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运营管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
3. **中电科数字技术股份有限公司**:
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
---
## 选型指南与量化评估矩阵
### 选型量化评估矩阵
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|----------|------|--------------|--------------|
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商 (如万达信息) |
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、维保费及定制开发费率 | RESA, 国内厂商 |
### 针对不同规模机场的建议
1. **超大型国际枢纽 (年客流 > 4000万)**:
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信科）。
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
3. **中小型及支线机场 (年客流 < 1000万)**:
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
---
## 结论与建议
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是一个被动的数据存储库，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的智能平台演进。
2. **云原生与 SaaS 成为主流**: 摆脱沉重的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商产品迭代的主要方向。
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任何第三方系统无缝对接。
---
## 参考文献
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
[20] 新浪财经. "喜报！中标民航机场建设“十五五”数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
[21] 国务院国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
[22] 上海市科学技术委员会. "2024年上海市认定机构认定报备的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
airport-wiki/raw/articles/daxing-airport-vertiv.md
-48
View File
@@ -1,48 +0,0 @@
# 北京大兴国际机场关键基础设施
来源：维谛技术（Vertiv）官网PDF（Case Study）
URL: https://www.vertiv.cn/4af62d/globalassets/documents/case-studies/trans_case_1_bdia_295354_0.pdf
## 项目概况
- 位置：北京市（天安门正南46公里）
- 投运时间：2019年9月
- 占地面积：140万平方米
- 定位：世界上规模最大单体航站楼
- 荣誉：2016年英国《卫报》"新世界七大奇迹"之首
## 智能化建设
- 建设19个平台、68个系统
- 统一运行信息数据平台
- 大数据分析整合
- 实现航班运行状态全面掌握
## 关键基础设施部署点
1. 信息中心
2. 西塔台
3. 空管核心工作区
4. 气象综合探测场二次雷达站
5. 华北空管生产运行中心
6. 北京终端管制中心
## 解决方案
**维谛技术（Vertiv）Liebert® PEX+ 系列机房专用精密空调**
- 超高效、高可靠性、高灵活性
- 全新模块化设计
- 高制冷量、高能效
- 全正面维护
- 灵活扩容（可增加制冷柜）
## 东方航空基地
东航核心机房大规模采用Vertiv方案：
- UPS系统
- 热管理系统
- 机柜
- SmartSolutions融合解决方案
范围：生活服务区、维修区、航空食品区、地面服务区、货运区
airport-wiki/raw/articles/dubai-airport-huawei-dc.md
-48
View File
@@ -1,48 +0,0 @@
# 迪拜机场 × 华为预制模块化数据中心
来源：华为官网PDF
URL: https://www.huawei.com/~/media/CORPORATE/PDF/case-studies/dubai-airports-cn.pdf
## 项目背景
迪拜机场面临的问题：
- 多个老旧数据中心，设备品牌众多、管理复杂
- 设备老化，制冷量不足
- 业务快速增长，需要快速扩容
## 解决方案
**华为 FusionModule1000B 预制模块化数据中心**
- 23个集装箱大小的预制模块
- 总功率：1MW
- 业务柜：100个，单柜 10kW/rack
- 建设周期：预计10个月（比传统数据中心节省近50%时间）
## 关键指标
| 指标 | 数值 |
|------|------|
| 等级 | Tier III 设计+建造双认证 |
| 可用性 | 99.98% |
| 年停机时间 | 1.6小时 |
| PUE | < 1.6（比传统数据中心节能30%+） |
| 建设周期 | 10个月 |
## 技术亮点
- 变频行级精密空调
- 高效模块化UPS
- 密闭通道设计
- NetEco 管理系统
## 业务覆盖
- 航班信息与机场运营
- 乘客运输与行李服务
- 连接与网络服务
- 安检、视频监控
- 企业业务运营、设施维护
## "DXB+"规划
预计未来10年旅客吞吐量从8360万增长到1.18亿。
airport-wiki/raw/articles/keydak-airport-expo-2025.md
-28
View File
@@ -1,28 +0,0 @@
# 2025国际机场博览会 — 风液融合算力解决方案
来源：Keydak金盾官网（2025-09-11）
URL: https://www.keydak.com/NEWS/news_100000063272748.html
## 展会信息
- 时间：2025年9月8-10日
- 地点：广州·中国进出口商品交易会展馆
- 主题：国际机场博览会
- 参展方：70多个国家、170多家机场
## 核心观点
### 智算中心散热挑战
- 传统数据中心单机柜：5-15kW
- 算力数据中心单机柜：50-120kW
- 传统风冷无法满足高功率服务器散热需求
### 风液融合解决方案参数
- 支持风冷：最高 40kW/柜
- 支持液冷：最高 150kW/柜
- 特点：风液同源、动态平衡、灵活部署、成本优化
### 价值
- 显著降低数据中心总体能耗和碳排放
- 契合"双碳"目标
- 适配AI算力密度持续上升趋势
airport-wiki/raw/articles/llm-wiki-v2-rohitg00.md
-99
View File
@@ -1,99 +0,0 @@
# LLM Wiki v2 — Comprehensive Summary
## Source
https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2
Author: rohitg00
Forked from: karpathy/llm-wiki.md
Last active: 2026-04-13
## Overview
A pattern for building personal knowledge bases using LLMs, extending Karpathy's original LLM Wiki idea with lessons from building agentmemory. Addresses what breaks at scale, what's missing, and what separates a useful wiki from one that rots.
---
## What the Original Gets Right
> **Stop re-deriving, start compiling.** RAG retrieves and forgets. A wiki accumulates and compounds.
- Three-layer architecture works: raw sources → wiki → schema
- Basic operations (ingest, query, lint) cover the basics
---
## Missing Layer: Memory Lifecycle
### Confidence Scoring
Every fact should carry a confidence score indicating:
- How many sources support it
- How recently it was confirmed
- Whether anything contradicts it
### Supersession
When new information contradicts existing claims:
- Old claim explicitly superseded, not just noted
- Linked and timestamped
- Old version preserved but marked stale
### Forgetting
- Wikis that never forget become noisy
- Implement a retention curve based on Ebbinghaus's forgetting curve
- Architecture decisions decay slowly. Transient bugs decay fast.
### Consolidation Tiers
| Tier | Description | Characteristics |
|------|-------------|------------------|
| Working memory | Recent observations | Not yet processed |
| Episodic memory | Session summaries | Compressed from raw |
| Semantic memory | Cross-session facts | Consolidated from episodes |
| Procedural memory | Workflows and patterns | Extracted from repeated semantics |
---
## Beyond Flat Pages: Knowledge Graph
### Entity Extraction
Extract structured entities: People, projects, libraries, concepts, files, decisions
### Typed Relationships
Not all connections are equal: uses, depends_on, contradicts, caused, fixed, supersedes
### Graph Traversal for Queries
Instead of keyword search: walk outward through typed edges to find all related nodes.
---
## Search That Actually Scales
### When index.md Breaks
Works up to ~100-200 pages. Beyond that, becomes too long for LLM.
### Hybrid Search Architecture
| Stream | Catches | Method |
|--------|---------|--------|
| BM25 | Exact terms | Keyword matching |
| Vector search | Semantic similarity | Embeddings |
| Graph traversal | Structural connections | Entity-aware relationship walking |
---
## Automation: Event-Driven Operations
| Event | Action |
|-------|--------|
| On new source | Auto-ingest, extract entities, update graph, update index |
| On session start | Load relevant context based on recent activity |
| On session end | Compress session into observations, file insights |
| On query | Check if answer is worth filing back (quality score > threshold) |
| On memory write | Check for contradictions, trigger supersession |
| On schedule | Periodic lint, consolidation, retention decay |
---
## Quality and Self-Correction
### Score Everything
Every piece of LLM-generated content gets a quality score based on structure, citations, wikilink density, length, and fact consistency.
airport-wiki/raw/articles/manus-future-airport-info-center-2026.md
-94
View File
@@ -1,94 +0,0 @@
# 未来机场信息中心（Future Airport Info Center）研究报告
**作者：Manus AI**
**日期：2026年4月10日**
## 1. 引言与概念定义
随着全球航空客运量的持续增长与旅客期望的不断提升，传统的机场信息服务台正在经历深刻的数字化转型。未来机场信息中心（Future Airport Info Center）不再仅仅是一个提供航班时刻表和简单指引的物理服务台，而是演变为一个高度集成、数据驱动且以旅客为中心的智能交互枢纽。
未来机场信息中心的核心概念在于"连接智能"（Connected Intelligence），它将物理基础设施、数字系统（如机场运营数据库 AODB、资源管理系统 RMS）与前沿技术（如人工智能、数字孪生、生物识别）深度融合，旨在为旅客提供无缝、个性化且无障碍的出行体验，同时大幅提升机场的运营效率与安全裕度。
## 2. 核心技术趋势
### 2.1 人工智能与智能体（Agentic AI）
人工智能已从简单的规则问答演进为具备自主决策能力的智能体（Agentic AI）。在信息中心场景下，AI 驱动的虚拟助手（Virtual Assistants）和多语言聊天机器人能够通过自然语言处理（NLP）与旅客进行流畅互动，提供实时的航班动态、行李追踪、个性化零售推荐以及动态寻路服务。此外，AI 还能根据实时客流密度自动调整航站楼内的环境参数（如温湿度、照明），并优化信息屏幕的显示内容。
### 2.2 数字孪生（Digital Twins）
数字孪生技术为机场物理环境创建了高精度的虚拟副本。通过接入物联网（IoT）传感器数据，信息中心能够实时监控航站楼内的运行状态。这种技术不仅用于预测性维护，还能在旅客服务端发挥巨大作用——例如，通过模拟客流瓶颈，提前调度资源或通过数字标牌引导旅客避开拥堵区域，实现全局的容量与流量优化。
### 2.3 生物识别与数字身份（Biometrics & Digital Identity）
"无接触"与"无缝通行"是未来机场的重要标志。生物识别技术（如面部识别）正与旅客信息系统深度绑定。旅客在信息中心或自助终端（Kiosks）进行一次身份验证后，其数字身份即可在安检、登机、免税店购物等全流程中通行无阻（即"出行一张脸"）。这种"生物识别走廊"（Biometric Corridors）极大地减少了排队时间，提升了通行效率。
### 2.4 智能运控平台（AOCC & IOC）
在后台，信息中心依托于强大的机场运行控制中心（AOCC）或综合运营中心（IOC）。例如，华为推出的机场智能运控中心解决方案，基于 5G、云计算和大数据底座，打破了传统系统的"数据孤岛"，实现了航班流、旅客流和行李流的统一调度与全景可视（"运行一张图"）。
## 3. 市场规模与行业前景
| 细分市场 | 2024/2025年估值 | 2030/2034年预测估值 | 复合年增长率 (CAGR) | 核心驱动因素 |
| :--- | :--- | :--- | :--- | :--- |
| **机场信息系统** | 约 37 - 42 亿美元 | 约 51 - 53.6 亿美元 | 3.5% - 4.0% | 运营效率需求、网络安全升级、旅客体验优化 |
| **智能机场整体市场** | 约 66.1 亿美元 (2025) | 约 108.3 亿美元 (2030) | 10.36% | AI、物联网、数字孪生技术的全面普及 |
| **机场运营控制中心 (AOCC)** | 约 18.38 亿美元 (2026) | 约 40.5 亿美元 (2034) | 10.38% | 实时数据整合、跨部门协同需求 |
数据表明，尽管基础信息系统的增长相对平稳，但涉及智能控制、自动化与高级旅客信息交互的细分领域（如 AOCC 和智能机场整体解决方案）正以两位数的惊人速度增长。
## 4. 典型项目与实践案例
### 4.1 纽约肯尼迪国际机场（JFK）新航站楼项目
在 2026 年即将投入使用的 JFK 6 号航站楼（Terminal 6）和新一号航站楼（New Terminal One）中，航空技术巨头 SITA 联合其收购的意大利设计公司 CCM，打造了全新的旅客信息中心。该项目打破了传统 IT 系统与建筑设计的界限，将数字标牌、智能寻路系统与高端家具设计无缝集成。信息中心不仅提供 ADA（美国残疾人法案）合规的无障碍服务，还通过沉浸式设计提升了旅客的情感体验。
### 4.2 罗马菲乌米奇诺机场（ADR）AI 虚拟助手
2025 年底，罗马机场（Aeroporti di Roma）引入了由生成式 AI 驱动的虚拟助手。该系统能够通过文本或语音与旅客自然交互，提供从停车、地面交通到实时航班状态、行李追踪的全方位个性化支持，显著提升了信息获取的便捷性。
### 4.3 匹兹堡国际机场（PIT）通用设计认证
2026 年 2 月，匹兹堡国际机场成为全球首个获得"通用设计"（Universal Design）认证的机场。其信息中心与航站楼设计深度融合了包容性理念，采用了直观的数字寻路系统、高可见度的信息显示屏以及适应不同身体条件旅客的交互终端，确保所有旅客（包括老年人和残障人士）都能平等、顺畅地获取信息。
### 4.4 新加坡樟宜机场与 SITA 体验中心
作为智慧机场的标杆，樟宜机场在 T5 航站楼的规划中全面拥抱 100% 无接触服务。同时，SITA 在新加坡设立了全新的体验中心，集中展示了未来机场信息处理的最新技术，包括生物识别、数字身份和 AI 驱动的旅客处理系统，为亚太地区的机场数字化转型提供了示范。
## 5. 设计理念与发展方向
1. **从"客户体验"到"人类体验"（Human-Centered Design）**：未来的信息中心设计将更加关注旅客的情感与心理需求。通过将冰冷的技术隐藏在温暖的建筑与家具设计中（如 SITA-CCM 的实践），减轻旅客的旅行焦虑。同时，通用设计（Universal Design）将成为标配，确保信息系统对所有人群的无障碍访问。
2. **数据驱动的超级个性化（Hyper-Personalization）**：借助 AI 和大数据，信息中心将从"被动响应"转向"主动服务"。系统能够根据旅客的行程、偏好甚至实时位置，通过移动端或附近的数字标牌推送定制化的餐饮优惠、登机提醒或最优步行路线。
3. **可持续性与绿色运营（Sustainability）**：信息中心的硬件设施（如自助终端、显示屏）将采用更环保的材料与低能耗技术。同时，通过数字孪生与 AI 优化航站楼的能源消耗，信息中心将成为机场实现净零排放（Net Zero）目标的重要辅助节点。
## 6. 面临的挑战
- **遗留系统整合（Legacy Systems Integration）**：许多机场仍依赖老旧的 IT 架构，打破数据孤岛、实现新旧系统的无缝对接是一项成本高昂且复杂的工程。
- **网络安全与数据隐私（Cybersecurity & Data Privacy）**：随着生物识别和实时数据的广泛应用，机场面临的勒索软件、数据泄露等网络攻击风险急剧增加。如何在提供便利的同时确保旅客隐私安全，是行业亟待解决的核心问题。
## 7. 结论
未来机场信息中心正在经历一场由 AI、数字孪生和生物识别技术驱动的深刻变革。它将不再是一个孤立的服务节点，而是深度融入机场整体智能生态的交互中枢。通过融合人性化设计、无障碍理念与强大的后台数据处理能力，未来的信息中心将重新定义航空出行的标准，为旅客带来更加智能、高效且充满温度的旅程。
---
## 参考文献
[1] Vantage Airport Group. (2025). Redefining Airport Operations, With Passengers at the Center.
[2] ACI. (2026). The Airport of the Future Runs on Connected Intelligence.
[3] McKinsey & Company. (2025). Smart airports: Clearing the runway for digital takeoff.
[4] IBM. (2026). Building the intelligent airport of the future.
[5] OAG. (2025). AI Returns to the Runway: Three Innovations Redefining Airline Tech.
[6] Virtual Workforce. (2026). AI assistant for airports: AI-powered airport support.
[7] Cisco. (2026). Soaring to New Heights: How AI is Redefining the Airport.
[8] Bentley Systems. Digital Twins for Passenger Experience.
[9] David McMullen. (2026). Airport Tech Trends 2026: AI, Digital Twins, Biometrics.
[10] Biometric Update. (2026). Biometric Corridors – an end to airport queues?
[11] SITA. (2025). Passenger IT insights 2025 | Passenger Experience trends.
[12] Huawei. (2025). Huawei Launches Five Aviation Solutions to Accelerate Intelligence.
[13] TAV Technologies. (2026). Airport Operations Control Center Market Size, Share [2034].
[14] Fortune Business Insights. (2026). Airport Information Systems Market Size, Trends.
[15] MarketsandMarkets. (2025). Airport Information Systems Market Report 2024 - 2030.
[16] Mordor Intelligence. (2025). Smart Airport Market Size & Share Analysis.
[17] Fortune Business Insights. (2026). AOCC Market Report.
airport-wiki/raw/articles/上海市-智算中心建设导则2025版-2025-01.md
-142
View File
@@ -1,142 +0,0 @@
# 上海市智算中心建设导则（2025年版）
**来源**: 上海市经济和信息化委员会
**日期**: 2025年1月
**URL**: https://www.sheitc.org.cn/uploadfile/20250114/20250114144347_3158.pdf
**性质**: 地方标准/建设指导文件（具有强制执行力）
---
## 选址分区要求
| 区域 | 范围 | 政策 |
|------|------|------|
| **适建区** | 外环以外 | 优先，既有工业区、发电厂区优先 |
| **禁止区** | 中环以内 | 不得新建智算中心 |
| **限制区** | 中环与外环之间 | 严格限制 |
| **边缘智算** | 靠近应用场景 | 不受分区限制 |
## 核心规模指标
### 大型智算中心
```
平均机架设计功率: ≥ 12kW
机架设计总功率: ≥ 24 MW
```
### 边缘智算中心
```
平均机架设计功率: ≥ 6kW
机架设计总功率: ≤ 1.2 MW
基准PUE: ≤ 1.4
```
## PUE能效指标
| 指标类型 | 准入值 | 先进值 | 长三角集群 |
|----------|--------|--------|------------|
| **基准PUE** | ≤ 1.25 | — | — |
| **综合PUE** | ≤ 1.22 | ≤ 1.18 | ≤ 1.20 |
## 选址关键要求
| 要求类型 | 具体指标 |
|----------|----------|
| **供电** | 靠近110kV及以上等级且配置冗余度高的电源点；宜引入一类市电；市电平均每月停电次数 ≤ 1次；平均每次故障时间 ≤ 0.5小时 |
| **网络** | 靠近干线通信线路；宜具备三路由及以上接入条件 |
| **水源** | 直线距离300米范围有水源；宜从两个独立水源各自引入一路供水 |
| **安全距离** | 地铁/铁路 ≥ 100m；加油站/加气站 ≥ 400m；一级石油库 ≥ 500m |
| **水灾** | 新建智算中心首层建筑完成面宜高出当地洪水百年重现期水位线1.0m以上 |
## 建筑与配套设施
### 液冷要求
- **新建智算中心宜采用液冷技术**满足高密算力散热需求（强制表述）
- 空调制冷设备应选用配置**变频、变容量冷却设备**
- 制冷剂ODP=0且GWP较低
### 机架要求
- 设计功率12kW以上机架宜采用就近的供配电部署方式
- 强电、弱电、光纤、铜缆宜分别布线
## AI基础设施架构
### AI服务器类型
| 类型 | 核心要求 |
|------|----------|
| **AI训练服务器** | 支持至少一种深度学习/机器学习训练框架；能执行至少一种场景模型训练（CV、NLP、语音等） |
| **AI推理服务器** | 支持至少一种深度学习/机器学习推理框架；能执行至少一种场景模型推理 |
### 存储设备要求
- 支持AI全生命周期数据存储
- 支持元数据管理、数据分层管理
- 支持对象存储、文件存储和块存储
- **宜支持RDMA技术**，实现高聚合带宽
- 应具备冗余存储能力，支持容量扩展
### 网络设备要求
- 应采用**智能无损网络**等新技术
- 大规模训练应用场景下，应采用智能无损网络
- 宜具备高速网络连接（**200Gbps计算网**）
### 平台层要求
**算力调度**:
- 应提供算力、网络等资源**虚拟化和池化**能力
- 应支持**异构芯片资源精细化管理**（负载感知、拓扑感知、算力切分）
**推理精度支持**: FP32、FP16、INT4、INT8
**存储性能**: 毫秒级延时、百万级IOPS
## 上架率要求
> 同一主体或相关主体前期批复数据中心/智算中心项目**两年内IT设备上架率达到75%及以上**的，给予支持
| 阶段 | IT设备上架率(Rackon) | 平均机架运行功率(Prack) |
|------|----------------------|------------------------|
| 第一年 | ≥ 50% | ≥ 设计功率的50% |
| 第二年及以后 | ≥ 70% | ≥ 设计功率的70% |
## 监测指标
| 指标 | 第一年 | 第二年及以后 |
|------|--------|--------------|
| **Rackon** | ≥ 50% | ≥ 70% |
| **PUE综合** | ≤ 1.32 | ≤ 1.22 |
| **WUE** | ≤ 2.2 L/kWh | ≤ 2.0 L/kWh |
| **CUE** | ≤ 1.2 gCO2/kWh | ≤ 1.0 gCO2/kWh |
## 绿电与清洁能源要求
| 区域 | 绿电占比要求 |
|------|-------------|
| 一般区域 | 宜 ≥ 30% |
| **长三角集群** | 应 > 80% |
**必须采用的绿色技术（至少1种）**:
- 园区风电
- 分布式光伏发电（安装面积 ≥ 建筑屋顶面积的50%）
- 余热回收利用
- 工业废弃能源利用
- 分布式储能
## 能效等级目标
- 绿色节能等级：宜达到GB/T 43331中**第五级**要求
- 绿色数据中心等级：宜达到DB31/T 1395中**AAAAA（5A）级**要求
---
## 技术备注
- 本导则为目前国内最详尽的智算中心建设地方标准之一
- 核心创新：**液冷强制化**（"宜采用"液冷=实质推进方向）、**PUE分级管控**、**异构算力虚拟化**
- 对机场智算中心建设最具参考价值：选址分区、机架功率密度门槛、RDMA网络要求
airport-wiki/raw/articles/中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md
-96
View File
@@ -1,96 +0,0 @@
# 工业智算发展研究报告（2025年）
**来源**: 中国工业互联网研究院
**日期**: 2026年1月8日发布
**URL**: https://www.china-aii.com/u/cms/www/202601/工业智算发展研究报告（2025年）.pdf
**性质**: 行业研究报告（官方研究机构）
---
## 核心定义
**工业智算**: 通过大规模异构算力资源（CPU、GPU、DPU、NPU、FPGA、ASIC等），为工业智能终端、工业网络智能控制、工业智能边缘计算、工业智能化应用提供所需算力、数据、算法和模型，实现**"云-边-端"一体化融合智能计算**。
## 全球算力格局（2025年8月）
```
美国: 68.9%
中国: 14.5%
欧洲: 6.1%
日本: 1.2%
其他: 9.3%
```
## 我国工业智算市场规模
| 指标 | 2024年 | 2025年(预计) | 2026年(预计) | 2028年(预计) |
|------|--------|--------------|--------------|--------------|
| **智算规模** | 725.3 EFLOPS | 1,037.3 EFLOPS (+43%) | 1,460.3 EFLOPS (+40.8%) | 2,781.9 EFLOPS |
| **智算市场** | 1,325亿元 | 1,806亿元 (+36.2%) | 2,350亿元 (+30.1%) | — |
| **工业智算占比** | 30%+ | 35%+ | 40%+ | 50%+ |
## 基础设施现状
| 指标 | 数值 |
|------|------|
| 在用算力中心机架 | 1,085万标准机架 |
| 国家算力枢纽节点省市机架占比 | 72.6% |
| 智能算力规模 | 788 EFLOPS |
| 液冷技术渗透率 | 64% |
| 平均PUE | 1.42（目标<1.2） |
| 工业大数据市场规模 | 2024年1,200亿元 → 2025年底约1,600亿元 |
## 美欧发展策略对比
### 美国: "资本+技术"双轮驱动
- 2025年1月: "星际之门"项目启动，4年内投资**5,000亿美元**
- 2025年7月: 发布《美国人工智能行动计划》
- 2025年11月: "创世纪计划"行政令，整合17个国家实验室超级算力
- NIST投入2,000万美元建立制造业AI中心（联邦承诺7,000万美元/五年期）
### 欧盟: "政策+协同"牵引
- 2025年2月: "投资人工智能"计划，筹集**2,000亿欧元**
- 2025年4月: "人工智能大陆行动计划"
- 液冷渗透率: 42%
## 典型企业产品（国产替代）
| 企业 | 产品/技术 | 规格/突破 |
|------|-----------|-----------|
| **华为** | 昇腾910 | 云边端一体AI芯片 |
| **寒武纪** | 云边端一体AI芯片 | 全场景覆盖 |
| **英维克** | 冷板式液冷系统 | 单机柜功率密度24kW，散热效率提升40% |
| **中科曙光** | 浸没式液冷系统 | PUE低至1.04，年减碳量超万吨 |
| **新华三** | 800G国芯智算交换机 | 支持10万卡集群组网 |
| **中际旭创** | 1.6T光模块 | 全球首发 |
| **长电科技** | HBM4封装技术 | 带宽达1TB/s |
## 典型行业案例
### 汽车制造
- 奥迪中国工厂AI焊点质量控制: 每班150万个焊点全量分析
- 吉利星睿智算中心: 3.54PFlops算力，累计1.2万次虚拟碰撞试验，研发仿真计算效率提升30%
### 航空航天
- 中国商飞FuncGenFoil翼型生成设计: 设计误差降低74.4%，多样性提升23.2%
### 工业机器人
- 在役工业机器人突破**200万台**，2024年新增29.5万台（全球新安装量54%）
## 智算中心分布
```
大型智算中心(>1000P): 20% → 京津冀、长三角、珠三角
中型智算中心(300-1000P): 70% → 一线、新一线及二线城市
小型智算中心(<100P): 10% → 二线及以下城市
```
---
## 技术备注
- 本报告为工业智算领域的权威官方报告
- 机场智算中心属于"工业智算"应用场景之一，但本报告未专门覆盖机场行业
- 国产液冷企业（英维克、中科曙光）的技术参数对机场项目有直接参考价值
airport-wiki/raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md
-106
View File
@@ -1,106 +0,0 @@
# 2025年中国AIDC产业发展白皮书：智算中心如何撑起大模型时代的蓝图？
**来源**: 头豹研究院（LeadLeo）
**日期**: 2025年7月
**URL**: https://pdf.dfcfw.com/pdf/H3_AP202507101706460530_1.pdf
**性质**: 商业研究白皮书
---
## 核心发现
| 维度 | 关键发现 |
|------|----------|
| 市场导向 | 从性能为王转向业务场景适配：金融/医疗用70B，文档用7B，边缘用1.5B |
| 竞争格局 | 差异化竞争：百度"云智一体"、阿里"MaaS开源生态"、火山"应用反哺技术" |
| 算力结构 | 2023年全球智算力达875EFLOPS，首次超基础算力；中美合计超七成 |
| 制冷革新 | GPU功耗激增，液冷成PUE<1.10核心路径，传统风冷进入结构性瓶颈 |
## GPU芯片演进
| 架构 | 型号 | FP16算力 | 显存带宽 | NVLink带宽 | 功耗 |
|------|------|----------|----------|------------|------|
| Ampere | A100 | 312T | 2TB/s | 600GB/s | 400W |
| Hopper | H100 | 1P | 3.35TB/s | 900GB/s | 700W |
| Hopper | H200 | 1P | 4.8TB/s | 900GB/s | 700W |
| Blackwell | B100 | 1.75P | 8TB/s | 1.8TB/s | 1,000W |
| Blackwell | B200 | 2.25P | 8TB/s | 1.8TB/s | 1,200W |
| Blackwell | **GB200** | **5P** | **16TB/s** | **3.6TB/s** | **2,700W** |
## 服务器功耗趋势
| 型号 | GPU算力 | GPU功耗 | 总功耗 |
|------|---------|---------|--------|
| HGX A100 | 2.4P | 3.2kW | 6.5kW |
| HGX H100 | 8P | 5.6kW | 10.2kW |
| HGX B100 | 14P | 5.6kW | 10.2kW |
| HGX B200 | 18P | 8kW | **14.3kW** |
**结论**: 单机柜功率密度急剧攀升，液冷已成必然选择
## 千卡集群(H100)前期投入
| 组成 | 费用 |
|------|------|
| 算力设备 | 约3亿元 |
| 网络设备 | 约2,500万元 |
| 存储/安全 | 约1,000万元 |
| 平台软件/液冷改造 | 约1,000万元 |
| **总计** | **约3.5亿元** |
**年运营支出**: 约5,000万元
## 能耗结构
```
IT设备: 67%
制冷系统: 27%
供电系统: 5%
照明及其他: 1%
```
## 制冷技术PUE对比
| 冷却方式 | PUE范围 | 适用场景 |
|----------|---------|----------|
| **液冷(相变浸没式)** | 1.00 | >30kW/机柜，高性能场景 |
| **液冷(冷板式)** | ~1.10 | 高密度智算中心 |
| **自然冷(间接蒸发冷)** | 1.10-1.20 | 北方气候区 |
| **冷冻水系统** | 1.30+ | 传统数据中心 |
| **风冷** | 1.40+ | 面临淘汰 |
## 大模型训练资源消耗
| 模型 | 参数量 | GPU规模 | 训练时长 |
|------|--------|---------|----------|
| LLaMA-1 | 65.2B | 2,028块 | 90天 |
| LLaMA-3 | 405B | 16,384块H100 | 54天 |
**关键**: 预训练消耗90-99%总算力，微调仅占1-10%
## PD分离技术
| 阶段 | 特征 | 资源瓶颈 | 优化策略 |
|------|------|----------|----------|
| **Prefill** | 并行处理所有输入token | GPU计算能力 | 批处理、张量并行 |
| **Decode** | 逐个自回归生成 | 内存带宽和延迟 | KV缓存、Flash Attention |
**关键发现**: Prefill与Decode存在高达**137倍**速度差距，Decode耗时占99%以上
## 中国厂商差异化路线
| 厂商 | 战略定位 | 核心路径 |
|------|----------|----------|
| 百度智能云 | "云智一体" | 全栈自研，B端标杆案例 |
| 阿里云 | MaaS基础设施 | 公有云标准化服务 |
| 火山引擎 | 应用反哺技术 | 豆包先服务抖音/头条，再输出B端 |
| 科大讯飞 | 行业垂直整合 | 教育/医疗/司法/政务 |
| DeepSeek | 非对称竞争 | 极致性价比，开源顶尖模型 |
---
## 技术备注
- 本白皮书数据详实，GPU/服务器功耗演进数据极具参考价值
- GB200 NVL72整机柜方案（2,700W功耗）对机场智算中心选址和供配电设计有直接指导意义
- "千卡集群3.5亿元"投入数据可作为机场项目预算参考基准
airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md
-1166
View File
File diff suppressed because it is too large Load Diff
airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md
-285
View File
@@ -1,285 +0,0 @@
# 机场运行数据库 (AODB) 产品对比分析报告
**作者**: Manus AI
**时间**: 2026 年 4 月
**版本**: 2.0 (专业修订版)
---
## 目录
1. [执行摘要](#执行摘要)
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
3. [主流商业产品深度对比](#主流商业产品深度对比)
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
5. [报价与商业模式](#报价与商业模式)
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
8. [结论与建议](#结论与建议)
9. [参考文献](#参考文献)
---
## 执行摘要
机场运行数据库 (AODB, Airport Operational Database) 是现代机场运营的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理和分发航班、旅客、行李、资源等所有运营相关数据，为机场的协调决策提供实时数据支撑 [1]。
**当前市场现状**:
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多数主要枢纽机场。
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
4. **技术升级需求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成成为新一代 AODB 的核心特征 [5]。
**关键产品对比概览**:
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|------|------|------|---------|
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"验证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞻时刻表、云原生 | 全球 700+ 机场 [7] |
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
| **ADB Safegate** | Cortex AODB | Airside 4.0 智能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等规模机场 [12] |
---
## AODB 概述与技术标准
### AODB 的定义与核心功能
机场运行数据库 (Airport Operational Database, AODB) 是机场运营的中央数据仓库，负责集中存储、管理、分发和维护所有与航班运营相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运行数据，定义运行数据的关联关系和处理规则 [13]。
**核心功能模块**:
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、验证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
4. **计费与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或计费系统提供准确的原始凭证。
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
### 关键技术与数据交换标准
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
1. **AIDX (Aviation Information Data Exchange)**:
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运营数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
2. **SSIM (Standard Schedules Information Manual)**:
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
3. **传统报文标准**:
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
---
## 主流商业产品深度对比
### 1. SITA Operations Manager
**产品背景与定位**:
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
**核心技术特性**:
- **"最可信信源" (Most Confident Source) 引擎**: 区别于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运营（准点率、容量、环保指标）的动态优先级优化 [16]。
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS (不正常航班) 的快速恢复。
**优势与劣势**:
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
### 2. Amadeus AODB
**产品背景与定位**:
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统治地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
**核心技术特性**:
- **365 天前瞻航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
**优势与劣势**:
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
### 3. Collins Aerospace AirDB (AirPlan)
**产品背景与定位**:
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
**核心技术特性**:
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
- **AirVue FIDS 原生协同**: 与其市场领先的 AirVue 航显系统深度耦合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
**优势与劣势**:
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施集成度好；界面现代化。
- **劣势**: 在亚太地区本地化支持团队相对较小。
### 4. ADB Safegate Cortex AODB
**产品背景与定位**:
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
**核心技术特性**:
- **空侧运营深度融合**: 区别于偏向航站楼的 AODB，Cortex 能够深度整合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
- **AI 资源优化**: 利用人工智能进行准确的资源分配和运营规划，支持"假设" (What-if) 场景模拟 [9]。
**优势与劣势**:
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
### 5. RESA INFOPAX AODB
**产品背景与定位**:
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
**核心技术特性**:
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
**优势与劣势**:
- **优势**: 实施快；成本效益高；移动端支持好。
- **劣势**: 应对超大型机场海量并发数据的能力未经验证。
---
## 产品技术架构与集成能力
### 现代 AODB 技术架构演进
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、计费规则解耦，支持独立扩展。
4. **展现与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
### A-CDM (机场协同决策) 集成
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运营效率 [19]。
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据追踪，特别是：
- **TOBT (目标撤轮挡时间)**: 接收地服或航司的更新。
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
---
## 报价与商业模式
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+维保"向 SaaS 订阅模式转变。
### 1. 传统许可费模式 (On-Premise License)
适用于对数据绝对控制有要求的大型枢纽机场：
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
- **年度维保费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
### 2. SaaS 云订阅模式 (Cloud Subscription)
适用于中小型机场或寻求降低初期 CapEx 的机场：
- **实施与接入费**: 10 万 - 30 万美元。
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
---
## 中国市场现状与国产化替代
### 市场格局与政策导向
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
### 典型国产化案例：北京首都国际机场
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产品到完全自主可控的"换心"手术。
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
- **解决方案**: 历时 14 个月，首都机场信息技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常维护工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
### 主要国内供应商
1. **中国民航信息集团 (TravelSky)**:
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
2. **万达信息股份有限公司**:
国内较早涉足机场信息化的上市企业。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运营管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
3. **中电科数字技术股份有限公司**:
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
---
## 选型指南与量化评估矩阵
### 选型量化评估矩阵
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|----------|------|--------------|--------------|
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商 (如万达信息) |
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、维保费及定制开发费率 | RESA, 国内厂商 |
### 针对不同规模机场的建议
1. **超大型国际枢纽 (年客流 > 4000万)**:
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信科）。
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
3. **中小型及支线机场 (年客流 < 1000万)**:
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
---
## 结论与建议
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是一个被动的数据存储库，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的智能平台演进。
2. **云原生与 SaaS 成为主流**: 摆脱沉重的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商产品迭代的主要方向。
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任何第三方系统无缝对接。
---
## 参考文献
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
[20] 新浪财经. "喜报！中标民航机场建设“十五五”数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
[21] 国务院国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
[22] 上海市科学技术委员会. "2024年上海市认定机构认定报备的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
airport-wiki/raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md
-77
View File
@@ -1,77 +0,0 @@
# 深圳机场：数智化水平位居全国42家千万级机场第二名
**来源**: 深圳新闻网
**日期**: 2026-01-15
**URL**: https://www.sznews.com/news/content/2026-01/15/content_31905100.htm
---
## 核心成就
- **全国排名**: 42家千万级机场综合评价**第二名**（民航局《千万级机场智慧民航建设综合评价报告2024》）
- **大模型**: 率先完成DeepSeek R1-671B满血版千亿参数大模型全栈本地化部署（华为昇腾算力集群）
- **国际货邮**: 2025年首次突破100万吨
- **航班放行正常率**: 91.19%
## AI基础设施
### 算力底座
- **硬件**: 华为昇腾算力服务器与工具平台
- **模型**: DeepSeek R1-671B（满血版）——千亿参数大模型
- **数据整合**: 打通航班运行、物流服务、设备物联日志等**18类**核心业务数据壁垒
- **特点**: 国产算力集群支撑该级别大模型落地，业内首批
### 智能体矩阵（10余个业务专属智能体）
| 智能体 | 功能 |
|--------|------|
| AI安全助手 | 融合1,500余份安全文档，检索效率提升60倍 |
| AI乘机助手 | 中英文交互、对话式咨询，秒级响应 |
| AI采购助手 | 采购流程智能化 |
| AI财务助手 | 财务工作自动化 |
| 党务工作小助手 | 党务工作辅助 |
| iHR人力智能体 | 人力资源管理 |
| AI公文助手 | 公文处理智能化 |
## 全场景落地应用
### 旅客服务
- **机位智能分配**: 每日航班分配耗时从4小时压缩至**1分钟**，靠桥率提升至**85.44%**
- **"小黄蜂"配送机器人**: 卫星厅38个登机口餐饮直达
- **旅客自弃物品回收机器人**: 全国首个，日均收集禁限带物品**25公斤**
- **AI翻译设备**: 支持100余种语言实时翻译，信息录入时间缩短**80%**
### 航空物流
- **深畅国际货站**: AGV机器人+智能卡口，全国首个24小时智慧远程监管货站
- 进出口货物库内停留时间分别缩短**82%**、**33%**
- **快件中心**: "机械臂+单件分离器+六面扫描仪"三合一全自动作业
- **无人驾驶牵引车**: 无人接驳7×24小时不间断
- **巡逻监管机器人**: 海关查验平台货物自动收取、园区智能巡逻
### 安全运行
- **AI辅助判图**: 三维图像深度学习，精准识别锂电池/充电宝/刀具/打火机，安检效率提升**30%以上**
- **一体化主动运控**: 多源数据融合+AI，提前**20分钟**精准预判保障节点，航班正常率提升约**4个百分点**
### 综合交通
- **"综合交通全域一张图"**: AI实时分析人流/车流/道路，处置响应时间稳定控制在**1分钟以内**（获第二届"兴智杯"全国人工智能创新应用大赛一等奖）
- **全国首个网约车全链条管理体系**: AI智能调度，服务车次超**854万**、旅客约**1,276万**，地面交通服务测评指标全国第一
## 创新机制
- **"揭榜挂帅"机制**: 第六届深圳人工智能展发布9个特色项目榜单，吸引17家企业参与
- **国企民企协同**: 联合华为、腾讯共建"未来机场数字化平台"，联动哈工大产学研
- **统一架构底座**: "一次开发、复用共享"
- **"1+2+N"创新制度体系**: 制度设计→落地执行→资源保障→激励约束
---
## 技术备注
- DeepSeek R1-671B在华为昇腾集群上的部署细节（集群规模、互联网络）未披露
- 深圳机场未披露具体服务器数量和功率密度
- 液冷技术未提及，可能仍在建设智算中心基础设施层面
airport-wiki/raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md
-60
View File
@@ -1,60 +0,0 @@
# 15000P算力+年产值可超1.5亿！福州长乐机场综保区人工智能智算中心全速推进
**来源**: 福建省商务厅
**日期**: 2026-01-22
**URL**: https://swt.fujian.gov.cn/xxgk/jgzn/jgcs/zsxdc/tzdt/202601/t20260122_7084250.htm
---
## 核心数据
| 参数 | 数值 |
|------|------|
| **总投资** | 11亿元（一期3.3亿元） |
| **用地面积** | 33,347平方米（50.02亩） |
| **规划算力** | 15,000P |
| **预计投产** | 2026年10月 |
| **年营收目标** | 超1.5亿元 |
| **年税收目标** | 超1,000万元 |
## 建设进度
- **2025年7月**: 完成工程勘察、施工图审查、设备进场
- **2025年9月**: 正式启动装机和土建施工
- **2026年6月**: 主体建筑封顶
- **2026年6-10月**: 设备安装、系统集成、全流程调试
- **2026年10月**: 验收合格后正式投产
## 技术方案
### 核心架构
- **液冷机柜矩阵**：规模化智算液冷机柜（具体机柜数未披露）
- **网络存储机柜阵列**：体系化网络存储机柜阵列
- **AI服务器**：搭载国际领先的高性能AI服务器（型号未披露）
### 二期规划（算力服务器及推理一体机生产线）
- 高性能人工智能服务器及边缘/云端推理一体机的设计、组装与制造
- "研发测试-生产制造-部署应用"产业闭环
## 选址优势
- **位置**：福州滨海新城临空经济区，综保一路东侧、综保三街南侧
- **政策红利**：长乐机场综保区多重政策优势
- **区位**：依托空港保税优势，深化闽港、闽台数字协作
- **辐射**：填补东南沿海高端智算缺口，赋能华南地区数字化转型
## 主体信息
- **投资方**: 福建智算方舟科技有限公司
- **主营业务**: 智算中心投资运营、高性能服务器及推理一体机研发生产销售
- **定位**: 全栈式算力解决方案提供商
---
## 技术备注
- 项目处于在建状态，核心硬件配置（GPU型号/数量、机柜功率密度）未披露
- 液冷技术类型（冷板/浸没）未明确
- "国际领先高性能AI服务器"表述模糊，疑为NVIDIA HGX系列或国产品牌
airport-wiki/raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md
-50
View File
@@ -1,50 +0,0 @@
# 郑州航空港何以竞逐"人工智能之城"？
**来源**: 中国新闻网
**日期**: 2026-03-05
**URL**: https://www.zzhkgq.gov.cn/2026/03-05/3632175.html
---
## 核心数据
- **当前算力**: 10,000P（中部最大、国内领先的万卡算力集群）
- **规划总规模**: 超过 100,000P（三中心：训练/推理/推训一体）
- **DeepSeek部署**: 2025年1月全量接入DeepSeek-R1，中部首个全面部署DeepSeek的智算中心
- **配套投资**: 总投资1.2亿元的AI+智能人才公共实训基地（2025年11月揭牌）
## 关键内容
### 河南空港智算中心定位
该中心是港区智算产业的"智慧大脑"，分三板块规划：
1. **一中心**：主攻高端训练算力
2. **二中心**：聚焦推理算力
3. **三中心**：面向未来规划十万卡推训一体算力集群
### 区位优势
- 2小时高铁圈覆盖国内4亿人口
- 2小时航空圈覆盖全国90%的人口和市场
- 郑州新郑国际机场2025年货邮吞吐量首破100万吨（全国第五、中部首个"百万吨级"航空货运枢纽）
- 郑州航空港区2025年外贸进出口总值4,935亿元，占河南全省52.7%
### 产业生态
- **龙头企业**：富士康（灯塔工厂）、超聚变（先进计算）、科大讯飞（产业生态基地）、联想
- **万亿级电子信息产业集群**：2024年产值近6,000亿元，占河南全省八成，从"芯"到"屏"到"端"全产业链
### 应用场景
- 富士康灯塔工厂：AGV无人车、AI质检（毫米级精度）、5G全连接"熄灯生产"
- 河南省医学科学院：多模态智慧远程医疗平台，覆盖全省县级医疗机构
- "心晴少年"AI心理健康大模型：3所学校落地，惠及1.4万学生
- "空地一体"智联协同系统：无人机+机器狗+自动驾驶巡检车网格化管理
---
## 技术备注
- 来源标注为"中国新闻网"，原文含大量产业生态描述，核心智算中心技术参数有限
- 10,000P算力具体硬件配置（GPU型号、机柜数、功率）未披露
- 三个板块分期建设，三中心"十万卡"仍为规划阶段
airport-wiki/systems-design/aodb-system-architecture.md
-758
View File
@@ -1,758 +0,0 @@
---
title: AODB 系统架构设计文档
created: 2026-04-13
updated: 2026-04-13
type: system-design
tags: [aodb, system-design, architecture, ddd, acdm]
sources: [参考: aodb-core, aodb-vendors, flight-data-exchange, a-cdm]
---
# AODB 系统架构设计文档
> **项目代号**: AeroCore AODB
> **设计依据**: 参考 SITA Operations Manager、Amadeus AODB、ADB SAFEGATE Cortex、AirportLabs SkyCore 等商用系统，结合 IATA A-CDM Toolkit 2025、IATA AIDX v22.1、SSIM 第36版标准
> **架构风格**: DDD（领域驱动设计）+ 事件驱动 + 微服务架构（可拆分为单体或微服务部署）
> **目标定位**: 对标商用 AODB（年旅客量 1000万~4000万级别），具备 A-CDM 全链路、SSIM/AIDX 原生支持、多源融合、AI 辅助决策能力
---
## 一、设计目标与验收标准
### 1.1 核心能力目标
| 能力维度 | 目标 | 对标商用系统 |
|---------|------|------------|
| 航班数据管理 | 全生命周期覆盖（计划→执飞→历史） | Amadeus AODB |
| A-CDM Milestone | 16项里程碑全自动触发 | SITA Operations Manager |
| SSIM 解析 | 第36版格式全字段解析 | IATA SSIM 标准 |
| AIDX XML 引擎 | v22.1 全消息类型支持 | IATA AIDX 标准 |
| 多源融合 | 最多支持 8 路数据源优先判定 | ADB SAFEGATE Cortex |
| VTT 预测 | 基于历史数据的 EXOT/EXIT ML 预测 | ADB SAFEGATE VTT |
| What-if 仿真 | 配置变更方案评估 | ADB SAFEGATE "What-if" |
| 高可用 | 99.99% 可用性（4个9） | Collins AirDB |
| 响应延迟 | API P99 < 200ms，事件推送 < 2s | PDC Aviation |
### 1.2 非功能目标
- **水平扩展**: 无状态服务层，存储层按需扩容，支持航班量 10x 增长
- **多租户**: 支持单机场 + 多机场集团模式，数据隔离
- **国产化**: 适配国产芯片（鲲鹏/飞腾）、国产数据库（GaussDB/达梦）、国产操作系统（麒麟/统信）
- **国际化**: 字符编码 UTF-8，支持 IATA Airport Code（3字母）、ICAO Code（4字母）双码制
- **合规**: 满足等保2.0三级、民航局 MH/T 5103-2020 标准
---
## 二、系统架构概览
### 2.1 四层架构总览
```
┌──────────────────────────────────────────────────────────────────────┐
│ 接入层（Access Layer） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Web Console │ │ Mobile App │ │ 第三方API │ │ 报文网关 │ │
│ │ (运营控制) │ │ (移动操作) │ │ (REST/GraphQL)│ │ (SSIM/AIDX) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ 网关层（Gateway Layer） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ API Gateway │ │ 消息网关 │ │ 规则引擎 │ │
│ │ (认证/限流) │ │ (AIDX/SSIM) │ │ (业务规则) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ 核心服务层（Core Services） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Flight Domain│ │ Resource │ │ A-CDM │ │ Billing │ │
│ │ 航班领域服务 │ │ Domain │ │ 协同服务 │ │ Domain │ │
│ │ │ │ 资源领域服务 │ │ │ │ 计费领域 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Messaging │ │ AI Engine │ │ Simulation │ │ Reference │ │
│ │ 消息交换服务 │ │ AI推理引擎 │ │ What-if仿真 │ │ Data │ │
│ │ │ │ (VTT/预测) │ │ │ │ 参考数据 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ 数据层（Data Layer） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PostgreSQL │ │ Redis │ │ Kafka │ │ TimescaleDB │ │
│ │ 主数据存储 │ │ 热缓存/会话 │ │ 事件总线 │ │ 时序数据 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ MinIO/S3 │ │ Elasticsearch│ │ SQLite │ │
│ │ 文件存储 │ │ 日志检索 │ │ 嵌入式测试 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
```
### 2.2 技术选型
| 层级 | 组件 | 选型理由 | 备选 |
|------|------|---------|------|
| 主数据存储 | **PostgreSQL 16+** | ACID 强一致、JSONB 支持 GIS、时序插件、分区表 | GaussDB, 达梦 |
| 缓存/会话 | **Redis Cluster** | 集群模式、高并发缓存、Redis Streams 事件驱动 | |
| 消息总线 | **Apache Kafka** | 事件溯源、多消费者、 Exactly-once 语义 | RocketMQ |
| 时序分析 | **TimescaleDB** | 基于 PG 的时序扩展，航班历史趋势分析 | InfluxDB |
| 全文检索 | **Elasticsearch** | 日志分析、航班号/乘客名搜索 | |
| 文件存储 | **MinIO** | S3 兼容、国产化支持 | 华为 OBS |
| 搜索框 | **Blazor WebAssembly** | 运营控制台，技术栈统一 | React/Vue |
| 移动端 | **Flutter** | iOS/Android 双端，Low-code 表单 | |
| API 网关 | **Kong/Apache APISIX** | 开源、可插拔插件、mTLS | |
| 服务网格 | **Istio**（可选） | 微服务治理、流量管理、mTLS | |
| 容器平台 | **Kubernetes** | 可移植性、国产化（麒麟/达梦） | |
---
## 三、DDD 领域划分
### 3.1 限界上下文（Bounded Contexts）
```
┌─────────────────────────────────────────────────────────────────┐
│ AeroCore AODB │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
│ │ Flight │ │ Resource │ │ Operations │ │ Billing │ │
│ │ Context │ │ Context │ │ Context │ │ Context │ │
│ │ │ │ │ │ │ │ │ │
│ │ - 航班计划 │ │ - 登机口 │ │ - A-CDM │ │ - 账单 │ │
│ │ - 航班动态 │ │ - 机位 │ │ - Milestone │ │ - 发票 │ │
│ │ - 机型机号 │ │ - 行李转盘 │ │ - PDS │ │ - 结算 │ │
│ │ - 旅客数据 │ │ - 设备 │ │ - VTT │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ └──────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Messaging │ │ Reference │ │ Integration│ │
│ │ Context │ │ Context │ │ Context │ │
│ │ │ │ │ │ │ │
│ │ - SSIM解析 │ │ - 机场基础 │ │ - AIDX引擎 │ │
│ │ - AIDX处理 │ │ - 航司数据 │ │ - 第三方API │ │
│ │ - 报文路由 │ │ - 机型字典 │ │ - Webhook │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Shared Kernel │ │
│ │ AirportCode(IATA/ICAO) | Time(UTC) | FlightNumber | Event │ │
│ └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
### 3.2 各领域核心实体
#### Flight Context（航班上下文）
```
Flight（航班聚合根）
├── FlightId (UUID, 业务ID)
├── FlightNumber (CA1234, 航司码+数字)
├── OperationalSuffix (A/B, 同一日重复航班)
├── AircraftId → Aircraft (实体)
├── AirlineId → Airline (实体)
├── OriginAirport (IATACode, 值对象)
├── DestinationAirport (IATACode, 值对象)
├── ServiceType (J/C/F/P/M, 值对象)
├── OperationalStatus (OP/NOP/DV/DX/RT/GRT/SQ, 枚举)
│
├── Legs: List<FlightLeg> (去程/回程, 聚合内实体)
│ └── FlightLeg
│ ├── LegIdentifier: UFI (唯一航班标识, 值对象)
│ ├── LegData
│ │ ├── ScheduledTimes (计划时间, SCT)
│ │ ├── EstimatedTimes (预计时间, EST)
│ │ ├── ActualTimes (实际时间, ACT)
│ │ ├── PaxCount (旅客数)
│ │ └── AircraftInfo (机型/注册号/尾号)
│ └── Resources: List<AssignedResource>
│
├── Milestones: List<FlightMilestone> (16项里程碑, 值对象集合)
│ └── FlightMilestone
│ ├── Code (ELDT/ALDT/EOBT/AOBT/TOBT/TSAT/TTOT/ATOT/CTOT/EXOT/EIBT/EXIT/AIBT/ATIGT/TTIGT/COBT)
│ ├── Time (时间戳)
│ ├── Source (来源系统)
│ ├── Provenance (数据溯源, 枚举: IATA_AIDX/SITA/ATC/_HANDLER)
│ └── Confirmed (是否已确认)
│
└── Domains Events
├── FlightCreatedEvent
├── FlightStatusChangedEvent
├── MilestoneUpdatedEvent
└── FlightCancelledEvent
```
#### Resource Context（资源上下文）
```
Gate（登机口聚合根）
├── GateId
├── IATACode (A1, B12)
├── TerminalId → Terminal
├── GateType (Domestic/International/Transfer)
├── ContactInfo (对讲机频道等)
└── CurrentAssignment → FlightLeg? (当前绑定航班)
Stand（机位聚合根）
├── StandId
├── IATACode (B12, 远机位编号)
├── TerminalId
├── StandType (Narrow/Wide/Heavy)
├── MaxAircraftSize (ICAO Wake Turbulence Category)
└── Equipment (400Hz/Pre-conditioned Air/jetway等)
BaggageCarousel（行李转盘）
├── CarouselId
├── IATACode (C1, 物理转盘编号)
├── TerminalId
├── CarouselType (Arrival/Departure)
└── CurrentAssignment → FlightLeg?
```
#### Operations Context（运营协同上下文）
```
ACDMCollaborativeSession（A-CDM 协同会话聚合根）
├── SessionId
├── AirportCode (IATA, 值对象)
├── Date (UTC 日期)
├── CDMPhase (PRE_DEPARTURE/INBOUND/ABNORMAL)
├── Participants (Set<Participant>, 航司/管制/服务商)
│
├── PreDeparturesequencing: List<PDSEntry>
│ └── PDSEntry
│ ├── Position (起飞序列位置)
│ ├── FlightLegId → FlightLeg
│ ├── CTOT (ATFM 分配)
│ ├── TSAT (目标启动许可时间)
│ ├── EXOT (预计滑出时间)
│ └── ConstraintViolation (违反约束列表)
│
├── VTTModel: VTTPredictor (滑行时间预测模型)
│ ├── HistoricalAverage
│ ├── TimeOfDayFactor
│ ├── WeatherFactor
│ └── TrafficFactor
│
└── Domain Events
├── SequencingUpdatedEvent
└── TTOTChangedEvent
```
---
## 四、核心模块详细设计
### 4.1 消息交换引擎（Messaging Engine）
#### 模块职责
- 接收并解析 SSIM 批次文件，构建航班季节性计划
- 接收并解析 AIDX XML 实时报文，更新航班动态
- 多源数据优先判定：同一时间字段出现多源冲突时，执行优先级裁定
- 事件发布：解析结果发布为领域事件，供下游服务消费
#### AIDX 处理流水线
```
AIDX XML Message (HTTP/SMTP/SFTP)
│
▼
┌───────────────────┐
│ Schema Validation│ ← XSD v22.1 校验 + 自定义规则
│ (javax.xml.bind) │
└───────────────────┘
│
▼
┌───────────────────┐
│ UFI 去重检查 │ ← 同一 UFI 30min 内去重
│ (Redis Cache) │
└───────────────────┘
│
▼
┌───────────────────┐
│ 多源优先判定 │ ← 配置优先表（见下表）
│ (Priority Engine) │
└───────────────────┘
│
▼
┌───────────────────┐
│ Flight Aggregate │ ← 更新聚合根 + 持久化
│ (JPA + Events) │
└───────────────────┘
│
▼
┌───────────────────┐
│ 发布领域事件 │ ← Kafka Topic: flight-events
│ (Domain Events) │
└───────────────────┘
```
#### 多源数据优先判定表
| 里程碑字段 | 第一优先 | 第二优先 | 第三优先 | 第四优先 |
|-----------|---------|---------|---------|---------|
| ALDT（实际落地） | ANSP（管制雷达） | 泊位传感器（Docking） | AODB 推算 | 航司报告 |
| AOBT（实际推出） | 地面服务商（GHD） | 登机口操作员 | 航司 | AODB |
| ATOT（实际起飞） | ANSP（塔台） | 跑道传感器 | AODB | 航司 |
| TOBT（目标推出） | 航司（空班） | 地面服务商 | AODB 计算 | |
| ELDT（预计落地） | NMOC（欧洲） | ANSP | 航司 FMS | AODB 推算 |
| EXOT（预计滑出） | AODB VTT 模型 | 历史均值 | 固定值 |
| EXIT（预计滑入） | AODB VTT 模型 | 历史均值 | 固定值 |
#### SSIM 解析器
- 支持 SSIM Chapter 6（SCR 报文）/ Chapter 7（SSR 报文）
- 批次导入模式：文件上传 → 后台任务解析 → 逐条入库 → 批量确认
- 冲突检测：同一航班号+日期出现多条，以 `Action Code` 判定（N=新增/C=变更/D=删除）
- 历史归档：SSIM 数据存入 TimescaleDB，供长期趋势分析
### 4.2 A-CDM 协同引擎
#### Milestone 管理
```
航班生命周期中16项里程碑全部由系统自动触发/接收：
ELDT ──[估算]──→ ALDT ──[实际]──┐
│
EOBT ──[计划]──→ AOBT ──[实际]──┤──→ TOBT ──[目标]──→ TSAT ──[许可]──→ TTOT ──[目标]──┐
│ │
COBT ←──[CTOT计算]── CTOT ──────┘ │
│
EIBT ──[预计靠桥]────────────────────────────┐ │
EXIT │
AIBT ──[实际靠桥]────────────────────────────┘ │
ATIGT │
TTIGT ──[目标靠桥]──────────────────────────────┘
触发规则：
- ACT（实际）类里程碑：收到 AIDX 报文中的 Actual Time → 自动写入
- EST（预计）类里程碑：AODB VTT 模块持续计算更新（每60秒重算）
- SCT（计划）类里程碑：来自 SSIM 导入或航班创建时写入
- TTIGT：基于 EXIT + 标准靠桥时间（按机型/机位计算）
```
#### PDS（Pre-Departure Sequencer）算法
```
输入：
- CTOT（来自 ATFM/NMOC）
- 管制离港率（Departure Rate, 架次/小时）
- TOBT 列表（各航班目标推出时间）
- 机位-跑道距离（Stand to Runway Matrix）
- VTT 预测值（EXOT）
- 约束条件（最小间隔、航司优先级、特殊航班）
输出：
- TSAT（目标启动许可时间）
- 起飞序列（PDS Entry List）
- COBT（计算推出时间）
算法：改进版 Shortest Processing Time（SPT）+ 约束满足
1. 按 TTOT 升序排列候选航班
2. 对每架航班，计算 earliest_start = max(TOBT, CTOT - EXOT - taxi_time)
3. 插入序列，检查与前机尾随间隔（Wake Turbulence分离）
4. 若违反约束，触发重排（re-sequencing）
5. 输出最终 TSAT 和序列位置
```
#### VTT（Variable Taxi-Time）预测
```
模型类型：梯度提升回归（XGBoost），特征包括：
特征维度（24维）：
- time_of_day（小时，周期性编码）
- day_of_week（周一～周日）
- month（季节性）
- runway_config（跑道运行模式：独立进/独立出/混合）
- qty_departures（当前离港队列长度）
- qty_arrivals（当前进港队列长度）
- visibility（能见度：CAT I/II/III 或 VFR/IFR）
- wind_speed / wind_dir（风速/风向）
- temperature（温度）
- precipitation（降水：是/否）
- visibility_meters（能见度，米）
- historical_avg_EXIT / EXOT（同小时历史均值）
- airport_load_level（机场负载等级：低/中/高/饱和）
预测输出：
- EXOT（Expected Taxi-Out Time）：预计滑出时间
- EXIT（Expected Taxi-In Time）：预计滑入时间
- EIBT（Expected In-Block Time）：预计靠桥时间 = ELDT + EXIT
重算策略：
- 正常情况：每 60 秒批量重算所有活跃航班
- 事件触发：收到 AOBT/ALDT/天气变化 → 立即重算相关航班
- 模型更新：每日使用前30天历史数据重训练
```
### 4.3 What-if 仿真模块
#### 功能定位
对标 ADB SAFEGATE Cortex 的 "What-if" 仿真能力，支持运营场景假设分析。
#### 仿真场景
| 场景 | 输入 | 模拟输出 |
|------|------|---------|
| 跑道关闭 | 关闭跑道号、开始时间、持续时长 | 各航班 CTOT/TSAT 变化、延误传播链 |
| 大面积延误 | 延误航班数量、延误量级 | 受影响航班列表、恢复时间估算 |
| 临时增加航班 | 新航班时刻表 | 资源冲突告警（机位/登机口/设备）|
| 极端天气 | 天气类型、持续时间、能见度 | VTT 重算结果、对离港率影响 |
| 资源调配 | 临时调整机位分配 | 新 TSAT 序列、旅客连接影响 |
#### 技术实现
```
What-if Scenario 创建 → 快照当前状态（Flight/Resource/A-CDM）
→ 应用假设变更（ScenarioMutation）
→ 在独立 Simulation Sandbox 中运行 VTT + PDS 算法
→ 生成对比报告（与基线偏差）
→ 可选：发布为正式变更（Commit）或丢弃（Discard）
```
### 4.4 AI 决策辅助模块
#### 能力矩阵
| 能力 | 算法 | 输入 | 输出 |
|------|------|------|------|
| VTT 滑行时间预测 | XGBoost | 天气/流量/时间 | EXOT/EXIT 预测值 |
| 过站时间预测 | LSTM | 历史过站数据/天气/机型 | 预计过站时长 |
| 延误链传播分析 | 图神经网络 | 航班衔接关系 | 受影响航班列表 |
| 异常预警 | 孤立森林 | 全量实时数据流 | 异常事件告警 |
| 资源冲突预测 | 约束求解+RL | 资源分配状态 | 冲突概率/建议调整 |
---
## 五、API 设计
### 5.1 REST API 概览
```
API Version Prefix: /api/v1
认证: OAuth 2.0 (JWT Bearer Token)
内容类型: application/json
字符编码: UTF-8
时间格式: ISO 8601 UTC (2026-04-13T14:30:00Z)
```
#### 核心资源
| 资源 | 路径 | 说明 |
|------|------|------|
| Flight | `/flights` | 航班 CRUD |
| Flight Leg | `/flights/{flightId}/legs` | 航段管理 |
| Milestone | `/flights/{flightId}/milestones` | 里程碑管理 |
| Gate | `/gates` | 登机口管理 |
| Stand | `/stands` | 机位管理 |
| Carousel | `/carousels` | 行李转盘 |
| PDS Sequence | `/pds/sequences` | 起飞排序 |
| TOBT | `/tobt` | 目标推出时间上报 |
| SSIM Import | `/imports/ssim` | SSIM 文件上传 |
| AIDX Webhook | `/webhooks/aidx` | AIDX 消息接收 |
| Simulation | `/simulations` | What-if 仿真 |
| Reports | `/reports` | 运营报告 |
#### 关键 API 设计示例
**TOBT 上报（航司/地面服务商）**
```
POST /api/v1/tobt
{
"flightLeg": {
"airline": "CA",
"flightNumber": "1234",
"originDate": "2026-04-13",
"departureAirport": "PEK"
},
"tobt": "2026-04-13T14:30:00Z",
"reason": "PASSENGER_BOARDING_COMPLETE",
"submittedBy": "HANDLER_CA_PEK",
"submittedAt": "2026-04-13T14:00:00Z"
}
响应 200:
{
"tobt": "2026-04-13T14:30:00Z",
"tsat": "2026-04-13T14:35:00Z", // AODB 基于 TSAT=TTOT-EXOT 重算
"revision": 3,
"status": "CONFIRMED"
}
```
**航班动态查询（支持过滤条件）**
```
GET /api/v1/flights?date=2026-04-13&airport=PEK&status=OP,DX,DV&page=0&size=50
响应 200:
{
"content": [
{
"flightId": "f-uuid-001",
"flightNumber": "CA1234",
"operationalStatus": "OP",
"currentLeg": {
"departureAirport": "PEK",
"arrivalAirport": "PVG",
"etd": "2026-04-13T14:30:00Z",
"eta": "2026-04-13T15:45:00Z",
"stand": "B12",
"gate": "A12",
"carousel": "C5"
},
"milestones": {
"ELDT": { "time": "2026-04-13T15:40:00Z", "confirmed": true },
"TOBT": { "time": "2026-04-13T14:30:00Z", "confirmed": true },
"TSAT": { "time": "2026-04-13T14:35:00Z", "confirmed": false }
}
}
],
"totalElements": 842,
"page": 0,
"size": 50
}
```
### 5.2 事件订阅（Webhook / Kafka）
```
外部系统可通过 Webhook 订阅 AODB 事件：
POST /api/v1/webhooks
{
"name": "FIDS系统订阅",
"url": "https://fids.airport.com/webhook/aodb",
"events": [
"flight.created",
"flight.status_changed",
"flight.milestone_updated",
"flight.gate_assigned",
"pds.sequencing_updated"
],
"secret": "whsec_xxxxx",
"active": true
}
签名机制: HMAC-SHA256(RequestBody, secret) → X-Signature 头
```
---
## 六、数据模型设计
### 6.1 核心实体 ER 图（简化）
```
Airport (1) ──< (N) Terminal (1) ──< (N) Gate
│
├──< (N) Stand
│
└──< (N) BaggageCarousel
Airline (1) ──< (N) Flight
│
└──< (N) Aircraft
Flight (1) ──< (N) FlightLeg
│
├──< (N) FlightMilestone
├──< (N) AircraftAssignment
└──< (N) Pax (旅客数据)
FlightLeg (N) ──> (1) Gate (可选)
FlightLeg (N) ──> (1) Stand (可选)
FlightLeg (N) ──> (1) BaggageCarousel (可选)
ACDM_Session (1) ──< (N) PDS_Entry
│
└──< VTT_Model (滑行时间预测)
```
### 6.2 关键索引设计
```sql
-- 航班唯一查询（UFI 组合索引）
CREATE UNIQUE INDEX idx_flight_leg_ufi
ON flight_legs (airline_code, flight_number, departure_airport, origin_date);
-- 航班日计划查询（高频）
CREATE INDEX idx_flight_leg_date
ON flight_legs (origin_date, departure_airport, operational_status)
WHERE origin_date >= CURRENT_DATE;
-- 里程碑查询（按航班+时间范围）
CREATE INDEX idx_milestone_flight_code
ON flight_milestones (flight_leg_id, milestone_code, event_time);
-- 资源当前分配（实时查找）
CREATE INDEX idx_stand_current
ON stand_assignments (stand_id, actual_off_blocks)
WHERE actual_on_blocks IS NULL;
-- 时序数据（TimescaleDB hypertable）
CREATE MATERIALIZED VIEW v_flight_punctuality
WITH (timescaledb.continuous) AS
SELECT time_bucket('5 min', event_time) AS ts,
airport_code,
count(*) FILTER (WHERE abs(ATOT - TTOT) > 900) AS delayed_count,
avg(extract(EPOCH FROM (ATOT - TTOT))) FILTER (WHERE ATOT IS NOT NULL) AS avg_delay_seconds
FROM flight_milestones
WHERE milestone_code = 'ATOT'
GROUP BY ts, airport_code;
```
---
## 七、安全与运维体系
### 7.1 零信任安全架构
```
安全原则：
1. 最小权限（Least Privilege）：每个微服务仅拥有完成其任务所需的最低权限
2. 默认拒绝（Default Deny）：未明确授权的请求一律拒绝
3. 永不信任（Never Trust）：所有跨服务调用均需验证 JWT，即使在内部网络
4. 始终加密（Always Encrypt）：传输加密（mTLS）+ 存储加密（AES-256）
认证体系：
- 用户认证：OAuth 2.0 + OpenID Connect（支持 SAML 2.0 企业 SSO）
- 机器认证：mTLS（服务间）+ API Key（第三方系统）
- 多因素认证：TOTP（运营人员）+ 证书（管制系统）
权限模型：RBAC + ABAC 混合
- RBAC：角色（Airport Admin / Airline Ops / Ground Handler / ATC / Viewer）
- ABAC：属性（机场代码 × 可操作资源范围 × 时间窗口）
```
### 7.2 审计日志
```sql
-- 审计日志表（防篡改）
CREATE TABLE audit_log (
id BIGSERIAL PRIMARY KEY,
event_id UUID NOT NULL DEFAULT gen_random_uuid(),
timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),
actor_id VARCHAR(64) NOT NULL, -- user_id 或 system_id
actor_type VARCHAR(16) NOT NULL, -- USER / SYSTEM / EXTERNAL
action VARCHAR(64) NOT NULL, -- flight.update / gate.assign
resource JSONB NOT NULL, -- 受影响的资源快照
changes JSONB, -- 变更前后差异（Before/After）
ip_address INET,
user_agent TEXT,
request_id UUID, -- 关联 HTTP 请求
integrity TEXT GENERATED ALWAYS AS (encode(sha256((event_id||timestamp||actor_id||action||resource)::text::bytea), 'hex')) STORED
);
-- 审计日志不可直接 DELETE/UPDATE（用 DB RULE 拦截）
CREATE RULE audit_log_no_delete AS ON DELETE TO audit_log DO INSTEAD NOTHING;
CREATE RULE audit_log_no_update AS ON UPDATE TO audit_log DO INSTEAD NOTHING;
```
### 7.3 高可用架构
```
部署模式：主动-待机双活（Active-Active 或 Active-Standby 可配置）
┌──────────────────┐ ┌──────────────────┐
│ AZ-1（主） │ │ AZ-2（备） │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ K8s Node 1 │◄┼─────┼─►│ K8s Node 3 │ │
│ └────────────┘ │ │ └────────────┘ │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ K8s Node 2 │◄┼─────┼─►│ K8s Node 4 │ │
│ └────────────┘ │ │ └────────────┘ │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ PG Primary │ │ ←───│──│ PG Standby │ │
│ └────────────┘ │ 同步 │ └────────────┘ │
└──────────────────┘ └──────────────────┘
│ │
└─────────┬───────────────┘
▼
┌────────────────┐
│ MinIO S3 │ (跨 AZ 复制)
└────────────────┘
RTO（恢复时间目标）: < 30 秒（自动故障转移）
RPO（恢复点目标）: < 1 分钟（同步复制）
```
---
## 八、部署与运维
### 8.1 Kubernetes 部署结构
```
namespace: aerocore-aodb
├── ConfigMap: aodb-config（环境配置）
├── Secret: aodb-secrets（数据库密码/证书）
├── Ingress: aodb-ingress（域名 + TLS）
│
├── Deployment: aodb-api（无状态服务，3+ 副本）
├── Deployment: aodb-message-engine（AIDX/SSIM 处理，2 副本）
├── Deployment: aodb-acdm-engine（A-CDM/PDS，2 副本）
├── Deployment: aodb-vtt-predictor（AI 推理服务，GPU 节点）
├── Deployment: aodb-simulation（What-if 仿真，按需扩缩）
├── Deployment: aodb-scheduler（Cron 任务，SSIM 导入等）
│
├── StatefulSet: postgresql（主从，1 副本）
├── StatefulSet: redis（集群模式，3 副本）
├── StatefulSet: kafka（3 副本）
└── DaemonSet: log-collector（Fluent Bit → Elasticsearch）
```
### 8.2 国产化适配清单
| 组件层 | 商业版 | 国产化替代 |
|-------|-------|-----------|
| 操作系统 | RHEL/Ubuntu | 麒麟 Kylin OS、统信 UOS |
| 数据库 | PostgreSQL | 华为 GaussDB、达梦 DM8 |
| 缓存 | Redis | 华为云 DCS（Redis 兼容）|
| 消息队列 | Apache Kafka | 华为云 DMS、Apache RocketMQ |
| 对象存储 | MinIO/S3 | 华为云 OBS、阿里云 OSS |
| 容器平台 | Kubernetes | 麒麟容器云、阿里云 ACK |
| 网关 | Kong | Apache APISIX（国产分支）|
---
## 九、模块开发优先级
### Phase 1（MVP，3个月）
| 模块 | 产出 |
|------|------|
| Flight Context（核心） | 航班 CRUD、实体、REST API |
| Messaging Engine（简化版）| AIDX XML 解析 + SSIM 解析 |
| Reference Data | 机场/航司/机型基础数据 |
| 基础安全 | JWT 认证、RBAC |
### Phase 2（6个月）
| 模块 | 产出 |
|------|------|
| A-CDM Engine | 16项 Milestone 追踪、PDS 算法 |
| Resource Context | Gate/Stand/Carousel 分配 |
| VTT 预测 | XGBoost EXOT/EXIT 预测 |
| 多租户 | 多机场数据隔离 |
### Phase 3（9个月）
| 模块 | 产出 |
|------|------|
| What-if 仿真 | 场景编辑器 + 沙箱引擎 |
| AI 决策辅助 | 延误传播图分析、异常预警 |
| 完整审计日志 | 防篡改审计链 |
| 高可用部署 | K8s 容器化、双活架构 |
---
## 十、已知局限与待验证项
1. **VTT 模型精度**：需要至少 6 个月历史数据才能达到商用精度（< 5min MAE）
2. **AIDX 全消息类型**：当前优先实现 `FlightLegNotifRQ/RS`，其他类型（AIDX-PAX、AIDX-BAG）后续迭代
3. **PDS 算法**：当前为规则驱动，Phase 3 考虑引入 RL 优化序列
4. **国产数据库兼容性**：GaussDB/达梦的 PG 兼容模式需实测验证
5. **多机场模式**：共享基础设施的多机场部署方案 Phase 2 再详细设计
airport-wiki/机场智算中心技术方案.md
-1205
View File
File diff suppressed because it is too large Load Diff
airport-wiki/机场航班数据管理运营方案.md
-463
View File
@@ -1,463 +0,0 @@
---
title: 机场航班数据管理运营技术方案
created: 2026-04-08
updated: 2026-04-10
type: solution
tags: [solution, aodb, a-cdm, smgcs, bhs, flight-data]
sources: [IATA A-CDM Toolkit 2025, SSIM 第36版, adb safegate/Amadeus/Assaia 2025官方资料]
---
# 机场航班数据管理运营技术方案
> 本方案综合整理自：IATA A-CDM Toolkit June 2025、SSIM 第 36 版（2026）、adb safegate/Amadeus/Assaia 2025 官方资料、Mordor Intelligence BHS 市场报告、ReAnIn A-SMGCS 市场报告、底特律机场除冰系统文档
> 生成时间：2026-04-08
> 数据来源：详见各子系统页面
---
## 一、系统总体架构
### 1.1 架构分层
```
┌──────────────────────────────────────────────────────────────────┐
│ 应用服务层 │
│ 航班智能调度 │ 行李追踪 │ 安防分析 │ 机位优化 │ 除冰管理 │ 客服 │
├──────────────────────────────────────────────────────────────────┤
│ 数据交换层 │
│ SSIM │ AIRIMP │ CIDX │ IATA-OS │ XML real-time feeds │
├──────────────────────────────────────────────────────────────────┤
│ 运营协同层（A-CDM 核心） │
│ ACISP（信息共享平台 / SSOT） │
│ ↑ │
│ ┌──────────┼──────────┐ │
│ │ AODB │ PDS │ TMS（过站监控） │
│ │ 运营数据库│ 起飞排序器 │ │
│ └──────────┴──────────┘ │
├──────────────────────────────────────────────────────────────────┤
│ 资源管理层 │
│ RMS（资源管理）│ Smart Gating │ BHS │ SMGCS │ 除冰系统 │
├──────────────────────────────────────────────────────────────────┤
│ 数据采集层 │
│ ADS-B │ SMR │ 多点定位 │ RFID │ VDGS │ 气象 │ 地面传感器 │
└──────────────────────────────────────────────────────────────────┘
```
### 1.2 核心数据流
```
航司（FMS/CRS）
↓ SSIM 格式（计划数据）
机场 AODB
↓
ACISP（单一真相源 SSOT）
↓ [实时推送 / Web API / 手持终端]
├── PDS（Pre-Departure Sequencer）→ TSAT 计算 → 离港序列
├── Smart Gating → 机位实时分配
├── BHS → 行李分拣优先级
├── SMGCS → 场面活动引导
└── 除冰调度系统 → TOBT 更新
```
---
## 二、AODB — 机场运营数据库
### 2.1 定位
AODB 是整个航班管理系统的**数据中枢**，为所有业务系统提供 Single Source of Truth（SSOT）。A-CDM 的 ACISP 平台以 AODB 为核心数据源，所有参与方的数据最终汇入 AODB 进行一致性管理。
### 2.2 核心数据模型（基于 IATA A-CDM Toolkit）
| 数据类型 | 内容 | 更新频率 |
|---------|------|---------|
| 航班静态数据 | 航班号、机型、航司、起降机场 | 季度更新 |
| 航班计划数据 | EOBT、起降时刻、停机位 | 每日更新（SSIM） |
| 航班动态数据 | ELDT、AOBT、ATOT、ALDT | 实时（5s-1min） |
| A-CDM Milestone | TOBT、TSAT、TTOT、CTOT、EXIT | 实时 |
| 资源状态 | 机位可用性、登机口、设备状态 | 实时 |
| 衍生计算数据 | EIBT、预测延误、冲突预警 | 实时 |
### 2.3 A-CDM Milestone 完整定义
| 缩写 | 全称 | 定义方 | 更新责任方 |
|------|------|--------|---------|
| ELDT | Estimated Landing Time | AODB 自动计算 | 系统 |
| ALDT | Actual Landing Time | 塔台 | ANSP |
| EOBT | Estimated Off-Block Time | 航司 | 航司 |
| TOBT | Target Off-Block Time | AODB 综合计算 | 航司/地面服务商 |
| TSAT | Target Start-Up Approval Time | PDS 计算 | AODB/PDS |
| TTOT | Target Take-Off Time | PDS 计算 | AODB/PDS |
| ATOT | Actual Take-Off Time | 塔台 | ANSP |
| CTOT | Calculated Take-Off Time | ATFM | Network Manager |
| EXOT | Expected Taxi-Out Time | AODB VTT 模块 | 系统 |
| EXIT | Expected Taxi-In Time | AODB VTT 模块 | 系统 |
### 2.4 供应商选型
| 厂商 | 产品 | 推荐场景 | 核心优势 |
|------|------|---------|---------|
| adb safegate | Cortex AODB | 大型枢纽 | 模块化 + AI，原生 A-CDM 支持 |
| Amadeus | Airport Operational Data Base | 中大型机场 | 覆盖全球 95% 航司计划数据 |
| AirportLabs | SkyCore AODB | 中型机场 | 2025 年已落地 ORD，性价比高 |
| PDC | AODB | 多机场集团 | Multi-Airport Mode 支持 |
---
## 三、A-CDM — 机场协同决策系统
### 3.1 系统定位
A-CDM（Airport Collaborative Decision Making）是 IATA 与 Eurocontrol 联合推动的运营协同框架，目标是通过信息共享机制使机场各运营方（航司、机场、地面服务商、管制）在统一操作视图下做决策，提升航班可预测性和机场整体效率。
**全球已实施机场：40+**（以欧洲为主，亚太增长快）
### 3.2 三大核心组件
#### ACISP（信息共享平台）
- 实现 SSOT（Single Source of Operational Truth）
- 多渠道接入：Web 界面 + 手持终端
- 各参与方直接录入 TOBT 等数据
- 集成：AODB、VDGS、RMS、PDS、塔台、地面服务系统
#### AODB（运营数据库）
见第二章。
#### PDS（Pre-Departure Sequencer）
**核心公式：** `TSAT = TTOT - EXOT`
- 依据管制设定的离港率（departure rate）分配起飞序列
- **硬约束：** CTOT（ATFM）、VTT、机位限制
- **软约束：** 航司优先级、航班互换、寒区优先权、禁区优先权
**TSAT 计算示例：**
```
TTOT = 14:30（目标起飞时间，PDS 依据离港率计算）
EXOT = 00:12（预计滑出时间，基于 VTT 历史统计 + 实时场面状态）
TSAT = 14:18（目标启动许可时间 = TTOT - EXOT）
→ 航司需在 14:18 之前申请启动，14:18 之前完成所有过站操作
→ 若 TOBT > TSAT，PDS 触发重排序告警
```
### 3.3 参与方职责与数据交互
| 参与方 | 输入数据 | 使用数据 |
|--------|---------|---------|
| 航司 | TOBT、EOBT、实际动态 | TSAT、CTOT、PDS 序列 |
| 地面服务商 | 过站保障时间、除冰完成时间 | TSAT、TOBT |
| 机场运营方 | 机位分配、VDGS 状态 | 全部 |
| ANSP（管制） | CTOT、跑道离港率、ATOT、ALDT | TSAT、TTOT |
### 3.4 A-CDM 关键绩效指标
| KPI | 定义 | 目标 |
|-----|------|------|
| TOBT 准确性 | TOBT vs AOBT 偏差 | ≤ 3 分钟 |
| TSAT 准确性 | TSAT vs ASAT 偏差 | ≤ 1 分钟 |
| 离港准点率 | ATOT ≤ CTOT + 15min | ≥ 80% |
| CTOT 顺从率 | 实际按 CTOT 起飞比例 | ≥ 90% |
### 3.5 与 ATFM 集成
```
ATFM（Network Manager）
│
├──→ CTOT（Calculated Take-Off Time）
│ ↓
│ PDS 接收 CTOT 作为硬约束
│ ↓
└──→ 流量限制信息
↓
ACISP 显示全网状态
```
澳大利亚已将 A-CDM 深度整合入国家 ATFM 系统，2025 年 IATA A-CDM Toolkit 推广此模式。
---
## 四、SMGCS / A-SMGCS — 场面活动引导与控制系统
### 4.1 系统定位
SMGCS 在低能见度条件（< 1200ft RVR）下管控飞机地面滑行、推出、起飞、落地。机场场面是 A-CDM 离港/到港流程中最后一环，SMGCS 与 A-CDM 共享场面状态数据。
### 4.2 功能等级
| 级别 | 功能 | 技术说明 |
|------|------|---------|
| L1 | 场面监视 | SMR/ADS-B/多点定位，探测所有活动目标位置 |
| L2 | 路径引导 | 最优滑行路径计算 + 冲突预警 |
| L3 | 运动规划 | 自动优化停机位、滑行路线分配 |
| L4 | 场景管理 | 应急响应自动化（紧急救援、鸟击） |
### 4.3 核心技术组件
| 组件 | 技术 | 供应商参考 |
|------|------|---------|
| 场面探测雷达 | ASDE-X / SMR | Saab |
| 广播式监视 | ADS-B 接收站 | — |
| 精确定位 | Multilateration（TDOA） | — |
| 停止排灯 | 停止排灯控制 | TERMA |
| 泊位引导 | VDGS（Visual Docking Guidance） | — |
| 场面灯控 | 可变距灯（VSLS）| TERMA |
### 4.4 SMGCS Plan 核心内容（FAA 规范）
- 低能见度运营程序（LVP Level 1/2/3）
- 跑道等待点 / 停止排灯控制程序
- 地面车辆活动限制区域
- 应急救援路线保障
- 年度评审机制
**市场规模（2025）：** USD 5,922.47 百万，AI/ML 集成是发展方向。
---
## 五、AI Smart Gating — 智能停机位管理
### 5.1 系统定位
AI Smart Gating 利用 AI 算法实时优化停机位（gate/stand）分配，目标是最小化滑行时间、提升机位利用率、减少航班延误。与 A-CDM 和 SMGCS 深度集成。
### 5.2 核心算法能力
| 能力 | 说明 |
|------|------|
| 实时机位分配 | 基于航班实际到达时间、机型、衔接航班动态重分配 |
| 冲突检测 | 机位时间重叠、翼展冲突、拖车路径冲突 |
| 预测性分析 | 预测机位冲突并提前调整 |
| 多目标优化 | 平衡航司偏好、旅客步行距离、地面滑行时间 |
| 可持续性指标 | 减少地面滑行燃油消耗和碳排放 |
### 5.3 与 A-CDM 的集成
```
AODB（航班动态）
↓
Smart Gating AI 引擎
↓ [机位分配更新]
ACISP（SSOT）
↓
TSAT 重新计算（若机位变更影响 EXOT）
↓
PDS 序列调整
```
### 5.4 供应商动态（2025）
| 厂商 | 产品 | 进展 |
|------|------|------|
| Assaia | StandManager | 2025 年全新发布，AI 视频分析为核心 |
| adb safegate | AmberFAIR | 可持续分配算法 |
| AirportLabs | SkyCore RMS | 2025 年 8 月部署于芝加哥 ORD |
### 5.5 典型效益
- 减少飞机滑行时间 → 降低燃油消耗和碳排放
- 机位利用率提升 → 相同资源处理更多航班
- 预测性分配 → 减少延误被动响应
---
## 六、BHS — 行李处理系统
### 6.1 系统定位
BHS 覆盖行李从值机托运到目的地提取全流程的分拣、输送、追踪管理。行李系统与 AODB 航班动态联动：航班延误影响行李分拣优先级和中转分拣时机。
### 6.2 IATA Resolution 753 合规
行李必须在以下四个节点被追踪并向航司数据系统报告：
| 节点 | 说明 |
|------|------|
| Acceptance（接收）| 值机口接收并记录 |
| Loading（装载）| 装入飞机货舱 |
| Transfer（中转）| 航班衔接时的转运 |
| Arrival（到达）| 到达目的地交付 |
**RFID 是满足 Res. 753 的核心技术，追踪精度接近 100%。**
### 6.3 核心技术选型
| 技术 | 参数 | 说明 |
|------|------|------|
| RFID | 读准率 ~100% | 替代条码，满足 Res.753 |
| Tote-based 分拣 | 损坏率大幅降低 | 轮式载具代替皮带，枢纽标配 |
| Cross-Belt Sorter | 处理量 6000+ 件/小时 | 高速分拣机 |
| EBS（Early Bag Storage）| 提前储存 | 平衡高峰处理压力 |
### 6.4 系统效益
- RFID + 实时追踪后，行李错运率降低 **30-50%**
- 预测性维护减少计划外停机 **30-50%**
- 维护成本降低 **18-25%**
### 6.5 供应商（头部）
| 厂商 | 技术亮点 |
|------|---------|
| Siemens Logistics | RFID 全流程追踪 |
| Beumer Group | Tote-based 分拣，快速成为高吞吐量航站楼标准 |
| Vanderlande | 高吞吐量分拣 |
| Alstef | 仓储自动化 |
---
## 七、除冰运营管理
### 7.1 系统定位
除冰运营是 A-CDM 过站时间的重要变量：实际除冰完成时间直接影响 AOBT，进而影响 TSAT、TTOT 和离港排序。除冰延误具有级联效应，需纳入 A-CDM 过站监控（TMS）。
### 7.2 除冰液（ADF）类型
| 类型 | 成分 | 适用场景 |
|------|------|---------|
| Propylene Glycol（PG）| 丙二醇 | 主流，大型机场回收再用（DTW）|
| Ethylene Glycol（EG）| 乙二醇 | 早期，环境毒性较高 |
### 7.3 除冰对 A-CDM 的影响链
```
气象预警 → 除冰需求识别 → 除冰排程
│
├──→ TOBT 更新（含除冰时间）
│ ↓
├──→ AOBT 实际除冰完成时间
│ ↓
├──→ TSAT 重算（TSAT = TTOT - EXOT）
│ ↓
└──→ PDS 离港序列调整
```
2025 年 IATA A-CDM Toolkit 将除冰运营状态纳入 **TMS（Turnaround Monitoring System）**。
### 7.4 底特律 DTW 案例（行业标杆）
- 全球最大 ADF 管理系统运营方
- 4 个远程除冰坪 + 回收系统
- 除冰径流与一般雨水完全分流
- 回收丙二醇用于塑料/油漆生产
---
## 八、航班数据交换标准
### 8.1 标准体系
| 标准 | 用途 | 格式 |
|------|------|------|
| SSIM | 航班计划数据交换 | Flat file（固定长度）|
| AIRIMP | 订座与运价报文 | 报文格式 |
| AHM | 地面操作数据 | 报文格式 |
| CIDX | 货运数据交换（部分机场用于航班动态）| XML |
| IATA-OS | 机场运营数据模型 | XML/JSON |
### 8.2 SSIM 最新动态
| 项目 | 信息 |
|------|------|
| 最新版本 | **第 36 版（2026）** |
| 发布方 | IATA |
| 核心内容 | 航班计划报文格式、最小衔接时间（MCT）、机场协调程序 |
### 8.3 IATA Schedule Data Exchange Program（2025 新动态）
- **2025 年 8 月启动**：航司可从 IATA 数据库接收其他航司的航班计划数据
- **开放性**：向所有航司开放，包括非 IATA 成员
- **数据范围**：航班计划 + MCT 异常数据
### 8.4 数据流向
```
航司 ──SSIM──→ 机场 AODB ──ACISP──→ 各运营系统
│ │
│←──── 运营更新（动态）───→│
└──── 地面服务商 ─────────┘
```
---
## 九、系统集成与数据接口
### 9.1 接口关系总览
```
┌──────────────────────────────────────────────────────────────┐
│ ACISP（SSOT 核心） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ AODB │ PDS │ TMS │ Smart Gating │ BHS │ 除冰系统 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↑ ↑ ↑ ↑ ↑ │
└─────────┼────────────┼──────────┼──────────┼───────┼───────┘
│ │ │ │ │
SSIM/ARINC ATFM/CTOT SMGCS RFID 气象
XML实时 (Network 场面状态 Res.753
feeds Manager) 行李追踪
```
### 9.2 关键集成点
| 集成项 | 数据内容 | 频率 |
|--------|---------|------|
| AODB ↔ 航司 | SSIM 计划数据、EOBT、TOBT | 批量/实时 |
| ACISP ↔ ANSP | CTOT、跑道离港率 | 实时 |
| Smart Gating ↔ SMGCS | 机位分配、场面活动状态 | 实时 |
| BHS ↔ AODB | 行李分拣状态、中转优先级 | 实时 |
| 除冰系统 ↔ A-CDM | 除冰完成时间 → TOBT 更新 | 实时 |
---
## 十、供应商综合推荐
### 10.1 全栈平台 vs. 单点专家
| 类型 | 厂商 | 推荐场景 |
|------|------|---------|
| **全栈平台** | adb safegate | 需要 AODB + A-CDM + Smart Gating + SMGCS 统一管理 |
| **全栈平台** | Amadeus | 已有 Amadeus PSS，希望扩展运营系统 |
| **全栈平台** | Siemens | 需要 BHS + 运营系统整合 |
| **单点专家** | Assaia | 专注 AI 机位+视频分析，集成到其他平台 |
| **单点专家** | AirportLabs | 中型机场性价比方案 |
| **单点专家** | Beumer Group | 高吞吐量 BHS 分拣系统 |
### 10.2 推荐组合
| 机场规模 | 推荐组合 |
|---------|---------|
| 大型枢纽（年旅客 > 5000万）| adb safegate 全栈 + Assaia StandManager + Beumer BHS |
| 中型机场（年旅客 1000-5000万）| AirportLabs SkyCore（AODB+RMS+Gating）+ Siemens BHS |
| 小型机场（年旅客 < 1000万）| Amadeus Cloud AODB + 基础 RMS |
---
## 附录
### A. IATA A-CDM Toolkit June 2025 关键参考
- SSOT 实现：ACISP 为核心，所有参与方通过同一平台访问一致数据
- VTT（Variable Taxi-Times）：EXIT/EXOT 是 TSAT 准确性的关键变量
- 澳大利亚案例：A-CDM 与 ATFM 深度整合为行业示范
### B. IATA SSIM 第 36 版（2026）关键变更
- 协调程序章节独立（Chapter 6）
- MCT（Minimum Connect Time）数据质量要求提升
- 推动向 XML/IATA-OS 迁移
### C. 相关页面索引
- [[aodb-core]] — 机场运营数据库详解
- [[a-cdm]] — A-CDM 协同决策完整规范
- [[smgcs]] — 场面活动引导控制系统
- [[smart-gating]] — AI 智能停机位管理
- [[baggage-handling]] — BHS 系统与 Res.753
- [[deicing-operations]] — 除冰运营管理
- [[flight-data-exchange]] — SSIM/AIRIMP/CIDX 标准
- [[airport-operations-systems]] — 供应商综合对比