12 KiB
12 KiB
title, created, modified, status, domain, tags, domain_tags, sources
| title | created | modified | status | domain | tags | domain_tags | sources | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 开放式架构(Open Architecture)— 机场信息系统集成平台 | 2026-04-15 | 2026-04-15 | draft | integration-platforms |
|
|
|
机场开放式架构(Open Architecture)—— 信息系统集成平台
概念与背景
传统机场信息系统采用单体集成模式:AODB 作为单一中央数据库,各子系统通过点对点接口(Point-to-Point)连接 AODB 形成星形拓扑。这种模式的问题包括:
- 接口耦合度高:每新增一个系统需要与所有相关系统建立连接
- 厂商锁定:核心系统(AODB/FIDS/RMS)更换成本极高
- 技术债务累积:协议异构(SOAP/REST/WebSocket/文件传输/数据库直连)导致维护困难
- 扩展性差:新业务场景(如 AI 运营分析、数字孪生)需要大量定制开发
开放式架构的核心思想是引入**集成中间件层(Integration Middleware Layer)**作为系统间的统一交换总线,实现:
- 协议解耦:各系统只与中间件通信,无需互相了解实现细节
- 数据标准化:统一使用 IATA AIDX/AMIS、ICAO FIXM 等行业标准消息格式
- 可插拔系统:新系统只需适配集成平台即可接入
- 事件驱动:支持实时事件发布/订阅,不仅是被动查询
本页面与
integration-platforms/event-bus-pattern.md互补——前者偏架构,后者偏实施细节。
参考架构
三层架构模型(ACI/Airtel 方案)
┌─────────────────────────┐
│ 应用与呈现层 │
│ (Apps & Presentation) │
│ FIDS / 移动 App / API │
│ Dashboards / AI 分析 │
└─────────▲───────────────┘
│ REST/GraphQL/WebSocket
┌─────────┴───────────────┐
│ 集成中间件层 │
│ (Integration Layer) │
│ ESB + ETL + EIP + API │
│ Gateway │
└─────────▲───────────────┘
│ AIDX/AMIS/自定义格式
┌─────────┴───────────────┐
│ 核心系统层 │
│ (Core Systems) │
│ AODB / FIDS / RMS / │
│ BHS / A-CDM / VDCS / │
│ 离港 / 安检 / 商业 │
└─────────────────────────┘
Layer 1 — 核心系统层:保持各子系统独立运行,不做架构改造。每个系统通过适配器连接到集成层。
Layer 2 — 集成中间件层:这是开放式架构的核心。参考 ACI/Airtel 方案:
| 组件 | 功能 | 示例技术 |
|---|---|---|
| ESB (Enterprise Service Bus) | 系统间消息路由、协议转换 | MuleSoft, WSO2, RabbitMQ + 自定义路由 |
| ETL (Extract-Transform-Load) | 数据抽取、清洗、格式转换 | Apache NiFi, Kafka Connect |
| EIP (Enterprise Integration Pattern) | 消息路由、内容路由、聚合 | Apache Camel, Spring Integration |
| API Gateway | 外部 API 统一入口、限流、认证 | Kong, Apigee, AWS API Gateway |
| EDA (Event-Driven Architecture) | 实时事件发布/订阅 | Kafka, RabbitMQ, NATS |
Layer 3 — 应用与呈现层:消费集成层提供的数据和服务。可以独立开发,不直接依赖核心系统。
集成平台参考架构(Leonardo/ACI 安全系统方案)
ACI Europe 在 Open Architecture for Airport Security Systems 中定义了安检系统(CT/EDS/ATRS/CBSS)的开放式集成框架,其原则可推广到整个机场信息系统:
| 层级 | 组件 | 说明 |
|---|---|---|
| L2 (设备层) | EDS/CT/ATRS 等安检设备 | OEM 硬件,通过标准化接口接入 |
| L2.5 (集成层) | OEM 专用集成软件(OIS) | 厂商提供的事件网关,向上暴露标准接口 |
| L3 (站点管理系统) | SSMS / AODB / RMS | 机场运营管理系统,消费 L2.5 提供的数据 |
| L4 (机场/网络管理层) | ACM / AIMS | 多机场集中管理平台 |
关键集成接口定义:
| 接口 | 用途 | 标准 |
|---|---|---|
| IDI (Inspection Data Interface) | 检查结果数据(图像、威胁状态、分辨率) | DICOS/IOD 或 CSV |
| CDI (Corrected Data Interface) | 修正后的检测数据 | DICOS |
| MTA (Maintenance Ticketing) | 维护工单与状态 | 自定义或 SNMP |
| RMM (Remote Monitoring & Management) | 远程监控与管理 | MQTT 或 SNMP |
安全认证框架:
- SAML SSO for user authentication
- OAuth 2.0 for API authorization
- RBAC for access control
- TLS 1.2+ for transport security
- KMS for key management
混合集成模式(ACI Europe 定义)
ACI Europe 定义了三种集成方式,实际部署中通常混合使用:
┌────────────────────┐
│ Data Centre │
│ (本地数据中心) │
│ │
┌──────┴─┐ ┌────────────┐ │
│ ESB/ │ │ 本地系统 │ │
│ ETL │ │ AODB/RMS │ │
└───┬────┘ └────────────┘ │
│ │
│ 混合连接 │
▼ │
┌──────────────┐ │
│ 云平台 │ │
│ SaaS / PaaS │ │
│ API Gateway │ │
└──────────────┘ │
└────────────────────────────┘
- Local Mode:所有集成组件和系统都在本地数据中心 ESB/EIP 处理所有集成
- Cloud Mode:集成平台部署在云上,本地系统通过安全通道连接
- Hybrid Mode(推荐):核心数据(AODB)保持本地,分析/移动端/SaaS 服务通过云平台
数据交换标准
IATA AIDX (Airport Information Exchange)
AODB 之间航班数据交换的行业标准,基于 XML 和 Web Services:
| 版本 | 特点 |
|---|---|
| AIDX 1.4 | 基础航班数据交换(起飞、降落、延误、取消) |
| AIDX 1.5 | 增加资源信息(登机口、行李转盘、值机柜台)关联 |
| AIDX 1.6 | 增加航班状态变更(ETA/ATA/ETD/ATD)实时更新 |
| AIDX 1.7 | 增加多机场网络支持 |
| AIDX 1.8 | 最新完整版本,新增商业数据、旅客数据字段 |
IATA AMIS (Airport Messaging Integration Services)
下一代机场消息交换平台,基于云端 API,支持:
- RESTful API 访问(替代传统 Web Services)
- 实时事件推送(Webhook/Callback)
- 多数据源聚合(AODB、FIDS、BHS、RMS)
- SaaS 订阅模式
ICAO FIXM (Flight Information Exchange Model)
空中交通管理领域的航班信息交换标准,与 AIDX 互补:
- 覆盖空管系统间的航班计划、航路、高度等信息
- 未来与 AIDX 融合趋势(AIDX 1.8 已部分采纳 FIXM 概念)
其他相关标准
| 标准 | 领域 | 说明 |
|---|---|---|
| AMHS (ATS Message Handling Services) | 空管消息 | ICAO 标准,替代 AFTN/AMHS |
| IATA Type B Messaging | 航班电报 | 传统电报格式(SSIM、PTM) |
| ACI A-CDM Toolkit | 协同决策 | A-CDM 数据采集与共享 |
厂商与产品格局
专用集成平台厂商
| 厂商 | 产品 | 模式 | 特点 |
|---|---|---|---|
| Airtel(ACI partner) | Airport Open Platform | ESB + Cloud Hybrid | 10+ 机场部署,模块化 SaaS,API-first,多机场网络支持 |
| Indra | Open Architecture Suite | On-Premise / Hybrid | 模块化 AODB,多机场集中部署,移动访问 |
| SITA | AirportHub | Cloud SaaS | 云端 AODB + FIDS,API 集成,全球网络 |
| Collins (Rockwell) | AIMS | On-Premise | 大型机场专用(迪拜、多哈等),高度定制 |
| Amadeus | Altea AMDB | Cloud SaaS | 云端 AODB,与 Altea 离港系统深度集成 |
通用集成中间件(适配机场场景)
| 产品 | 类型 | 适用场景 |
|---|---|---|
| MuleSoft Anypoint Platform | ESB + API Gateway | 大型机场全面集成 |
| WSO2 Integration Studio | 开源 ESB | 预算有限的中等机场 |
| Apache Camel + Kafka | 开源 EIP + EDA | 技术团队强的机场 |
| Kong Gateway | API Gateway | API 统一管理和外部开发者 |
实施建议
| 机场规模 | 推荐模式 | 理由 |
|---|---|---|
| 小型机场 (< 5M pax/年) | Cloud SaaS (SITA/Amadeus) | 低运维成本,无需本地 IT 团队 |
| 中型机场 (5-25M pax/年) | Hybrid (本地 ESB + Cloud API) | 平衡控制力与灵活性 |
| 大型机场 (> 25M pax/年) | 本地 ESB + 定制化 | 高度定制需求,数据主权 |
| 多机场网络 | 云端集中 AODB + 本地边缘 | 集中管理 + 本地自治 |
实际案例
ACI Europe Open Architecture for Security Systems
ACI Europe 2020 年发布第一版指南,定义了安检系统(CT EDS、ATRS、CBSS)的开放集成框架。关键成果:
- 定义了 IOA(Interoperable Open Architecture)参考模型
- 规定了 L2/L2.5/L3/L4 四层架构
- 定义了标准接口(IDI/CDI/MTA/RMM)和数据格式(DICOS/CSV)
- 推动了安检设备厂商从封闭系统向开放 API 转变
Leonardo 智能安检平台
Leonardo 公司基于 ACI OA 框架开发的安检集成方案,支持:
- CT EDS 设备集成
- Auto Tray Return System (ATRS) 集成
- Common Use Self Service (CUSS) 集成
- 与 AODB/A-CDM 的实时数据交换
- 支持 SAML SSO 和 OAuth 2.0
Aruba 机场开放平台
Aruba 机场部署的开放性架构集成平台:
- 多厂商设备统一接入
- 事件驱动架构(EDA)
- 与 AODB/FIDS/RMS 实时集成
- 支持移动端和 API 访问
与传统架构的对比
| 维度 | 传统点对点集成 | 开放式架构 |
|---|---|---|
| 接口数量 | N×(N-1) | 2N(各系统只连集成层) |
| 新增系统成本 | 高(需适配所有相关系统) | 低(只需适配集成平台) |
| 协议支持 | 异构,每个系统不同 | 统一,由集成层处理转换 |
| 替换核心系统 | 极难(所有接口需重写) | 较易(只需新系统适配集成层) |
| 实时能力 | 通常批量/轮询 | 事件驱动,实时推送 |
| 数据主权 | 数据分散在各系统 | 通过数据总线统一管理 |
| 厂商锁定 | 严重(接口绑定特定厂商) | 降低(通过标准接口解耦) |
技术挑战
- 遗留系统兼容:旧系统只有 SOAP 或文件传输接口,需要编写适配器
- 数据一致性:分布式环境下 AODB 与子系统数据同步
- 性能要求:机场运营对实时性要求高(航班状态更新需在秒级)
- 安全合规:航空安保数据的跨境传输限制
- 标准碎片化:AIDX、FIXM、AMHX 等标准并存,适配成本高
实施路线图(建议)
| 阶段 | 时间 | 目标 |
|---|---|---|
| Phase 1 | 0-3 月 | 部署 ESB 基础框架,接入 AODB 和 FIDS |
| Phase 2 | 3-6 月 | 接入 RMS、BHS、离港系统,实现 AIDX 消息交换 |
| Phase 3 | 6-12 月 | 部署 API Gateway,开放外部 API(移动 App、航司直连) |
| Phase 4 | 12-18 月 | 部署事件总线(Kafka),实现实时事件驱动架构 |
| Phase 5 | 18+ 月 | 云平台集成、AI 分析、数字孪生等高级应用 |
相关页面
concepts/flight-operations/airport-systems-landscape.md— 机场系统全景图integration-platforms/event-bus-pattern.md— 事件总线实施模式concepts/flight-operations/aodb-core.md— AODB 核心功能