From abce5516e4c50d6b585d375e838c0a24de38e976 Mon Sep 17 00:00:00 2001 From: windyboy Date: Mon, 13 Apr 2026 17:39:10 +0800 Subject: [PATCH] refactor aodb design docs around technical architecture --- .../concepts/aodb/AODB 实施 Backlog.md | 257 ---------------- .../concepts/aodb/AODB 最小部署拓扑草案.md | 6 +- .../concepts/aodb/AODB 核心需求提炼.md | 68 ++--- .../concepts/aodb/AODB 高层设计修订计划.md | 79 ----- .../开源机场运营数据库（AODB）高层设计文档.md | 115 ++++--- .../机场运行数据库 (AODB) 产品对比分析报告.md | 285 ++++++++++++++++++ 6 files changed, 365 insertions(+), 445 deletions(-) delete mode 100644 airport-wiki/concepts/aodb/AODB 实施 Backlog.md delete mode 100644 airport-wiki/concepts/aodb/AODB 高层设计修订计划.md create mode 100644 airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md diff --git a/airport-wiki/concepts/aodb/AODB 实施 Backlog.md b/airport-wiki/concepts/aodb/AODB 实施 Backlog.md deleted file mode 100644 index f892984..0000000 --- a/airport-wiki/concepts/aodb/AODB 实施 Backlog.md +++ /dev/null @@ -1,257 +0,0 @@ -# AODB 实施 Backlog - -## 1. 文档定位 - -本文档将 AODB 高层设计拆解为可执行实施 backlog，用于排期、分工、估算和测试准备。 - -- 上位输入： - - `AODB 核心需求提炼.md` - - `开源机场运营数据库（AODB）高层设计文档.md` - - `开源技术栈选型决策.md` -- 输出对象： - - Epic / Story / Task - - 验收条件 - - 测试关注点 - -## 2. 里程碑视图 - -| 里程碑 | 目标 | 完成标准 | -| --- | --- | --- | -| M1 | 建立核心文档和 ADR 基线 | 需求、架构、技术栈、ADR 对齐 | -| M2 | 完成核心数据接入和当前态闭环 | SSIM / AIDX / AFTN 接入后能形成 Published Fact | -| M3 | 完成资源分配、冲突和告警闭环 | Stand / Gate / Belt / Counter 的分配和冲突可追溯 | -| M4 | 完成查询、订阅、审计和人工复核闭环 | 外部读取、事件回放、人工裁决可运行 | -| M5 | 完成容灾、压测和上线门禁 | SLO、演练、对账、补偿全部达标 | - -## 3. Epic 清单 - -### Epic 1：领域模型与数据契约落地 - -目标： - -- 将高层设计中的聚合、字段、事件和权威矩阵落到实现契约。 - -Stories： - -1. 建立 `FlightOperation` 数据模型 -2. 建立 `Turnaround` 数据模型 -3. 建立 `MilestoneObservation` 和 `DecisionLog` 数据模型 -4. 建立 `Resource` / `ResourceAllocation` 数据模型 -5. 建立 `AlertCase` / `DataQualityFlag` 数据模型 - -验收条件： - -- 所有核心对象具备主键、唯一键、幂等键和状态字段定义 -- Published Fact 可追溯到 Observation 和 Decision - -测试关注点： - -- 主键稳定性 -- 幂等键生成 -- 配对修正一致性 - -### Epic 2：接入与标准化 - -目标： - -- 接入 SSIM、AIDX、AFTN 并形成统一内部事件模型。 - -Stories： - -1. 实现 SSIM 导入和批次标识 -2. 实现 AIDX 标准化映射 -3. 实现 AFTN / Type B 报文解析 -4. 实现标准化失败进入 DLQ -5. 实现人工复核任务创建 - -验收条件： - -- 三类输入都能进入标准化事件模型 -- 解析失败可复核、可重放、可审计 - -测试关注点： - -- 重复导入 -- 报文乱序 -- 格式错误 - -### Epic 3：Published Fact 与字段级权威治理 - -目标： - -- 实现 Observation -> Decision -> Published Fact 的治理链路。 - -Stories： - -1. 实现字段级权威矩阵加载与版本化 -2. 实现候选事实评估 -3. 实现自动裁决 -4. 实现人工裁决写入 -5. 实现 Published Fact 更新和审计 - -验收条件： - -- ALDT、AIBT、TOBT、Stand Assignment 等关键字段完成治理闭环 -- 当前值可返回来源、可信度和裁决摘要 - -测试关注点： - -- 多源冲突 -- 更正报文 -- 超窗乱序 - -### Epic 4：资源分配与冲突治理 - -目标： - -- 让资源分配具备最小可运营能力，而不是只有时间窗逻辑。 - -Stories： - -1. 建立 Resource 主数据和能力约束 -2. 实现 ResourceAllocation 软锁 / 硬锁 -3. 实现时间冲突检测 -4. 实现适配 / 状态 / 策略冲突检测 -5. 实现人工覆盖与回滚 - -验收条件： - -- 四类资源都具备分配、冲突、覆盖和审计能力 -- 冲突能明确归类并生成告警 - -测试关注点： - -- 延误引发冲突 -- 换机型 -- 资源停用 - -### Epic 5：告警、Case 和人工复核 - -目标： - -- 把“人工介入”从口头方案变成有状态可追溯流程。 - -Stories： - -1. 建立 AlertCase 状态机 -2. 建立 ReviewTask 状态机 -3. 实现 `ManualDecisionRecorded` -4. 实现 `ReviewTaskOpened / Closed` -5. 实现告警确认、关闭、抑制 - -验收条件： - -- 告警和复核都有结构化状态流转 -- 人工动作全部事件化和审计化 - -测试关注点： - -- 告警重复触发 -- 复核结果重放 -- 覆盖与回滚 - -### Epic 6：事件骨干与订阅 - -目标： - -- 构建可重放、可补偿、可隔离的标准化事件分发能力。 - -Stories： - -1. 设计 Topic 与分区策略 -2. 实现统一事件信封 -3. 实现 Outbox + CDC 发布 -4. 实现事件订阅接口 -5. 实现断线重连与游标回放 - -验收条件： - -- 对外事件以 Kafka 标准化事件为唯一源头 -- 订阅具备至少一次投递和补偿能力 - -测试关注点： - -- 重复投递 -- CDC 断点恢复 -- 消费者去重 - -### Epic 7：查询接口与权限治理 - -目标： - -- 提供只读查询，不污染事实事件路径。 - -Stories： - -1. 实现 FlightOperation 查询 -2. 实现 MilestoneObservation 历史查询 -3. 实现 ResourceAllocation 生效集查询 -4. 实现 AlertCase 查询 -5. 接入 OIDC / OAuth2 / RBAC - -验收条件： - -- 查询接口支持过滤、分页、更新时间和数据质量字段 -- 读权限和订阅权限隔离 - -测试关注点： - -- 稳定分页 -- 字段权限 -- 限流 - -### Epic 8：平台、容灾与观测 - -目标： - -- 为 SLO 提供可验证支撑，而不是口头承诺。 - -Stories： - -1. 实现 PostgreSQL HA 和备份恢复 -2. 实现 Kafka 副本和保留策略 -3. 实现 CDC / 发布器观测 -4. 建立端到端延迟、DLQ、幂等命中率监控 -5. 完成容灾与回放演练 - -验收条件： - -- RTO / RPO 有演练记录 -- P95 延迟、对账、订阅补偿可验证 - -测试关注点： - -- DB 切换 -- 事件堆积 -- 订阅重连 - -## 4. Story 模板 - -每个 story 必须具备： - -- 背景 -- 范围 -- 非范围 -- 接口 / 数据影响 -- 验收条件 -- 回归风险 -- 测试点 - -## 5. 建议实施顺序 - -1. Epic 1：领域模型与数据契约落地 -2. Epic 2：接入与标准化 -3. Epic 3：Published Fact 与字段级权威治理 -4. Epic 4：资源分配与冲突治理 -5. Epic 5：告警、Case 和人工复核 -6. Epic 6：事件骨干与订阅 -7. Epic 7：查询接口与权限治理 -8. Epic 8：平台、容灾与观测 - -## 6. 进入开发前的 Gate - -- 高层设计、技术栈、ADR 无结构性冲突 -- 字段级权威矩阵完成首版 -- 事件 schema 草案完成首版 -- 最小部署拓扑完成首版 -- Epic 级拆解得到负责人和初步估算 diff --git a/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md b/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md index c523e84..bd922ab 100644 --- a/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md +++ b/airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md @@ -2,7 +2,7 @@ ## 1. 文档定位 -本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于支撑高层设计中的 SLO 和上线门禁。 +本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于细化高层设计中的部署、SLO 和容灾约束。 ## 2. 目标 @@ -162,7 +162,7 @@ | conflict_mttr | 冲突平均处置时间 | | review_task_open_count | 未关闭复核任务数 | -## 8. 上线前必须演练 +## 8. 关键演练场景 1. PostgreSQL 主备切换 2. Kafka 单 broker 故障恢复 @@ -173,4 +173,4 @@ ## 9. 与高层设计的关系 - 本文档细化 `开源机场运营数据库（AODB）高层设计文档.md` 中的部署与 SLO 章节。 -- 它不是最终部署手册，但必须足以支撑架构评审和上线门禁定义。 +- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。 diff --git a/airport-wiki/concepts/aodb/AODB 核心需求提炼.md b/airport-wiki/concepts/aodb/AODB 核心需求提炼.md index 8e4e360..854a5cc 100644 --- a/airport-wiki/concepts/aodb/AODB 核心需求提炼.md +++ b/airport-wiki/concepts/aodb/AODB 核心需求提炼.md @@ -2,7 +2,7 @@ ## 1. 文档定位 -本文档定义 AODB 的业务目标、范围边界、功能清单和验收指标，用于立项评审、架构设计和实施排期对齐。 +本文档定义 AODB 的业务目标、范围边界、核心能力和约束条件，作为高层设计和技术选型的上位输入。 - 目标对象：年旅客吞吐量 500 万至 3000 万的中型机场 - 目标系统：机场运营数据库（AODB）及其核心协同能力 @@ -28,32 +28,19 @@ MVP（首期必须）： - 外部数据共享接口（查询 + 事件订阅） - 审计、裁决、人工复核闭环 -非 MVP（后续迭代）： +非 MVP： - 高级优化排班（全局优化/仿真） - 深度 AI 预测（跨季节模型、异常解释） - 多机场统一调度与集团化运营 - 起飞排序和复杂流处理平台化能力 -### 2.3 路线分层（MVP / P1 / P2） +### 2.3 范围约束 -| 能力 | MVP | P1 | P2 | 备注 | -| --- | --- | --- | --- | --- | -| 航班计划导入 | 是 | | | SSIM / 计划批量导入 | -| 动态更新 | 是 | | | AIDX / AFTN 等运行态接入 | -| 里程碑管理 | 是 | | | 关键里程碑统一治理 | -| 航班配对与过站关联 | 是 | | | 以 `Turnaround` 最小建模 | -| 基础资源分配 | 是 | | | Stand / Gate / Belt / Counter | -| 冲突检测与告警 | 是 | | | 时间冲突、适配冲突、状态冲突 | -| 查询接口 | 是 | | | 面向外部系统和运营终端 | -| 事件订阅 | 是 | | | 至少一次投递、支持重连补偿 | -| 审计与人工裁决 | 是 | | | 关键写入必须可追溯 | -| EIBT / EXIT / EXOT 预测 | | 是 | | 有状态流处理增强能力 | -| TSAT / TTOT 计算 | | 是 | | 与 PDS 衔接 | -| 复杂 CEP | | 是 | | 实时模式识别和复杂聚合 | -| 全局优化排班 | | | 是 | 不属于首期闭环 | -| AI 调度与异常解释 | | | 是 | 在数据基础稳定后引入 | -| 多机场统一调度 | | | 是 | 单机场稳定后再扩展 | +- 单机场优先，跨机场能力不作为 MVP 前提。 +- MVP 聚焦“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为前提。 +- 若外部系统稳定性不足，必须预留灰度、手工复核和数据质量标记兜底流程。 +- 首期不要求深度历史迁移，只要求新接入链路具备统一主键、幂等和审计能力。 ## 3. 功能需求清单 @@ -82,24 +69,24 @@ MVP（首期必须）： 3. 解析失败消息必须进入死信队列并提供人工复核入口。 4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。 -## 5. 非功能需求（SLO） +## 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 + 传输加密 | 安全测试与配置核查 | +| 可用性 | 月度 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. 上线假设与约束 +## 6. 架构约束 -- 单机场优先，跨机场能力不作为首期交付前提。 -- 首期仅覆盖核心运行场景，不包含深度历史迁移改造。 -- 2 至 4 周快速上线只适用于受控数据源、缩减版 MVP、单团队交付场景，不包含复杂流处理、复杂工作流平台和多机场能力。 -- 若外部系统接口稳定性不足，需预留灰度、手工复核和数据质量标记兜底流程。 -- 首期架构优先保证“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为上线前提。 +- Flight 当前态必须只有一个写主，不允许多个系统直接并行改写权威字段。 +- 所有关键写入必须带来源、时间、幂等键和关联 ID。 +- 原始观测、裁决记录、发布事实必须分层保存，不允许只保留当前值。 +- 查询接口和事件订阅接口必须分离，不允许把查询层当作事实流输出。 +- 人工覆盖、回滚和复核必须事件化、审计化。 ## 7. 术语与缩写（权威定义） @@ -115,21 +102,10 @@ MVP（首期必须）： | EIBT | Estimated In-Block Time，预计靠桥时间 | | Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 | -## 8. 验收清单（DoD） - -1. MVP 功能域全部具备可演示业务闭环。 -2. 关键非功能指标达到最低可接受值。 -3. 核心实体和关键事件具备统一主键、幂等规则和写主边界。 -4. 对外接口具备鉴权、限流、审计和重连补偿能力。 -5. 字段级权威矩阵、事件契约、容灾策略和人工复核流程具备文档化定义。 -6. 文档与实现一致，可用于排期拆解、测试用例编制和 ADR 评审。 - -## 9. 关联文档 +## 8. 关联文档 - `airport-wiki/concepts/aodb/开源技术栈选型决策.md` - `airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md` -- `airport-wiki/concepts/aodb/AODB 高层设计修订计划.md` -- `airport-wiki/concepts/aodb/AODB 实施 Backlog.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/AODB 高层设计修订计划.md b/airport-wiki/concepts/aodb/AODB 高层设计修订计划.md deleted file mode 100644 index ff3f77b..0000000 --- a/airport-wiki/concepts/aodb/AODB 高层设计修订计划.md +++ /dev/null @@ -1,79 +0,0 @@ -# AODB 高层设计修订计划 - -## 1. 修订目标 - -本轮修订目标不是继续扩展概念，而是把 AODB 设计收敛成可以进入开工评审的版本： - -- 收缩 MVP，避免首期过载 -- 锁定领域边界和写主归属 -- 明确事实分层和字段级权威矩阵 -- 将资源冲突从单一时间窗问题升级为可运营模型 -- 分离查询接口与事件订阅 -- 补齐部署、容灾、审计和演练要求 - -## 2. 当前主要问题 - -1. MVP 范围过重，和目标机场规模、交付周期不匹配。 -2. 服务边界偏描述性，未锁定写主和聚合边界。 -3. 缺少 `Turnaround` 等关键领域对象。 -4. SSOT 仅有原则，缺少 Observation / Decision / Published Fact 分层。 -5. 资源模型过薄，无法表达适配、冻结、软硬锁定等真实约束。 -6. SLO 未充分映射到部署和容灾设计。 - -## 3. 分阶段任务 - -### 3.1 阶段 1：收缩范围 - -- 重写需求文档中的 MVP / P1 / P2 分层 -- 在高层设计文档中删去首期不需要的平台化能力 -- 在技术栈文档中区分 MVP 主选和后续启用组件 - -### 3.2 阶段 2：重构领域边界 - -- 新增聚合边界表 -- 锁定 Flight 当前态唯一写主 -- 引入 `Turnaround` 作为首期核心对象 - -### 3.3 阶段 3：补齐事实模型 - -- 引入 Observation / Decision / Published Fact 三层模型 -- 增加字段级权威矩阵 -- 明确人工覆盖和更正语义 - -### 3.4 阶段 4：补齐资源与事件模型 - -- 扩展 Resource / ResourceAllocation 模型 -- 建立冲突分类 -- 规范事件分类、事件归属和消费者契约 - -### 3.5 阶段 5：补齐部署与 ADR - -- 增加最小部署拓扑、SLO 映射和容灾约束 -- 写入关键 ADR，固化设计取舍 - -## 4. 决策记录索引 - -- `adr/ADR-001 MVP 不引入 Flink.md` -- `adr/ADR-002 Kafka 作为唯一事件骨干.md` -- `adr/ADR-003 事实分层模型.md` -- `adr/ADR-004 FlightOperation 写主归属.md` -- `adr/ADR-005 Turnaround 独立建模.md` -- `adr/ADR-006 资源锁定模型.md` -- `adr/ADR-007 查询与订阅分离.md` -- `adr/ADR-008 Outbox 与 CDC.md` -- `adr/ADR-009 PostgreSQL HA.md` -- `adr/ADR-010 人工裁决事件化.md` - -## 5. 下层设计文档 - -- `AODB 实施 Backlog.md` -- `AODB 字段级权威矩阵.md` -- `AODB 事件 Schema 草案.md` -- `AODB 最小部署拓扑草案.md` - -## 6. 完成标准 - -- 三份核心文档在范围、技术栈和边界定义上相互一致 -- 关键设计取舍全部具备 ADR -- 文档可直接支持任务拆解、测试设计和架构评审 -- 下层设计文档足以支撑实现前的细化评审 diff --git a/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md b/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md index 5397688..8704730 100644 --- a/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md +++ b/airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md @@ -1,35 +1,35 @@ # 开源机场运营数据库（AODB）高层设计文档 -## 1. 目标 +## 1. 文档目标 -本设计给出 AODB 的首期可开工高层方案，重点回答六件事： +本文档定义 AODB MVP 的技术方案基线，重点回答以下问题： -1. 首期上线到底做什么、不做什么。 -2. 系统由哪些核心聚合和服务组成。 -3. 关键业务数据如何在“观测、裁决、发布事实”之间流转。 -4. 资源分配、冲突、告警和人工复核如何闭环。 -5. 对外查询与事件订阅如何解耦。 -6. SLO 与部署、容灾和审计如何对齐。 +1. AODB 在 MVP 内承载哪些业务闭环，以及哪些能力明确不做。 +2. 系统如何划分聚合、服务、数据流和事件边界。 +3. 航班、里程碑、资源、告警等核心对象如何建模。 +4. 发布事实如何在观测、裁决、审计和订阅之间保持一致。 +5. 查询、订阅、部署、容灾和可观测性如何落到可实现架构。 -适用范围：年旅客吞吐量 500 万至 3000 万机场，单机场优先。 +适用范围：年旅客吞吐量 500 万至 3000 万机场，优先支持单机场部署。 ## 2. 设计原则 -- 单一事实源：AODB 对外只发布单一当前权威事实，不暴露“谁最后写入”式伪一致。 +- 单一事实源：AODB 对外发布单一当前权威事实，不暴露“谁最后写入”式伪一致。 - 事实分层：原始观测、裁决记录、发布事实必须分层建模。 -- 事件驱动：状态变化通过事件传播，系统间通过契约解耦。 -- 规则可解释：字段权威、冲突裁决、人工覆盖都必须能解释来源和原因。 -- 渐进建设：先做稳定闭环，再引入预测、CEP 和复杂编排能力。 +- 写主清晰：每个核心聚合只允许一个服务写入，避免跨服务共享可变状态。 +- 事件驱动：状态变化通过事件传播，系统通过契约解耦。 +- 规则可解释：字段权威、冲突裁决、人工覆盖必须可追溯、可回放、可解释。 +- 渐进复杂度：MVP 先建立稳定闭环，不引入复杂优化平台和长事务编排平台。 -## 3. 范围与阶段 +## 3. 范围定义 ### 3.1 MVP 范围 -首期上线只覆盖以下闭环： +首期只覆盖以下闭环： - 航班计划导入与实时状态更新 - 航班配对与过站上下文最小建模 -- 基础资源分配（Stand、Gate、Belt、Counter） +- 基础资源分配：Stand、Gate、Belt、Counter - 关键里程碑跟踪与发布事实治理 - 延误、资源冲突和数据质量告警 - 对外查询接口与事件订阅 @@ -37,33 +37,39 @@ ### 3.2 非 MVP 范围 -不纳入首期： +首期不纳入以下能力： -- 复杂优化排班（全局优化模型） -- 深度 AI 预测与自适应调度 -- Flink 驱动的复杂 CEP 和预测平台 +- 全局优化排班和复杂资源优化求解 +- 深度 AI 预测和自适应调度 +- Flink 驱动的复杂 CEP 平台 - Temporal 驱动的复杂长事务工作流平台 - 多机场统一调度中心能力 -### 3.3 分阶段演进 - -- Phase 1：完成 MVP 闭环并上线单机场。 -- Phase 2：引入预测能力、复杂规则平台和补偿编排能力。 -- Phase 3：增强容量、容灾和多机场扩展。 - ## 4. 总体架构 ### 4.1 架构分层 -| 层级 | 主要能力 | MVP 主路径组件 | 后续增强组件 | +| 层级 | 主要能力 | MVP 主路径组件 | 说明 | | --- | --- | --- | --- | -| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 协议适配扩展插件 | -| 业务层 | 航班当前态、观测治理、资源分配、告警处置、对外接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 独立 Case / Workflow Service | -| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 订阅网关增强、Schema Registry | -| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | OpenSearch、对象存储 | -| 平台层 | 身份认证、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | Linkerd、Jaeger | +| 接入层 | 外部系统接入、协议解析、统一北向入口 | 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 领域划分与聚合边界 +### 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 采用以下聚合边界： @@ -82,7 +88,7 @@ - Resource Service 只拥有资源占用与冲突事实，不直接修改 Flight 当前态中的非资源字段。 - Alert Service 不产生业务事实，只管理处置状态和告警生命周期。 -### 4.3 核心服务职责 +### 4.4 核心服务职责 - `Flight Operation Service` - 管理 FlightOperation 当前态。 @@ -106,19 +112,19 @@ ### 5.1 核心标识约定 -- Flight： +- Flight - `flight_key`：`carrier + flight_number + op_date + leg_no` - `flight_id`：内部不可变主键 -- Turnaround： +- Turnaround - `turnaround_id` - 可关联一个到达航班和一个离港航班 -- MilestoneObservation： +- MilestoneObservation - `observation_id` - 幂等键优先使用上游报文 ID、序列号或批次 + 行号 -- Resource： +- Resource - `resource_id` - `resource_type + resource_code` 唯一 -- ResourceAllocation： +- ResourceAllocation - `allocation_id` - 幂等键由 `resource_id + validity_window + assignment_source + correlation_id` 组合约束 @@ -414,7 +420,7 @@ MVP 采用 `Outbox Pattern + CDC`： - 顺序仅保证到 `flight_id` - 消费者必须按 `event_id` 去重 - 消费者必须处理数据质量标记和裁决摘要 -- 回放窗口和游标语义必须文档化并纳入验收 +- 回放窗口和游标语义必须文档化 ## 12. 规则体系与人工复核 @@ -486,30 +492,19 @@ MVP 采用 `Outbox Pattern + CDC`： - Outbox / CDC 必须具备断点恢复和重复投递幂等能力。 - 容灾演练必须覆盖数据库切换、事件堆积、订阅重连和回放。 -### 13.4 SLO 映射表 +### 13.4 可观测性要求 -| SLO | 设计支撑 | 验收方式 | -| --- | --- | --- | -| 可用性 | 多副本 API、DB HA、Kafka 副本 | 演练和月度故障统计 | -| 延迟 | 单聚合写主、Kafka 事件骨干、缓存热点读 | 压测和生产观测 | -| RTO / RPO | DB 备份恢复、Kafka 重放、CDC 恢复 | 容灾演练 | -| 审计覆盖 | Observation / Decision / AuditTrail | 抽样链路回放 | +- 所有写路径必须具备请求追踪、事件追踪和审计追踪三类关联 ID。 +- 关键链路必须暴露延迟、失败率、积压量和重试次数指标。 +- 人工裁决、资源覆盖和更正事件必须进入统一审计检索视图。 +- 订阅接口必须暴露连接数、滞后量、推送速率和补偿次数指标。 -## 14. 上线门禁（Go / No-Go） +## 14. 文档边界与引用 -- 功能门禁：计划导入、动态接入、里程碑发布事实、资源分配、冲突告警、人工裁决链路可端到端演示。 -- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。 -- 一致性门禁：Outbox / CDC、重放、幂等和断线补偿完成验证。 -- 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。 -- 演练门禁：完成数据库恢复、事件重放和订阅补偿演练。 - -## 15. 文档边界与引用 - -- 本文档定义首期可开工的高层设计，不展开字段级数据字典和实现细节。 -- 技术栈主选、后续启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。 -- 需求边界、验收基线以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。 +- 本文档定义首期可开工的技术方案，不展开字段级数据字典和实现细节。 +- 技术栈主选和启用条件以 `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/AODB 实施 Backlog.md` 为准。 - 关键设计取舍以 `airport-wiki/concepts/aodb/adr/` 下 ADR 为准。 diff --git a/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md b/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md new file mode 100644 index 0000000..6aeba29 --- /dev/null +++ b/airport-wiki/raw/articles/机场运行数据库 (AODB) 产品对比分析报告.md @@ -0,0 +1,285 @@ +# 机场运行数据库 (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