refactor aodb design docs around technical architecture

2026-04-13 17:39:10 +08:00
parent 99d66a9601
commit abce5516e4
6 changed files with 365 additions and 445 deletions
@@ -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 级拆解得到负责人和初步估算
@@ -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 章节。
- 它不是最终部署手册，但必须足以支撑架构评审和上线门禁定义。
+- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。
@@ -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 | 备注 |
+- 单机场优先，跨机场能力不作为 MVP 前提。
-| --- | --- | --- | --- | --- |
+- MVP 聚焦“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为前提。
-| 航班计划导入 | 是 |  |  | SSIM / 计划批量导入 |
+- 若外部系统稳定性不足，必须预留灰度、手工复核和数据质量标记兜底流程。
-| 动态更新 | 是 |  |  | AIDX / AFTN 等运行态接入 |
+- 首期不要求深度历史迁移，只要求新接入链路具备统一主键、幂等和审计能力。
 | 里程碑管理 | 是 |  |  | 关键里程碑统一治理 |
 | 航班配对与过站关联 | 是 |  |  | 以 `Turnaround` 最小建模 |
 | 基础资源分配 | 是 |  |  | Stand / Gate / Belt / Counter |
 | 冲突检测与告警 | 是 |  |  | 时间冲突、适配冲突、状态冲突 |
 | 查询接口 | 是 |  |  | 面向外部系统和运营终端 |
 | 事件订阅 | 是 |  |  | 至少一次投递、支持重连补偿 |
 | 审计与人工裁决 | 是 |  |  | 关键写入必须可追溯 |
 | EIBT / EXIT / EXOT 预测 |  | 是 |  | 有状态流处理增强能力 |
 | TSAT / TTOT 计算 |  | 是 |  | 与 PDS 衔接 |
 | 复杂 CEP |  | 是 |  | 实时模式识别和复杂聚合 |
 | 全局优化排班 |  |  | 是 | 不属于首期闭环 |
 | AI 调度与异常解释 |  |  | 是 | 在数据基础稳定后引入 |
 | 多机场统一调度 |  |  | 是 | 单机场稳定后再扩展 |
 ## 3. 功能需求清单
@@ -82,24 +69,24 @@ MVP（首期必须）：
 3. 解析失败消息必须进入死信队列并提供人工复核入口。
 4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。
-## 5. 非功能需求（SLO）
+## 5. 非功能需求
-| 维度 | 目标值 | 最低可接受值 | 验收方式 |
+| 维度 | 目标值 | 最低可接受值 | 说明 |
 | --- | --- | --- | --- |
-| 可用性 | 月度 99.95% | 月度 99.9% | 监控报表与故障统计 |
+| 可用性 | 月度 99.95% | 月度 99.9% | 保障核心运行时段可用 |
-| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 压测与生产观测 |
+| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 覆盖接入到发布事实主链路 |
-| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 对账任务与抽检 |
+| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 当前态和事件流必须可对账 |
-| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 容灾演练记录 |
+| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 支撑单机场容灾恢复 |
-| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 审计抽样与链路回放 |
+| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 覆盖自动裁决和人工动作 |
-| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 安全测试与配置核查 |
+| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 对外查询和订阅必须受控 |
-## 6. 上线假设与约束
+## 6. 架构约束
- 单机场优先，跨机场能力不作为首期交付前提。
+- Flight 当前态必须只有一个写主，不允许多个系统直接并行改写权威字段。
- 首期仅覆盖核心运行场景，不包含深度历史迁移改造。
+- 所有关键写入必须带来源、时间、幂等键和关联 ID。
- 2 至 4 周快速上线只适用于受控数据源、缩减版 MVP、单团队交付场景，不包含复杂流处理、复杂工作流平台和多机场能力。
+- 原始观测、裁决记录、发布事实必须分层保存，不允许只保留当前值。
- 若外部系统接口稳定性不足，需预留灰度、手工复核和数据质量标记兜底流程。
+- 查询接口和事件订阅接口必须分离，不允许把查询层当作事实流输出。
- 首期架构优先保证“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为上线前提。
+- 人工覆盖、回滚和复核必须事件化、审计化。
 ## 7. 术语与缩写（权威定义）
@@ -115,21 +102,10 @@ MVP（首期必须）：
 | EIBT | Estimated In-Block Time，预计靠桥时间 |
 | Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 |
-## 8. 验收清单（DoD）
+## 8. 关联文档
 1. MVP 功能域全部具备可演示业务闭环。
 2. 关键非功能指标达到最低可接受值。
 3. 核心实体和关键事件具备统一主键、幂等规则和写主边界。
 4. 对外接口具备鉴权、限流、审计和重连补偿能力。
 5. 字段级权威矩阵、事件契约、容灾策略和人工复核流程具备文档化定义。
 6. 文档与实现一致，可用于排期拆解、测试用例编制和 ADR 评审。
 ## 9. 关联文档
 - `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`
@@ -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
 - 文档可直接支持任务拆解、测试设计和架构评审
 - 下层设计文档足以支撑实现前的细化评审
@@ -1,35 +1,35 @@
 # 开源机场运营数据库（AODB）高层设计文档
-## 1. 目标
+## 1. 文档目标
-本设计给出 AODB 的首期可开工高层方案，重点回答六件事：
+本文档定义 AODB MVP 的技术方案基线，重点回答以下问题：
-1. 首期上线到底做什么、不做什么。
+1. AODB 在 MVP 内承载哪些业务闭环，以及哪些能力明确不做。
-2. 系统由哪些核心聚合和服务组成。
+2. 系统如何划分聚合、服务、数据流和事件边界。
-3. 关键业务数据如何在“观测、裁决、发布事实”之间流转。
+3. 航班、里程碑、资源、告警等核心对象如何建模。
-4. 资源分配、冲突、告警和人工复核如何闭环。
+4. 发布事实如何在观测、裁决、审计和订阅之间保持一致。
-5. 对外查询与事件订阅如何解耦。
+5. 查询、订阅、部署、容灾和可观测性如何落到可实现架构。
 6. SLO 与部署、容灾和审计如何对齐。
-适用范围：年旅客吞吐量 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 预测与自适应调度
+- 深度 AI 预测和自适应调度
- Flink 驱动的复杂 CEP 和预测平台
+- Flink 驱动的复杂 CEP 平台
 - Temporal 驱动的复杂长事务工作流平台
 - 多机场统一调度中心能力
 ### 3.3 分阶段演进
 - Phase 1：完成 MVP 闭环并上线单机场。
 - Phase 2：引入预测能力、复杂规则平台和补偿编排能力。
 - Phase 3：增强容量、容灾和多机场扩展。
 ## 4. 总体架构
 ### 4.1 架构分层
-| 层级 | 主要能力 | MVP 主路径组件 | 后续增强组件 |
+| 层级 | 主要能力 | MVP 主路径组件 | 说明 |
 | --- | --- | --- | --- |
-| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 协议适配扩展插件 |
+| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 接收计划、动态、资源和人工操作输入 |
-| 业务层 | 航班当前态、观测治理、资源分配、告警处置、对外接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 独立 Case / Workflow Service |
+| 业务层 | 航班当前态、观测治理、资源分配、告警处置、外部接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 承担领域逻辑和对外契约 |
-| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 订阅网关增强、Schema Registry |
+| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 负责异步传播和回放 |
-| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | OpenSearch、对象存储 |
+| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | 保存当前态、审计链路和热点读模型 |
-| 平台层 | 身份认证、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | Linkerd、Jaeger |
+| 平台层 | 认证鉴权、部署、观测 | 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 | 设计支撑 | 验收方式 |
+- 所有写路径必须具备请求追踪、事件追踪和审计追踪三类关联 ID。
-| --- | --- | --- |
+- 关键链路必须暴露延迟、失败率、积压量和重试次数指标。
-| 可用性 | 多副本 API、DB HA、Kafka 副本 | 演练和月度故障统计 |
+- 人工裁决、资源覆盖和更正事件必须进入统一审计检索视图。
-| 延迟 | 单聚合写主、Kafka 事件骨干、缓存热点读 | 压测和生产观测 |
+- 订阅接口必须暴露连接数、滞后量、推送速率和补偿次数指标。
 | RTO / RPO | DB 备份恢复、Kafka 重放、CDC 恢复 | 容灾演练 |
 | 审计覆盖 | Observation / Decision / AuditTrail | 抽样链路回放 |
-## 14. 上线门禁（Go / No-Go）
+## 14. 文档边界与引用
- 功能门禁：计划导入、动态接入、里程碑发布事实、资源分配、冲突告警、人工裁决链路可端到端演示。
+- 本文档定义首期可开工的技术方案，不展开字段级数据字典和实现细节。
- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
+- 技术栈主选和启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
- 一致性门禁：Outbox / CDC、重放、幂等和断线补偿完成验证。
+- 需求边界以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
 - 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
 - 演练门禁：完成数据库恢复、事件重放和订阅补偿演练。
 ## 15. 文档边界与引用
 - 本文档定义首期可开工的高层设计，不展开字段级数据字典和实现细节。
 - 技术栈主选、后续启用条件以 `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 为准。
@@ -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