--- title: "开放式架构(Open Architecture)— 机场信息系统集成平台" created: 2026-04-15 modified: 2026-04-15 status: draft domain: integration-platforms tags: [architecture, integration, AODB, API, SOA, microservices, event-driven] domain_tags: [open-architecture, SOA, microservices, integration-platform, IEP, ESB, AIDX, AMHS, AMOS, FIXM] sources: - open-architecture-aci-europe - open-architecture-aci-africa - aciref-airport-open-platform - indra-airport-open-architecture-2025 - leonardo-open-architecture-security-2024 - iata-acis-digital-transformation-2025 - IATA-AIDX-18 - IATA-AMIS - aruba-airport-open-platform-2025 --- # 机场开放式架构(Open Architecture)—— 信息系统集成平台 ## 概念与背景 传统机场信息系统采用单体集成模式:AODB 作为单一中央数据库,各子系统通过点对点接口(Point-to-Point)连接 AODB 形成星形拓扑。这种模式的问题包括: - **接口耦合度高**:每新增一个系统需要与所有相关系统建立连接 - **厂商锁定**:核心系统(AODB/FIDS/RMS)更换成本极高 - **技术债务累积**:协议异构(SOAP/REST/WebSocket/文件传输/数据库直连)导致维护困难 - **扩展性差**:新业务场景(如 AI 运营分析、数字孪生)需要大量定制开发 开放式架构的核心思想是引入**集成中间件层(Integration Middleware Layer)**作为系统间的统一交换总线,实现: 1. **协议解耦**:各系统只与中间件通信,无需互相了解实现细节 2. **数据标准化**:统一使用 IATA AIDX/AMIS、ICAO FIXM 等行业标准消息格式 3. **可插拔系统**:新系统只需适配集成平台即可接入 4. **事件驱动**:支持实时事件发布/订阅,不仅是被动查询 > 本页面与 `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(各系统只连集成层) | | 新增系统成本 | 高(需适配所有相关系统) | 低(只需适配集成平台) | | 协议支持 | 异构,每个系统不同 | 统一,由集成层处理转换 | | 替换核心系统 | 极难(所有接口需重写) | 较易(只需新系统适配集成层) | | 实时能力 | 通常批量/轮询 | 事件驱动,实时推送 | | 数据主权 | 数据分散在各系统 | 通过数据总线统一管理 | | 厂商锁定 | 严重(接口绑定特定厂商) | 降低(通过标准接口解耦) | ## 技术挑战 1. **遗留系统兼容**:旧系统只有 SOAP 或文件传输接口,需要编写适配器 2. **数据一致性**:分布式环境下 AODB 与子系统数据同步 3. **性能要求**:机场运营对实时性要求高(航班状态更新需在秒级) 4. **安全合规**:航空安保数据的跨境传输限制 5. **标准碎片化**: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 核心功能