windy/airport-wiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
windyboy
2026-04-15 14:48:14 +08:00
commit 42b6f73d1e
97 changed files with 16997 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
concepts/aodb/AODB 事件 Schema 草案.md
+252
View File
@@ -0,0 +1,252 @@
# 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` 作为强语义，而不是展示附注。
- 不得把查询接口结果当作事件流补偿来源。
concepts/aodb/AODB 字段级权威矩阵.md
+65
View File
@@ -0,0 +1,65 @@
# 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 被恢复时，必须有显式更正，不允许静默取消取消状态。
concepts/aodb/AODB 最小部署拓扑草案.md
+176
View File
@@ -0,0 +1,176 @@
# 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 章节。
- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。
concepts/aodb/AODB 核心需求提炼.md
+111
View File
@@ -0,0 +1,111 @@
# 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`
concepts/aodb/adr/ADR-001 MVP 不引入 Flink.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-001 MVP 不引入 Flink
## 状态
Accepted
## 背景
首期目标是完成单机场 AODB 核心闭环，规模为 500 万至 3000 万旅客机场，优先解决当前态统一、资源冲突和审计问题。
## 决策
MVP 不引入 Flink。首期只保留 Kafka 事件骨干和应用服务内流式处理逻辑。预测、CEP 和复杂有状态计算推迟到 P1。
## 原因
- 首期复杂度应优先让位于交付确定性。
- 预测与复杂流处理不是首期闭环前提。
- Flink 会显著提高部署、运维和故障恢复复杂度。
## 后果
- MVP 中实时计算能力受限。
- 事件契约和聚合边界必须为未来引入 Flink 预留演进空间。
concepts/aodb/adr/ADR-002 Kafka 作为唯一事件骨干.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-002 Kafka 作为唯一事件骨干
## 状态
Accepted
## 背景
AODB 需要支撑事件可回放、订阅分发、补偿和审计。
## 决策
Kafka 作为唯一事实事件骨干。所有对外事件订阅都以 Kafka 上的标准化事件为源头，禁止多路事件源头并存。
## 原因
- 统一重放和补偿语义。
- 避免“写库成功但未发布”或“已发布但未落库”的治理空洞。
- 降低外部消费者理解成本。
## 后果
- 事件可靠发布必须依赖 Outbox + CDC。
- 查询 API 不能被下游误当作事件事实源。
concepts/aodb/adr/ADR-003 事实分层模型.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-003 事实分层模型
## 状态
Accepted
## 背景
AODB 需要同时处理多源观测、字段裁决和对外权威事实发布。
## 决策
采用 `Observation / Decision / Published Fact` 三层模型。
## 原因
- 让 SSOT 真正表示“经过治理后发布的事实”。
- 保证原始观测、人工覆盖和当前值三者不互相污染。
- 便于审计、回放和责任归因。
## 后果
- 数据模型和事件模型会更明确，但设计和实现复杂度略有上升。
- Published Fact 的任何变更都必须可追溯到 Observation 和 Decision。
concepts/aodb/adr/ADR-004 FlightOperation 写主归属.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-004 FlightOperation 写主归属
## 状态
Accepted
## 背景
原方案中 Flight、Milestone、Resource、Alert 边界存在写入重叠风险。
## 决策
Flight 当前权威态只能由 `Flight Operation Service` 写入，其他服务只能产生观测、候选事实、资源事实或告警事实。
## 原因
- 避免多个服务共同修改同一当前态。
- 降低一致性和回放复杂度。
- 方便将 Published Fact 聚合到单一领域对象。
## 后果
- Milestone 和 Resource 服务必须通过事件影响 Flight 当前态。
- Flight Service 需要承担更明确的聚合协调责任。
concepts/aodb/adr/ADR-005 Turnaround 独立建模.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-005 Turnaround 独立建模
## 状态
Accepted
## 背景
仅以单航班建模无法充分表达到离港配对、机尾号上下文和资源联动。
## 决策
将 `Turnaround` 作为首期核心领域对象，引入最小独立建模。
## 原因
- 支撑航班配对（Linking）需求。
- 提高资源分配和时序解释能力。
- 为换机、延误联动和周转分析提供上下文。
## 后果
- 文档和模型复杂度上升。
- 配对修正和不完整配对需要额外的事件和审计语义。
concepts/aodb/adr/ADR-006 资源锁定模型.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-006 资源锁定模型
## 状态
Accepted
## 背景
单纯的资源时间窗分配无法表达建议分配、已确认分配和人工强制覆盖。
## 决策
ResourceAllocation 支持 `soft lock` 和 `hard lock` 两种锁定语义。
## 原因
- 表达自动建议和人工强制分配的区别。
- 支持冲突检测、覆盖和回滚的可解释性。
- 为未来优化排班预留空间。
## 后果
- 冲突检测和分配逻辑需要区分锁定强度。
- 人工覆盖必须伴随审计和事件输出。
concepts/aodb/adr/ADR-007 查询与订阅分离.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-007 查询与订阅分离
## 状态
Accepted
## 背景
将 GraphQL Subscription 或查询层直接作为事实流会混淆读取和事件分发语义。
## 决策
对外查询接口和事件订阅接口分离设计。
## 原因
- 查询和事件分发的稳定性、回放、限流语义不同。
- 便于明确外部消费者的消费契约。
- 降低把查询接口误当权威事件骨干的风险。
## 后果
- 需要独立设计事件订阅网关或分发适配层。
- API 文档要分别描述查询和订阅契约。
concepts/aodb/adr/ADR-008 Outbox 与 CDC.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-008 Outbox 与 CDC
## 状态
Accepted
## 背景
AODB 必须避免“写库成功但没发事件”或“发了事件但没落库”。
## 决策
采用 `Outbox Pattern + CDC` 作为写库与发事件一致性策略。
## 原因
- 能把数据库状态变化和事件发布绑定到同一事务边界。
- 适合首期 Kafka 作为唯一事件骨干的架构。
- 支持失败重试、断点恢复和事件回放。
## 后果
- 需要部署 CDC / 发布器组件。
- 发布流程和 Outbox 堆积需要专门监控。
concepts/aodb/adr/ADR-009 PostgreSQL HA.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-009 PostgreSQL HA
## 状态
Accepted
## 背景
Published Fact、审计和 Outbox 都依赖 PostgreSQL，数据库可用性直接决定系统可用性。
## 决策
MVP 必须采用 PostgreSQL 高可用部署，并具备备份恢复和 PITR 或等价能力。
## 原因
- 满足 RTO / RPO 目标。
- 为审计、重放和一致性提供稳定基础。
- 避免首期把可靠性寄托在应用层补偿上。
## 后果
- 部署和运维门槛上升，但这是首期必须承担的复杂度。
- 需要单独演练主备切换和恢复流程。
concepts/aodb/adr/ADR-010 人工裁决事件化.md
+24
View File
@@ -0,0 +1,24 @@
# ADR-010 人工裁决事件化
## 状态
Accepted
## 背景
AODB 中数据冲突、资源覆盖和解析失败都可能需要人工参与。
## 决策
所有人工裁决、人工覆盖和人工复核动作必须事件化和审计化，禁止仅通过数据库备注或日志留痕。
## 原因
- 人工动作是业务事实的一部分。
- 需要对外解释当前值为何成立。
- 便于回放、对账和合规审计。
## 后果
- Case 流程和审计模型需要更完整。
- 首期必须实现最小人工复核状态机。
concepts/aodb/开源技术栈选型决策.md
+101
View File
@@ -0,0 +1,101 @@
# 开源技术栈选型决策
## 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/` 下文件为准。
concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md
+510
View File
@@ -0,0 +1,510 @@
# 开源机场运营数据库（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 为准。
concepts/flight-operations/a-cdm.md
+87
View File
@@ -0,0 +1,87 @@
---
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 过站时间的重要变量
concepts/flight-operations/agentic-ai-airports.md
+63
View File
@@ -0,0 +1,63 @@
---
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 驅動超級個性化服務
concepts/flight-operations/airport-systems-landscape.md
+106
View File
@@ -0,0 +1,106 @@
---
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]] — 供应商横向对比
concepts/flight-operations/aocc-ioc.md
+81
View File
@@ -0,0 +1,81 @@
---
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 實時監控與預測性維護的技術基礎
concepts/flight-operations/aodb-china.md
+243
View File
@@ -0,0 +1,243 @@
---
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]] — 機場運營系統供應商全景對比
concepts/flight-operations/aodb-core.md
+163
View File
@@ -0,0 +1,163 @@
---
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]] — 供應商綜合對比
concepts/flight-operations/aodb-vendors.md
+495
View File
@@ -0,0 +1,495 @@
---
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]] — 運營系統供應商全景對比
concepts/flight-operations/baggage-handling.md
+63
View File
@@ -0,0 +1,63 @@
---
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]] — 航班动态影响行李中转分拣时机
concepts/flight-operations/biometric-corridors.md
+48
View File
@@ -0,0 +1,48 @@
---
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]] — 生物特徵走廊與智能登機口密切相關
concepts/flight-operations/deicing-operations.md
+65
View File
@@ -0,0 +1,65 @@
---
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 体系中
concepts/flight-operations/digital-twins-airports.md
+48
View File
@@ -0,0 +1,48 @@
---
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 能源優化的重要工具
concepts/flight-operations/flight-data-exchange.md
+266
View File
@@ -0,0 +1,266 @@
---
title: 航班数据交换标准
created: 2026-04-08
updated: 2026-04-08
type: concept
tags: [flight-data, api, integration, system]
sources: [raw/articles/iata-ssim-2026.md, raw/articles/schedule-data-exchange-2025.md, raw/articles/aidx-xml-imp-guide-v22.1.md]
---
# 航班数据交换标准
## 定义
航班数据交换标准是 IATA 主导的全球航空数据格式规范，涵盖航班计划、运营动态、地面保障数据的标准化报文格式，是机场信息化系统的数据互操作基础。
## 核心标准
| 标准 | 全称 | 用途 |
|------|------|------|
| **SSIM** | Standard Schedules Information Manual | 航班计划数据交换格式 |
| **AIRIMP** | Airline Industry Reservations Interline Message Procedures | 订座与运价报文 |
| **AHM** | Airport Handling Manual | 地面操作数据标准 |
| **CIDX** | Cargo Interchange Data Standard | 货运数据交换（部分机场也用于航班动态） |
| **IATA-OS** | IATA-OS Data Model | 机场运营数据模型（与 ICDM 合并演进） |
## SSIM — Standard Schedules Information Manual
|| 项目 | 信息 |
|------|------|
|| 最新版本 | **第 36 版（2026）** |
|| 发布频率 | 年度 |
|| 适用范围 | 全球所有 IATA 成员航司及合作伙伴 |
|| 核心内容 | 航班计划报文格式、最小衔接时间（MCT）、机场协调程序 |
SSIM 是航班计划数据交换的行业基准，采用**固定长度报文格式（flat file）**，支持批量数据交换。
### SSIM 信息数据行字段定义（Chapter 6/7 SCR 报文）
每行数据包含 14 个固定字段，固定位置，不可变长：
```
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGPAGP1000 1055BCNBCN JP
^1 ^3 ^4 ^6 ^7 ^8 ^9 ^10 ^11
```
| 字段 | 名称 | 内容 | 示例 |
|------|------|------|------|
| 1 | Action Code | 操作代码（N=新请求/C=变更/D=删除） | N |
| 2 | Arrival Flight Designator | 到达航班（航司代码+航班号，最低3位数字） | XZ101 |
| 3 | Departure Flight Designator | 出发航班（航司代码+航班号） | XZ102 |
| 4 | Period Start | 有效期开始 | 20JUN |
| 5 | Period End | 有效期结束 | 20AUG |
| 6 | Weekdays of Operation | 周运营日（1=周一～7=周日，1-7数字串） | 0234500 |
| 7 | Number of Seats | 座位数（3位数字） | 189 |
| 8 | Aircraft Subtype | IATA 机型代码（3位） | 738 |
| 9 | Origin Airport | 出发/到达机场代码（同一行往返） | AGP |
| 10 | Arrival Time (UTC) | 到达时间（UTC，过夜加1后缀） | 1000 |
| 11 | Departure Time (UTC) | 出发时间（UTC） | 1055 |
| 12 | Next/Destination Airport | 目的地/下一机场代码 | BCN |
| 13 | Arrival Service Type | 到达服务类型（J=定期客机/P=调机） | J |
| 14 | Departure Service Type | 出发服务类型 | P |
### SSIM SCR 报文示例
**标准 turnaround 格式（新请求）：**
```
SCR /schedule@carrier.com
S21 01APR DUB
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGP1000 1055BCN JP
SI NEW SERIES
GI BEST REGARDS
```
含义：S21航季，4月1日发给 DUB 机场，XZ 航司新 slot 请求，XZ101 进港/XZ102 出港，6月20日—8月20日每周二三四五执飞，189座，B738 机型，AGP 进港 1000z，BCN 出港 1055z。
### 协调员响应代码
| 代码 | 含义 |
|------|------|
| K | 确认（Confirmed） |
| X | 变更（Change required） |
| U | 拒绝（Refused） |
| O | 建议（Offer alternative） |
---
## AIDX — Aviation Information Data Exchange
|| 项目 | 信息 |
|------|------|
|| 类型 | XML 消息标准（ISO/IEC 19757-3） |
|| 版本 | v22.1（每年 2 次发布） |
|| 覆盖 | 约 **180 个**数据元素，涵盖航班运营全生命周期 |
|| 开发者 | IATA Delivery on Orders Working Group（80+ 航司/机场/厂商参与） |
|| 适用范围 | 航司↔机场↔第三方，运营动态实时交换 |
AIDX 由 IATA、ATA、ACI 共同认可，是 SESAR A-CDM、ACI ACRIS A-CDM Web Services、ICAO A-CDM（亚太区）信息交换的标准格式。
### 三种核心消息类型
| 消息类型 | 用途 | 方向 |
|----------|------|------|
| `IATA_AIDX_FlightLegNotifRQ` | 无请求方主动通知（推送） | 发送方 → 接收方 |
| `IATA_AIDX_FlightLegRQ` | 查询请求 | 发送方 → 接收方 |
| `IATA_AIDX_FlightLegRS` | 响应/确认 | 接收方 → 发送方 |
### 集成模式
**模式1：无请求方主动通知（推送）**
```
Sender → IATA_AIDX_FlightLegNotifRQ → Receiver
Sender ← IATA_AIDX_FlightLegRS ← Receiver（可选确认）
```
**模式2：查询 + 同步响应**
```
Sender → IATA_AIDX_FlightLegRQ → Receiver
Sender ← IATA_AIDX_FlightLegRS ← Receiver
```
### XML 数据结构（IATA_AIDX_FlightLegNotifRQ）
```xml
<IATA_AIDX_FlightLegNotifRQ Version="2" TimeStamp="2017-01-16T17:27:49Z"
TransactionIdentifier="1484587669244" Target="Production" PrimaryLangID="en-us">
<Originator CompanyShortName="UAL" TravelSector="A" Code="UA" CodeContext="3"/>
<DeliveringSystem CompanyShortName="DEN" TravelSector="C" Code="DEN" CodeContext="3"/>
<FlightLeg>
<LegIdentifier>
<Airline CodeContext="3">UA</Airline>
<FlightNumber>1815</FlightNumber>
<DepartureAirport CodeContext="3">LAX</DepartureAirport>
<ArrivalAirport CodeContext="3">IAH</ArrivalAirport>
<OriginDate>2017-01-16</OriginDate>
<RepeatNumber CurrentInd="true">1</RepeatNumber>
</LegIdentifier>
<LegData InternationalStatus="Domestic">
<ServiceType>J</ServiceType>
<OperationalStatus>OP</OperationalStatus>
<CabinClass Class="7">
<PaxCount Qualifier="70A" Usage="Actual">166</PaxCount>
<SeatCapacity>166</SeatCapacity>
</CabinClass>
<AircraftInfo>
<AircraftType>737</AircraftType>
<AircraftSubType>73Q</AircraftSubType>
<Registration>N77518</Registration>
<TailNumber>518</TailNumber>
</AircraftInfo>
<AirportResources Usage="Actual">
<Resource DepartureOrArrival="Departure">
<PassengerGate>70A</PassengerGate>
</Resource>
<Resource DepartureOrArrival="Arrival">
<PassengerGate>E8</PassengerGate>
<BaggageClaimUnit>C5</BaggageClaimUnit>
</Resource>
</AirportResources>
<OperationTime OperationQualifier="OFB" CodeContext="9750" TimeType="ACT">2017-01-16T14:28:00Z</OperationTime>
<OperationTime OperationQualifier="TKO" CodeContext="9750" TimeType="ACT">2017-01-16T14:41:00Z</OperationTime>
<OperationTime OperationQualifier="TDN" CodeContext="9750" TimeType="ACT">2017-01-16T17:27:00Z</OperationTime>
<OperationTime OperationQualifier="ONB" CodeContext="9750" TimeType="EST">2017-01-16T17:33:00Z</OperationTime>
</LegData>
</FlightLeg>
</IATA_AIDX_FlightLegNotifRQ>
```
### 航班唯一标识（UFI）规则
`LegIdentifier` 构成唯一标识，必须严格遵循以下规则：
| 字段 | 规则 |
|------|------|
| `OriginDate` | **静态** — 即使航班改期仍不变，以首个航段的 UTC 计划出发日期为准 |
| `ArrivalAirport` | **静态** — 航班备降后原字段不变，新增 `PlannedArrivalAptHistory` 记录 |
| `OperationalSuffix` | **静态** — 如需变更须取消原航班并创建新航班 |
| `RepeatNumber` | 同一计划日期的重复起飞次数，1=首次尝试 |
### 运营状态代码
| 代码 | 含义 | 使用场景 |
|------|------|----------|
| OP | Operational Flight | 正常执行 |
| NOP | Non-Operational | 计划但不执行 |
| DV | Diverted | 备降 |
| DX | Cancelled | 取消 |
| RT | Re-route | 改航路 |
| GRT | Ground Return | 返回始发地（未起飞） |
| SQ | Re-instate | 恢复已取消/备降航班 |
### A-CDM 里程碑时间代码（Codeset 9750）
| 代码 | 含义 | 阶段 |
|------|------|------|
| SCH | Scheduled | 计划 |
| INI | Flight Plan Activated | 起飞前 |
| OFB | Off Blocks（撤轮档） | 推出 |
| TKO | Takeoff（起飞） | 离地 |
| FIN | Final Approach | 最后进近 |
| TDN | Touch Down（落地） | 接地 |
| LAN | Landed | 落地 |
| ONB | On Blocks（靠桥） | 停靠 |
### 时间类型
| 类型 | 含义 |
|------|------|
| SCT | Scheduled Time（计划时间） |
| EST | Estimated Time（预计时间） |
| ACT | Actual Time（实际时间） |
> **注意**：所有时间必须为 UTC，以 `xsd:DateTime` 格式传输，后缀 Z。元素缺失=无更新；`xsi:nil="true"`=显式清空；空元素（如 `<PassengerGate/>`）可能引发校验错误。
### 技术规范
| 项目 | 要求 |
|------|------|
| 字符编码 | UTF-8 |
| 时间格式 | xsd:DateTime，UTC，末尾 Z |
| 重复元素 | 使用 `RepeatIndex` 属性标记序号 |
| Nil 值 | 使用 `xsi:nil="true"`，禁止空白元素 |
| 传输机制 | 未规定（可基于 HTTPS REST、SFTP、WebService 等） |
### SSIM 与 AIDX 对比
| 维度 | SSIM Flat File | AIDX XML |
|------|----------------|----------|
| 数据类型 | 航班计划（季节性/批量） | 航班运营动态（实时） |
| 更新频率 | 批量定时交换（航季） | 实时推送/查询 |
| 格式 | 固定长度字段（ mainframe 遗留格式） | 树形 XML 结构 |
| 复杂度 | 低（字段固定），但解析困难 | 高（180+ 元素），但扩展性强 |
| 典型场景 | slot 协调、季节计划 | A-CDM、地面保障、旅客信息 |
| IATA 策略 | 逐步向 XML/IATA-OS 迁移 | 主推方向，已广泛部署 |
## IATA Schedule Data Exchange Program（2025 新动态）
- **2025 年 8 月启动**：航司可从 IATA 数据库**接收**其他航司的航班计划数据
- **数据范围**：航班计划 + MCT（Minimum Connect Time）异常数据
- **开放性**：向所有航司开放，包括非 IATA 成员
- **与现有 DDS / CDD 协同**：IATA Direct Data Solutions 系列扩展
## 数据流向示意
```
航司 ──SSIM格式──→ 机场 AODB ──ACISP──→ 各运营系统
│ │
│←──── 运营更新（动态）───────→│
│ │
└──── 地面服务商 ────────────┘
```
## XML vs. 传统 Flat File
| 维度 | SSIM Flat File | XML/IATA-OS |
|------|----------------|-------------|
| 结构 | 固定长度字段 | 树形结构，可扩展 |
| 实时性 | 批量/定时交换 | 支持实时 API |
| 主流场景 | 计划数据批量交换 | 运营动态实时共享 |
| IATA 推进方向 | 逐步向 XML/IATA-OS 迁移 | — |
## 相关链接
- [[aodb-core]] — AODB 是数据交换标准的最终接收与处理方
- [[a-cdm]] — A-CDM 的 ACISP 平台实现运营数据实时共享
- [[baggage-handling]] — 行李数据也通过类似报文标准交换
concepts/flight-operations/future-airport-info-center.md
+97
View File
@@ -0,0 +1,97 @@
---
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]] — 通用設計是信息中心無障礙服務的核心理念
concepts/flight-operations/open-architecture.md
+131
View File
@@ -0,0 +1,131 @@
---
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/)
concepts/flight-operations/smart-gating.md
+54
View File
@@ -0,0 +1,54 @@
---
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]] — 除冰作业影响航班推出时间，影响机位占用时长
concepts/flight-operations/smgcs.md
+57
View File
@@ -0,0 +1,57 @@
---
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]] — 机位分配与场面活动联动
concepts/flight-operations/universal-design-airports.md
+58
View File
@@ -0,0 +1,58 @@
---
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 在無障礙領域的具體實踐
concepts/knowledge-management/automation-hooks.md
+569
View File
@@ -0,0 +1,569 @@
---
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。
concepts/knowledge-management/knowledge-graph.md
+200
View File
@@ -0,0 +1,200 @@
---
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 集群的依赖关系
concepts/knowledge-management/knowledge-lifecycle.md
+474
View File
@@ -0,0 +1,474 @@
---
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。
concepts/knowledge-management/llm-wiki-v2-reference.md
+584
View File
@@ -0,0 +1,584 @@
---
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
> **维护状态**: 活跃 | **支持**: 用户文档 + 技术支持论坛
> **注意**: 本系统持续演进，建议定期查看相关文档获取最新信息。
concepts/knowledge-management/memory-lifecycle.md
+197
View File
@@ -0,0 +1,197 @@
---
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 相关的量化指标）
concepts/knowledge-management/quality-control.md
+616
View File
@@ -0,0 +1,616 @@
---
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。
concepts/knowledge-management/wiki-operations.md
+186
View File
@@ -0,0 +1,186 @@
---
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）
concepts/tech-infrastructure/airport-data-center-overview.md
+59
View File
@@ -0,0 +1,59 @@
---
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]] — 供配电与制冷
concepts/tech-infrastructure/commissioning.md
+88
View File
@@ -0,0 +1,88 @@
---
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]]
concepts/tech-infrastructure/construction-management.md
+82
View File
@@ -0,0 +1,82 @@
---
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]]
concepts/tech-infrastructure/design-phase.md
+79
View File
@@ -0,0 +1,79 @@
---
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]]
concepts/tech-infrastructure/glossary.md
+335
View File
@@ -0,0 +1,335 @@
---
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]]（數據中心子系統全圖）
concepts/tech-infrastructure/gpu-cluster.md
+139
View File
@@ -0,0 +1,139 @@
---
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`
concepts/tech-infrastructure/modern-airport-trends.md
+66
View File
@@ -0,0 +1,66 @@
---
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]]
concepts/tech-infrastructure/network-architecture.md
+36
View File
@@ -0,0 +1,36 @@
---
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]]
concepts/tech-infrastructure/operation-maintenance.md
+107
View File
@@ -0,0 +1,107 @@
---
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]]
concepts/tech-infrastructure/power-and-cooling.md
+83
View File
@@ -0,0 +1,83 @@
---
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]]
concepts/tech-infrastructure/prefab-modular-dc.md
+49
View File
@@ -0,0 +1,49 @@
---
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]]
concepts/tech-infrastructure/rfp-and-vendor-selection.md
+78
View File
@@ -0,0 +1,78 @@
---
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]]
concepts/tech-infrastructure/security-design.md
+95
View File
@@ -0,0 +1,95 @@
---
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]]
concepts/tech-infrastructure/site-planning.md
+54
View File
@@ -0,0 +1,54 @@
---
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]]
concepts/tech-infrastructure/tier-iii-design.md
+29
View File
@@ -0,0 +1,29 @@
---
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]]
concepts/tech-infrastructure/tier-iv-design.md
+30
View File
@@ -0,0 +1,30 @@
---
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]]