From 81d62725d8cd48692b6545b5f51089700afac5c4 Mon Sep 17 00:00:00 2001 From: windyboy Date: Wed, 15 Apr 2026 14:34:24 +0800 Subject: [PATCH] remove airport wiki --- .codex/config.toml | 7 - airport-wiki/.gitignore | 6 - airport-wiki/.markdownlint.json | 15 - airport-wiki/SCHEMA.md | 388 ---- airport-wiki/_archive/aodb-redirect-stub.md | 16 - .../comparisons/airport-dc-case-studies.md | 50 - .../comparisons/airport-operations-systems.md | 49 - .../concepts/aodb/AODB 事件 Schema 草案.md | 252 --- .../concepts/aodb/AODB 字段级权威矩阵.md | 65 - .../concepts/aodb/AODB 最小部署拓扑草案.md | 176 -- .../concepts/aodb/AODB 核心需求提炼.md | 111 -- .../aodb/adr/ADR-001 MVP 不引入 Flink.md | 24 - .../adr/ADR-002 Kafka 作为唯一事件骨干.md | 24 - .../concepts/aodb/adr/ADR-003 事实分层模型.md | 24 - .../adr/ADR-004 FlightOperation 写主归属.md | 24 - .../aodb/adr/ADR-005 Turnaround 独立建模.md | 24 - .../concepts/aodb/adr/ADR-006 资源锁定模型.md | 24 - .../aodb/adr/ADR-007 查询与订阅分离.md | 24 - .../aodb/adr/ADR-008 Outbox 与 CDC.md | 24 - .../aodb/adr/ADR-009 PostgreSQL HA.md | 24 - .../aodb/adr/ADR-010 人工裁决事件化.md | 24 - .../concepts/aodb/开源技术栈选型决策.md | 101 - .../开源机场运营数据库（AODB）高层设计文档.md | 510 ----- .../concepts/flight-operations/a-cdm.md | 87 - .../flight-operations/agentic-ai-airports.md | 63 - .../airport-systems-landscape.md | 106 -- .../concepts/flight-operations/aocc-ioc.md | 81 - .../concepts/flight-operations/aodb-china.md | 243 --- .../concepts/flight-operations/aodb-core.md | 163 -- .../flight-operations/aodb-vendors.md | 495 ----- .../flight-operations/baggage-handling.md | 63 - .../flight-operations/biometric-corridors.md | 48 - .../flight-operations/deicing-operations.md | 65 - .../digital-twins-airports.md | 48 - .../flight-operations/flight-data-exchange.md | 266 --- .../future-airport-info-center.md | 97 - .../flight-operations/open-architecture.md | 131 -- .../flight-operations/smart-gating.md | 54 - .../concepts/flight-operations/smgcs.md | 57 - .../universal-design-airports.md | 58 - .../knowledge-management/automation-hooks.md | 569 ------ .../knowledge-management/knowledge-graph.md | 200 -- .../knowledge-lifecycle.md | 474 ----- .../llm-wiki-v2-reference.md | 584 ------ .../knowledge-management/memory-lifecycle.md | 197 -- .../knowledge-management/quality-control.md | 616 ------ .../knowledge-management/wiki-operations.md | 186 -- .../airport-data-center-overview.md | 59 - .../tech-infrastructure/commissioning.md | 88 - .../construction-management.md | 82 - .../tech-infrastructure/design-phase.md | 79 - .../concepts/tech-infrastructure/glossary.md | 335 ---- .../tech-infrastructure/gpu-cluster.md | 139 -- .../modern-airport-trends.md | 66 - .../network-architecture.md | 36 - .../operation-maintenance.md | 107 -- .../tech-infrastructure/power-and-cooling.md | 83 - .../tech-infrastructure/prefab-modular-dc.md | 49 - .../rfp-and-vendor-selection.md | 78 - .../tech-infrastructure/security-design.md | 95 - .../tech-infrastructure/site-planning.md | 54 - .../tech-infrastructure/tier-iii-design.md | 29 - .../tech-infrastructure/tier-iv-design.md | 30 - .../entities/fuzhou-changle-airport-bsj.md | 55 - airport-wiki/entities/index.md | 224 --- airport-wiki/entities/jfk-airport.md | 37 - airport-wiki/entities/pittsburgh-airport.md | 35 - .../entities/rome-fiumicino-airport.md | 40 - airport-wiki/entities/shenzhen-airport.md | 56 - .../entities/singapore-changi-airport.md | 43 - .../entities/zhengzhou-airport-hangang.md | 46 - airport-wiki/hybrid-search.md | 435 ----- airport-wiki/index.md | 173 -- airport-wiki/log.md | 236 --- airport-wiki/package-lock.json | 1645 ----------------- airport-wiki/package.json | 10 - .../2025-airport-construction-summit.md | 35 - .../articles/AI-Driven-Smart-Gating-2025.md | 103 -- ...uilding-intelligent-airport-future-2025.md | 90 - .../aci-tsa-open-architecture-2023.md | 97 - airport-wiki/raw/articles/aodb-manus-2026.md | 288 --- airport-wiki/raw/articles/aodb.md | 285 --- .../raw/articles/daxing-airport-vertiv.md | 48 - .../raw/articles/dubai-airport-huawei-dc.md | 48 - .../raw/articles/keydak-airport-expo-2025.md | 28 - .../raw/articles/llm-wiki-v2-rohitg00.md | 99 - .../manus-future-airport-info-center-2026.md | 94 - .../上海市-智算中心建设导则2025版-2025-01.md | 142 -- ...研究院-工业智算发展研究报告2025-2026-01.md | 96 - ...究院-中国AIDC产业发展白皮书2025-2025-07.md | 106 -- .../机场数据中心建设方案（综合性完整方案）.md | 1166 ------------ .../机场运行数据库 (AODB) 产品对比分析报告.md | 285 --- ...场-数智化全国第二-AI全栈部署-2026-01-15.md | 77 - .../福州长乐机场-15000P智算中心-2026-01-22.md | 60 - ...航空港-中部最大万卡算力集群-2026-03-05.md | 50 - .../aodb-system-architecture.md | 758 -------- airport-wiki/机场智算中心技术方案.md | 1205 ------------ airport-wiki/机场航班数据管理运营方案.md | 463 ----- 98 files changed, 17004 deletions(-) delete mode 100644 airport-wiki/.gitignore delete mode 100644 airport-wiki/.markdownlint.json delete mode 100644 airport-wiki/SCHEMA.md delete mode 100644 airport-wiki/_archive/aodb-redirect-stub.md delete mode 100644 airport-wiki/comparisons/airport-dc-case-studies.md delete mode 100644 airport-wiki/comparisons/airport-operations-systems.md delete mode 100644 airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md delete mode 100644 airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md delete mode 100644 airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md delete mode 100644 airport-wiki/concepts/aodb/AODB 核心需求提炼.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-003 事实分层模型.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-005 Turnaround 独立建模.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-006 资源锁定模型.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-007 查询与订阅分离.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-008 Outbox 与 CDC.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-009 PostgreSQL HA.md delete mode 100644 airport-wiki/concepts/aodb/adr/ADR-010 人工裁决事件化.md delete mode 100644 airport-wiki/concepts/aodb/开源技术栈选型决策.md delete mode 100644 airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md delete mode 100644 airport-wiki/concepts/flight-operations/a-cdm.md delete mode 100644 airport-wiki/concepts/flight-operations/agentic-ai-airports.md delete mode 100644 airport-wiki/concepts/flight-operations/airport-systems-landscape.md delete mode 100644 airport-wiki/concepts/flight-operations/aocc-ioc.md delete mode 100644 airport-wiki/concepts/flight-operations/aodb-china.md delete mode 100644 airport-wiki/concepts/flight-operations/aodb-core.md delete mode 100644 airport-wiki/concepts/flight-operations/aodb-vendors.md delete mode 100644 airport-wiki/concepts/flight-operations/baggage-handling.md delete mode 100644 airport-wiki/concepts/flight-operations/biometric-corridors.md delete mode 100644 airport-wiki/concepts/flight-operations/deicing-operations.md delete mode 100644 airport-wiki/concepts/flight-operations/digital-twins-airports.md delete mode 100644 airport-wiki/concepts/flight-operations/flight-data-exchange.md delete mode 100644 airport-wiki/concepts/flight-operations/future-airport-info-center.md delete mode 100644 airport-wiki/concepts/flight-operations/open-architecture.md delete mode 100644 airport-wiki/concepts/flight-operations/smart-gating.md delete mode 100644 airport-wiki/concepts/flight-operations/smgcs.md delete mode 100644 airport-wiki/concepts/flight-operations/universal-design-airports.md delete mode 100644 airport-wiki/concepts/knowledge-management/automation-hooks.md delete mode 100644 airport-wiki/concepts/knowledge-management/knowledge-graph.md delete mode 100644 airport-wiki/concepts/knowledge-management/knowledge-lifecycle.md delete mode 100644 airport-wiki/concepts/knowledge-management/llm-wiki-v2-reference.md delete mode 100644 airport-wiki/concepts/knowledge-management/memory-lifecycle.md delete mode 100644 airport-wiki/concepts/knowledge-management/quality-control.md delete mode 100644 airport-wiki/concepts/knowledge-management/wiki-operations.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/airport-data-center-overview.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/commissioning.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/construction-management.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/design-phase.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/glossary.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/gpu-cluster.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/modern-airport-trends.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/network-architecture.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/operation-maintenance.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/power-and-cooling.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/prefab-modular-dc.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/rfp-and-vendor-selection.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/security-design.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/site-planning.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/tier-iii-design.md delete mode 100644 airport-wiki/concepts/tech-infrastructure/tier-iv-design.md delete mode 100644 airport-wiki/entities/fuzhou-changle-airport-bsj.md delete mode 100644 airport-wiki/entities/index.md delete mode 100644 airport-wiki/entities/jfk-airport.md delete mode 100644 airport-wiki/entities/pittsburgh-airport.md delete mode 100644 airport-wiki/entities/rome-fiumicino-airport.md delete mode 100644 airport-wiki/entities/shenzhen-airport.md delete mode 100644 airport-wiki/entities/singapore-changi-airport.md delete mode 100644 airport-wiki/entities/zhengzhou-airport-hangang.md delete mode 100644 airport-wiki/hybrid-search.md delete mode 100644 airport-wiki/index.md delete mode 100644 airport-wiki/log.md delete mode 100644 airport-wiki/package-lock.json delete mode 100644 airport-wiki/package.json delete mode 100644 airport-wiki/raw/articles/2025-airport-construction-summit.md delete mode 100644 airport-wiki/raw/articles/AI-Driven-Smart-Gating-2025.md delete mode 100644 airport-wiki/raw/articles/IBM-Building-intelligent-airport-future-2025.md delete mode 100644 airport-wiki/raw/articles/aci-tsa-open-architecture-2023.md delete mode 100644 airport-wiki/raw/articles/aodb-manus-2026.md delete mode 100644 airport-wiki/raw/articles/aodb.md delete mode 100644 airport-wiki/raw/articles/daxing-airport-vertiv.md delete mode 100644 airport-wiki/raw/articles/dubai-airport-huawei-dc.md delete mode 100644 airport-wiki/raw/articles/keydak-airport-expo-2025.md delete mode 100644 airport-wiki/raw/articles/llm-wiki-v2-rohitg00.md delete mode 100644 airport-wiki/raw/articles/manus-future-airport-info-center-2026.md delete mode 100644 airport-wiki/raw/articles/上海市-智算中心建设导则2025版-2025-01.md delete mode 100644 airport-wiki/raw/articles/中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md delete mode 100644 airport-wiki/raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md delete mode 100644 airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md delete mode 100644 airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md delete mode 100644 airport-wiki/raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md delete mode 100644 airport-wiki/raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md delete mode 100644 airport-wiki/raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md delete mode 100644 airport-wiki/systems-design/aodb-system-architecture.md delete mode 100644 airport-wiki/机场智算中心技术方案.md delete mode 100644 airport-wiki/机场航班数据管理运营方案.md diff --git a/.codex/config.toml b/.codex/config.toml index bf4bd92..408719c 100644 --- a/.codex/config.toml +++ b/.codex/config.toml @@ -1,8 +1 @@ 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' diff --git a/airport-wiki/.gitignore b/airport-wiki/.gitignore deleted file mode 100644 index 888a2de..0000000 --- a/airport-wiki/.gitignore +++ /dev/null @@ -1,6 +0,0 @@ -node_modules/ -.obsidian/ -.trash/ -*.log -# 已被新方案取代 -机场数据中心建设方案.md diff --git a/airport-wiki/.markdownlint.json b/airport-wiki/.markdownlint.json deleted file mode 100644 index 5a58c25..0000000 --- a/airport-wiki/.markdownlint.json +++ /dev/null @@ -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 -} diff --git a/airport-wiki/SCHEMA.md b/airport-wiki/SCHEMA.md deleted file mode 100644 index 1980723..0000000 --- a/airport-wiki/SCHEMA.md +++ /dev/null @@ -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 完整參考 -``` diff --git a/airport-wiki/_archive/aodb-redirect-stub.md b/airport-wiki/_archive/aodb-redirect-stub.md deleted file mode 100644 index 96a41a3..0000000 --- a/airport-wiki/_archive/aodb-redirect-stub.md +++ /dev/null @@ -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） - -本文件保留作為索引入口。 diff --git a/airport-wiki/comparisons/airport-dc-case-studies.md b/airport-wiki/comparisons/airport-dc-case-studies.md deleted file mode 100644 index 0903c12..0000000 --- a/airport-wiki/comparisons/airport-dc-case-studies.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/comparisons/airport-operations-systems.md b/airport-wiki/comparisons/airport-operations-systems.md deleted file mode 100644 index dad7b2d..0000000 --- a/airport-wiki/comparisons/airport-operations-systems.md +++ /dev/null @@ -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 数据模型 diff --git a/airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md b/airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md deleted file mode 100644 index 447aa05..0000000 --- a/airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md +++ /dev/null @@ -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` 作为强语义，而不是展示附注。 -- 不得把查询接口结果当作事件流补偿来源。 diff --git a/airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md b/airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md deleted file mode 100644 index d7b4ad6..0000000 --- a/airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md +++ /dev/null @@ -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 被恢复时，必须有显式更正，不允许静默取消取消状态。 diff --git a/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md b/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md deleted file mode 100644 index bd922ab..0000000 --- a/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md +++ /dev/null @@ -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 章节。 -- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。 diff --git a/airport-wiki/concepts/aodb/AODB 核心需求提炼.md b/airport-wiki/concepts/aodb/AODB 核心需求提炼.md deleted file mode 100644 index 854a5cc..0000000 --- a/airport-wiki/concepts/aodb/AODB 核心需求提炼.md +++ /dev/null @@ -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` diff --git a/airport-wiki/concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md b/airport-wiki/concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md deleted file mode 100644 index 999723c..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-001 MVP 不引入 Flink - -## 状态 - -Accepted - -## 背景 - -首期目标是完成单机场 AODB 核心闭环，规模为 500 万至 3000 万旅客机场，优先解决当前态统一、资源冲突和审计问题。 - -## 决策 - -MVP 不引入 Flink。首期只保留 Kafka 事件骨干和应用服务内流式处理逻辑。预测、CEP 和复杂有状态计算推迟到 P1。 - -## 原因 - -- 首期复杂度应优先让位于交付确定性。 -- 预测与复杂流处理不是首期闭环前提。 -- Flink 会显著提高部署、运维和故障恢复复杂度。 - -## 后果 - -- MVP 中实时计算能力受限。 -- 事件契约和聚合边界必须为未来引入 Flink 预留演进空间。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md b/airport-wiki/concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md deleted file mode 100644 index 744ebbc..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-002 Kafka 作为唯一事件骨干 - -## 状态 - -Accepted - -## 背景 - -AODB 需要支撑事件可回放、订阅分发、补偿和审计。 - -## 决策 - -Kafka 作为唯一事实事件骨干。所有对外事件订阅都以 Kafka 上的标准化事件为源头，禁止多路事件源头并存。 - -## 原因 - -- 统一重放和补偿语义。 -- 避免“写库成功但未发布”或“已发布但未落库”的治理空洞。 -- 降低外部消费者理解成本。 - -## 后果 - -- 事件可靠发布必须依赖 Outbox + CDC。 -- 查询 API 不能被下游误当作事件事实源。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-003 事实分层模型.md b/airport-wiki/concepts/aodb/adr/ADR-003 事实分层模型.md deleted file mode 100644 index 9e56e64..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-003 事实分层模型.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-003 事实分层模型 - -## 状态 - -Accepted - -## 背景 - -AODB 需要同时处理多源观测、字段裁决和对外权威事实发布。 - -## 决策 - -采用 `Observation / Decision / Published Fact` 三层模型。 - -## 原因 - -- 让 SSOT 真正表示“经过治理后发布的事实”。 -- 保证原始观测、人工覆盖和当前值三者不互相污染。 -- 便于审计、回放和责任归因。 - -## 后果 - -- 数据模型和事件模型会更明确，但设计和实现复杂度略有上升。 -- Published Fact 的任何变更都必须可追溯到 Observation 和 Decision。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md b/airport-wiki/concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md deleted file mode 100644 index d7bd994..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-004 FlightOperation 写主归属 - -## 状态 - -Accepted - -## 背景 - -原方案中 Flight、Milestone、Resource、Alert 边界存在写入重叠风险。 - -## 决策 - -Flight 当前权威态只能由 `Flight Operation Service` 写入，其他服务只能产生观测、候选事实、资源事实或告警事实。 - -## 原因 - -- 避免多个服务共同修改同一当前态。 -- 降低一致性和回放复杂度。 -- 方便将 Published Fact 聚合到单一领域对象。 - -## 后果 - -- Milestone 和 Resource 服务必须通过事件影响 Flight 当前态。 -- Flight Service 需要承担更明确的聚合协调责任。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-005 Turnaround 独立建模.md b/airport-wiki/concepts/aodb/adr/ADR-005 Turnaround 独立建模.md deleted file mode 100644 index 5af54b8..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-005 Turnaround 独立建模.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-005 Turnaround 独立建模 - -## 状态 - -Accepted - -## 背景 - -仅以单航班建模无法充分表达到离港配对、机尾号上下文和资源联动。 - -## 决策 - -将 `Turnaround` 作为首期核心领域对象，引入最小独立建模。 - -## 原因 - -- 支撑航班配对（Linking）需求。 -- 提高资源分配和时序解释能力。 -- 为换机、延误联动和周转分析提供上下文。 - -## 后果 - -- 文档和模型复杂度上升。 -- 配对修正和不完整配对需要额外的事件和审计语义。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-006 资源锁定模型.md b/airport-wiki/concepts/aodb/adr/ADR-006 资源锁定模型.md deleted file mode 100644 index 724d3f9..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-006 资源锁定模型.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-006 资源锁定模型 - -## 状态 - -Accepted - -## 背景 - -单纯的资源时间窗分配无法表达建议分配、已确认分配和人工强制覆盖。 - -## 决策 - -ResourceAllocation 支持 `soft lock` 和 `hard lock` 两种锁定语义。 - -## 原因 - -- 表达自动建议和人工强制分配的区别。 -- 支持冲突检测、覆盖和回滚的可解释性。 -- 为未来优化排班预留空间。 - -## 后果 - -- 冲突检测和分配逻辑需要区分锁定强度。 -- 人工覆盖必须伴随审计和事件输出。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-007 查询与订阅分离.md b/airport-wiki/concepts/aodb/adr/ADR-007 查询与订阅分离.md deleted file mode 100644 index 7f3b59c..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-007 查询与订阅分离.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-007 查询与订阅分离 - -## 状态 - -Accepted - -## 背景 - -将 GraphQL Subscription 或查询层直接作为事实流会混淆读取和事件分发语义。 - -## 决策 - -对外查询接口和事件订阅接口分离设计。 - -## 原因 - -- 查询和事件分发的稳定性、回放、限流语义不同。 -- 便于明确外部消费者的消费契约。 -- 降低把查询接口误当权威事件骨干的风险。 - -## 后果 - -- 需要独立设计事件订阅网关或分发适配层。 -- API 文档要分别描述查询和订阅契约。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-008 Outbox 与 CDC.md b/airport-wiki/concepts/aodb/adr/ADR-008 Outbox 与 CDC.md deleted file mode 100644 index 8ca4928..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-008 Outbox 与 CDC.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-008 Outbox 与 CDC - -## 状态 - -Accepted - -## 背景 - -AODB 必须避免“写库成功但没发事件”或“发了事件但没落库”。 - -## 决策 - -采用 `Outbox Pattern + CDC` 作为写库与发事件一致性策略。 - -## 原因 - -- 能把数据库状态变化和事件发布绑定到同一事务边界。 -- 适合首期 Kafka 作为唯一事件骨干的架构。 -- 支持失败重试、断点恢复和事件回放。 - -## 后果 - -- 需要部署 CDC / 发布器组件。 -- 发布流程和 Outbox 堆积需要专门监控。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-009 PostgreSQL HA.md b/airport-wiki/concepts/aodb/adr/ADR-009 PostgreSQL HA.md deleted file mode 100644 index 7333952..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-009 PostgreSQL HA.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-009 PostgreSQL HA - -## 状态 - -Accepted - -## 背景 - -Published Fact、审计和 Outbox 都依赖 PostgreSQL，数据库可用性直接决定系统可用性。 - -## 决策 - -MVP 必须采用 PostgreSQL 高可用部署，并具备备份恢复和 PITR 或等价能力。 - -## 原因 - -- 满足 RTO / RPO 目标。 -- 为审计、重放和一致性提供稳定基础。 -- 避免首期把可靠性寄托在应用层补偿上。 - -## 后果 - -- 部署和运维门槛上升，但这是首期必须承担的复杂度。 -- 需要单独演练主备切换和恢复流程。 diff --git a/airport-wiki/concepts/aodb/adr/ADR-010 人工裁决事件化.md b/airport-wiki/concepts/aodb/adr/ADR-010 人工裁决事件化.md deleted file mode 100644 index 3ce5262..0000000 --- a/airport-wiki/concepts/aodb/adr/ADR-010 人工裁决事件化.md +++ /dev/null @@ -1,24 +0,0 @@ -# ADR-010 人工裁决事件化 - -## 状态 - -Accepted - -## 背景 - -AODB 中数据冲突、资源覆盖和解析失败都可能需要人工参与。 - -## 决策 - -所有人工裁决、人工覆盖和人工复核动作必须事件化和审计化，禁止仅通过数据库备注或日志留痕。 - -## 原因 - -- 人工动作是业务事实的一部分。 -- 需要对外解释当前值为何成立。 -- 便于回放、对账和合规审计。 - -## 后果 - -- Case 流程和审计模型需要更完整。 -- 首期必须实现最小人工复核状态机。 diff --git a/airport-wiki/concepts/aodb/开源技术栈选型决策.md b/airport-wiki/concepts/aodb/开源技术栈选型决策.md deleted file mode 100644 index 4d5d270..0000000 --- a/airport-wiki/concepts/aodb/开源技术栈选型决策.md +++ /dev/null @@ -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/` 下文件为准。 diff --git a/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md b/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md deleted file mode 100644 index 8704730..0000000 --- a/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md +++ /dev/null @@ -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 为准。 diff --git a/airport-wiki/concepts/flight-operations/a-cdm.md b/airport-wiki/concepts/flight-operations/a-cdm.md deleted file mode 100644 index bb8edbf..0000000 --- a/airport-wiki/concepts/flight-operations/a-cdm.md +++ /dev/null @@ -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 过站时间的重要变量 diff --git a/airport-wiki/concepts/flight-operations/agentic-ai-airports.md b/airport-wiki/concepts/flight-operations/agentic-ai-airports.md deleted file mode 100644 index 34cb671..0000000 --- a/airport-wiki/concepts/flight-operations/agentic-ai-airports.md +++ /dev/null @@ -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 驅動超級個性化服務 diff --git a/airport-wiki/concepts/flight-operations/airport-systems-landscape.md b/airport-wiki/concepts/flight-operations/airport-systems-landscape.md deleted file mode 100644 index 6923278..0000000 --- a/airport-wiki/concepts/flight-operations/airport-systems-landscape.md +++ /dev/null @@ -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]] — 供应商横向对比 diff --git a/airport-wiki/concepts/flight-operations/aocc-ioc.md b/airport-wiki/concepts/flight-operations/aocc-ioc.md deleted file mode 100644 index 32810fa..0000000 --- a/airport-wiki/concepts/flight-operations/aocc-ioc.md +++ /dev/null @@ -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 實時監控與預測性維護的技術基礎 diff --git a/airport-wiki/concepts/flight-operations/aodb-china.md b/airport-wiki/concepts/flight-operations/aodb-china.md deleted file mode 100644 index 393fa78..0000000 --- a/airport-wiki/concepts/flight-operations/aodb-china.md +++ /dev/null @@ -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]] — 機場運營系統供應商全景對比 diff --git a/airport-wiki/concepts/flight-operations/aodb-core.md b/airport-wiki/concepts/flight-operations/aodb-core.md deleted file mode 100644 index 3c8a140..0000000 --- a/airport-wiki/concepts/flight-operations/aodb-core.md +++ /dev/null @@ -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]] — 供應商綜合對比 diff --git a/airport-wiki/concepts/flight-operations/aodb-vendors.md b/airport-wiki/concepts/flight-operations/aodb-vendors.md deleted file mode 100644 index f78ccd5..0000000 --- a/airport-wiki/concepts/flight-operations/aodb-vendors.md +++ /dev/null @@ -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]] — 運營系統供應商全景對比 diff --git a/airport-wiki/concepts/flight-operations/baggage-handling.md b/airport-wiki/concepts/flight-operations/baggage-handling.md deleted file mode 100644 index 89815c8..0000000 --- a/airport-wiki/concepts/flight-operations/baggage-handling.md +++ /dev/null @@ -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]] — 航班动态影响行李中转分拣时机 diff --git a/airport-wiki/concepts/flight-operations/biometric-corridors.md b/airport-wiki/concepts/flight-operations/biometric-corridors.md deleted file mode 100644 index bd7db38..0000000 --- a/airport-wiki/concepts/flight-operations/biometric-corridors.md +++ /dev/null @@ -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]] — 生物特徵走廊與智能登機口密切相關 diff --git a/airport-wiki/concepts/flight-operations/deicing-operations.md b/airport-wiki/concepts/flight-operations/deicing-operations.md deleted file mode 100644 index 88f3ef0..0000000 --- a/airport-wiki/concepts/flight-operations/deicing-operations.md +++ /dev/null @@ -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 体系中 diff --git a/airport-wiki/concepts/flight-operations/digital-twins-airports.md b/airport-wiki/concepts/flight-operations/digital-twins-airports.md deleted file mode 100644 index 225ba37..0000000 --- a/airport-wiki/concepts/flight-operations/digital-twins-airports.md +++ /dev/null @@ -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 能源優化的重要工具 diff --git a/airport-wiki/concepts/flight-operations/flight-data-exchange.md b/airport-wiki/concepts/flight-operations/flight-data-exchange.md deleted file mode 100644 index df266ca..0000000 --- a/airport-wiki/concepts/flight-operations/flight-data-exchange.md +++ /dev/null @@ -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 - - - - - - UA - 1815 - LAX - IAH - 2017-01-16 - 1 - - - J - OP - - 166 - 166 - - - 737 - 73Q - N77518 - 518 - - - - 70A - - - E8 - C5 - - - 2017-01-16T14:28:00Z - 2017-01-16T14:41:00Z - 2017-01-16T17:27:00Z - 2017-01-16T17:33:00Z - - - -``` - -### 航班唯一标识（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"`=显式清空；空元素（如 ``）可能引发校验错误。 - -### 技术规范 - -| 项目 | 要求 | -|------|------| -| 字符编码 | 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]] — 行李数据也通过类似报文标准交换 diff --git a/airport-wiki/concepts/flight-operations/future-airport-info-center.md b/airport-wiki/concepts/flight-operations/future-airport-info-center.md deleted file mode 100644 index cb6af8d..0000000 --- a/airport-wiki/concepts/flight-operations/future-airport-info-center.md +++ /dev/null @@ -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]] — 通用設計是信息中心無障礙服務的核心理念 diff --git a/airport-wiki/concepts/flight-operations/open-architecture.md b/airport-wiki/concepts/flight-operations/open-architecture.md deleted file mode 100644 index 550c39d..0000000 --- a/airport-wiki/concepts/flight-operations/open-architecture.md +++ /dev/null @@ -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/) diff --git a/airport-wiki/concepts/flight-operations/smart-gating.md b/airport-wiki/concepts/flight-operations/smart-gating.md deleted file mode 100644 index e2fbb95..0000000 --- a/airport-wiki/concepts/flight-operations/smart-gating.md +++ /dev/null @@ -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]] — 除冰作业影响航班推出时间，影响机位占用时长 diff --git a/airport-wiki/concepts/flight-operations/smgcs.md b/airport-wiki/concepts/flight-operations/smgcs.md deleted file mode 100644 index 199d9a9..0000000 --- a/airport-wiki/concepts/flight-operations/smgcs.md +++ /dev/null @@ -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]] — 机位分配与场面活动联动 diff --git a/airport-wiki/concepts/flight-operations/universal-design-airports.md b/airport-wiki/concepts/flight-operations/universal-design-airports.md deleted file mode 100644 index 9eee71d..0000000 --- a/airport-wiki/concepts/flight-operations/universal-design-airports.md +++ /dev/null @@ -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 在無障礙領域的具體實踐 diff --git a/airport-wiki/concepts/knowledge-management/automation-hooks.md b/airport-wiki/concepts/knowledge-management/automation-hooks.md deleted file mode 100644 index 1014b9f..0000000 --- a/airport-wiki/concepts/knowledge-management/automation-hooks.md +++ /dev/null @@ -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。 \ No newline at end of file diff --git a/airport-wiki/concepts/knowledge-management/knowledge-graph.md b/airport-wiki/concepts/knowledge-management/knowledge-graph.md deleted file mode 100644 index 4f14f57..0000000 --- a/airport-wiki/concepts/knowledge-management/knowledge-graph.md +++ /dev/null @@ -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 集群的依赖关系 diff --git a/airport-wiki/concepts/knowledge-management/knowledge-lifecycle.md b/airport-wiki/concepts/knowledge-management/knowledge-lifecycle.md deleted file mode 100644 index 41fca52..0000000 --- a/airport-wiki/concepts/knowledge-management/knowledge-lifecycle.md +++ /dev/null @@ -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。 \ No newline at end of file diff --git a/airport-wiki/concepts/knowledge-management/llm-wiki-v2-reference.md b/airport-wiki/concepts/knowledge-management/llm-wiki-v2-reference.md deleted file mode 100644 index 8a41442..0000000 --- a/airport-wiki/concepts/knowledge-management/llm-wiki-v2-reference.md +++ /dev/null @@ -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 -> **维护状态**: 活跃 | **支持**: 用户文档 + 技术支持论坛 -> **注意**: 本系统持续演进，建议定期查看相关文档获取最新信息。 \ No newline at end of file diff --git a/airport-wiki/concepts/knowledge-management/memory-lifecycle.md b/airport-wiki/concepts/knowledge-management/memory-lifecycle.md deleted file mode 100644 index a1f9dd5..0000000 --- a/airport-wiki/concepts/knowledge-management/memory-lifecycle.md +++ /dev/null @@ -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 相关的量化指标） diff --git a/airport-wiki/concepts/knowledge-management/quality-control.md b/airport-wiki/concepts/knowledge-management/quality-control.md deleted file mode 100644 index 9ddeb7c..0000000 --- a/airport-wiki/concepts/knowledge-management/quality-control.md +++ /dev/null @@ -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。 \ No newline at end of file diff --git a/airport-wiki/concepts/knowledge-management/wiki-operations.md b/airport-wiki/concepts/knowledge-management/wiki-operations.md deleted file mode 100644 index 025d54f..0000000 --- a/airport-wiki/concepts/knowledge-management/wiki-operations.md +++ /dev/null @@ -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） diff --git a/airport-wiki/concepts/tech-infrastructure/airport-data-center-overview.md b/airport-wiki/concepts/tech-infrastructure/airport-data-center-overview.md deleted file mode 100644 index d3eed30..0000000 --- a/airport-wiki/concepts/tech-infrastructure/airport-data-center-overview.md +++ /dev/null @@ -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]] — 供配电与制冷 diff --git a/airport-wiki/concepts/tech-infrastructure/commissioning.md b/airport-wiki/concepts/tech-infrastructure/commissioning.md deleted file mode 100644 index c887095..0000000 --- a/airport-wiki/concepts/tech-infrastructure/commissioning.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/construction-management.md b/airport-wiki/concepts/tech-infrastructure/construction-management.md deleted file mode 100644 index 08c5d78..0000000 --- a/airport-wiki/concepts/tech-infrastructure/construction-management.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/design-phase.md b/airport-wiki/concepts/tech-infrastructure/design-phase.md deleted file mode 100644 index 8b34afa..0000000 --- a/airport-wiki/concepts/tech-infrastructure/design-phase.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/glossary.md b/airport-wiki/concepts/tech-infrastructure/glossary.md deleted file mode 100644 index dc9bb91..0000000 --- a/airport-wiki/concepts/tech-infrastructure/glossary.md +++ /dev/null @@ -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]]（數據中心子系統全圖） diff --git a/airport-wiki/concepts/tech-infrastructure/gpu-cluster.md b/airport-wiki/concepts/tech-infrastructure/gpu-cluster.md deleted file mode 100644 index 4ba3420..0000000 --- a/airport-wiki/concepts/tech-infrastructure/gpu-cluster.md +++ /dev/null @@ -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` diff --git a/airport-wiki/concepts/tech-infrastructure/modern-airport-trends.md b/airport-wiki/concepts/tech-infrastructure/modern-airport-trends.md deleted file mode 100644 index 3f3665c..0000000 --- a/airport-wiki/concepts/tech-infrastructure/modern-airport-trends.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/network-architecture.md b/airport-wiki/concepts/tech-infrastructure/network-architecture.md deleted file mode 100644 index 730b4d8..0000000 --- a/airport-wiki/concepts/tech-infrastructure/network-architecture.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/operation-maintenance.md b/airport-wiki/concepts/tech-infrastructure/operation-maintenance.md deleted file mode 100644 index 9f0a0a7..0000000 --- a/airport-wiki/concepts/tech-infrastructure/operation-maintenance.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/power-and-cooling.md b/airport-wiki/concepts/tech-infrastructure/power-and-cooling.md deleted file mode 100644 index be4a534..0000000 --- a/airport-wiki/concepts/tech-infrastructure/power-and-cooling.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/prefab-modular-dc.md b/airport-wiki/concepts/tech-infrastructure/prefab-modular-dc.md deleted file mode 100644 index 45e8977..0000000 --- a/airport-wiki/concepts/tech-infrastructure/prefab-modular-dc.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/rfp-and-vendor-selection.md b/airport-wiki/concepts/tech-infrastructure/rfp-and-vendor-selection.md deleted file mode 100644 index de9b94b..0000000 --- a/airport-wiki/concepts/tech-infrastructure/rfp-and-vendor-selection.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/security-design.md b/airport-wiki/concepts/tech-infrastructure/security-design.md deleted file mode 100644 index 4436ae9..0000000 --- a/airport-wiki/concepts/tech-infrastructure/security-design.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/site-planning.md b/airport-wiki/concepts/tech-infrastructure/site-planning.md deleted file mode 100644 index 7a5ad0b..0000000 --- a/airport-wiki/concepts/tech-infrastructure/site-planning.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/tier-iii-design.md b/airport-wiki/concepts/tech-infrastructure/tier-iii-design.md deleted file mode 100644 index 2b4a0cc..0000000 --- a/airport-wiki/concepts/tech-infrastructure/tier-iii-design.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/concepts/tech-infrastructure/tier-iv-design.md b/airport-wiki/concepts/tech-infrastructure/tier-iv-design.md deleted file mode 100644 index a3b9650..0000000 --- a/airport-wiki/concepts/tech-infrastructure/tier-iv-design.md +++ /dev/null @@ -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]] diff --git a/airport-wiki/entities/fuzhou-changle-airport-bsj.md b/airport-wiki/entities/fuzhou-changle-airport-bsj.md deleted file mode 100644 index 4aa90e5..0000000 --- a/airport-wiki/entities/fuzhou-changle-airport-bsj.md +++ /dev/null @@ -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服务器"表述模糊 -- 目前处于在建状态，核心硬件配置待投产时披露 diff --git a/airport-wiki/entities/index.md b/airport-wiki/entities/index.md deleted file mode 100644 index a172705..0000000 --- a/airport-wiki/entities/index.md +++ /dev/null @@ -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。 \ No newline at end of file diff --git a/airport-wiki/entities/jfk-airport.md b/airport-wiki/entities/jfk-airport.md deleted file mode 100644 index aa1d405..0000000 --- a/airport-wiki/entities/jfk-airport.md +++ /dev/null @@ -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 的沉浸式設計體現人本設計理念 diff --git a/airport-wiki/entities/pittsburgh-airport.md b/airport-wiki/entities/pittsburgh-airport.md deleted file mode 100644 index a064b4d..0000000 --- a/airport-wiki/entities/pittsburgh-airport.md +++ /dev/null @@ -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]] — 通用設計是人本設計在身體無障礙維度的具體落地 diff --git a/airport-wiki/entities/rome-fiumicino-airport.md b/airport-wiki/entities/rome-fiumicino-airport.md deleted file mode 100644 index 84bf958..0000000 --- a/airport-wiki/entities/rome-fiumicino-airport.md +++ /dev/null @@ -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 的典型應用形式 diff --git a/airport-wiki/entities/shenzhen-airport.md b/airport-wiki/entities/shenzhen-airport.md deleted file mode 100644 index 0a4b83e..0000000 --- a/airport-wiki/entities/shenzhen-airport.md +++ /dev/null @@ -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卡数）未披露 -- 液冷技术是否使用未提及 -- 属于"国产算力+开源大模型"标杆案例 diff --git a/airport-wiki/entities/singapore-changi-airport.md b/airport-wiki/entities/singapore-changi-airport.md deleted file mode 100644 index c322fbd..0000000 --- a/airport-wiki/entities/singapore-changi-airport.md +++ /dev/null @@ -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 進一步強化 diff --git a/airport-wiki/entities/zhengzhou-airport-hangang.md b/airport-wiki/entities/zhengzhou-airport-hangang.md deleted file mode 100644 index 6da2732..0000000 --- a/airport-wiki/entities/zhengzhou-airport-hangang.md +++ /dev/null @@ -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型号、机柜数、功率）未披露 -- 三中心"十万卡"仍为规划阶段 -- 适合作为机场临空经济区智算集群选址对标 diff --git a/airport-wiki/hybrid-search.md b/airport-wiki/hybrid-search.md deleted file mode 100644 index 073020e..0000000 --- a/airport-wiki/hybrid-search.md +++ /dev/null @@ -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。 \ No newline at end of file diff --git a/airport-wiki/index.md b/airport-wiki/index.md deleted file mode 100644 index 47776ae..0000000 --- a/airport-wiki/index.md +++ /dev/null @@ -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/]] 了解更多。 - ---- - diff --git a/airport-wiki/log.md b/airport-wiki/log.md deleted file mode 100644 index c9c1df4..0000000 --- a/airport-wiki/log.md +++ /dev/null @@ -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 - - diff --git a/airport-wiki/package-lock.json b/airport-wiki/package-lock.json deleted file mode 100644 index 46b8832..0000000 --- a/airport-wiki/package-lock.json +++ /dev/null @@ -1,1645 +0,0 @@ -{ - "name": "wiki", - "lockfileVersion": 3, - "requires": true, - "packages": { - "": { - "devDependencies": { - "markdownlint": "^0.37.0", - "markdownlint-cli": "^0.32.2", - "markdownlint-cli2": "^0.22.0" - } - }, - "node_modules/@nodelib/fs.scandir": { - "version": "2.1.5", - "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.5.tgz", - "integrity": "sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==", - "dev": true, - "dependencies": { - "@nodelib/fs.stat": "2.0.5", - "run-parallel": "^1.1.9" - }, - "engines": { - "node": ">= 8" - } - }, - "node_modules/@nodelib/fs.stat": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.5.tgz", - "integrity": "sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==", - "dev": true, - "engines": { - "node": ">= 8" - } - }, - "node_modules/@nodelib/fs.walk": { - "version": "1.2.8", - "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.8.tgz", - "integrity": "sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==", - "dev": true, - "dependencies": { - "@nodelib/fs.scandir": "2.1.5", - "fastq": "^1.6.0" - }, - "engines": { - "node": ">= 8" - } - }, - "node_modules/@sindresorhus/merge-streams": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/@sindresorhus/merge-streams/-/merge-streams-4.0.0.tgz", - "integrity": "sha512-tlqY9xq5ukxTUZBmoOp+m61cqwQD5pHJtFY3Mn8CA8ps6yghLH/Hw8UPdqg4OLmFW3IFlcXnQNmo/dh8HzXYIQ==", - "dev": true, - "engines": { - "node": ">=18" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/@types/debug": { - "version": "4.1.13", - "resolved": "https://registry.npmjs.org/@types/debug/-/debug-4.1.13.tgz", - "integrity": "sha512-KSVgmQmzMwPlmtljOomayoR89W4FynCAi3E8PPs7vmDVPe84hT+vGPKkJfThkmXs0x0jAaa9U8uW8bbfyS2fWw==", - "dev": true, - "dependencies": { - "@types/ms": "*" - } - }, - "node_modules/@types/katex": { - "version": "0.16.8", - "resolved": "https://registry.npmjs.org/@types/katex/-/katex-0.16.8.tgz", - "integrity": "sha512-trgaNyfU+Xh2Tc+ABIb44a5AYUpicB3uwirOioeOkNPPbmgRNtcWyDeeFRzjPZENO9Vq8gvVqfhaaXWLlevVwg==", - "dev": true - }, - "node_modules/@types/ms": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/@types/ms/-/ms-2.1.0.tgz", - "integrity": "sha512-GsCCIZDE/p3i96vtEqx+7dBUGXrc7zeSK3wwPHIaRThS+9OhWIXRqzs4d6k1SVU8g91DrNRWxWUGhp5KXQb2VA==", - "dev": true - }, - "node_modules/@types/unist": { - "version": "2.0.11", - "resolved": "https://registry.npmjs.org/@types/unist/-/unist-2.0.11.tgz", - "integrity": "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==", - "dev": true - }, - "node_modules/ansi-regex": { - "version": "6.2.2", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-6.2.2.tgz", - "integrity": "sha512-Bq3SmSpyFHaWjPk8If9yc6svM8c56dB5BAtW4Qbw5jHTwwXXcTLoRMkpDJp6VL0XzlWaCHTXrkFURMYmD0sLqg==", - "dev": true, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/ansi-regex?sponsor=1" - } - }, - "node_modules/argparse": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", - "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", - "dev": true - }, - "node_modules/balanced-match": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.2.tgz", - "integrity": "sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==", - "dev": true - }, - "node_modules/brace-expansion": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-2.0.3.tgz", - "integrity": "sha512-MCV/fYJEbqx68aE58kv2cA/kiky1G8vux3OR6/jbS+jIMe/6fJWa0DTzJU7dqijOWYwHi1t29FlfYI9uytqlpA==", - "dev": true, - "dependencies": { - "balanced-match": "^1.0.0" - } - }, - "node_modules/braces": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.3.tgz", - "integrity": "sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==", - "dev": true, - "dependencies": { - "fill-range": "^7.1.1" - }, - "engines": { - "node": ">=8" - } - }, - "node_modules/character-entities": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/character-entities/-/character-entities-2.0.2.tgz", - "integrity": "sha512-shx7oQ0Awen/BRIdkjkvz54PnEEI/EjwXDSIZp86/KKdbafHh1Df/RYGBhn4hbe2+uKC9FnT5UCEdyPz3ai9hQ==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/character-entities-legacy": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/character-entities-legacy/-/character-entities-legacy-3.0.0.tgz", - "integrity": "sha512-RpPp0asT/6ufRm//AJVwpViZbGM/MkjQFxJccQRHmISF/22NBtsHqAWmL+/pmkPWoIUJdWyeVleTl1wydHATVQ==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/character-reference-invalid": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/character-reference-invalid/-/character-reference-invalid-2.0.1.tgz", - "integrity": "sha512-iBZ4F4wRbyORVsu0jPV7gXkOsGYjGHPmAyv+HiHG8gi5PtC9KI2j1+v8/tlibRvjoWX027ypmG/n0HtO5t7unw==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/commander": { - "version": "8.3.0", - "resolved": "https://registry.npmjs.org/commander/-/commander-8.3.0.tgz", - "integrity": "sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww==", - "dev": true, - "engines": { - "node": ">= 12" - } - }, - "node_modules/debug": { - "version": "4.4.3", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.4.3.tgz", - "integrity": "sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==", - "dev": true, - "dependencies": { - "ms": "^2.1.3" - }, - "engines": { - "node": ">=6.0" - }, - "peerDependenciesMeta": { - "supports-color": { - "optional": true - } - } - }, - "node_modules/decode-named-character-reference": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/decode-named-character-reference/-/decode-named-character-reference-1.3.0.tgz", - "integrity": "sha512-GtpQYB283KrPp6nRw50q3U9/VfOutZOe103qlN7BPP6Ad27xYnOIWv4lPzo8HCAL+mMZofJ9KEy30fq6MfaK6Q==", - "dev": true, - "dependencies": { - "character-entities": "^2.0.0" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/deep-extend": { - "version": "0.6.0", - "resolved": "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz", - "integrity": "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==", - "dev": true, - "engines": { - "node": ">=4.0.0" - } - }, - "node_modules/dequal": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/dequal/-/dequal-2.0.3.tgz", - "integrity": "sha512-0je+qPKHEMohvfRTCEo3CrPG6cAzAYgmzKyxRiYSSDkS6eGJdyVJm7WaYA5ECaAD9wLB2T4EEeymA5aFVcYXCA==", - "dev": true, - "engines": { - "node": ">=6" - } - }, - "node_modules/devlop": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/devlop/-/devlop-1.1.0.tgz", - "integrity": "sha512-RWmIqhcFf1lRYBvNmr7qTNuyCt/7/ns2jbpp1+PalgE/rDQcBT0fioSMUpJ93irlUhC5hrg4cYqe6U+0ImW0rA==", - "dev": true, - "dependencies": { - "dequal": "^2.0.0" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/entities": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz", - "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==", - "dev": true, - "engines": { - "node": ">=0.12" - }, - "funding": { - "url": "https://github.com/fb55/entities?sponsor=1" - } - }, - "node_modules/fast-glob": { - "version": "3.3.3", - "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.3.3.tgz", - "integrity": "sha512-7MptL8U0cqcFdzIzwOTHoilX9x5BrNqye7Z/LuC7kCMRio1EMSyqRK3BEAUD7sXRq4iT4AzTVuZdhgQ2TCvYLg==", - "dev": true, - "dependencies": { - "@nodelib/fs.stat": "^2.0.2", - "@nodelib/fs.walk": "^1.2.3", - "glob-parent": "^5.1.2", - "merge2": "^1.3.0", - "micromatch": "^4.0.8" - }, - "engines": { - "node": ">=8.6.0" - } - }, - "node_modules/fastq": { - "version": "1.20.1", - "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.20.1.tgz", - "integrity": "sha512-GGToxJ/w1x32s/D2EKND7kTil4n8OVk/9mycTc4VDza13lOvpUZTGX3mFSCtV9ksdGBVzvsyAVLM6mHFThxXxw==", - "dev": true, - "dependencies": { - "reusify": "^1.0.4" - } - }, - "node_modules/fill-range": { - "version": "7.1.1", - "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.1.1.tgz", - "integrity": "sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==", - "dev": true, - "dependencies": { - "to-regex-range": "^5.0.1" - }, - "engines": { - "node": ">=8" - } - }, - "node_modules/fs.realpath": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", - "integrity": "sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==", - "dev": true - }, - "node_modules/get-east-asian-width": { - "version": "1.5.0", - "resolved": "https://registry.npmjs.org/get-east-asian-width/-/get-east-asian-width-1.5.0.tgz", - "integrity": "sha512-CQ+bEO+Tva/qlmw24dCejulK5pMzVnUOFOijVogd3KQs07HnRIgp8TGipvCCRT06xeYEbpbgwaCxglFyiuIcmA==", - "dev": true, - "engines": { - "node": ">=18" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/get-stdin": { - "version": "9.0.0", - "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-9.0.0.tgz", - "integrity": "sha512-dVKBjfWisLAicarI2Sf+JuBE/DghV4UzNAVe9yhEJuzeREd3JhOTE9cUaJTeSa77fsbQUK3pcOpJfM59+VKZaA==", - "dev": true, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/glob": { - "version": "8.0.3", - "resolved": "https://registry.npmjs.org/glob/-/glob-8.0.3.tgz", - "integrity": "sha512-ull455NHSHI/Y1FqGaaYFaLGkNMMJbavMrEGFXG/PGrg6y7sutWHUHrz6gy6WEBH6akM1M414dWKCNs+IhKdiQ==", - "deprecated": "Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me", - "dev": true, - "dependencies": { - "fs.realpath": "^1.0.0", - "inflight": "^1.0.4", - "inherits": "2", - "minimatch": "^5.0.1", - "once": "^1.3.0" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/sponsors/isaacs" - } - }, - "node_modules/glob-parent": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz", - "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==", - "dev": true, - "dependencies": { - "is-glob": "^4.0.1" - }, - "engines": { - "node": ">= 6" - } - }, - "node_modules/globby": { - "version": "16.1.1", - "resolved": "https://registry.npmjs.org/globby/-/globby-16.1.1.tgz", - "integrity": "sha512-dW7vl+yiAJSp6aCekaVnVJxurRv7DCOLyXqEG3RYMYUg7AuJ2jCqPkZTA8ooqC2vtnkaMcV5WfFBMuEnTu1OQg==", - "dev": true, - "dependencies": { - "@sindresorhus/merge-streams": "^4.0.0", - "fast-glob": "^3.3.3", - "ignore": "^7.0.5", - "is-path-inside": "^4.0.0", - "slash": "^5.1.0", - "unicorn-magic": "^0.4.0" - }, - "engines": { - "node": ">=20" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/ignore": { - "version": "7.0.5", - "resolved": "https://registry.npmjs.org/ignore/-/ignore-7.0.5.tgz", - "integrity": "sha512-Hs59xBNfUIunMFgWAbGX5cq6893IbWg4KnrjbYwX3tx0ztorVgTDA6B2sxf8ejHJ4wz8BqGUMYlnzNBer5NvGg==", - "dev": true, - "engines": { - "node": ">= 4" - } - }, - "node_modules/inflight": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", - "integrity": "sha512-k92I/b08q4wvFscXCLvqfsHCrjrF7yiXsQuIVvVE7N82W3+aqpzuUdBbfhWcy/FZR3/4IgflMgKLOsvPDrGCJA==", - "deprecated": "This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.", - "dev": true, - "dependencies": { - "once": "^1.3.0", - "wrappy": "1" - } - }, - "node_modules/inherits": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", - "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==", - "dev": true - }, - "node_modules/ini": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/ini/-/ini-3.0.1.tgz", - "integrity": "sha512-it4HyVAUTKBc6m8e1iXWvXSTdndF7HbdN713+kvLrymxTaU4AUBWrJ4vEooP+V7fexnVD3LKcBshjGGPefSMUQ==", - "dev": true, - "engines": { - "node": "^12.13.0 || ^14.15.0 || >=16.0.0" - } - }, - "node_modules/is-alphabetical": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/is-alphabetical/-/is-alphabetical-2.0.1.tgz", - "integrity": "sha512-FWyyY60MeTNyeSRpkM2Iry0G9hpr7/9kD40mD/cGQEuilcZYS4okz8SN2Q6rLCJ8gbCt6fN+rC+6tMGS99LaxQ==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/is-alphanumerical": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/is-alphanumerical/-/is-alphanumerical-2.0.1.tgz", - "integrity": "sha512-hmbYhX/9MUMF5uh7tOXyK/n0ZvWpad5caBA17GsC6vyuCqaWliRG5K1qS9inmUhEMaOBIW7/whAnSwveW/LtZw==", - "dev": true, - "dependencies": { - "is-alphabetical": "^2.0.0", - "is-decimal": "^2.0.0" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/is-decimal": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/is-decimal/-/is-decimal-2.0.1.tgz", - "integrity": "sha512-AAB9hiomQs5DXWcRB1rqsxGUstbRroFOPPVAomNk/3XHR5JyEZChOyTWe2oayKnsSsr/kcGqF+z6yuH6HHpN0A==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/is-extglob": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", - "integrity": "sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==", - "dev": true, - "engines": { - "node": ">=0.10.0" - } - }, - "node_modules/is-glob": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.3.tgz", - "integrity": "sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==", - "dev": true, - "dependencies": { - "is-extglob": "^2.1.1" - }, - "engines": { - "node": ">=0.10.0" - } - }, - "node_modules/is-hexadecimal": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/is-hexadecimal/-/is-hexadecimal-2.0.1.tgz", - "integrity": "sha512-DgZQp241c8oO6cA1SbTEWiXeoxV42vlcJxgH+B3hi1AiqqKruZR3ZGF8In3fj4+/y/7rHvlOZLZtgJ/4ttYGZg==", - "dev": true, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/is-number": { - "version": "7.0.0", - "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", - "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", - "dev": true, - "engines": { - "node": ">=0.12.0" - } - }, - "node_modules/is-path-inside": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-4.0.0.tgz", - "integrity": "sha512-lJJV/5dYS+RcL8uQdBDW9c9uWFLLBNRyFhnAKXw5tVqLlKZ4RMGZKv+YQ/IA3OhD+RpbJa1LLFM1FQPGyIXvOA==", - "dev": true, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/js-yaml": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.1.tgz", - "integrity": "sha512-qQKT4zQxXl8lLwBtHMWwaTcGfFOZviOJet3Oy/xmGk2gZH677CJM9EvtfdSkgWcATZhj/55JZ0rmy3myCT5lsA==", - "dev": true, - "dependencies": { - "argparse": "^2.0.1" - }, - "bin": { - "js-yaml": "bin/js-yaml.js" - } - }, - "node_modules/jsonc-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.3.1.tgz", - "integrity": "sha512-HUgH65KyejrUFPvHFPbqOY0rsFip3Bo5wb4ngvdi1EpCYWUQDC5V+Y7mZws+DLkr4M//zQJoanu1SP+87Dv1oQ==", - "dev": true - }, - "node_modules/jsonpointer": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/jsonpointer/-/jsonpointer-5.0.1.tgz", - "integrity": "sha512-p/nXbhSEcu3pZRdkW1OfJhpsVtW1gd4Wa1fnQc9YLiTfAjn0312eMKimbdIQzuZl9aa9xUGaRlP9T/CJE/ditQ==", - "dev": true, - "engines": { - "node": ">=0.10.0" - } - }, - "node_modules/katex": { - "version": "0.16.45", - "resolved": "https://registry.npmjs.org/katex/-/katex-0.16.45.tgz", - "integrity": "sha512-pQpZbdBu7wCTmQUh7ufPmLr0pFoObnGUoL/yhtwJDgmmQpbkg/0HSVti25Fu4rmd1oCR6NGWe9vqTWuWv3GcNA==", - "dev": true, - "funding": [ - "https://opencollective.com/katex", - "https://github.com/sponsors/katex" - ], - "dependencies": { - "commander": "^8.3.0" - }, - "bin": { - "katex": "cli.js" - } - }, - "node_modules/linkify-it": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz", - "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==", - "dev": true, - "dependencies": { - "uc.micro": "^2.0.0" - } - }, - "node_modules/markdown-it": { - "version": "14.1.1", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.1.tgz", - "integrity": "sha512-BuU2qnTti9YKgK5N+IeMubp14ZUKUUw7yeJbkjtosvHiP0AZ5c8IAgEMk79D0eC8F23r4Ac/q8cAIFdm2FtyoA==", - "dev": true, - "dependencies": { - "argparse": "^2.0.1", - "entities": "^4.4.0", - "linkify-it": "^5.0.0", - "mdurl": "^2.0.0", - "punycode.js": "^2.3.1", - "uc.micro": "^2.1.0" - }, - "bin": { - "markdown-it": "bin/markdown-it.mjs" - } - }, - "node_modules/markdownlint": { - "version": "0.37.0", - "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.37.0.tgz", - "integrity": "sha512-kdw5PG3dQFkExmUdcNc7dVTxrQU+lBx2+HuNrfa/gaRHzHExQNGdTTtvz0YtpFabKijbs5a3rVlLY75x/6VB7A==", - "dev": true, - "dependencies": { - "markdown-it": "14.1.0", - "micromark": "4.0.1", - "micromark-extension-directive": "3.0.2", - "micromark-extension-gfm-autolink-literal": "2.1.0", - "micromark-extension-gfm-footnote": "2.1.0", - "micromark-extension-gfm-table": "2.1.0", - "micromark-extension-math": "3.1.0", - "micromark-util-types": "2.0.1" - }, - "engines": { - "node": ">=18" - }, - "funding": { - "url": "https://github.com/sponsors/DavidAnson" - } - }, - "node_modules/markdownlint-cli": { - "version": "0.32.2", - "resolved": "https://registry.npmjs.org/markdownlint-cli/-/markdownlint-cli-0.32.2.tgz", - "integrity": "sha512-xmJT1rGueUgT4yGNwk6D0oqQr90UJ7nMyakXtqjgswAkEhYYqjHew9RY8wDbOmh2R270IWjuKSeZzHDEGPAUkQ==", - "dev": true, - "dependencies": { - "commander": "~9.4.0", - "get-stdin": "~9.0.0", - "glob": "~8.0.3", - "ignore": "~5.2.0", - "js-yaml": "^4.1.0", - "jsonc-parser": "~3.1.0", - "markdownlint": "~0.26.2", - "markdownlint-rule-helpers": "~0.17.2", - "minimatch": "~5.1.0", - "run-con": "~1.2.11" - }, - "bin": { - "markdownlint": "markdownlint.js" - }, - "engines": { - "node": ">=14" - } - }, - "node_modules/markdownlint-cli/node_modules/commander": { - "version": "9.4.1", - "resolved": "https://registry.npmjs.org/commander/-/commander-9.4.1.tgz", - "integrity": "sha512-5EEkTNyHNGFPD2H+c/dXXfQZYa/scCKasxWcXJaWnNJ99pnQN9Vnmqow+p+PlFPE63Q6mThaZws1T+HxfpgtPw==", - "dev": true, - "engines": { - "node": "^12.20.0 || >=14" - } - }, - "node_modules/markdownlint-cli/node_modules/entities": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/entities/-/entities-3.0.1.tgz", - "integrity": "sha512-WiyBqoomrwMdFG1e0kqvASYfnlb0lp8M5o5Fw2OFq1hNZxxcNk8Ik0Xm7LxzBhuidnZB/UtBqVCgUz3kBOP51Q==", - "dev": true, - "engines": { - "node": ">=0.12" - }, - "funding": { - "url": "https://github.com/fb55/entities?sponsor=1" - } - }, - "node_modules/markdownlint-cli/node_modules/ignore": { - "version": "5.2.4", - "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.2.4.tgz", - "integrity": "sha512-MAb38BcSbH0eHNBxn7ql2NH/kX33OkB3lZ1BNdh7ENeRChHTYsTvWrMubiIAMNS2llXEEgZ1MUOBtXChP3kaFQ==", - "dev": true, - "engines": { - "node": ">= 4" - } - }, - "node_modules/markdownlint-cli/node_modules/jsonc-parser": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.1.0.tgz", - "integrity": "sha512-DRf0QjnNeCUds3xTjKlQQ3DpJD51GvDjJfnxUVWg6PZTo2otSm+slzNAxU/35hF8/oJIKoG9slq30JYOsF2azg==", - "dev": true - }, - "node_modules/markdownlint-cli/node_modules/linkify-it": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-4.0.1.tgz", - "integrity": "sha512-C7bfi1UZmoj8+PQx22XyeXCuBlokoyWQL5pWSP+EI6nzRylyThouddufc2c1NDIcP9k5agmN9fLpA7VNJfIiqw==", - "dev": true, - "dependencies": { - "uc.micro": "^1.0.1" - } - }, - "node_modules/markdownlint-cli/node_modules/markdown-it": { - "version": "13.0.1", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-13.0.1.tgz", - "integrity": "sha512-lTlxriVoy2criHP0JKRhO2VDG9c2ypWCsT237eDiLqi09rmbKoUetyGHq2uOIRoRS//kfoJckS0eUzzkDR+k2Q==", - "dev": true, - "dependencies": { - "argparse": "^2.0.1", - "entities": "~3.0.1", - "linkify-it": "^4.0.1", - "mdurl": "^1.0.1", - "uc.micro": "^1.0.5" - }, - "bin": { - "markdown-it": "bin/markdown-it.js" - } - }, - "node_modules/markdownlint-cli/node_modules/markdownlint": { - "version": "0.26.2", - "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.26.2.tgz", - "integrity": "sha512-2Am42YX2Ex5SQhRq35HxYWDfz1NLEOZWWN25nqd2h3AHRKsGRE+Qg1gt1++exW792eXTrR4jCNHfShfWk9Nz8w==", - "dev": true, - "dependencies": { - "markdown-it": "13.0.1" - }, - "engines": { - "node": ">=14" - } - }, - "node_modules/markdownlint-cli/node_modules/mdurl": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz", - "integrity": "sha512-/sKlQJCBYVY9Ers9hqzKou4H6V5UWc/M59TH2dvkt+84itfnq7uFOMLpOiOS4ujvHP4etln18fmIxA5R5fll0g==", - "dev": true - }, - "node_modules/markdownlint-cli/node_modules/uc.micro": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz", - "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==", - "dev": true - }, - "node_modules/markdownlint-cli2": { - "version": "0.22.0", - "resolved": "https://registry.npmjs.org/markdownlint-cli2/-/markdownlint-cli2-0.22.0.tgz", - "integrity": "sha512-mOC9BY/XGtdX3M9n3AgERd79F0+S7w18yBBTNIQ453sI87etZfp1z4eajqSMV70CYjbxKe5ktKvT2HCpvcWx9w==", - "dev": true, - "dependencies": { - "globby": "16.1.1", - "js-yaml": "4.1.1", - "jsonc-parser": "3.3.1", - "jsonpointer": "5.0.1", - "markdown-it": "14.1.1", - "markdownlint": "0.40.0", - "markdownlint-cli2-formatter-default": "0.0.6", - "micromatch": "4.0.8", - "smol-toml": "1.6.0" - }, - "bin": { - "markdownlint-cli2": "markdownlint-cli2-bin.mjs" - }, - "engines": { - "node": ">=20" - }, - "funding": { - "url": "https://github.com/sponsors/DavidAnson" - } - }, - "node_modules/markdownlint-cli2-formatter-default": { - "version": "0.0.6", - "resolved": "https://registry.npmjs.org/markdownlint-cli2-formatter-default/-/markdownlint-cli2-formatter-default-0.0.6.tgz", - "integrity": "sha512-VVDGKsq9sgzu378swJ0fcHfSicUnMxnL8gnLm/Q4J/xsNJ4e5bA6lvAz7PCzIl0/No0lHyaWdqVD2jotxOSFMQ==", - "dev": true, - "funding": { - "url": "https://github.com/sponsors/DavidAnson" - }, - "peerDependencies": { - "markdownlint-cli2": ">=0.0.4" - } - }, - "node_modules/markdownlint-cli2/node_modules/markdownlint": { - "version": "0.40.0", - "resolved": "https://registry.npmjs.org/markdownlint/-/markdownlint-0.40.0.tgz", - "integrity": "sha512-UKybllYNheWac61Ia7T6fzuQNDZimFIpCg2w6hHjgV1Qu0w1TV0LlSgryUGzM0bkKQCBhy2FDhEELB73Kb0kAg==", - "dev": true, - "dependencies": { - "micromark": "4.0.2", - "micromark-core-commonmark": "2.0.3", - "micromark-extension-directive": "4.0.0", - "micromark-extension-gfm-autolink-literal": "2.1.0", - "micromark-extension-gfm-footnote": "2.1.0", - "micromark-extension-gfm-table": "2.1.1", - "micromark-extension-math": "3.1.0", - "micromark-util-types": "2.0.2", - "string-width": "8.1.0" - }, - "engines": { - "node": ">=20" - }, - "funding": { - "url": "https://github.com/sponsors/DavidAnson" - } - }, - "node_modules/markdownlint-cli2/node_modules/micromark": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.2.tgz", - "integrity": "sha512-zpe98Q6kvavpCr1NPVSCMebCKfD7CA2NqZ+rykeNhONIJBpc1tFKt9hucLGwha3jNTNI8lHpctWJWoimVF4PfA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "@types/debug": "^4.0.0", - "debug": "^4.0.0", - "decode-named-character-reference": "^1.0.0", - "devlop": "^1.0.0", - "micromark-core-commonmark": "^2.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-chunked": "^2.0.0", - "micromark-util-combine-extensions": "^2.0.0", - "micromark-util-decode-numeric-character-reference": "^2.0.0", - "micromark-util-encode": "^2.0.0", - "micromark-util-normalize-identifier": "^2.0.0", - "micromark-util-resolve-all": "^2.0.0", - "micromark-util-sanitize-uri": "^2.0.0", - "micromark-util-subtokenize": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/markdownlint-cli2/node_modules/micromark-extension-directive": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/micromark-extension-directive/-/micromark-extension-directive-4.0.0.tgz", - "integrity": "sha512-/C2nqVmXXmiseSSuCdItCMho7ybwwop6RrrRPk0KbOHW21JKoCldC+8rFOaundDoRBUWBnJJcxeA/Kvi34WQXg==", - "dev": true, - "dependencies": { - "devlop": "^1.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-factory-whitespace": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0", - "parse-entities": "^4.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/markdownlint-cli2/node_modules/micromark-extension-gfm-table": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.1.tgz", - "integrity": "sha512-t2OU/dXXioARrC6yWfJ4hqB7rct14e8f7m0cbI5hUmDyyIlwv5vEtooptH8INkbLzOatzKuVbQmAYcbWoyz6Dg==", - "dev": true, - "dependencies": { - "devlop": "^1.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/markdownlint-rule-helpers": { - "version": "0.17.2", - "resolved": "https://registry.npmjs.org/markdownlint-rule-helpers/-/markdownlint-rule-helpers-0.17.2.tgz", - "integrity": "sha512-XaeoW2NYSlWxMCZM2B3H7YTG6nlaLfkEZWMBhr4hSPlq9MuY2sy83+Xr89jXOqZMZYjvi5nBCGoFh7hHoPKZmA==", - "dev": true, - "engines": { - "node": ">=12" - } - }, - "node_modules/markdownlint/node_modules/markdown-it": { - "version": "14.1.0", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.0.tgz", - "integrity": "sha512-a54IwgWPaeBCAAsv13YgmALOF1elABB08FxO9i+r4VFk5Vl4pKokRPeX8u5TCgSsPi6ec1otfLjdOpVcgbpshg==", - "dev": true, - "dependencies": { - "argparse": "^2.0.1", - "entities": "^4.4.0", - "linkify-it": "^5.0.0", - "mdurl": "^2.0.0", - "punycode.js": "^2.3.1", - "uc.micro": "^2.1.0" - }, - "bin": { - "markdown-it": "bin/markdown-it.mjs" - } - }, - "node_modules/markdownlint/node_modules/micromark-util-types": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-2.0.1.tgz", - "integrity": "sha512-534m2WhVTddrcKVepwmVEVnUAmtrx9bfIjNoQHRqfnvdaHQiFytEhJoTgpWJvDEXCO5gLTQh3wYC1PgOJA4NSQ==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ] - }, - "node_modules/mdurl": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz", - "integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==", - "dev": true - }, - "node_modules/merge2": { - "version": "1.4.1", - "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz", - "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==", - "dev": true, - "engines": { - "node": ">= 8" - } - }, - "node_modules/micromark": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/micromark/-/micromark-4.0.1.tgz", - "integrity": "sha512-eBPdkcoCNvYcxQOAKAlceo5SNdzZWfF+FcSupREAzdAh9rRmE239CEQAiTwIgblwnoM8zzj35sZ5ZwvSEOF6Kw==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "@types/debug": "^4.0.0", - "debug": "^4.0.0", - "decode-named-character-reference": "^1.0.0", - "devlop": "^1.0.0", - "micromark-core-commonmark": "^2.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-chunked": "^2.0.0", - "micromark-util-combine-extensions": "^2.0.0", - "micromark-util-decode-numeric-character-reference": "^2.0.0", - "micromark-util-encode": "^2.0.0", - "micromark-util-normalize-identifier": "^2.0.0", - "micromark-util-resolve-all": "^2.0.0", - "micromark-util-sanitize-uri": "^2.0.0", - "micromark-util-subtokenize": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-core-commonmark": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/micromark-core-commonmark/-/micromark-core-commonmark-2.0.3.tgz", - "integrity": "sha512-RDBrHEMSxVFLg6xvnXmb1Ayr2WzLAWjeSATAoxwKYJV94TeNavgoIdA0a9ytzDSVzBy2YKFK+emCPOEibLeCrg==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "decode-named-character-reference": "^1.0.0", - "devlop": "^1.0.0", - "micromark-factory-destination": "^2.0.0", - "micromark-factory-label": "^2.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-factory-title": "^2.0.0", - "micromark-factory-whitespace": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-chunked": "^2.0.0", - "micromark-util-classify-character": "^2.0.0", - "micromark-util-html-tag-name": "^2.0.0", - "micromark-util-normalize-identifier": "^2.0.0", - "micromark-util-resolve-all": "^2.0.0", - "micromark-util-subtokenize": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-extension-directive": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/micromark-extension-directive/-/micromark-extension-directive-3.0.2.tgz", - "integrity": "sha512-wjcXHgk+PPdmvR58Le9d7zQYWy+vKEU9Se44p2CrCDPiLr2FMyiT4Fyb5UFKFC66wGB3kPlgD7q3TnoqPS7SZA==", - "dev": true, - "dependencies": { - "devlop": "^1.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-factory-whitespace": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0", - "parse-entities": "^4.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/micromark-extension-gfm-autolink-literal": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-extension-gfm-autolink-literal/-/micromark-extension-gfm-autolink-literal-2.1.0.tgz", - "integrity": "sha512-oOg7knzhicgQ3t4QCjCWgTmfNhvQbDDnJeVu9v81r7NltNCVmhPy1fJRX27pISafdjL+SVc4d3l48Gb6pbRypw==", - "dev": true, - "dependencies": { - "micromark-util-character": "^2.0.0", - "micromark-util-sanitize-uri": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/micromark-extension-gfm-footnote": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-extension-gfm-footnote/-/micromark-extension-gfm-footnote-2.1.0.tgz", - "integrity": "sha512-/yPhxI1ntnDNsiHtzLKYnE3vf9JZ6cAisqVDauhp4CEHxlb4uoOTxOCJ+9s51bIB8U1N1FJ1RXOKTIlD5B/gqw==", - "dev": true, - "dependencies": { - "devlop": "^1.0.0", - "micromark-core-commonmark": "^2.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-normalize-identifier": "^2.0.0", - "micromark-util-sanitize-uri": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/micromark-extension-gfm-table": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-extension-gfm-table/-/micromark-extension-gfm-table-2.1.0.tgz", - "integrity": "sha512-Ub2ncQv+fwD70/l4ou27b4YzfNaCJOvyX4HxXU15m7mpYY+rjuWzsLIPZHJL253Z643RpbcP1oeIJlQ/SKW67g==", - "dev": true, - "dependencies": { - "devlop": "^1.0.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/micromark-extension-math": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/micromark-extension-math/-/micromark-extension-math-3.1.0.tgz", - "integrity": "sha512-lvEqd+fHjATVs+2v/8kg9i5Q0AP2k85H0WUOwpIVvUML8BapsMvh1XAogmQjOCsLpoKRCVQqEkQBB3NhVBcsOg==", - "dev": true, - "dependencies": { - "@types/katex": "^0.16.0", - "devlop": "^1.0.0", - "katex": "^0.16.0", - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - }, - "funding": { - "type": "opencollective", - "url": "https://opencollective.com/unified" - } - }, - "node_modules/micromark-factory-destination": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-factory-destination/-/micromark-factory-destination-2.0.1.tgz", - "integrity": "sha512-Xe6rDdJlkmbFRExpTOmRj9N3MaWmbAgdpSrBQvCFqhezUn4AHqJHbaEnfbVYYiexVSs//tqOdY/DxhjdCiJnIA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-factory-label": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-factory-label/-/micromark-factory-label-2.0.1.tgz", - "integrity": "sha512-VFMekyQExqIW7xIChcXn4ok29YE3rnuyveW3wZQWWqF4Nv9Wk5rgJ99KzPvHjkmPXF93FXIbBp6YdW3t71/7Vg==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "devlop": "^1.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-factory-space": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-factory-space/-/micromark-factory-space-2.0.1.tgz", - "integrity": "sha512-zRkxjtBxxLd2Sc0d+fbnEunsTj46SWXgXciZmHq0kDYGnck/ZSGj9/wULTV95uoeYiK5hRXP2mJ98Uo4cq/LQg==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-character": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-factory-title": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-factory-title/-/micromark-factory-title-2.0.1.tgz", - "integrity": "sha512-5bZ+3CjhAd9eChYTHsjy6TGxpOFSKgKKJPJxr293jTbfry2KDoWkhBb6TcPVB4NmzaPhMs1Frm9AZH7OD4Cjzw==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-factory-whitespace": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-factory-whitespace/-/micromark-factory-whitespace-2.0.1.tgz", - "integrity": "sha512-Ob0nuZ3PKt/n0hORHyvoD9uZhr+Za8sFoP+OnMcnWK5lngSzALgQYKMr9RJVOWLqQYuyn6ulqGWSXdwf6F80lQ==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-factory-space": "^2.0.0", - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-character": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/micromark-util-character/-/micromark-util-character-2.1.1.tgz", - "integrity": "sha512-wv8tdUTJ3thSFFFJKtpYKOYiGP2+v96Hvk4Tu8KpCAsTMs6yi+nVmGh1syvSCsaxz45J6Jbw+9DD6g97+NV67Q==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-chunked": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-chunked/-/micromark-util-chunked-2.0.1.tgz", - "integrity": "sha512-QUNFEOPELfmvv+4xiNg2sRYeS/P84pTW0TCgP5zc9FpXetHY0ab7SxKyAQCNCc1eK0459uoLI1y5oO5Vc1dbhA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-symbol": "^2.0.0" - } - }, - "node_modules/micromark-util-classify-character": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-classify-character/-/micromark-util-classify-character-2.0.1.tgz", - "integrity": "sha512-K0kHzM6afW/MbeWYWLjoHQv1sgg2Q9EccHEDzSkxiP/EaagNzCm7T/WMKZ3rjMbvIpvBiZgwR3dKMygtA4mG1Q==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-character": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-combine-extensions": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-combine-extensions/-/micromark-util-combine-extensions-2.0.1.tgz", - "integrity": "sha512-OnAnH8Ujmy59JcyZw8JSbK9cGpdVY44NKgSM7E9Eh7DiLS2E9RNQf0dONaGDzEG9yjEl5hcqeIsj4hfRkLH/Bg==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-chunked": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-decode-numeric-character-reference": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/micromark-util-decode-numeric-character-reference/-/micromark-util-decode-numeric-character-reference-2.0.2.tgz", - "integrity": "sha512-ccUbYk6CwVdkmCQMyr64dXz42EfHGkPQlBj5p7YVGzq8I7CtjXZJrubAYezf7Rp+bjPseiROqe7G6foFd+lEuw==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-symbol": "^2.0.0" - } - }, - "node_modules/micromark-util-encode": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-encode/-/micromark-util-encode-2.0.1.tgz", - "integrity": "sha512-c3cVx2y4KqUnwopcO9b/SCdo2O67LwJJ/UyqGfbigahfegL9myoEFoDYZgkT7f36T0bLrM9hZTAaAyH+PCAXjw==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ] - }, - "node_modules/micromark-util-html-tag-name": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-html-tag-name/-/micromark-util-html-tag-name-2.0.1.tgz", - "integrity": "sha512-2cNEiYDhCWKI+Gs9T0Tiysk136SnR13hhO8yW6BGNyhOC4qYFnwF1nKfD3HFAIXA5c45RrIG1ub11GiXeYd1xA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ] - }, - "node_modules/micromark-util-normalize-identifier": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-normalize-identifier/-/micromark-util-normalize-identifier-2.0.1.tgz", - "integrity": "sha512-sxPqmo70LyARJs0w2UclACPUUEqltCkJ6PhKdMIDuJ3gSf/Q+/GIe3WKl0Ijb/GyH9lOpUkRAO2wp0GVkLvS9Q==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-symbol": "^2.0.0" - } - }, - "node_modules/micromark-util-resolve-all": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-resolve-all/-/micromark-util-resolve-all-2.0.1.tgz", - "integrity": "sha512-VdQyxFWFT2/FGJgwQnJYbe1jjQoNTS4RjglmSjTUlpUMa95Htx9NHeYW4rGDJzbjvCsl9eLjMQwGeElsqmzcHg==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-sanitize-uri": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-sanitize-uri/-/micromark-util-sanitize-uri-2.0.1.tgz", - "integrity": "sha512-9N9IomZ/YuGGZZmQec1MbgxtlgougxTodVwDzzEouPKo3qFWvymFHWcnDi2vzV1ff6kas9ucW+o3yzJK9YB1AQ==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "micromark-util-character": "^2.0.0", - "micromark-util-encode": "^2.0.0", - "micromark-util-symbol": "^2.0.0" - } - }, - "node_modules/micromark-util-subtokenize": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/micromark-util-subtokenize/-/micromark-util-subtokenize-2.1.0.tgz", - "integrity": "sha512-XQLu552iSctvnEcgXw6+Sx75GflAPNED1qx7eBJ+wydBb2KCbRZe+NwvIEEMM83uml1+2WSXpBAcp9IUCgCYWA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ], - "dependencies": { - "devlop": "^1.0.0", - "micromark-util-chunked": "^2.0.0", - "micromark-util-symbol": "^2.0.0", - "micromark-util-types": "^2.0.0" - } - }, - "node_modules/micromark-util-symbol": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/micromark-util-symbol/-/micromark-util-symbol-2.0.1.tgz", - "integrity": "sha512-vs5t8Apaud9N28kgCrRUdEed4UJ+wWNvicHLPxCa9ENlYuAY31M0ETy5y1vA33YoNPDFTghEbnh6efaE8h4x0Q==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ] - }, - "node_modules/micromark-util-types": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/micromark-util-types/-/micromark-util-types-2.0.2.tgz", - "integrity": "sha512-Yw0ECSpJoViF1qTU4DC6NwtC4aWGt1EkzaQB8KPPyCRR8z9TWeV0HbEFGTO+ZY1wB22zmxnJqhPyTpOVCpeHTA==", - "dev": true, - "funding": [ - { - "type": "GitHub Sponsors", - "url": "https://github.com/sponsors/unifiedjs" - }, - { - "type": "OpenCollective", - "url": "https://opencollective.com/unified" - } - ] - }, - "node_modules/micromatch": { - "version": "4.0.8", - "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.8.tgz", - "integrity": "sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==", - "dev": true, - "dependencies": { - "braces": "^3.0.3", - "picomatch": "^2.3.1" - }, - "engines": { - "node": ">=8.6" - } - }, - "node_modules/minimatch": { - "version": "5.1.9", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-5.1.9.tgz", - "integrity": "sha512-7o1wEA2RyMP7Iu7GNba9vc0RWWGACJOCZBJX2GJWip0ikV+wcOsgVuY9uE8CPiyQhkGFSlhuSkZPavN7u1c2Fw==", - "dev": true, - "dependencies": { - "brace-expansion": "^2.0.1" - }, - "engines": { - "node": ">=10" - } - }, - "node_modules/minimist": { - "version": "1.2.8", - "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.8.tgz", - "integrity": "sha512-2yyAR8qBkN3YuheJanUpWC5U3bb5osDywNB8RzDVlDwDHbocAJveqqj1u8+SVD7jkWT4yvsHCpWqqWqAxb0zCA==", - "dev": true, - "funding": { - "url": "https://github.com/sponsors/ljharb" - } - }, - "node_modules/ms": { - "version": "2.1.3", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", - "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==", - "dev": true - }, - "node_modules/once": { - "version": "1.4.0", - "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz", - "integrity": "sha512-lNaJgI+2Q5URQBkccEKHTQOPaXdUxnZZElQTZY0MFUAuaEqe1E+Nyvgdz/aIyNi6Z9MzO5dv1H8n58/GELp3+w==", - "dev": true, - "dependencies": { - "wrappy": "1" - } - }, - "node_modules/parse-entities": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/parse-entities/-/parse-entities-4.0.2.tgz", - "integrity": "sha512-GG2AQYWoLgL877gQIKeRPGO1xF9+eG1ujIb5soS5gPvLQ1y2o8FL90w2QWNdf9I361Mpp7726c+lj3U0qK1uGw==", - "dev": true, - "dependencies": { - "@types/unist": "^2.0.0", - "character-entities-legacy": "^3.0.0", - "character-reference-invalid": "^2.0.0", - "decode-named-character-reference": "^1.0.0", - "is-alphanumerical": "^2.0.0", - "is-decimal": "^2.0.0", - "is-hexadecimal": "^2.0.0" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/wooorm" - } - }, - "node_modules/picomatch": { - "version": "2.3.2", - "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.3.2.tgz", - "integrity": "sha512-V7+vQEJ06Z+c5tSye8S+nHUfI51xoXIXjHQ99cQtKUkQqqO1kO/KCJUfZXuB47h/YBlDhah2H3hdUGXn8ie0oA==", - "dev": true, - "engines": { - "node": ">=8.6" - }, - "funding": { - "url": "https://github.com/sponsors/jonschlinkert" - } - }, - "node_modules/punycode.js": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz", - "integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==", - "dev": true, - "engines": { - "node": ">=6" - } - }, - "node_modules/queue-microtask": { - "version": "1.2.3", - "resolved": "https://registry.npmjs.org/queue-microtask/-/queue-microtask-1.2.3.tgz", - "integrity": "sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ] - }, - "node_modules/reusify": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.1.0.tgz", - "integrity": "sha512-g6QUff04oZpHs0eG5p83rFLhHeV00ug/Yf9nZM6fLeUrPguBTkTQOdpAWWspMh55TZfVQDPaN3NQJfbVRAxdIw==", - "dev": true, - "engines": { - "iojs": ">=1.0.0", - "node": ">=0.10.0" - } - }, - "node_modules/run-con": { - "version": "1.2.12", - "resolved": "https://registry.npmjs.org/run-con/-/run-con-1.2.12.tgz", - "integrity": "sha512-5257ILMYIF4RztL9uoZ7V9Q97zHtNHn5bN3NobeAnzB1P3ASLgg8qocM2u+R18ttp+VEM78N2LK8XcNVtnSRrg==", - "dev": true, - "dependencies": { - "deep-extend": "^0.6.0", - "ini": "~3.0.0", - "minimist": "^1.2.8", - "strip-json-comments": "~3.1.1" - }, - "bin": { - "run-con": "cli.js" - } - }, - "node_modules/run-parallel": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz", - "integrity": "sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==", - "dev": true, - "funding": [ - { - "type": "github", - "url": "https://github.com/sponsors/feross" - }, - { - "type": "patreon", - "url": "https://www.patreon.com/feross" - }, - { - "type": "consulting", - "url": "https://feross.org/support" - } - ], - "dependencies": { - "queue-microtask": "^1.2.2" - } - }, - "node_modules/slash": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/slash/-/slash-5.1.0.tgz", - "integrity": "sha512-ZA6oR3T/pEyuqwMgAKT0/hAv8oAXckzbkmR0UkUosQ+Mc4RxGoJkRmwHgHufaenlyAgE1Mxgpdcrf75y6XcnDg==", - "dev": true, - "engines": { - "node": ">=14.16" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/smol-toml": { - "version": "1.6.0", - "resolved": "https://registry.npmjs.org/smol-toml/-/smol-toml-1.6.0.tgz", - "integrity": "sha512-4zemZi0HvTnYwLfrpk/CF9LOd9Lt87kAt50GnqhMpyF9U3poDAP2+iukq2bZsO/ufegbYehBkqINbsWxj4l4cw==", - "dev": true, - "engines": { - "node": ">= 18" - }, - "funding": { - "url": "https://github.com/sponsors/cyyynthia" - } - }, - "node_modules/string-width": { - "version": "8.1.0", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-8.1.0.tgz", - "integrity": "sha512-Kxl3KJGb/gxkaUMOjRsQ8IrXiGW75O4E3RPjFIINOVH8AMl2SQ/yWdTzWwF3FevIX9LcMAjJW+GRwAlAbTSXdg==", - "dev": true, - "dependencies": { - "get-east-asian-width": "^1.3.0", - "strip-ansi": "^7.1.0" - }, - "engines": { - "node": ">=20" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/strip-ansi": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-7.2.0.tgz", - "integrity": "sha512-yDPMNjp4WyfYBkHnjIRLfca1i6KMyGCtsVgoKe/z1+6vukgaENdgGBZt+ZmKPc4gavvEZ5OgHfHdrazhgNyG7w==", - "dev": true, - "dependencies": { - "ansi-regex": "^6.2.2" - }, - "engines": { - "node": ">=12" - }, - "funding": { - "url": "https://github.com/chalk/strip-ansi?sponsor=1" - } - }, - "node_modules/strip-json-comments": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-3.1.1.tgz", - "integrity": "sha512-6fPc+R4ihwqP6N/aIv2f1gMH8lOVtWQHoqC4yK6oSDVVocumAsfCqjkXnqiYMhmMwS/mEHLp7Vehlt3ql6lEig==", - "dev": true, - "engines": { - "node": ">=8" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/to-regex-range": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", - "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", - "dev": true, - "dependencies": { - "is-number": "^7.0.0" - }, - "engines": { - "node": ">=8.0" - } - }, - "node_modules/uc.micro": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz", - "integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==", - "dev": true - }, - "node_modules/unicorn-magic": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/unicorn-magic/-/unicorn-magic-0.4.0.tgz", - "integrity": "sha512-wH590V9VNgYH9g3lH9wWjTrUoKsjLF6sGLjhR4sH1LWpLmCOH0Zf7PukhDA8BiS7KHe4oPNkcTHqYkj7SOGUOw==", - "dev": true, - "engines": { - "node": ">=20" - }, - "funding": { - "url": "https://github.com/sponsors/sindresorhus" - } - }, - "node_modules/wrappy": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", - "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==", - "dev": true - } - } -} diff --git a/airport-wiki/package.json b/airport-wiki/package.json deleted file mode 100644 index 80b31e0..0000000 --- a/airport-wiki/package.json +++ /dev/null @@ -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/**\"" - } -} diff --git a/airport-wiki/raw/articles/2025-airport-construction-summit.md b/airport-wiki/raw/articles/2025-airport-construction-summit.md deleted file mode 100644 index 25e3ddb..0000000 --- a/airport-wiki/raw/articles/2025-airport-construction-summit.md +++ /dev/null @@ -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施工管理平台 -- 风液融合算力解决方案 diff --git a/airport-wiki/raw/articles/AI-Driven-Smart-Gating-2025.md b/airport-wiki/raw/articles/AI-Driven-Smart-Gating-2025.md deleted file mode 100644 index 89c045c..0000000 --- a/airport-wiki/raw/articles/AI-Driven-Smart-Gating-2025.md +++ /dev/null @@ -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运营系统的技术方案参考 -- 论文未包含具体模型参数或商业实现细节 diff --git a/airport-wiki/raw/articles/IBM-Building-intelligent-airport-future-2025.md b/airport-wiki/raw/articles/IBM-Building-intelligent-airport-future-2025.md deleted file mode 100644 index 52a8e3e..0000000 --- a/airport-wiki/raw/articles/IBM-Building-intelligent-airport-future-2025.md +++ /dev/null @@ -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技术细节（模型规模、硬件配置） -- 主要面向机场运营管理层，非技术规格文档 -- 适合与国内具体机场案例对比参照 diff --git a/airport-wiki/raw/articles/aci-tsa-open-architecture-2023.md b/airport-wiki/raw/articles/aci-tsa-open-architecture-2023.md deleted file mode 100644 index fe9929b..0000000 --- a/airport-wiki/raw/articles/aci-tsa-open-architecture-2023.md +++ /dev/null @@ -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/) diff --git a/airport-wiki/raw/articles/aodb-manus-2026.md b/airport-wiki/raw/articles/aodb-manus-2026.md deleted file mode 100644 index 3c46975..0000000 --- a/airport-wiki/raw/articles/aodb-manus-2026.md +++ /dev/null @@ -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 diff --git a/airport-wiki/raw/articles/aodb.md b/airport-wiki/raw/articles/aodb.md deleted file mode 100644 index 6aeba29..0000000 --- a/airport-wiki/raw/articles/aodb.md +++ /dev/null @@ -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 diff --git a/airport-wiki/raw/articles/daxing-airport-vertiv.md b/airport-wiki/raw/articles/daxing-airport-vertiv.md deleted file mode 100644 index 8b81769..0000000 --- a/airport-wiki/raw/articles/daxing-airport-vertiv.md +++ /dev/null @@ -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融合解决方案 - -范围：生活服务区、维修区、航空食品区、地面服务区、货运区 diff --git a/airport-wiki/raw/articles/dubai-airport-huawei-dc.md b/airport-wiki/raw/articles/dubai-airport-huawei-dc.md deleted file mode 100644 index 500ded7..0000000 --- a/airport-wiki/raw/articles/dubai-airport-huawei-dc.md +++ /dev/null @@ -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亿。 diff --git a/airport-wiki/raw/articles/keydak-airport-expo-2025.md b/airport-wiki/raw/articles/keydak-airport-expo-2025.md deleted file mode 100644 index 57aa406..0000000 --- a/airport-wiki/raw/articles/keydak-airport-expo-2025.md +++ /dev/null @@ -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算力密度持续上升趋势 diff --git a/airport-wiki/raw/articles/llm-wiki-v2-rohitg00.md b/airport-wiki/raw/articles/llm-wiki-v2-rohitg00.md deleted file mode 100644 index 8212660..0000000 --- a/airport-wiki/raw/articles/llm-wiki-v2-rohitg00.md +++ /dev/null @@ -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. diff --git a/airport-wiki/raw/articles/manus-future-airport-info-center-2026.md b/airport-wiki/raw/articles/manus-future-airport-info-center-2026.md deleted file mode 100644 index 7457e22..0000000 --- a/airport-wiki/raw/articles/manus-future-airport-info-center-2026.md +++ /dev/null @@ -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. diff --git a/airport-wiki/raw/articles/上海市-智算中心建设导则2025版-2025-01.md b/airport-wiki/raw/articles/上海市-智算中心建设导则2025版-2025-01.md deleted file mode 100644 index cb7f0b6..0000000 --- a/airport-wiki/raw/articles/上海市-智算中心建设导则2025版-2025-01.md +++ /dev/null @@ -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网络要求 diff --git a/airport-wiki/raw/articles/中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md b/airport-wiki/raw/articles/中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md deleted file mode 100644 index 31c7b72..0000000 --- a/airport-wiki/raw/articles/中国工业互联网研究院-工业智算发展研究报告2025-2026-01.md +++ /dev/null @@ -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% → 二线及以下城市 -``` - ---- - -## 技术备注 - -- 本报告为工业智算领域的权威官方报告 -- 机场智算中心属于"工业智算"应用场景之一，但本报告未专门覆盖机场行业 -- 国产液冷企业（英维克、中科曙光）的技术参数对机场项目有直接参考价值 diff --git a/airport-wiki/raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md b/airport-wiki/raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md deleted file mode 100644 index 6ae6aa4..0000000 --- a/airport-wiki/raw/articles/头豹研究院-中国AIDC产业发展白皮书2025-2025-07.md +++ /dev/null @@ -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亿元"投入数据可作为机场项目预算参考基准 diff --git a/airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md b/airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md deleted file mode 100644 index 0c84836..0000000 --- a/airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md +++ /dev/null @@ -1,1166 +0,0 @@ -# 机场数据中心建设方案（综合性完整方案） - ---- - -## 执行摘要 - -本方案基于对国内外大型机场数据中心的深度调研，综合北京大兴机场、上海浦东机场、迪拜机场等典型实践案例，以及最新的数据中心技术进展，提出一套适应民航业特点、符合国际标准、兼具创新性和可实施性的机场数据中心建设与运营方案。 - -**核心要点**： -- **适应规模**：支持50-500个机柜的各类机场 -- **可用性目标**：关键系统99.99% (Tier III+)，重要系统99.9% (Tier III) -- **技术架构**：本地IDC + 边缘计算 + 混合云 -- **建设周期**：18-24个月 -- **投资规模**：100机柜约5000万元CAPEX，年OPEX约8000万元 - ---- - -# 第一部分：项目背景与需求分析 - -## 1. 机场信息系统现状 - -### 1.1 核心业务系统 - -机场运营涉及众多关键业务系统，数据中心需要为这些系统提供可靠的基础设施支撑： - -**航班运营系统（AODB）** -机场航班运营数据库是机场信息系统的"大脑"，汇聚了全球95%航空公司的航班数据，提前365天的航班计划可见性。AODB与离港系统紧密集成，实时跟踪航班状态，支撑航班准点、高效运营。 - -**离港系统（Departure Control System）** -负责航班离港全流程管理，包括旅客值机、行李分拣、登机、舱单确认等环节。系统需支持秒级响应时间，确保高峰时段旅客流畅登机。 - -**安检系统** -实时处理安全检查数据，与公安、边检等系统对接。需要支持高并发处理，确保安检通道不成为瓶颈。 - -**飞行信息显示系统（FIDS）** -航站楼内的电子航班显示屏由FIDS驱动，需实时同步AODB数据，显示更新延迟 < 50ms。 - -**行李处理系统（BHS）** -自动分拣数万件行李，与安检、值机系统联动。对网络延迟敏感(< 30ms)，数据丢失不可接受。 - -**视频监控系统** -遍布机场各处，每天产生PB级数据。需要边缘计算支持实时分析（人脸识别、异常检测）。 - -**物联网系统** -部署数万个传感器监测能源（电力、水、燃气）、环境（温湿度、空气质量）、设备状态等。 - -### 1.2 数据中心需求清单 - -| 需求项 | 数值/描述 | -|--------|---------| -| 核心业务系统数量 | 100+ | -| 虚拆化服务器数量 | 200-500台 | -| 存储容量 | 100-500 TB(可扩展) | -| 网络带宽 | 出口 200M-1G | -| 可用性目标 | AODB/离港 99.99%, 其他 99.9% | -| 最大停机容忍时间 | 关键系统 < 5分钟 | -| 数据丢失容忍度 | 关键系统 0 (零数据丢失) | -| 灾备能力 | 支持异地灾备 | - ---- - -## 2. 机场类型与差异化需求 - -### 2.1 国际枢纽机场（北京、上海等） - -**特点**：旅客量大(日均 ≥ 50万人)、业务复杂、国际通航 - -**数据中心需求**： -- Tier III/IV级别，支持99.99%可用性 -- 600-1000个机柜规模，支持容量持续增长 -- 本地IDC + 异地灾备 + 混合云 -- 完整的安全合规体系(等保四级、民航要求) - -**典型投资**：CAPEX 20000-30000万元，年OPEX 15000-20000万元 - -### 2.2 区域机场（成都、西安、杭州等） - -**特点**：旅客量中等(日均 10-30万人)、业务相对稳定 - -**数据中心需求**： -- Tier III级别，支持99.9%可用性 -- 200-400个机柜规模 -- 本地IDC，可通过云平台扩展 -- 等保三级合规 - -**典型投资**：CAPEX 8000-12000万元，年OPEX 6000-8000万元 - -### 2.3 支线机场（武夷山、景德镇等） - -**特点**：旅客量小(日均 < 10万人)、业务相对简单 - -**数据中心需求**： -- Tier II/III级别，支持99.9%可用性 -- 50-150个机柜规模 -- 本地小型IDC + 云优先策略 -- 等保二级合规 - -**典型投资**：CAPEX 2000-4000万元，年OPEX 1500-2000万元 - ---- - -# 第二部分：国内外典型机场案例分析 - -## 3. 标杆案例研究 - -### 3.1 北京大兴国际机场 - -**项目背景** -北京大兴国际机场是中国最大的单体建筑，代表了新一代智慧机场的建设标准。从2014年12月开工到2019年9月投运，仅用4年9个月创造了世界工程建设奇迹。 - -**数据中心架构创新** -大兴机场引入数字孪生技术，构建了智能数据中心作为整个机场智慧平台的核心。该数据中心接入100+个复杂业务系统，管理数万个物联网节点，通过三维可视化实现机场全景管理。 - -**关键指标** -- 承载100+个业务系统 -- 接入数万个IoT传感器 -- 支撑旅客流、航班动态、能源消耗的实时分析 -- 通过BIM模型编码实现建筑信息与IT系统的无缝集成 - -**经验启示** -新建机场应从规划阶段开始融入数字孪生和智能运营理念，数据中心不仅是基础设施，更是驱动机场智能化的引擎。 - -### 3.2 上海浦东国际机场卫星厅 - -**项目背景** -浦东机场三期扩建工程（2019年启用）新增了全球最大的单体卫星厅(62.2万m²)。该项目面临一个关键挑战：如何在保留现有"烟囱式"系统的前提下，快速实现IT基础设施的现代化。 - -**技术方案** -浦东采用了**软件定义数据中心(SDDC)**方案，由VMware提供技术支撑： -- 网络层：通过NSX虚拆化实现跨数据中心的大二层网络，打破异构设备厂商间的技术壁垒 -- 存储层：用超融合基础设施(vSAN)替代传统SAN存储，支持灵活的存储扩展 -- 管理层：通过vCloud Suite + vCenter实现统一的资源管理和自动化运维 - -**关键成果** -- 400+机场业务系统运行在统一的SDDC平台上 -- 实现了T2航站楼和卫星厅的双活容灾 -- 系统维护复杂度降低，人工运维成本下降 -- 支持业务系统的灵活迁移和扩展 - -**经验启示** -对于存量机场的IT基础设施升级，**软件定义是突破技术限制的关键**。无需完全更换硬件，通过虚拆化和软件定义可以快速实现目标。 - -### 3.3 迪拜国际机场 - -**项目背景** -迪拜机场日均23万旅客，面临"零停机"的严格要求。华为为其设计并实施了全球首个**模块化数据中心复合体(MDCC)**。 - -**技术亮点** -- 采用Huawei FusionModule1000B预制模块 -- 23个集装箱级模块，总功率1MW，100个服务机柜 -- 获得Uptime Institute Tier III认证(设计+建设双认证) -- PUE < 1.6，比传统数据中心能效提升30% - -**建设成效** -- **快速部署**：仅需10个月(相比传统18-30个月) -- **成本节省**：建设成本节省50% -- **灵活扩展**：模块化设计支持按需添加新模块 -- **高温适应**：专门针对中东高温环境优化，冷却系统高效 - -**经验启示** -模块化数据中心是快速部署和成本优化的有效路径，适合机场的扩建期需求。 - -### 3.4 新加坡樟宜机场Terminal 5 - -**项目背景** -樟宜机场Terminal 5项目(2025年破土，2030年代中期投运)代表了下一代机场的数据中心设计思路。该项目特别强调AI驱动的自动化。 - -**创新点** -- 从新建阶段就融入AI/ML考量，而非事后改造 -- 数据基础设施为AI算法提供一流的支撑能力 -- 预计投运后日吞吐50万旅客，需要支撑500+业务系统 - -**规划指标** -- 年旅客目标：1.4亿(增幅55%) -- 数据处理能力：支持实时旅客流管理、货物追踪等AI应用 -- 基础设施：模块化、未来可扩展 - -**经验启示** -新一代机场数据中心必须从0到1阶段就考虑AI/ML能力，而不是等到业务需求迫切才升级。 - -### 3.5 伦敦希斯罗机场 - -**项目背景** -希斯罗机场(年均8000万旅客)正在进行"75年来最大的现代化改造"(11亿英镑投资)，同步进行IT基础设施的云化转型。 - -**云转型战略** -希斯罗采用**混合多云**策略： -- Oracle Cloud + Microsoft Azure用于不同业务 -- 构建"IT公共基础设施"概念，实现资源共享 -- 关键系统(如FIDS升级)采用Azure的多区域主-主架构 - -**迁移成果** -Flight Information Hub(FIHub)升级到Azure后： -- 采用原生云功能(无服务器部署) -- 支持主-主容灾，切换时间 < 30秒 -- 自动扩展应对突发流量 -- 托管成本下降，灵活性提升 - -**经验启示** -大型枢纽机场的IT现代化已经进入"云优先"时代，公有云和私有云的混合部署成为主流选择。 - ---- - -# 第三部分：技术架构设计 - -## 4. 总体架构框架 - -### 4.1 分层架构模型 - -机场数据中心采用"三层两域"的分层设计： - -**三层架构** -- **基础设施层(IaaS)**：服务器、存储、网络等物理资源 -- **平台服务层(PaaS)**：虚拆化平台、容器平台、中间件等 -- **应用服务层(SaaS)**：业务应用系统 - -**两域划分** -- **生产域**：支撑机场日常运营的关键系统 -- **灾备域**：异地部署或本地冷备，支持生产域故障转移 - -### 4.2 混合部署架构 - -采用"本地IDC + 边缘计算 + 混合云"的混合部署模式： - -**本地IDC(主数据中心)** -- 承载AODB、离港、安检等核心业务系统 -- 支持99.98%-99.99%的可用性 -- 与航站楼、停坪等通过高速通道互连 - -**边缘计算节点(分布式)** -- 部署于各航站楼、停坪、安检区域 -- 支撑FIDS航显、视频监控、IoT数据的实时处理 -- 通过私线与主数据中心互连 - -**混合云平台(弹性扩展)** -- 接入公有云(阿里云、腾讯云等) -- 用于非关键系统的冷备、容量溢出 -- 支持大数据分析、AI训练等弹性计算需求 - ---- - -## 5. 网络架构设计 - -### 5.1 三层网络模型 - -**核心层(Core)** -- 双核心交换机，支持网状拓扑 -- 核心交换机间百兆级互连(40G/100G) -- 实现核心数据转发的高速、低延迟 - -**汇聚层(Aggregation)** -- 8-12台中档交换机汇聚各业务区域流量 -- 支持VLAN隔离，实现安全域划分 -- 与核心层冗余互连 - -**接入层(Access)** -- 每个机柜配置冗余接入交换机 -- 支持不低于10Gbps链路速率 -- 服务器采用双网卡，分别连接不同交换机 - -### 5.2 核心业务系统网络需求 - -| 业务系统 | 带宽 | 延迟要求 | 冗余等级 | 传输协议 | -|---------|------|--------|---------|---------| -| AODB | 10-50 Mbps | <100ms | 双链路 | TCP/IP | -| 离港系统 | 20-100 Mbps | <50ms | 双链路 | TCP/IP | -| 安检系统 | 50-200 Mbps | <100ms | 双链路 | TCP + RT | -| FIDS | 5-20 Mbps | <50ms | 单链路+备 | UDP/TCP | -| 行李系统BHS | 100-500 Mbps | <30ms | 双链路 | 工业ET | -| 视频监控 | 500M-2G | <200ms | 单链路 | UDP/RTSP | -| IoT传感器 | 10-50 Mbps | <500ms | 单链路 | MQTT | - -### 5.3 双活多活设计 - -**站点级双活** -- 主数据中心与灾备中心距离100-200km -- 专线光纤互连，时延 ≤ 5ms -- AODB、离港系统等关键业务实现主-主双活 - -**网络虚拆化(NSX)** -- 通过VMware NSX实现虚拆化网络覆盖 -- 支持跨域虚拟机动态迁移 -- 实现零信任安全架构 - -**RTO/RPO目标** -- RTO: < 5分钟(关键系统) -- RPO: < 1分钟(核心交易数据) - ---- - -## 6. 计算与存储架构 - -### 6.1 虚拆化平台 - -采用**VMware vSphere**作为计算基础： - -**vSphere核心特性** -- vSphere 8.0+版本，支持最新CPU/内存技术 -- vCenter管理中心，集中管理所有主机 -- vMotion支持在线迁移，无业务中断 -- DRS智能分配资源 - -**服务器配置建议** - -| 场景 | CPU | 内存 | 存储 | 网卡 | -|------|-----|------|------|------| -| 计算密集 | 2×Xeon Platinum 8480 | 512GB+ | SSD | 2×25G | -| 通用应用 | 2×Xeon Gold 6426 | 256-384GB | NVMe | 2×25G | -| 存储优化 | 2×Xeon Gold 5318 | 256GB | 多盘位 | 2×25G | - -### 6.2 超融合基础设施(HCI) - -部分机房采用超融合架构(计算+存储+网络融合)： - -**架构优势** -- 占地面积减少40%相比传统架构 -- 维护点减少，管理复杂度降低 -- 支持弹性扩展 - -**典型部署** -- 最小集群：3节点(支持1节点故障) -- 建议规模：6-8节点 -- 单节点配置：2×Xeon Gold 6426、384GB内存、4×3.2TB NVMe SSD - -**性能指标** -- IOPS：50,000+/节点 -- 吞吐量：3GB/s+/集群 -- 数据可靠性：99.999%(三副本机制) - -### 6.3 分层存储策略 - -**Tier 1 - 热数据存储** -- 介质：NVMe SSD或高速SAS SSD -- 用途：AODB、离港、安检系统数据 -- 保留期：3-6个月 -- 备份：每小时增量 - -**Tier 2 - 温数据存储** -- 介质：SATA SSD或SAS硬盘 -- 用途：航班历史、乘客信息 -- 保留期：1-3年 -- 备份：每天增量 - -**Tier 3 - 冷数据存储** -- 介质：归档存储(磁带/OSS) -- 用途：合规存档、长期统计 -- 保留期：7-10年 -- 备份：每周或每月 - -### 6.4 数据同步策略 - -**关键业务(AODB、离港)** -- 采用同步复制 -- RPO = 0(零数据丢失) -- 代价：写入延迟增加、吞吐下降~30% - -**重要业务(安检、行李)** -- 采用准同步复制 -- RPO < 1分钟 -- 平衡可用性与数据安全 - -**一般业务(监控、IoT)** -- 采用异步复制 -- RPO可接受5-15分钟延迟 - ---- - -## 7. 容器编排与微服务 - -### 7.1 Kubernetes平台 - -对新建应用采用**Kubernetes**微服务架构： - -**核心特性** -- 自动部署、扩展、管理容器化应用 -- 支持多云部署(本地、阿里云ACK、腾讯TKE) -- 自动故障转移和自我修复 - -**集群规划** -- Master节点：3个(高可用，支持1节点故障) -- Worker节点：8-16个(根据业务规模) -- 单Worker配置：8 CPU、32GB内存、100GB存储 - -### 7.2 微服务拆分 - -适合微服务改造的应用： - -**业务微服务**：航班服务、乘客服务、行李追踪、登机服务 - -**中间件服务**：消息队列(Kafka)、缓存(Redis)、配置中心(Consul/Nacos) - -**基础设施服务**：监控告警(Prometheus+Grafana)、日志(ELK)、链路追踪 - ---- - -## 8. 边缘计算与IoT集成 - -### 8.1 边缘计算节点 - -**部署位置** -- 各航站楼运营中心 -- 停坪管理中心 -- 安检通道 -- 行李分拣中心 - -**节点配置** -- CPU：4-8核心(中等功率) -- 内存：16-32GB -- 存储：256GB SSD -- 网络：2×10G对称光纤 - -**软件栈** -- 轻量级容器运时(containerd) -- Kubernetes Edge版本(K3s或KubeEdge) -- MQTT/CoAP IoT协议栈 -- 本地实时处理与缓存 - -### 8.2 IoT数据流处理 - -**数据流架构** -``` -IoT传感器 → 边缘计算 → MQTT Broker → Kafka集群 → 数据湖 - ↓ - 本地实时处理(告警) - ↓ - 上传主数据中心 -``` - -**关键指标** -- 端到端延迟：< 500ms(用于实时告警) -- 数据吞吐：10,000+ msg/sec -- 数据可靠性：99.9% - ---- - -# 第四部分：基础设施规划与工程设计 - -## 9. 机房选址与建筑标准 - -### 9.1 选址原则 - -**生产数据中心** -- 宜在机场内部或周边5-10km -- 网络延迟 ≤ 2ms -- 光纤直连距离 < 5km -- 物理安全易控制 - -**灾备数据中心** -- 距生产中心100-200km -- 不同地震震源区 -- 不同气候风险区 -- 专线光纤互连(RPO ≤ 1min) - -**环境评估** -- 避开地震频发区、滑坡易发地 -- 远离台风路线、冰雹区、强风口 -- 避开洪水易发区 -- 远离高压输电线(距离 ≥ 300m) - -### 9.2 建筑标准 - -**A级(Tier III及以上)** -- 抗震烈度：8度 -- 耐火等级：一级 -- 使用年限：≥ 50年 - -**B级(Tier II-III)** -- 抗震烈度：7度 -- 耐火等级：一-二级 -- 使用年限：≥ 30年 - -**建筑结构** -- 独立式专用建筑(推荐新建) -- 占地3000-5000m²(100-200机柜) -- 建筑高度15-25m(含配电、冷却设备层) -- 2-3层结构(下层配电/冷却，上层管理) - ---- - -## 10. 供电系统设计 - -### 10.1 电源架构 - -采用**N+N冗余设计**(Tier III/IV推荐)： - -**市政电源接入** -- 双路市电独立进线(来自不同变电站，距离 ≥ 15km) -- 进线电压：10kV或35kV(高压直供) -- 进线容量：足够支撑总功率120%(含冗余) - -**变压器配置** -- 两台主变压器(N+1)，单台容量=总负载100% -- 容量：1000-2000 kVA(取决于规模) -- 冷却方式：油冷(ONAN)或强油循环(OFAF) - -**柴油发电机** -- 套数：2台(N+1冗余) -- 容量：每台=总负载100% -- 燃油储备：满载运行 ≥ 72小时 -- 启动时间：< 10秒 - -**柴油机配置示例** - -| 数据中心规模 | 总功率 | 单台柴油机 | 油罐容量 | -|------------|--------|----------|---------| -| 100机柜 | 500kW | 250-300kW | 50m³ | -| 200机柜 | 1MW | 500-600kW | 100m³ | -| 500机柜 | 2.5MW | 1.2-1.5MW | 250m³ | - -### 10.2 不间断电源(UPS) - -**UPS配置** -- 在线式UPS，N+1冗余(双机热备) -- 容量：≥ 110% × IT设备功耗 + 5分钟裕度 -- 电池技术：锂电池(LiFePO₄) -- 备电时间：≥ 15分钟(保证柴油机启动) - -**典型UPS配置** - -| 方案 | 容量 | 电池时间 | 输入PF | 输出THD | -|------|------|---------|--------|--------| -| 标准型 | 200-300kW | 15分钟 | 0.99 | <3% | -| 增强型 | 300-600kW | 30分钟 | 0.99 | <3% | -| 高端型 | 600-1000kW+ | 45分钟+ | 0.99 | <2% | - -### 10.3 防雷保护 - -**建筑防雷** -- 避雷针设置，接地等级Ⅱ级 -- 主要设备外壳接地，接地电阻 ≤ 1Ω - -**电源防雷** -- 所有电源进线配备级联防雷器 -- 网络/光纤进线配备信号防雷器 - ---- - -## 11. 冷却系统设计 - -### 11.1 冷却方案选择 - -**精密空调系统(通用型)** -- 适用：≤ 500机柜 -- 机柜密度：3-8 kW/机柜 -- PUE目标：1.4-1.6 -- 优点：成熟稳定、易维护 -- 缺点：能耗相对较高 - -**液冷系统(高密度型)** -- 适用：≥ 8 kW/机柜或高端计算 -- 技术类型：背板液冷、直接液冷、浸没式液冷 -- PUE目标：1.2-1.3 -- 优点：能耗低、散热高效 -- 缺点：初期投资大、维护复杂 - -**混合冷却(推荐)** -- 主机房采用精密空调(80%) -- 高密度区采用液冷(20%) -- PUE目标：1.35-1.45 - -### 11.2 精密空调配置 - -**系统参数** -- 类型：变频精密空调，CRAH或CRAC -- 冗余：N+1(至少2套独立系统) -- 冷却能力：根据机柜功耗设计，冗余 ≥ 20% - -**单套空调配置建议** - -| 机柜数 | 冷却容量 | 套数 | 总功率 | -|--------|---------|------|--------| -| 50 | 50kW | 2 | 100kW | -| 100 | 100kW | 2 | 200kW | -| 200 | 150kW | 3 | 450kW | -| 500 | 300kW | 4 | 1200kW | - -**冷却管理** -- 冷热通道隔离(闭合冷通道效率提升 ≥ 25%) -- 变频控制(节能 ≥ 30%) -- 温度设定：进风18-27℃(推荐22-24℃)，出风 ≤ 40℃ - ---- - -## 12. 布线与网络传输 - -### 12.1 布线架构 - -**主干缆线** -- 类型：多模光纤(OM4，100G)或单模光纤(OS2，400G) -- 冗余度：N+1或N+2 -- 预留：≥ 30%额外管道供未来扩展 - -**机柜接入** -- 水平缆线：CAT6A或CAT7 -- 密度：每机柜 ≥ 48口(10G+) -- 冗余：关键系统 ≥ 2条独立网线 - -**布线管理** -- 综合布线槽系统，支持整理扩展 -- 光纤走线架，弯曲半径 ≥ 30mm -- 所有缆线标签清晰、编号规范 - -### 12.2 通讯网络 - -**互联网出口** -- 带宽：≥ 机内流量的30% -- 冗余：2条独立链路(不同运营商) -- 链路速率：100M-1G - -**专线互连** -- 生产-灾备专线：200M-1G，单纤双向(DWDM) -- 延迟指标：≤ 5ms(同城)或 ≤ 20ms(异地) -- 冗余：2条不同物理路径 - ---- - -## 13. 消防与安全防护 - -### 13.1 消防系统 - -**气体灭火**(推荐FM-200或IG-541) -- 覆盖整个机房 -- 启动方式：温感探测器+手动启动 -- 灭火浓度：FM-200 ≤ 7% -- 释放时间：< 8秒 - -**火灾探测** -- 感烟探测器+感温探测器 -- 密度：间距 ≤ 5m -- 自动关闭空调、切断燃气、启动应急照明 - -### 13.2 物理安全 - -**出入控制** -- 生物识别(指纹/虹膜) + IC卡双因素认证 -- 所有出入事件记录，保存 ≥ 1年 -- 通道宽度 ≥ 2m，安全出口 ≥ 2个 - -**视频监控** -- 2K或4K分辨率，支持夜视 -- 录像保存 ≥ 30天高清，异地备份 ≥ 7天 -- 实时告警系统(异常出入、温度超限等) - -**防盗防破坏** -- 每个机柜防撬锁 -- 每日巡检 ≥ 3次 -- 未授权物品移动、机柜打开触发告警 - ---- - -## 14. 建设工程时间表 - -| 阶段 | 任务 | 周期 | -|------|------|------| -| 前期策划 | 选址、可研、方案论证 | 2-4个月 | -| 设计阶段 | 详细设计、审图、招标 | 3-4个月 | -| 建设阶段 | 土建、设备安装、调试 | 12-18个月 | -| 试运行 | 系统测试、容量验证 | 2-3个月 | -| 投运 | 正式投运、割接上线 | 1个月 | - -**总周期**：18-24个月 - ---- - -## 15. 关键设计指标对标 - -| 指标 | Tier II | Tier III | Tier IV | -|------|--------|----------|---------| -| 年可用性 | 99.6% | 99.99% | 99.995% | -| 年停机 | 35h | 52min | 26min | -| UPS备电 | ≥5min | ≥15min | ≥30min | -| 柴油机 | 1台 | N+1 | N+1 | -| 电源冗余 | N | N+1 | 2N | -| 冷却冗余 | N | N+1 | 2N | -| PUE值 | 1.8-2.0 | 1.4-1.6 | 1.2-1.4 | -| 机柜密度 | 3-5kW | 5-8kW | 8-15kW | -| 抗震等级 | 6度 | 8度 | 9度 | -| 建筑寿命 | 20年 | 30年 | 50年 | - ---- - -# 第五部分：安全合规与运维体系 - -## 16. 网络安全架构 - -### 16.1 零信任安全模型 - -机场数据中心采用**零信任**安全架构，核心原则是"永不信任，始终验证"： - -**关键要素** -- 身份认证：MFA(密码+生物识别+硬件令牌) -- 设备认证：完整性检查、病毒扫描 -- 应用隔离：微分段，关键系统独立网络 -- 传输加密：TLS 1.2+ - -### 16.2 数据安全分级 - -按照《民航数据管理办法》，分为五个等级： - -| 等级 | 数据类型 | 存储要求 | 访问控制 | -|------|---------|---------|--------| -| 1级 | 公开数据(导航、时刻) | 无特殊要求 | 可公开 | -| 2级 | 内部数据(统计、员工信息) | 一般加密 | 内部使用 | -| 3级 | 敏感数据(乘客信息、安检记录) | 密钥加密 | 需审计 | -| 4级 | 机密数据(安保计划、漏洞信息) | 最高级加密 | 严格限制 | -| 5级 | 绝密数据(威胁预警) | 符合保密标准 | 极端限制 | - -### 16.3 数据加密策略 - -**传输层**：SSL/TLS 1.2+加密所有网络通讯 - -**存储层**：数据库透明加密(TDE)，关键数据采用主密钥管理(HSM) - -**密钥管理**：通过KMS(如AWS KMS或阿里云KMS)，主密钥存储在HSM中，定期轮换(周期 ≤ 1年) - ---- - -## 17. 民航合规要求 - -### 17.1 等级保护(GB/T 22239) - -机场数据中心应满足**等保2.0第三级或第四级**： - -**定级原则** -- AODB、离港、安检系统：第四级(关键基础设施) -- FIDS、行李系统、视频监控：第三级(重要系统) -- 办公、财务系统：第二级 - -**四级要求核心内容** -- 物理安全：24/7守卫、无死角监控、门禁、防盗报警 -- 网络安全：零信任、微分段、异常检测、自动响应 -- 应用安全：代码审计、漏洞扫描、渗透测试 -- 数据安全：全数据加密、分级存储、隐私脱敏、审计溯源 -- 运维安全：变更管理、访问控制、日志审计、应急响应 - -**测评周期**：投运前初评，之后每两年复评 - -### 17.2 民航特殊要求 - -**MH/T 0076—2020标准** - -核心要求包括： -- 多层防御策略(纵深防御) -- 建立安全运维团队 -- 定期安全培训和演练 -- AODB支持A-CDM流程 -- 与民航局/空管部门通讯加密认证 -- 飞行安全数据实时备份 -- SOC 24/7监测 -- 网络安全事件2小时内上报民航局 - -### 17.3 国际标准对标 - -**ICAO Annex 14**：电力可用性 ≥ 99.98%，通讯延迟 ≤ 100ms，备份距离 > 100km - -**ISO 27001**：建立信息安全管理体系，每年第三方审计 - ---- - -## 18. 运维体系 - -### 18.1 组织结构 - -**运维团队**(100机柜规模约30-35人) - -``` -数据中心总经理 -├─ 系统运维经理(负责基础设施可用性) -│ ├─ 基础设施运维(4-5人) -│ ├─ 网络运维(2-3人) -│ ├─ 数据库运维(2-3人) -│ └─ 应用运维(3-4人) -├─ 安全经理(负责安全运维) -│ ├─ 安全架构师(1人) -│ ├─ 安全运维(2-3人) -│ └─ 合规官(1人) -├─ 规划经理(容量规划和优化) -└─ 应急响应经理(24/7轮班) -``` - -### 18.2 运维流程 - -**变更管理** -1. 提交变更申请(含业务影响评估) -2. 变更审批委员会审批(风险评估) -3. 安排变更窗口(非高峰时段) -4. 执行变更，全程记录 -5. 变更后验证和回滚确认 -6. 经验总结 - -**关键系统变更限制** -- AODB/离港系统：需民航局批准，仅在深夜(23:00-6:00) -- 重要系统：业务部门和安全部门共同签字 -- 所有变更需详细回滚方案 - -### 18.3 监控与告警 - -**监控栈**：Prometheus + Grafana + AlertManager - -**基础设施监控** -- CPU、内存、磁盘使用率 -- 网络吞吐、延迟、丢包率 -- 电源、温度、湿度 -- 告警阈值：CPU > 80%，内存 > 85%，磁盘 > 90% - -**应用层监控** -- 响应时间(RT)、吞吐量(QPS)、错误率 -- 数据库连接数、查询响应时间 - -**告警升级机制** -- 一级：值班人员，15分钟无响应升级 -- 二级：运维经理，30分钟无响应升级 -- 三级：总经理+业务部门 - -### 18.4 关键运维KPI - -- 系统可用性：≥ 99.99%(关键系统) -- 平均修复时间(MTTR)：< 30分钟 -- 人均管理系统数：1人 > 500个虚拟机 -- 运维成本/IT支出：≤ 40% - ---- - -## 19. 灾难恢复与业务连续性 - -### 19.1 灾备等级与RTO/RPO - -| 系统 | RPO | RTO | 恢复等级 | -|------|-----|-----|--------| -| AODB | 0 | 5分钟 | 零数据丢失 | -| 离港系统 | 0 | 5分钟 | 零数据丢失 | -| 行李系统 | <1分钟 | 15分钟 | 低丢失 | -| FIDS | <5分钟 | 30分钟 | 中等恢复 | -| 视频监控 | 不限 | 24小时 | 自动恢复 | - -### 19.2 灾备演练 - -**计划** -- 每季度完整灾备切换演练 -- 每月特定系统恢复演练 -- 每周备份恢复验证 - -**演练流程** -1. 计划阶段：明确目标、系统范围、风险评估 -2. 实施阶段：按计划执行，记录关键指标 -3. 验证阶段：数据一致性、业务功能完整性 -4. 总结阶段：分析结果，优化流程 - ---- - -# 第六部分：成本估算与技术选型 - -## 20. CAPEX投资成本 - -### 20.1 成本详解(100机柜规模，500kW) - -| 项目 | 单价 | 数量 | 小计 | -|------|------|------|------| -| **土建工程** | | | **1000万** | -| 建筑主体 | - | 5000m² | 800万 | -| 装修装饰 | - | 5000m² | 150万 | -| 基础设施 | - | - | 50万 | -| **电力系统** | | | **800万** | -| 双路市电接入 | - | 2路 | 200万 | -| 变压器 | 800k | 2台 | 160万 | -| UPS系统 | 1500k | 2×250kW | 300万 | -| 柴油发电机 | 1800k | 2×300kW | 360万 | -| **冷却系统** | | | **600万** | -| 精密空调 | 200k | 4套 | 400万 | -| 冷冻水系统 | - | - | 150万 | -| 管道配件 | - | - | 50万 | -| **IT基础设施** | | | **1200万** | -| 服务器(虚拆化) | 80k | 25台 | 200万 | -| 存储系统 | 600k | 2套 | 120万 | -| 网络交换机 | 200k | 6台 | 120万 | -| 防火墙/安全 | 500k | 2套 | 100万 | -| 其他设备 | - | - | 60万 | -| **布线网络** | | | **200万** | -| 光纤布线 | - | - | 80万 | -| 综合布线 | - | - | 60万 | -| 网络配件 | - | - | 40万 | -| 通讯专线(首年) | 20k/月 | 12 | 20万 | -| **消防安全** | | | **150万** | -| 气体灭火 | - | - | 80万 | -| 火灾报警 | - | - | 40万 | -| 应急照明 | - | - | 20万 | -| 门禁视频 | - | - | 10万 | -| **其他费用** | | | **100万** | -| 设计咨询 | - | - | 50万 | -| 项目管理 | - | - | 30万 | -| 预留费 | - | - | 20万 | - -**总CAPEX**：**约5050万元**(51万/机柜) - -### 20.2 按规模推算 - -- 50机柜：2500-2800万元 -- 100机柜：5000-5200万元 -- 200机柜：9500-10000万元 -- 500机柜：22000-25000万元 - ---- - -## 21. OPEX运营成本 - -### 21.1 年度运营成本(100机柜) - -| 成本项 | 月成本 | 年成本 | -|--------|--------|--------| -| **电力成本** | | | -| 电费(1元/度) | 250万 | 3000万 | -| 柴油机燃油 | 50万 | 600万 | -| 小计 | 300万 | 3600万 | -| **人员成本** | | | -| 运维工资(20人) | 150万 | 1800万 | -| 安全工资(3人) | 25万 | 300万 | -| 管理工资(5人) | 50万 | 600万 | -| 小计 | 225万 | 2700万 | -| **维护支持** | | | -| 设备维保 | 50万 | 600万 | -| 软件许可 | 20万 | 240万 | -| 安全咨询 | 10万 | 120万 | -| 小计 | 80万 | 960万 | -| **通讯互联** | | | -| 互联网带宽 | 15万 | 180万 | -| 专线费用 | 30万 | 360万 | -| 小计 | 45万 | 540万 | -| **其他** | 20万 | 240万 | -| **合计** | 670万 | 8040万 | - -### 21.2 成本优化建议 - -**降低CAPEX(15-25%)** -- 模块化分阶段建设(初期50柜) -- 混合部署(与航站楼共用) -- 国产品牌设备(成本降20-30%) - -**降低OPEX(20-30%)** -- 提高虚拆化率(节省20-30%) -- 自动化运维(节省15-25%) -- 液冷技术(节省10-20%能耗) -- 云优先(非关键系统迁移) - -### 21.3 ROI与投资回收期 - -**5年总投资**：CAPEX 5050万 + 5年OPEX 40200万 = **约45250万元** - -**成本回收期**：5-7年(取决于机柜租赁/业务产值) - ---- - -## 22. 技术选型建议 - -### 22.1 分层选型指南 - -**计算虚拆化** -- 推荐：VMware vSphere(成熟稳定) 或 开源KVM -- 替代：Hyper-V(Windows环境) - -**存储** -- 高端：EMC/Dell、NetApp SAN(企业级) -- 中端：超融合(vSAN、Nutanix) -- 开源：Ceph、MooseFS - -**容器编排** -- 推荐：Kubernetes(K8s) -- 边缘：K3s、KubeEdge -- 微型：Docker Swarm - -**监控告警** -- 推荐：Prometheus + Grafana + AlertManager -- 企业级：Zabbix、Nagios - -**备份恢复** -- 推荐：Veeam、CommVault -- 开源：Bacula、Restic - -### 22.2 云平台选型 - -**公有云对标** - -| 平台 | 存储 | 计算 | 数据库 | 大数据 | 安全 | -|------|------|------|--------|--------|------| -| 阿里云 | OSS | ECS/ACK | RDS | MaxCompute | 等保四级 | -| 腾讯云 | COS | CVM/TKE | CDB | EMR | 等保四级 | -| AWS | S3 | EC2/EKS | RDS | EMR | AWS Gov云 | - -**推荐混合云组合** -- 本地IDC：核心业务系统 -- 公有云：大数据分析、AI训练、灾备 -- 成本平衡：冷数据/非关键系统迁移到云 - ---- - -## 23. 按机场等级的差异化方案 - -### 23.1 国际枢纽机场 - -**规模**：600-1000个机柜，CAPEX 20000-30000万元 - -**特点** -- Tier III/IV级别，99.99%可用性 -- 本地IDC + 异地灾备 + 混合云 -- 完整安全合规(等保四级) -- 支持500+业务系统 - -**重点投入** -- 双活/多活架构 -- 专业运维团队(30-40人) -- 国际标准对标(ICAO) - -### 23.2 区域机场 - -**规模**：200-400个机柜，CAPEX 8000-12000万元 - -**特点** -- Tier III级别，99.9%可用性 -- 本地IDC + 云扩展 -- 等保三级合规 -- 支持200+业务系统 - -**重点投入** -- 超融合基础设施 -- 自动化运维 -- 成本优化 - -### 23.3 支线机场 - -**规模**：50-150个机柜，CAPEX 2000-4000万元 - -**特点** -- Tier II/III级别，99.5-99.9% -- 本地小型IDC + 云优先 -- 等保二/三级合规 -- 支持100-150业务系统 - -**重点投入** -- 模块化设计 -- 云服务集成 -- 轻量级运维 - ---- - -# 第七部分：总体评估与建议 - -## 24. 方案优势分析 - -**技术先进性** -✓ 支持99.99%高可用性 -✓ 灵活的混合部署(本地+云+边缘) -✓ 完整的灾备保障(RPO < 1min，RTO < 5min) -✓ 支持未来扩展(容器化、边缘计算) -✓ 符合民航监管(等保四级、MH/T标准) - -**经济性** -✓ 分阶段建设降低初期投资 -✓ 模块化设计支持灵活扩展 -✓ 自动化运维降低人工成本 -✓ 混合云优化运营成本 - -**可持续性** -✓ 液冷技术降低PUE -✓ 绿色能源集成(太阳能+储能) -✓ 循环经济理念(设备回收利用) - ---- - -## 25. 风险应对与建议 - -**技术风险** -- 风险：虚拆化、容器化技术复杂度 -- 应对：建立专业运维团队，定期培训 - -**业务风险** -- 风险：系统迁移期间业务中断 -- 应对：分步迁移，灰度发布 - -**安全风险** -- 风险：网络安全威胁 -- 应对：零信任架构、SOC 24/7监测 - -**投资风险** -- 风险：成本超支 -- 应对：分阶段建设，严格招标管理 - ---- - -## 26. 实施路线图 - -**第一阶段(月1-6)：规划与设计** -- 完成选址论证、可研报告 -- 详细设计方案确定 -- 招标采购启动 - -**第二阶段(月6-18)：建设与部署** -- 土建工程并行 -- 设备采购与安装 -- 系统部署与集成测试 - -**第三阶段(月18-24)：试运行与投运** -- 容量验证、功能测试 -- 业务系统割接 -- 正式投运、知识沉淀 - ---- - -## 27. 成功因素与关键建议 - -**成功因素** -1. **领导支持**：机场管理层的充分重视和投入 -2. **技术引领**：引进国际先进设计理念，不盲目跟风 -3. **人才储备**：从建设期开始培养本地运维团队 -4. **全生命周期管理**：从规划、建设、运维全程把握 - -**关键建议** - -**建议1：标杆对标** -学习北京大兴、上海浦东等国内标杆，同时对标迪拜DXB、新加坡Changi等国际先进实践。 - -**建议2：分层差异化** -国际枢纽按最高标准(Tier IV)建设，区域机场和支线机场因地制宜，不追求过度冗余。 - -**建议3：云优先策略** -非关键系统优先上云，降低本地IT投资和运维成本。 - -**建议4：安全第一** -投入等保四级、MH/T合规建设，不能因成本压力而妥协。 - -**建议5：可持续创新** -持续跟踪液冷、AI运维等新技术，定期审视数据中心效能。 - ---- - -## 结论 - -本方案综合了国内外机场数据中心建设的最佳实践，结合中国民航的特色需求，提出了一套系统化、工程化、可实施的解决方案。该方案既满足当前机场信息系统的高可用需求，也为未来的智慧机场建设预留了充足的技术和空间扩展能力。 - -通过本方案的实施，机场数据中心将成为支撑业务高效运营、促进技术创新、保障信息安全的坚实基础。我们相信，按照本方案推进建设，机场数据中心将成为行业标杆，为中国民航的数字化转型和高质量发展做出积极贡献。 - ---- - -## 参考资源清单 - -本方案基于以下资源的深度调研： - -**国际标准与规范** -- Uptime Institute Tier Classification System -- ICAO Annex 14 - Aerodrome Design and Operations -- ISO 27001:2022 Information Security Management - -**国内标准与政策** -- GB 50174-2017 数据中心设计规范 -- GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求 -- MH/T 0076—2020 民用航空网络安全等级保护基本要求 - -**典型案例** -- 北京大兴国际机场建设及运营工作总结 -- 上海浦东机场卫星厅信息化建设(VMware SDDC案例) -- 迪拜国际机场模块化数据中心(Huawei FusionModule) -- 新加坡樟宜机场Terminal 5规划方案 - -**技术参考** -- 美国能源部《能效数据中心设计最佳实践指南》(2024版) -- 劳伦斯伯克利国家实验室《液冷技术标准与应用》 -- McKinsey《数据中心成本与计算力需求分析报告》 - diff --git a/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md b/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md deleted file mode 100644 index 6aeba29..0000000 --- a/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md +++ /dev/null @@ -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 diff --git a/airport-wiki/raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md b/airport-wiki/raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md deleted file mode 100644 index c5183cf..0000000 --- a/airport-wiki/raw/articles/深圳机场-数智化全国第二-AI全栈部署-2026-01-15.md +++ /dev/null @@ -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在华为昇腾集群上的部署细节（集群规模、互联网络）未披露 -- 深圳机场未披露具体服务器数量和功率密度 -- 液冷技术未提及，可能仍在建设智算中心基础设施层面 diff --git a/airport-wiki/raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md b/airport-wiki/raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md deleted file mode 100644 index 835b04c..0000000 --- a/airport-wiki/raw/articles/福州长乐机场-15000P智算中心-2026-01-22.md +++ /dev/null @@ -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系列或国产品牌 diff --git a/airport-wiki/raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md b/airport-wiki/raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md deleted file mode 100644 index 3cbd641..0000000 --- a/airport-wiki/raw/articles/郑州航空港-中部最大万卡算力集群-2026-03-05.md +++ /dev/null @@ -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型号、机柜数、功率）未披露 -- 三个板块分期建设，三中心"十万卡"仍为规划阶段 diff --git a/airport-wiki/systems-design/aodb-system-architecture.md b/airport-wiki/systems-design/aodb-system-architecture.md deleted file mode 100644 index 9322244..0000000 --- a/airport-wiki/systems-design/aodb-system-architecture.md +++ /dev/null @@ -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 -│ ├── LegIdentifier: UFI (唯一航班标识, 值对象) -│ ├── LegData -│ │ ├── ScheduledTimes (计划时间, SCT) -│ │ ├── EstimatedTimes (预计时间, EST) -│ │ ├── ActualTimes (实际时间, ACT) -│ │ ├── PaxCount (旅客数) -│ │ └── AircraftInfo (机型/注册号/尾号) -│ └── Resources: List -│ -├── Milestones: List (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, 航司/管制/服务商) -│ -├── PreDeparturesequencing: List -│ └── 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 再详细设计 diff --git a/airport-wiki/机场智算中心技术方案.md b/airport-wiki/机场智算中心技术方案.md deleted file mode 100644 index b5f098b..0000000 --- a/airport-wiki/机场智算中心技术方案.md +++ /dev/null @@ -1,1205 +0,0 @@ ---- -title: 机场智算中心技术方案 -created: 2026-04-08 -updated: 2026-04-10 -type: solution -tags: [solution, gpu, liquid-cooling, tier, power, network] -sources: [raw/articles/shanghai-ai-computing-guidelines.md, raw/articles/headleo-aiDC-whitepaper.md, raw/articles/industrial-ai-computing-report.md, raw/articles/dubai-airport-huawei-dc.md, raw/articles/daxing-airport-vertiv.md, raw/articles/2025-airport-construction-summit.md, raw/articles/zhengzhou-airport-hangang.md, raw/articles/fuzhou-changle-airport-bsj.md] ---- - -# 机场智算中心技术方案 - -> 本方案以机场 wiki 现有资料库为依据，综合：上海智算中心建设导则（2025）、头豹 AIDC 白皮书（2025）、工业智算报告、大兴/迪拜/大连/郑州/福州/深圳等机场案例 -> 生成时间：2026-04-10 | 数据来源：详见附录 - ---- - -## 一、概述 - -### 1.1 什么是机场智算中心 - -机场智算中心（Airport Intelligent Computing Center）是支撑机场智能化运营的 **GPU/NPU/ASIC 异构算力集群**，区别于传统数据中心（CPU 为主、风冷、PUE 1.4+），智算中心以 AI 训练/推理为核心负载，必须采用液冷散热和东西向高速网络。 - -### 1.2 传统 DC vs 智算中心核心差异 - -| 对比项 | 传统数据中心 | 智算中心 | -|--------|------------|---------| -| 核心负载 | ERP、Web、数据库 | AI 训练/推理、视频分析 | -| 算力芯片 | CPU 为主 | GPU/NPU 集群为主 | -| 单机柜功率 | 5–15 kW | **50–200+ kW** | -| 散热方式 | 风冷为主 | **液冷为主** | -| 网络重点 | 南北向 | **东西向高速互联** | -| PUE 目标 | 1.4–1.6 | **≤ 1.25**（全液冷 ≤ 1.15）| - -### 1.3 典型应用场景与算力需求 - -| 应用场景 | 算力类型 | 典型规模 | -|---------|---------|---------| -| 航班智能调度（大模型） | 训练 + 推理 | 7B–70B 参数模型微调 | -| 行李全流程追踪（CV） | 推理为主 | 100+ 摄像头视频流 | -| 航站楼安防/客流热力图 | 推理为主 | 实时视频分析 | -| 语音客服机器人 | 推理为主 | 并发 500+ QPS | -| 飞机故障预测（时序） | 训练 + 推理 | 时序数据分析 | -| 机场数字孪生 | 训练 + 推理 | 物理仿真 + 渲染 | -| 智能巡检机器人 | 推理为主 | 边缘部署 | -| 行李异常检测（多模态） | 推理为主 | CV + NLP | - -### 1.4 中国智算市场规模参考 - -| 年份 | 中国智算规模 | 同比增速 | -|------|----------|---------| -| 2024 | 725.3 EFlops（FP16）| +74.1% | -| 2025E | 1,037.3 EFlops | +43% | -| 2028E（复合增长 46.2%）| — | — | - -> 数据来源：IDC + 浪潮信息《中国人工智能计算力发展评估报告》 - -### 1.5 机场智算中心规模分级建议 - -| 机场规模 | 推荐算力 | GPU 卡数参考 | 典型机柜数 | -|---------|---------|------------|---------| -| 年旅客量 < 1,000 万 | 1–10 PFLOPS（FP16）| 64–512 卡 | 8–32 柜 | -| 年旅客量 1,000–5,000 万 | 10–50 PFLOPS | 512–2,048 卡 | 32–128 柜 | -| 年旅客量 > 5,000 万 | 50–200+ PFLOPS | 2,048–8,000+ 卡 | 128–500+ 柜 | - ---- - -## 二、系统架构 - -### 2.1 整体架构 - -``` -┌──────────────────────────────────────────────────────┐ -│ 应用服务层 │ -│ 航班调度大模型 │ 行李追踪 │ 安防分析 │ 客服机器人 │ -├──────────────────────────────────────────────────────┤ -│ 模型服务层 │ -│ 推理引擎（vLLM / TensorRT-LLM）│ 微调框架 │ 模型仓库 │ -├──────────────────────────────────────────────────────┤ -│ 训练平台层 │ -│ 分布式训练框架（NCCL / Megatron-LM / DeepSpeed） │ -├──────────────────────────────────────────────────────┤ -│ 算力调度层 │ -│ Kubernetes + Volcano │ 作业管理 │ 配额计费 │ 碳排管理│ -├──────────────────────────────────────────────────────┤ -│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ -│ │ 训练集群 │ │ 推理集群 │ │ 国产化集群 │ │ -│ │ HGX H100 │ │ L40S/昇腾 │ │ 昇腾 910B │ │ -│ └──────────┘ └──────────┘ └──────────┘ │ -├──────────────────────────────────────────────────────┤ -│ 存储层 │ -│ JuiceFS + 对象存储（S3）│ 全闪存分布式 │ 本地 NVMe 缓存│ -├──────────────────────────────────────────────────────┤ -│ 网络层 │ -│ Spine-Leaf 400G │ InfiniBand NDR 400G │ RoCE v2 │ -├──────────────────────────────────────────────────────┤ -│ 基础设施层 │ -│ 供配电（2N UPS）│ 液冷系统（CDU）│ 机柜 │ 消防 │ 监控│ -└──────────────────────────────────────────────────────┘ -``` - -### 2.2 云-边-端协同 - -``` -云端（智算中心） - ├── 训练集群：大规模长时训练任务 - ├── 推理服务：实时性要求不高的批量推理 - └── 模型管理：微调、版本管理 - -边缘（航站楼 / 塔台边缘节点） - ├── 实时推理：客流分析、安防告警（< 100ms） - ├── 数据汇聚：本地数据预处理 - └── 断网自治：与云端断连时独立运行 - -端侧（摄像头、传感器、机器人） - ├── 轻量推理：目标检测、异常初筛 - └── 数据采集：原始数据上报 -``` - -### 2.3 异构算力架构 - -| 芯片类型 | 代表产品 | FP16 算力 | 显存带宽 | 功耗 | 适用场景 | -|---------|---------|-----------|---------|------|---------| -| **GPU（主流）** | NVIDIA H100 SXM5 | ~1 PFLOPS | 3.35 TB/s | 700W | 大模型训练 | -| **GPU（主流）** | NVIDIA H200 SXM | ~1 PFLOPS | **4.8 TB/s**（HBM3e）| 700W | 大规模训练 / 推理 | -| **GPU** | NVIDIA B200 | 2.25 PFLOPS | 8 TB/s | 1,200W | 超大规模智算中心 | -| **GPU（旗舰）** | **GB200 NVL72** | **~5 PFLOPS** | 16 TB/s | 2,700W/芯片 | 万卡集群（整机柜方案）| -| **GPU（推理）** | NVIDIA L40S | ~2 PFLOPS | 864 GB/s | 350W | 推理为主、中等规模 | -| **NPU（国产）** | 华为昇腾 910B | 640 TFLOPS | — | 400W | 国产化替代 | -| **ASIC（国产）** | 海光 DCU Z100 | 256 TFLOPS | — | 350W | 国产化替代（ROCm 兼容 CUDA）| - -> GB200 NVL72 为整机柜方案：72 GPU + 36 Grace CPU，详见第四章 - ---- - -## 三、液冷系统 - -> **液冷是智算中心高功率密度散热的核心技术路线**，也是本方案重点。 - -### 3.1 背景：芯片功耗爆炸式增长 - -| 芯片 / 系统 | 功耗 | 散热方式 | -|------------|------|---------| -| CPU（至强 2000 系列）| 450–500W/颗 | 风冷极限 | -| GPU（A100） | 400W | 需液冷 | -| GPU（H100） | 700W | 必须液冷 | -| GPU（GB200） | **2,700W/超级芯片** | 必须液冷（相变或冷板）| -| GPU 机架（2024 年典型）| ~130 kW/rack | 必须液冷 | -| GPU 机架（2029 年预测）| **> 1 MW/rack** | 全面液冷 | - -### 3.2 液冷技术路线对比 - -| 对比项 | 冷板式液冷 | 浸没式液冷（单相）| 浸没式液冷（相变）| -|--------|----------|----------------|----------------| -| 成熟度 | ★★★★★ 最高 | ★★★★ 高 | ★★★ 中 | -| 服务器改动 | 冷板安装 | 需定制服务器 | 需定制服务器 | -| 维护便利性 | ★★★★ 较好 | ★★★ 一般 | ★★ 复杂 | -| 散热能力 | 强 | 极强 | 极强（相变换热）| -| 单机柜密度 | 40–130 kW | 100–500 kW | 250–500+ kW | -| 初期投资 | 中等 | 较高 | 最高 | -| **适用场景** | **当前主流，推荐** | 高密度细分场景 | 超高功率特种场景 | - -### 3.3 冷板式液冷架构 - -**系统架构：** - -``` -室外侧（一次侧冷源） - 冷却塔 / 干冷器 - ↓（自然冷却 / 蒸发冷却） - 冷水机组（夏季备用） - ↓ - 一次侧循环管路 - ↓ 板式换热器 -室内侧（二次侧供液） - CDU（冷却分配单元） - ↓ - Manifold（液冷分配岐管） - ↓ - 冷板（直接贴附芯片：CPU + GPU + 内存） - ↓ - 服务器内部 -``` - -**关键设备参数：** - -| 设备 | 功能 | 关键参数 | -|------|------|---------| -| CDU | 冷却液循环、温度控制 | 典型容量 200–400 kW，支持双路 | -| Manifold | 分液到各机柜 | 316L 不锈钢，多路分配 | -| 冷板 | 直接接触芯片散热 | 接触面导热硅脂，微通道设计 | -| 冷却液 | 冷板式常用 | 乙二醇/丙二醇溶液（防冻）| - -### 3.4 液冷方案推荐 - -#### 方案 A：冷板式液冷（推荐新建机场智算中心） - -| 参数 | 数值 | -|------|------| -| 液冷占比 | 80–100%（全液冷） | -| 风冷辅助 | 仅用于网络设备、少量通用服务器 | -| PUE 目标 | ≤ 1.15（全液冷）/ ≤ 1.25（80% 液冷）| -| 单柜功率上限 | 130 kW（GB200 NVL72 级别）| - -**Vertiv GB200 NVL72 参考架构：** -- 单机柜功率：**130 kW** -- 架构：72 GPU + 36 CPU（Grace Blackwell） -- 散热：100% 冷板液冷 -- 能耗节省：比传统风冷减少 **25%** -- 空间节省：减少 **75%** 机柜占地 - -#### 方案 B：风液融合（过渡期） - -| 参数 | 数值 | -|------|------| -| 风冷支持 | 最高 40 kW/柜 | -| 液冷支持 | 最高 150 kW/柜 | -| 特点 | 风液同源、动态平衡、灵活部署 | - -### 3.5 PUE / WUE / CUE 三级能效指标 - -上海智算中心建设导则（2025）要求（全国最严）： - -| 指标 | 新建标准值 | 运营先进值 | 长三角集群 | -|------|----------|----------|---------| -| **PUE（基准）** | ≤ 1.25 | — | — | -| **PUE（综合）** | ≤ 1.22 | ≤ 1.18 | ≤ 1.20 | -| **WUE** | ≤ 2.2 L/kWh | ≤ 2.0 L/kWh | — | -| **CUE** | ≤ 1.2 gCO₂/kWh | ≤ 1.0 gCO₂/kWh | — | - -**PUE 优化措施：** - -| 措施 | 效果 | -|------|------| -| 全液冷替代精密空调 | PUE 从 1.5 降至 **1.15–1.25** | -| 冷通道封闭 | 减少冷热气流混合，节能 10–15% | -| 自然冷却利用 | 冬季低温期配合液冷进一步降低 PUE | -| 高效 UPS（模块化效率 ≥ 96%）| 降低供电损耗 | -| AI 调优 | 实时调节液冷流量与温度 | - -### 3.6 国产液冷供应商参考 - -| 供应商 | 方案类型 | 代表参数 | -|--------|---------|---------| -| 英维克（Envicool）| 冷板式 + 浸没式 | 单机柜散热能力 24 kW，散热效率提升 40% | -| 中科曙光 | 浸没式液冷 | PUE 低至 1.04，年减碳量超万吨 | -| 华为 | 冷板式 + 液冷 CDU | 临港智算谷项目，单柜 20–60 kW | - ---- - -## 四、算力集群 - -> **设计原则**：本章遵循 **Scale-Up（节点内纵向扩展）+ Scale-Out（节点间横向扩展）** 双重架构。Scale-Up 以 NVLink/NVSwitch 为核心解决节点内 GPU 全互联；Scale-Out 以 InfiniBand/RoCE 为骨干解决多节点集合通信。 - -### 4.1 GPU 节点架构演进 - -| 代际 | 代表产品 | GPU 互联方式 | NVLink 聚合带宽 | GPU 对等带宽 | -|------|---------|------------|--------------|------------| -| 第 1 代（2018）| V100 SXM2 | NVLink 1.0，6 链路 | 300 GB/s | 300 GB/s | -| 第 2 代（2020）| A100 SXM4 | NVLink 3.0，12 链路 | 600 GB/s | 600 GB/s | -| 第 3 代（2022）| H100 SXM5 | NVLink 4.0，18 链路 | 900 GB/s | 900 GB/s | -| 第 4 代（2024）| B200 SXM | NVLink 5.0，18 链路 | **1.8 TB/s** | **900 GB/s** | -| 第 5 代（预测）| Rubin Ultra | NVLink 6.0 | ~3.6 TB/s | ~1.8 TB/s | - -> 注：NVLink 5 "1.8 TB/s" 为 Fabric 聚合总带宽，**任意 GPU 到任意 GPU 对等带宽为 900 GB/s 双向**（与 H100 相同）。带宽提升主要来自更多链路并行，而非单链路提速。 - -### 4.2 HGX H100 8-GPU 节点拓扑 - -``` - ┌─────────────────────────────────┐ - │ HGX H100 8-GPU Server │ - CPU (AMD EPYC / Intel Xeon) │ - │ × 2 │ - │ │ - PCIe Gen5 x16 (Host Bridge) │ - │ │ - ┌──────────────────────────────────────────────┐ │ - │ NVSwitch Fabric（6 芯片，2 平面） │ │ - │ NVSwitch① ── NVSwitch② ── NVSwitch③ │ │ - │ ↖ ↑ ↗ │ │ - │ NVSwitch④ ── NVSwitch⑤ ── NVSwitch⑥ │ │ - │ （全连接拓扑，任意 GPU 间单跳可达） │ │ - └──────────────────────────────────────────────┘ │ - │ │ │ │ │ │ │ │ │ - GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 │ - H100 H100 H100 H100 H100 H100 H100 H100 │ - SXM5 SXM5 SXM5 SXM5 SXM5 SXM5 SXM5 SXM5 │ - 80GB 80GB 80GB 80GB 80GB 80GB 80GB 80GB │ - HBM3 HBM3 HBM3 HBM3 HBM3 HBM3 HBM3 HBM3 │ - └────────── PCIe Gen5 ─────────┘ │ - └────── InfiniBand / RoCE 网卡 ───────────────┘ │ - └─────────────────────────────────┘ -``` - -**关键拓扑参数（HGX H100）：** - -| 参数 | 规格 | -|------|------| -| GPU 数量 | 8 × NVIDIA H100 SXM5 | -| GPU 间 NVLink 带宽 | 900 GB/s 双向（全互联）| -| NVSwitch 芯片数 | **6 片**（2 组各 3 片，双平面全连接）| -| NVSwitch 交换容量 | 25.6 Tb/s 每芯片 | -| 单节点 BF16 算力（稀疏）| ~3,958 TFLOPS ≈ **4 PFLOPS** | -| 单节点 FP16 算力（稠密）| ~1,979 TFLOPS ≈ **2 PFLOPS** | -| 每 GPU HBM3 容量 | 80 GB（SXM5）| -| 每 GPU HBM3 带宽 | 3.35 TB/s | -| CPU 配置 | 2 × AMD EPYC 9004/9005 或 Intel Xeon Scalable | -| 主机内存 | 2 TB DDR5 ECC | -| 本地 SSD | 2 × 3.84 TB NVMe（OS + 缓存）| -| 电源配置 | 4 × 3.3 kW PSU（整机 ~13 kW）| -| **散热方式** | **冷板式液冷（必须）** | - -### 4.3 GB200 NVL72 机架级超级芯片 - -**GB200 NVL72** 是 NVIDIA Blackwell 架构的整机柜集成方案，代表当前最极致的 Scale-Up 设计： - -| 组件 | 数量 | 参数 | -|------|------|------| -| Blackwell GPU (B200) | 72 张 | 每 GPU BF16 算力 ~1,800 TFLOPS（稀疏）| -| Grace CPU (Neoverse V2) | 36 颗 | 72 核 ARM，每颗 240 GB LPDDR5 | -| NVLink Switch 芯片 | 9 片 | 第 4 代 NVLink Switch | -| GPU 内存总量 | 13.5 TB HBM3e | 每 GPU 186 GB（×72）| -| CPU 内存总量 | 8.6 TB LPDDR5 | 每 CPU 240 GB（×36）| -| NVLink 域带宽（聚合）| **130 TB/s** | 72 GPU 全互联 | -| **单机柜功率** | **132 kW**（TDP）| -| **散热方式** | **100% 冷板液冷** | - -**计算托盘结构：** -``` -每个计算托盘： - ┌─────────────────────────────────┐ - │ 1 × GB200 超级芯片 (= 2×B200 + 1×Grace CPU) │ - │ 显存: 2 × 186 GB = 372 GB HBM3e │ - │ 功率: ~2.7 kW（超级芯片总功耗） │ - └─────────────────────────────────┘ - -18 个计算托盘 × 4 GPU/托盘 = 72 GPU -``` - -**NVLink 域设计：** -- 72 GPU 在同一个 NVLink 域内全互联，任意两 GPU 通信单跳 -- **对等带宽：900 GB/s**（是 InfiniBand NDR 400G 的约 2.3 倍） -- 张量并行可覆盖全部 72 GPU，适合超大规模模型 - -> 机场场景建议：GB200 NVL72 单柜 132 kW，功率密度极高。**当前阶段以 HGX H100/H200 8-GPU 节点为主**（单节点 ~13 kW，可用液冷机柜支撑）。NVL72 预留规划，待功率和液冷成熟后再规模部署。 - -### 4.4 推理服务器节点（4-GPU 配置） - -| 参数 | NVIDIA L40S 方案 | 昇腾 910B 方案（国产）| -|------|----------------|------------------| -| GPU 数量 | 4 × L40S | 4 × 昇腾 910B | -| GPU 显存 | 48 GB GDDR6 | 64 GB HBM | -| GPU 间互联 | PCIe Gen4 交换（无 NVLink）| HCCS（华为集合通信）| -| GPU 通信带宽 | ~64 GB/s（PCIe x16）| ~392 GB/s（HCCS）| -| 单节点算力 | ~2 PFLOPS（FP16）| ~2 PFLOPS（FP16）| -| 功耗 | ~4 kW/节点 | ~4.5 kW/节点 | -| 适用场景 | 中等规模推理 | 国产化推理 | - -### 4.5 多节点集群组网（Scale-Out） - -#### 4.5.1 三层三平面网络架构 - -``` -┌────────────────────────────────────────────────────────────┐ -│ 集群外部网络（Border） │ -│ 互联网 / 专线 / 机场内部网络 ←→ 防火墙 / 负载均衡 │ -└────────────────────────────────────────────────────────────┘ - │ -┌────────────────────────────────────────────────────────────┐ -│ 管理网络平面（Management Network） │ -│ BMC / IPMI / SSH / 监控采集 │ -│ ←→ 千兆以太网（Out-of-Band） │ -└────────────────────────────────────────────────────────────┘ - │ -┌────────────────────────────────────────────────────────────┐ -│ 存储网络平面（Storage Network） │ -│ 分布式存储读写 / Checkpoint 存取 │ -│ ←→ RoCE v2 / InfiniBand + NVMe-oF │ -│ 带宽：200–400 Gb/s │ -└────────────────────────────────────────────────────────────┘ - │ -┌────────────────────────────────────────────────────────────┐ -│ 计算网络平面（AI Fabric） │ -│ GPU 集合通信（NCCL） / 梯度同步 / 数据并行 │ -│ ←→ InfiniBand NDR 400G / Spectrum-X 400G │ -│ 带宽：400 Gb/s（节点间） │ -└────────────────────────────────────────────────────────────┘ -``` - -#### 4.5.2 InfiniBand NDR 400G 组网 - -**InfiniBand 是当前 AI 训练集群的事实标准网络：** - -| 特性 | 说明 | -|------|------| -| 硬件原生 RDMA | 绕过 OS 内核，延迟 < 1 μs | -| 自适应路由（AR）| 每包独立路由，充分利用所有链路 | -| SHARP 网内计算 | 交换机内聚合梯度，无需送回 GPU 再聚合 | -| NCCL 原生支持 | NVIDIA 集合通信库直接调用 | - -**关键参数：** - -| 参数 | 规格 | -|------|------| -| 单端口带宽 | 400 Gbps（NDR = Next Data Rate）| -| 编码方式 | PAM4（每 lane 53.125 Gbaud）| -| 线缆类型 | 光纤（多模 OM4 / 单模 LC）| -| 交换机型号 | NVIDIA QM9700 系列 | -| 交换机端口密度 | 64 端口 × 400G | -| 拓扑支持 | Fat-Tree / DragonFly+ / Hypercube | -| 每交换机延迟 | < 0.6 μs（端到端）| -| 拥塞控制 | CNP（Congestion Notification Packet）| - -**Fat-Tree 拓扑设计（推荐中小规模 512 GPU）：** - -``` - ┌─────────────┐ - │ Core Switch │ InfiniBand QM9700 - │ (2–4 台) │ 64 端口 400G - └──────┬──────┘ - │ - ┌─────────────────┼─────────────────┐ - │ │ │ - ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ - │ Agg 1 │ │ Agg 2 │ │ Agg 3 │ - │ QM9700 │ │ QM9700 │ │ QM9700 │ - └────┬────┘ └────┬────┘ └────┬────┘ - │ │ │ - [16 servers] [16 servers] [16 servers] - 每组 8× GPU 每组 8× GPU 每组 8× GPU -``` - -#### 4.5.3 Spectrum-X 以太网方案（替代 / 混合场景） - -| 参数 | Spectrum-X 400G | InfiniBand NDR 400G | -|------|---------------|---------------------| -| 技术基础 | 以太网（RoCE v2）| InfiniBand | -| 延迟 | 1–2 μs | < 0.6 μs | -| 生态开放性 | 高（标准以太网）| 低（需 IB 交换设备）| -| 运维复杂度 | 低（统一以太网运维）| 高（独立 IB 网络）| -| **推荐场景** | 推理集群、混合云 | **训练集群（强烈推荐）**| - -#### 4.5.4 万卡集群（SuperPOD）规格 - -| 参数 | 1,024 GPU（128 节点）| 2,048 GPU（256 节点）| -|------|-------------------|---------------------| -| 交换机型号 | QM9700 | QM9700 | -| Spine 数 | 8 | 16 | -| 每 Spine 下联 | 32 端口 400G | 32 端口 400G | -| Agg 层 | 16 | 32 | -| 收敛比 | 1:1（无收敛）| 1:1（无收敛）| -| 网络直径 | 3 跳（最差路径）| 3 跳 | - -**关键设计原则：** -1. **收敛比 ≤ 1:1**：AI 训练流量无阻塞 -2. 每服务器双上联（2 × 400G IB），LACP Bonding 冗余 -3. GPU Direct RDMA：跨节点 GPU 直接内存访问，绕过 CPU -4. SHARP 网内聚合：梯度在交换机内聚合，节省 30–50% 通信量 - -### 4.6 存储集群 - -#### 4.6.1 存储需求分析 - -| 存储类型 | 用途 | 性能要求 | 典型容量 | -|---------|------|---------|---------| -| **数据湖存储** | 原始训练数据、语料库 | 顺序读带宽 ≥ 500 GB/s | 10–100 PB | -| **模型存储** | 检查点、训练产出模型 | 写入带宽 ≥ 100 GB/s，延迟 < 1 ms | 1–10 PB | -| **共享文件系统** | 代码、配置、小文件共享 | IOPS ≥ 1M | 100 TB–1 PB | -| **本地缓存** | 热点数据本地加速 | NVMe 本地读缓存 | 1–10 TB/节点 | - -> 性能目标有前置条件：需足够的存储节点数量（20+ 全闪存存储节点）、充足的存储网络带宽（200G+）、正确配置的小文件聚合策略。 - -#### 4.6.2 推荐架构：JuiceFS + 对象存储（S3）+ 本地 NVMe 缓存 - -| 参数 | 推荐值 | -|------|-------| -| 元数据引擎 | TiKV（分布式，≥3 节点）| -| 数据存储 | 对象存储（S3 兼容）| -| 本地缓存 | 每节点 1–2 TB NVMe SSD（L1 缓存）| -| 小文件聚合 | 4 MiB chunk，减少元数据压力 | -| 读取预取 | 自动预取临近数据块 | - -**存储产品选型：** - -| 产品 | 类型 | 适用规模 | AI 训练适配度 | -|------|------|---------|------------| -| JuiceFS | 元数据 + 对象存储分离 | 中大规模 | ★★★★★ | -| BeeGFS | 并行文件系统 | 超大规模 | ★★★★ | -| GPFS（IBM Spectrum Scale）| 并行文件系统 | 企业级 | ★★★★ | -| 曙光 ParaStor | 全闪存分布式 | 国产化 | ★★★★ | -| 华为 OceanStor 9000 | 全闪存分布式 | 大规模 | ★★★★ | - -#### 4.6.3 存储网络设计 - -| 网络平面 | 协议 | 带宽 | 交换机 | -|---------|------|------|-------| -| 计算网络 | InfiniBand NDR | 400G × 2（双上联）| QM9700 | -| 存储网络 | RoCE v2 + NVMe-oF | 200–400G | Spectrum-X / 华为 CloudEngine | -| 管理网络 | 以太网 | 1G | 接入交换机 | - -### 4.7 软件栈与训练框架 - -#### 4.7.1 五层软件栈 - -``` -┌──────────────────────────────────────────┐ -│ 应用层：训练脚本（PyTorch / LLaMA-Factory） │ -├──────────────────────────────────────────┤ -│ 框架层：PyTorch 2.x + 分布式通信优化 │ -│ DeepSpeed / Megatron-LM / ColossalAI │ -├──────────────────────────────────────────┤ -│ 通信层：NCCL 2.x（NVIDIA） │ -│ HCCS（昇腾）/ OpenUCCL（国产） │ -├──────────────────────────────────────────┤ -│ 驱动层：CUDA 12.x / ROCm 6.x │ -│ GPU Driver / cuBLAS / cuDNN │ -├──────────────────────────────────────────┤ -│ 硬件层：NVLink / InfiniBand / RoCE │ -└──────────────────────────────────────────┘ -``` - -#### 4.7.2 框架选型 - -| 框架 | 适用场景 | 并行策略 | -|------|---------|---------| -| **PyTorch 2.x + FSDP** | 通用大模型训练 | DDP / FSDP / TP | -| **DeepSpeed ZeRO** | 超大模型（千亿参数+）| ZeRO-1/2/3、流水线、张量并行 | -| **Megatron-LM** | 极致张量并行优化 | TP + PP + DP 三维并行 | -| **ColossalAI** | 异构训练、多种并行策略 | 动态调度、ZeRO++ | - -#### 4.7.3 NCCL 关键配置 - -```bash -# NCCL 环境变量参考配置 -NCCL_DEBUG=info # 调试日志（生产环境关闭） -NCCL_IB_DISABLE=0 # 启用 InfiniBand -NCCL_NET_GDR_LEVEL=PIX # GPU 直接访问网卡（最佳性能） -NCCL_NVLS_DISABLE=0 # 启用 NVLink 域内通信 -NCCL_MAX_NCHANNELS=16 # InfiniBand 多路径 -``` - -**预期 NCCL 带宽基准：** - -| 通信模式 | H100 NVLink 域内 | H100 InfiniBand 400G | L40S PCIe | -|---------|----------------|---------------------|-----------| -| AllReduce（8 GPU）| ~850–900 GB/s | 300–350 GB/s | ~60 GB/s | -| AllGather | ~880 GB/s | 280–320 GB/s | ~55 GB/s | -| ReduceScatter | ~870 GB/s | 280–320 GB/s | ~55 GB/s | - -> **目标**：IB 400G 的 NCCL 带宽应达到理论峰值的 **80% 以上**（≥ 320 GB/s），否则说明网络瓶颈。 - -#### 4.7.4 作业调度器选型 - -| 调度器 | 适用场景 | 优点 | 缺点 | -|--------|---------|------|------| -| **Slurm** | 超算 / HPC 传统场景 | 生态成熟，稳定可靠 | 不支持容器原生 | -| **Kubernetes + Volcano** | 云原生 AI 平台 | 生态丰富，弹性伸缩 | 配置复杂 | -| **Kubeflow** | MLOps 全流程 | 与 K8s 深度集成 | 较重 | - -### 4.8 推理集群 - -#### 4.8.1 推理引擎对比 - -| 引擎 | 开发方 | KV Cache | 多模型 | 国产适配 | -|------|-------|---------|-------|--------| -| **vLLM** | 伯克利 LMSYS | PagedAttention | 是 | 昇腾（第三方）| -| **TensorRT-LLM** | NVIDIA 官方 | 动态批处理 | 是 | 仅 NVIDIA GPU | -| **SGLang** | 斯坦福 | RadixAttention | 是 | 昇腾（实验）| -| **TGI** | HuggingFace | 是 | 是 | 昇腾（第三方）| - -#### 4.8.2 PD 分离架构（超大规模推理） - -对于超大模型（> 70B），**Prefill-Deploy 分离**可显著提升 GPU 利用率： - -``` - ┌─────────────┐ - │ Router │ - └──────┬──────┘ - │ - ┌────────────┴────────────┐ - ▼ ▼ - ┌─────────────┐ ┌─────────────┐ - │ Prefill 节点 │ │ Decode 节点 │ - │ H100/H200 │ KV Cache │ L40S/H20 │ - │ 计算密集 │ ──传输──→ │ 显存密集 │ - │ 高延迟 │ │ 低延迟高吞吐 │ - └─────────────┘ └─────────────┘ -``` - -| 对比项 | 传统单节点推理 | PD 分离推理 | -|--------|------------|----------| -| GPU 利用率 | < 30%（Decode 瓶颈）| 70–90% | -| 首 token 延迟 | 固定 | 可优化 | -| 吞吐 | 受限于最慢阶段 | 各阶段独立扩缩容 | -| 适用模型 | < 30B 参数 | 任意规模，尤其是 > 70B | - -### 4.9 国产化集群 - -#### 4.9.1 华为昇腾 910B - -| 参数 | 昇腾 910B | NVIDIA H100 | 对比 | -|------|---------|-----------|------| -| FP16 算力 | 640 TFLOPS | 1,979 TFLOPS | H100 的 ~32% | -| INT8 算力 | 1,280 TOPS | 3,958 TOPS | H100 的 ~32% | -| HBM 容量 | 64 GB | 80 GB | — | -| HBM 带宽 | 1.6 TB/s | 3.35 TB/s | H100 的 ~48% | -| 芯片互联 | **HCCS（392 GB/s）**| NVLink（900 GB/s）| HCCS > PCIe Gen4，基本持平 NVLink 4 代单链路 | -| 功耗 | 400 W | 700 W | 能效比更优 | -| 制程 | 7nm | 4nm | 差一代 | -| 生态 | 昇腾 CANN / MindSpore | CUDA / cuDNN | **差距较大**，需移植 | - -> 注：HCCS 双向带宽 **392 GB/s**（8 × HCCS 端口），用于 8 × NPU 节点内全互联。 - -**昇腾软件栈：** - -| 层次 | 昇腾组件 | 替代 NVIDIA | -|------|---------|-----------| -| 芯片 | Ascend 910B NPU | H100/H200 GPU | -| 驱动 | Huawei CANN | CUDA | -| 通信库 | HCCS（昇腾集合通信）| NCCL | -| 框架 | MindSpore / PyTorch（第三方）| PyTorch | -| 推理引擎 | MindX / ATLAS | TensorRT | - -#### 4.9.2 海光 DCU Z100 - -| 参数 | 海光 DCU Z100 | NVIDIA A100 | 对比 | -|------|-------------|-----------|------| -| FP16 算力 | 256 TFLOPS | 624 TFLOPS | A100 的 ~41% | -| HBM 容量 | 64 GB | 40/80 GB | 对标 A100 80G | -| 功耗 | 350 W | 400 W | 略低 | -| 生态 | ROCm（部分兼容）| CUDA | **兼容性优于昇腾**，迁移成本较低 | - -### 4.10 硬件监控体系 - -| 监控维度 | 工具 | 采集指标 | -|---------|------|---------| -| GPU 监控 | DCGM（NVIDIA）/ msmonitor（昇腾）| 温度、功耗、利用率、显存、ECC 错误 | -| InfiniBand 监控 | UFM（NVIDIA）/ Mellanox firmware | 端口状态、误码率、拓扑 | -| 存储监控 | JuiceFS / BeeGFS 内置工具 | 带宽、IOPS、元数据延迟 | -| 节点监控 | node_exporter + Prometheus | CPU、内存、网络、磁盘 | -| 集群健康 | Grafana 大盘 | 综合集群状态 | - -**关键告警阈值：** - -| 级别 | 指标 | 阈值 | 动作 | -|------|------|------|------| -| P1（紧急）| GPU 温度 | > 85°C | 立即降频 / 关机 | -| P1 | GPU ECC 错误数 | > 100/小时 | 标记节点下线 | -| P2（重要）| GPU 利用率 | < 10%（训练时）| 检查 NCCL 通信 | -| P2 | InfiniBand 端口误码 | > 10⁻⁶ | 更换光模块 / 线缆 | - -### 4.11 机场智算中心推荐配置 - -#### 方案一：中等规模（年旅客量 < 1,000 万，推理为主） - -| 项目 | 配置 | -|------|------| -| GPU 类型 | NVIDIA L40S × 4/节点 | -| 节点数量 | 32 节点 = 128 GPU | -| 主要负载 | 推理服务、视频分析、Agent | -| 集群算力 | ~256 TFLOPS（FP16）| -| 网络 | RoCE v2 200G + 以太网管理 | -| 存储 | JuiceFS + 对象存储，2 PB | -| 服务器形态 | 4U 液冷机架服务器 | -| 预估总功耗 | 约 256 kW | -| 国产化 | 可选昇腾 910B × 4 混部 | - -#### 方案二：大规模（年旅客量 1,000–5,000 万，训练 + 推理） - -| 项目 | 配置 | -|------|------| -| 训练 GPU | NVIDIA H100 SXM5 × 8/节点 | -| 训练节点数 | 32 节点 = 256 GPU | -| 训练算力 | ~1 PFLOPS（BF16 稀疏）≈ **512 PFLOPS**（FP16 稠密）| -| 推理 GPU | L40S × 4/节点 | -| 推理节点数 | 16 节点 = 64 GPU | -| 计算网络 | InfiniBand NDR 400G × 2（双上联）| -| 存储网络 | RoCE v2 200G + 全闪存存储 | -| 存储容量 | JuiceFS + 全闪存，10 PB | -| 服务器形态 | HGX H100 8-GPU 液冷服务器 | -| 预估总功耗 | **约 550 kW**（训练 416 kW + 推理 64 kW + 存储/网络 70 kW）| -| 国产化备选 | 昇腾 910B 训练集群 | - -#### 方案三：旗舰规模（年旅客量 > 5,000 万，新建超大规模智算） - -| 项目 | 配置 | -|------|------| -| 训练 GPU | NVIDIA H200/H200 × 8/节点 | -| 训练节点数 | 128 节点 = 1,024 GPU | -| SuperPOD 架构 | 16 × 64 GPU SU，Fat-Tree 组网 | -| 训练算力 | ~2 EFLOPS（BF16 稀疏），~1 EFLOPS（BF16 稠密）| -| 推理 GPU | H100/L40S 混合 | -| 计算网络 | InfiniBand NDR 400G，1:1 无收敛 | -| 超节点扩展 | 支持 Scale-Up 到 GB200 NVL72 | -| 存储 | 全闪存并行文件系统，50 PB+ | -| 预估总功耗 | **约 13 MW**（GPU ~7 MW + 服务器/网络/液冷 ~6 MW）| -| PUE 目标 | ≤ 1.15（全液冷）| - -> 注：H200 GPU TDP ~700W/卡，1,024 GPU 仅 GPU 即 ~717 kW；8-GPU 服务器整机约 10–13 kW/台，128 台约 1.3–1.7 MW；加上 InfiniBand 交换机、存储节点、液冷 CDU、冷却塔等辅助负载，总计约 13 MW。 - ---- - -## 五、供电系统 - -### 5.1 供电架构 - -``` -市电（双路 10kV / 35kV） - ↓ -自动转换开关 ATS - ↓ -高压配电 - ↓ -SCALE-UP UPS（2N 冗余，模块化效率 ≥ 96%） - ↓ -配电单元 PDU - ↓ -GPU 服务器机柜（液冷 CDU 集成供电） -``` - -### 5.2 关键参数 - -| 项目 | 推荐值 | -|------|-------| -| 市电引入 | 双路 10kV 或 35kV（互为备用）| -| UPS 配置 | 2N 冗余（Tier IV）/ N+1（Tier III）| -| UPS 效率 | 模块化效率 ≥ 96% | -| 柴油发电机 | 1,000–5,000 kVA，启动时间 < 10s | -| 储油时间 | 24 小时（关键负载）| -| 单柜功率密度 | 40–130 kW（液冷方案）| -| 总功耗估算 | GPU 单柜 100kW × 100 柜 = 10 MW | - -### 5.3 液冷对供电的影响 - -| 影响项 | 说明 | -|-------|------| -| 供电密度提升 | 单机柜功率从 10 kW 升至 100 kW+，对 PDU 配电模块要求更高 | -| 液冷 CDU 供电 | CDU 设备需独立配电回路 | -| 变压器容量 | 需提前规划，按 100 kW/柜计算总容量 | -| 市电申请 | 大规模智算中心（10 MW+）需与电力公司单独协商 | - ---- - -## 六、网络技术方案 - -### 6.1 Spine-Leaf 架构（推荐大型机场） - -``` -Spine 层（核心） - ├── Spine-A（400G） - └── Spine-B（400G，冗余） - ↑ -Leaf 层（接入） - ├── Leaf-1,2（连接 GPU 服务器） - ├── Leaf-3（连接存储） - └── Leaf-4（连接通用服务器） -``` - -- **收敛比**：建议 1:1（无收敛） -- **东西向带宽**：全部东西向全速 - -### 6.2 网络安全 - -| 安全措施 | 说明 | -|---------|------| -| 零信任网络（ZTNA）| 微隔离，按需授权 | -| DDoS 防护 | 清洗异常流量 | -| 算力隔离 | 训练 / 推理网络物理隔离 | -| 数据加密 | 传输加密（TLS）+ 存储加密 | -| 运维审计 | 全量日志留存，堡垒机访问 | - ---- - -## 七、等級标准与选址 - -### 7.1 Uptime Tier 等级对比 - -| 等级 | 可用性 | 年停机时间 | 适用场景 | -|------|--------|----------|---------| -| Tier I | 99.67% | > 31.5 h | 基础，非关键系统 | -| Tier II | 99.75% | 22 h | 冗余组件，非关键业务 | -| **Tier III** | **99.98%** | **≤ 1.6 h** | **主机房，推荐等级** | -| Tier IV | 99.99% | ≤ 0.8 h | 最高等级，关键业务 | - -**Tier III 核心要求：** -- N+1 可并行维护冗余 -- 电力路径：2N UPS 或 N+1 UPS -- 冷却系统：N+1 冗余冷冻水系统或风冷系统 -- 网络接入：多运营商、多路由接入 - -**Tier IV 核心要求（机场应急指挥中心、空管核心系统等不允许停机的关键设施）：** -- 2N 完全冗余（任意单点故障不影响运行） -- 双市电引入 -- 2N UPS + 2N 冷却冗余 -- 建设成本约为 Tier III 的 1.5–2 倍 - -### 7.2 选址关键因素 - -| 因素 | 要求 | -|------|------| -| 电力容量 | 必须满足 100 kW/柜 × N 柜，需与电力公司协商 | -| 网络延迟 | 至航站楼核心系统 < 5 ms | -| 地理条件 | 机场限高、净空要求，土质条件 | -| 政策支持 | 综合保税区政策（可参考福州长乐案例）| -| 绿电条件 | 靠近可再生能源（如沿海风电）| - ---- - -## 八、典型机场案例 - -### 8.1 郑州航空港（中部最大万卡集群） - -| 参数 | 数值 | -|------|------| -| 当前算力 | **10,000 PFLOPS（万卡）** | -| 规划总规模 | **100,000 PFLOPS+**（三中心：训练/推理/推训一体）| -| DeepSeek 部署 | 2025 年 1 月全量接入 DeepSeek-R1（中部首个）| -| 定位 | 填补东南沿海高端智算缺口 | -| 二期规划 | 边缘 / 云端推理一体机 + 产业闭环 | - -### 8.2 福州长乐机场综合保税区智算中心 - -| 参数 | 数值 | -|------|------| -| 投资 | **11 亿元**（一期 3.3 亿元）| -| 用地面积 | **33,347 m²**（50.02 亩）| -| 规划算力 | **15,000 PFLOPS** | -| 预计投产 | **2026 年 10 月** | -| 技术方案 | 规模化智算液冷机柜 + 体系化网络存储机柜阵列 | -| 政策优势 | 综保区多重政策，深化粵港数字协作 | - -### 8.3 深圳宝安国际机场（AI 全栈部署标杆） - -| 参数 | 数值 | -|------|------| -| 排名 | 42 家千万级机场综合评价**第二名** | -| DeepSeek 部署 | **满血版 R1-671B**，华为昇腾集群全栈本地化部署 | -| 算力底座 | 华为昇腾算力服务器（规模未披露）| -| 数据整合 | 打通航班运行、物流服务、设备物联日志等 **18 类** 核心业务数据 | - -**核心智能体矩阵：** - -| 智能体 | 效果 | -|-------|------| -| 机位智能分配 | 每日起降分配：**4 小时 → 1 分钟**，靠桥率：**85.44%** | -| AI 安全助手 | 融合 1,500 份安全文档，检索效率提升 **60 倍** | -| 一体化主动运控 | 提前 **20 分钟** 预判保障节点，正常率提升约 **4 个百分点** | -| 综合交通全域一张图 | 响应时间 **< 1 分钟**（获"兴智杯"一等奖）| - -### 8.4 大兴 / 迪拜 / 大连横向对比 - -| 机场 | 等级 | 总功耗 | 制冷方案 | 建设模式 | PUE | 建设周期 | -|------|------|--------|---------|---------|-----|---------| -| 北京大兴 | 未公开（推 Tier III+）| 未公开 | Vertiv Liebert PEX+ 精密空调 | 传统建设 | 未公开 | 3 年+ | -| 迪拜（DXB）| Tier III 双认证 | 1 MW | 变容量行级空调 + 封闭通道 | **预制模块化** | < 1.6 | **10 个月** | -| 大连金州湾（在建）| 规划 Tier III+ | 未公开 | 风液融合 | BIM + 数字孪生 | 目标 < 1.4 | 3–4 年 | - -**关键结论：** -1. **快速交付选预制模块化**：迪拜案例 10 个月交付，节省 50% 时间 -2. **高功率密度必须液冷**：单柜 50 kW 以上场景风冷无法满足 -3. **BIM 是新建机场数据中心的标准**：设计施工运营一体化 -4. **Tier III 是机场数据中心的基准等级**：迪拜明确要求 Tier III 双认证 - ---- - -## 九、供应商参考 - -### 9.1 液冷系统 - -| 供应商 | 方案类型 | 代表产品 / 案例 | -|--------|---------|---------------| -| 维谛技术（Vertiv）| 冷板式（英伟达独家合作）| GB200 NVL72 参考设计，Liebert PEX+ | -| 英维克（Envicool）| 冷板式 + 浸没式 | 国产液冷龙头，多个 AIDC 项目 | -| 曙光数创 | 浸没式（相变 / 单相）| 国内浸没式液冷最大供应商，PUE 可低至 1.04 | -| 华为 | 冷板式 + 液冷 CDU | 临港智算谷项目 | -| Keydak 金盾 | 风液融合 | 2025 年国际机场博览会发布 | -| 施耐德电气 | 冷板式液冷基础设施 | 132 kW/rack 方案 | - -### 9.2 GPU 服务器 - -| 供应商 | 产品系列 | GPU 支持 | -|--------|---------|---------| -| 浪潮信息 | NF5688M7 / NF5698M7 | H100/H200/L20 | -| 新华三 | R4900 G6 | H100/H200 | -| 华为 | 昇腾 910B 集群 | 昇腾 NPU | -| 联想 | ThinkSystem SR670 V2 | H100/H200 | -| 超聚变 | FusionPoD | 多元异构 | - -### 9.3 网络设备 - -| 设备 | 推荐供应商 | 规格 | -|------|---------|------| -| InfiniBand 交换机 | NVIDIA Quantum-2（QM9700）| 400Gb/s NDR | -| 以太网交换机 | 华为 CloudEngine 16800 | 400G | -| RoCE 网卡 | NVIDIA ConnectX-7 | 400Gb/s | -| 光模块 | II-VI / 华为 | 400G DR4/FR4 | - ---- - -## 十、关键参数汇总 - -| 参数 | 数值 | -|------|------| -| 单机柜功率（训练）| 80–130 kW | -| 单机柜功率（推理）| 40–80 kW | -| GPU 互联带宽（节点内）| NVLink **900 GB/s**（双向对等，H100）| -| NVLink 聚合带宽（B200）| **1.8 TB/s**（Fabric 聚合）| -| GB200 NVL72 对等带宽 | **900 GB/s**（任意 GPU 到任意 GPU）| -| 网络互联带宽（节点间）| IB 400G / 以太网 400G | -| NCCL 带宽目标（IB 400G）| ≥ **320 GB/s**（理论峰值的 80%）| -| PUE | ≤ 1.25（典型）/ ≤ 1.15（全液冷）| -| WUE（上海标准）| ≤ 2.0 L/kWh（先进值）| -| CUE（上海标准）| ≤ 1.0 gCO₂/kWh（先进值）| -| 可用性（Tier III）| 99.982%，年均故障时间 ≤ 1.6 小时 | -| 千卡集群参考造价 | **3.5 亿元**（算力设备 3 亿 + 网络 2,500 万 + 存储 1,000 万 + 平台 / 液冷 1,000 万）| - ---- - -## 十一、GPU 集群建设建议与方案 - -> 以下建议基于上海智算导则（2025）、头豹 AIDC 白皮书、Vertiv GB200 白皮书、郑州/深圳/福州机场建设经验总结，适用于机场智算中心新建或扩建场景。 - ---- - -### 11.1 液冷是必选项，不是可选项 - -H100 单卡 700W、GB200 超级芯片 2.7 kW，风冷天花板已过。**强行风冷会导致 GPU 过热降频，得不偿失。** - -| 液冷方案 | 适用场景 | PUE | 代表供应商 | -|---------|---------|-----|---------| -| **冷板式液冷（推荐）** | 新建首选，40–130 kW/柜 | 1.15–1.25 | Vertiv（GB200 独家合作）/ 英维克 / 华为 | -| **浸没式液冷** | 超高密度（> 200 kW/柜）| 1.05–1.15 | 曙光数创（国内最大浸没式供应商）| -| **风液融合** | 过渡期、分期部署 | 1.25–1.35 | Keydak 金盾（2025 年国际机场博览会发布）| - -**冷板式液冷架构要点：** - -``` -冷却塔 / 干冷器（一次侧） - ↓ - 冷水机组（夏季备用） - ↓ - CDU（冷却液分配单元）← 独立配电回路，必须提前规划 - ↓ - Manifold（液冷岐管） - ↓ - 冷板（直接接触 GPU + CPU + 内存） -``` - -**关键坑**：CDU 必须独立配电回路；液冷系统调试周期比风冷长 2–3 个月；单机柜功率超过 100 kW 时，Vertiv GB200 NVL72 是唯一经过验证的方案。 - ---- - -### 11.2 网络：InfiniBand 是训练集群的事实标准 - -**别在网络上省钱。** 网络瓶颈会导致 GPU 训练效率系统性低于预期，且这个问题极难在后期排查。 - -| 场景 | 推荐网络 | 原因 | -|------|---------|------| -| **AI 训练集群** | InfiniBand NDR 400G（QM9700 交换机）| 延迟 < 0.6 μs；SHARP 网内聚合节省 30–50% 梯度通信量 | -| 推理集群 | Spectrum-X 400G（RoCE v2）或普通 200G 以太网 | 无需 IB 生态，运维简单，成本低 | -| 存储网络 | RoCE v2 + NVMe-oF | 与计算网络解耦，独立扩展 | - -**组网设计原则：** - -1. **收敛比 ≤ 1:1**：AI 训练东西向流量极大，收敛比 > 1:1 直接堵死 GPU -2. **每服务器双上联 2 × 400G IB**：LACP Bonding 冗余，任何单链路故障不影响集合通信 -3. **Fat-Tree 无阻塞拓扑**：千卡规模下，最差路径不超过 3 跳 - -**交换机数量估算（512 GPU 集群）：** - -| 层级 | 设备 | 数量 | -|------|------|------| -| Spine | QM9700 | 8 台 | -| Aggregation | QM9700 | 16 台 | -| 每组 Compute SU | 64 GPU（8 服务器 × 8 GPU）| 8 组 | - ---- - -### 11.3 存储：别用传统 NAS，直接上 JuiceFS + 对象存储 - -AI 训练的三类存储需求差异极大，**一套 NAS 打天下，必然有至少两类场景拉胯**。 - -| 存储类型 | 需求特征 | 推荐方案 | 性能目标 | -|---------|---------|---------|---------| -| **数据湖** | 大文件顺序读，带宽优先 | 对象存储（S3） + JuiceFS | 顺序读带宽 ≥ 500 GB/s | -| **模型存储（Checkpoint）| 小文件高速写入，延迟敏感 | 全闪存分布式存储（并行文件系统）| 写入带宽 ≥ 100 GB/s，延迟 < 1 ms | -| **共享文件系统** | 小文件 IOPS 高，元数据压力大 | JuiceFS + TiKV 元数据引擎 | IOPS ≥ 1M | - -> **性能目标有前置条件**：需足够的存储节点数量（20+ 全闪存存储节点）、充足的存储网络带宽（200G+）、正确配置的小文件聚合策略（建议 4 MiB chunk）。 - -**推荐架构：JuiceFS + S3 兼容对象存储 + 每节点 1–2 TB NVMe L1 缓存** - -```python -# JuiceFS 关键配置示例 -# 元数据引擎：TiKV（分布式，≥3 节点） -# 数据存储：S3 兼容对象存储（任意厂商） -# 本地缓存：每节点 1–2 TB NVMe SSD（L1 缓存热点数据） -# chunk_size：4194304 # 4 MiB，平衡元数据压力与读写效率 -# 预取：自动预取临近数据块，减少对象存储往返次数 -``` - -**存储产品选型参考：** - -| 产品 | 类型 | 适用规模 | AI 训练适配度 | -|------|------|---------|------------| -| JuiceFS | 元数据 + 对象存储分离 | 中大规模 | ★★★★★ | -| BeeGFS | 并行文件系统 | 超大规模 | ★★★★ | -| GPFS（IBM Spectrum Scale）| 并行文件系统 | 企业级 | ★★★★ | -| 曙光 ParaStor | 全闪存分布式 | 国产化 | ★★★★ | -| 华为 OceanStor 9000 | 全闪存分布式 | 大规模 | ★★★★ | - ---- - -### 11.4 分期建设，别一口气建完 - -智算中心投资巨大（千卡集群 ~3.5 亿元），一次性规划过大的风险极高。**推荐三期滚动建设**： - -| 阶段 | 建设内容 | 算力规模 | 优先级理由 | -|------|---------|---------|---------| -| **首期（0–12 个月）** | 推理集群为主（L40S × 64–128 卡）| ~256 TFLOPS（FP16）| 快速产出 AI 业务价值：客服机器人、视频分析、Agent 推理，ROI 可见 | -| **二期（12–24 个月）** | 训练集群（H100/H200 × 128–256 卡）| ~1 PFLOPS（BF16 稀疏）| 积累自有数据后，开展模型微调和垂直领域训练 | -| **三期（24–36 个月）** | 扩展至千卡 + 国产化混部 | 1,000+ PFLOPS | 规模化降本，昇腾 910B 或海光 DCU 纳入备线 | - -**分期建设的核心优势：** -- **液冷/电力容量可平滑扩展**：避免一次性投入后容量浪费 -- **技术路线验证**：H100 → H200 → GB200 NVL72，可逐步引入新硬件 -- **业务验证先行**：首期推理集群验证业务可行性，二期训练集群才有意义 - ---- - -### 11.5 国产化：昇腾可用但生态是核心门槛 - -| 芯片 | FP16 算力 | HBM 容量 | CUDA 兼容性 | 迁移成本 | 建议 | -|------|---------|---------|------------|---------|------| -| **NVIDIA H100/H200** | 1,979 TFLOPS | 80 GB | 原生 CUDA | **低** | **主力生产集群** | -| 昇腾 910B | 640 TFLOPS | 64 GB | **差**，需 CANN/MindSpore 移植 | 高 | 备胎 / 政务场景，配合华为原厂 | -| 海光 DCU Z100 | 256 TFLOPS | 64 GB | **较好**，ROCm 部分兼容 | 中 | 迁移成本低于昇腾，可作为备选 | - -**国产化实施路径（二选一）：** - -``` -路径 A（推荐，低风险）： - 主力：NVIDIA H100/H200 训练 + 推理集群 - 备线：昇腾 910B 集群（独立调度，混合训练暂不推荐） - 迁移优先级：推理场景优先，训练场景押后 - -路径 B（高风险，需华为原厂深度绑定）： - 主力：昇腾 910B 全栈（MindSpore + CANN + 昇腾集群） - 前提：必须有华为原厂交付团队驻场，且业务模型已通过昇腾兼容性验证 -``` - -**昇腾生态关键障碍（现实评估）：** -- PyTorch 模型需要重新适配（昇腾提供 PyTorch Adapter，但非所有算子覆盖） -- NCCL 通信库替换为 HCCS，集合通信参数需重新调优 -- 推理引擎（vLLM/TensorRT-LLM）昇腾适配不完整，vLLM 昇腾支持为第三方社区维护 -- **结论**：昇腾 910B 在推理场景相对可用；训练场景建议等待昇腾 920 或更高代际 - ---- - -### 11.6 上线前必须验证 NCCL 带宽 - -这是 GPU 集群上线后**最容易被忽略、也最容易出问题的环节**。网络配置不当会导致 GPU 训练效率系统性低于预期，且排查链路长（应用层 → NCCL → IB 驱动 → 物理层）。 - -**验证命令：** - -```bash -# ── 节点内 NVLink 带宽验证 ── -# 目标：> 850 GB/s（理论 900 GB/s 的 94%） -./build/all_reduce_perf -b 128M -e 1G -f 2 -g 8 - -# ── 跨节点 InfiniBand 带宽验证 ── -# 目标：> 320 GB/s（理论 400 GB/s 的 80%） -# 说明：若 < 320 GB/s，说明 IB 网络存在瓶颈（光模块/线缆/交换机配置/拥塞控制） -./build/all_reduce_perf -b 128M -e 1G -f 2 -g 8 -N 1 -w 100 -n 100 - -# ── GPU Direct RDMA 验证 ── -# 验证 GPU 直接访问远端存储（绕过 CPU），目标带宽接近 IB 线速 -nvidia-smi topo -m # 查看拓扑矩阵，确认 GPU 与 IB 网卡亲和性 -``` - -**NCCL 带宽不达标的常见原因：** - -| 原因 | 表现 | 解决 | -|------|------|------| -| IB 端口误码率 > 10⁻⁶ | 带宽波动剧烈，大量重传 | 更换光模块或光纤 | -| 收敛比 > 1:1 | 跨交换机流量丢包 | 增补交换机，改无阻塞拓扑 | -| GPU Direct RDMA 未启用 | GPU → CPU → 网卡绕路 | 确认 `NCCL_NET_GDR_LEVEL=PIX` | -| NVLink 域内流量被 PCIe 抢带宽 | 节点内 AllReduce 带宽不足 | 确认 NVLink 拓扑全连接 | -| SHARP 未启用 | 梯度聚合消耗额外带宽 | 启用 SHARP：`NCCL_SHARP_ENABLE=1` | - -**验收标准：** 512 GPU 集群规模下，跨节点 AllReduce 带宽稳定 ≥ 320 GB/s，且连续 72 小时压测无掉速。 - ---- - -### 11.7 推荐配置方案对比 - -| 配置项 | 方案 A：推理优先 | 方案 B：训练+推理均衡 | 方案 C：超大规模旗舰 | -|--------|---------------|---------------------|------------------| -| **定位** | 年旅客量 < 1,000 万 | 年旅客量 1,000–5,000 万 | 年旅客量 > 5,000 万 | -| **训练 GPU** | — | H100 SXM5 × 8/节点，32 节点 | H200 SXM5 × 8/节点，128 节点 | -| **推理 GPU** | L40S × 4/节点，32 节点 | L40S × 4/节点，16 节点 | H100/L40S 混合，32 节点 | -| **总 GPU 卡数** | 128 卡 | **384 卡**（训练 256 + 推理 128）| **1,152 卡** | -| **训练算力（BF16 稀疏）**| — | ~1 PFLOPS | ~2.5 PFLOPS | -| **计算网络** | RoCE v2 200G | IB NDR 400G × 2 上联 | IB NDR 400G，Fat-Tree 1:1 无收敛 | -| **存储网络** | RoCE v2 200G | RoCE v2 200G + 全闪存存储 | IB 400G + 并行文件系统 50 PB | -| **散热方案** | 冷板式液冷 | 冷板式液冷（80% 液冷占比）| 全液冷，PUE ≤ 1.15 | -| **液冷 CDU** | 英维克（200–400 kW）| Vertiv / 华为（400–800 kW）| Vertiv GB200 NVL72 配套 | -| **国产化** | 可选昇腾 910B 混部 | 昇腾 910B 作为备线 | 昇腾 920 作为下一代备选 | -| **预估总功耗** | ~256 kW | ~**550 kW** | ~**13 MW** | -| **预估投资** | ~8,000 万元 | ~**3.5 亿元** | ~15–20 亿元 | -| **PUE 目标** | ≤ 1.25 | ≤ 1.20 | ≤ 1.15 | -| **Tier 等级** | Tier III | Tier III | Tier III+ | - -> **方案 B**（训练+推理均衡）是大多数中型机场的推荐起点。千卡集群参考造价分项：**算力设备 ~3 亿 + InfiniBand 网络 ~2,500 万 + 全闪存存储 ~1,000 万 + 平台软件/液冷基础设施 ~1,000 万 = ~3.5 亿元**。 - ---- - -### 11.8 避坑清单 - -| # | 坑点 | 后果 | 预防措施 | -|---|------|------|---------| -| 1 | 液冷 CDU 配电容量未提前规划 | 液冷系统无法满载，GPU 过热降频 | 电力容量申请时按 100 kW/柜 × N 柜提前量 | -| 2 | InfiniBand 收敛比 > 1:1 | GPU 训练效率 < 50% | 组网设计审查必须过「无阻塞」关 | -| 3 | 存储用了传统 NAS | 并行训练时所有 GPU 饿死 | 存储必须满足 IOPS ≥ 1M、带宽 ≥ 500 GB/s 前置条件 | -| 4 | 国产化迁移低估生态障碍 | 昇腾集群上线后模型跑不起来 | **推理场景先行验证，训练场景押后** | -| 5 | 上线前未验证 NCCL 带宽 | 集群训练效率系统性低于预期 | 512 GPU 以上集群必须 72 小时压测 | -| 6 | 一次建完未分期 | 容量浪费或容量不足 | 三期滚动建设，首期验证业务可行性 | -| 7 | PUE 目标过于激进（全液冷但液冷调试滞后）| 夏季高温期集群性能受限 | 液冷调试周期留足 2–3 个月余量 | - ---- - -### 11.9 建设检查清单（验收参考） - -**液冷系统：** -- [ ] CDU 运行状态：出水温度、流量、压力在设计范围内 -- [ ] 冷板接触面导热硅脂状态正常，无干涸 -- [ ] 液冷回路无泄漏报警 -- [ ] 夏季高温工况下 GPU 温度稳定 < 80°C - -**网络系统：** -- [ ] InfiniBand 端口误码率 < 10⁻⁸（连续 24 小时） -- [ ] NCCL 跨节点 AllReduce 带宽 ≥ 320 GB/s（IB 400G） -- [ ] GPU Direct RDMA 验证通过 -- [ ] SHARP 网内聚合启用并生效 - -**存储系统：** -- [ ] JuiceFS/并行文件系统 IOPS ≥ 1M（4K 小文件随机读） -- [ ] Checkpoint 写入带宽 ≥ 100 GB/s（128 节点同时写） -- [ ] 对象存储读写延迟 < 10 ms（P99） - -**集群健康：** -- [ ] DCGM GPU 监控大屏正常运行 -- [ ] 训练作业 72 小时无 GPU ECC 错误告警 -- [ ] UFM InfiniBand 管理平台拓扑与实际一致 -- [ ] 故障节点自动隔离机制验证通过 - ---- - -## 附录 - -### A. 术语表 - -| 缩写 | 全称 | 说明 | -|------|------|------| -| AIDC | Artificial Intelligence Data Center | 智算中心 | -| PUE | Power Usage Effectiveness | 电能利用效率（= 总设施能耗 / IT 设备能耗）| -| WUE | Water Usage Effectiveness | 水资源利用效率 | -| CUE | Carbon Usage Effectiveness | 碳利用效率 | -| CDU | Coolant Distribution Unit | 冷却液分配单元 | -| NCCL | NVIDIA Collective Communications Library | GPU 集合通信库 | -| RoCE | RDMA over Converged Ethernet | 以太网远程直接内存访问 | -| NVLink | NVIDIA High-Speed GPU Interconnect | 英伟达高速 GPU 互连 | -| InfiniBand | High-Speed Network Architecture | 高速网络架构（400G NDR）| -| DCGM | Data Center GPU Manager | 数据中心 GPU 管理工具 | -| vLLM | Virtual Large Language Model Server | 开源 LLM 推理服务框架 | -| HBM | High Bandwidth Memory | 高带宽存储器（GPU 显存标准）| -| BF16 | Brain Float 16 | AI 训练常用浮点格式 | -| ZTNA | Zero Trust Network Architecture | 零信任网络架构 | -| SHARP | Scalable Hierarchical Aggregation and Reduction Protocol | 网内计算协议 | -| UFM | Unified Fabric Manager | InfiniBand 监控管理工具 | -| GPFS | General Parallel File System | IBM 并行文件系统 | - -### B. 数据来源 - -1. **上海**，《智算中心建设导则（2025 年版）》— 全国最严 PUE/WUE/CUE 三级指标 -2. **头豹研究院**，《2025 年中国 AIDC 产业发展白皮书》— GPU 选型、液冷市场 -3. **中国工业互联网研究院**，《工业智算发展研究报告（2025 年）》 -4. **Vertiv**，《GB200 NVL72 参考架构白皮书》— 130 kW 单柜设计 -5. **IDC + 浪潮信息**，《中国人工智能计算力发展评估报告》 -6. **中国信通院**，《人工智能算力基础设施赋能研究报告（2025 年）》 -7. **福州长乐机场保税区**，《15,000P 智算中心可行性报告》（2026-01-22） -8. **郑州航空港**，《中部最大万卡算力集群》报道（2026-03-05） -9. **深圳机场**，《智能化全国第二 AI 全栈部署》报道（2026-01-15） - -### C. 相关标准与政策 - -- 《数据中心绿色低碳发展专项行动计划》（发改环资〔2024〕970 号） -- 《数据中心设计规范》GB 50174-2017 -- 《新型数据中心发展三年行动计划（2021–2023）》 -- 《算力基础设施高质量发展行动计划》 -- Uptime Institute Tier Standard（Tier I/II/III/IV 认证体系） -- ANSI/TIA-942-B（数据中心电信基础设施标准） - ---- - -*本方案为技术方案参考文档，具体项目需结合机场业务规模、预算、国产化要求和所在地区政策进行定制化设计。建议在项目立项后委托专业设计院进行深化设计。* diff --git a/airport-wiki/机场航班数据管理运营方案.md b/airport-wiki/机场航班数据管理运营方案.md deleted file mode 100644 index 0f6bed5..0000000 --- a/airport-wiki/机场航班数据管理运营方案.md +++ /dev/null @@ -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]] — 供应商综合对比