存在多种针对提供与飞行器地面操作有关的产品和服务的实体的系统解决方案。在这里，有时候将这些实体称为业务域(business domain)。然而，这些业务域没有被良好地互相整合或者与例如飞行器制造商的系统良好地整合。至少对于飞行器地面操作(即，飞机、机场、航空公司、维护和修理组织、管理当局以及飞行器制造商)，在这些业务域之间通信的当前方法是私有系统和单机解决方案的专门分类。

尽管这些单机系统可以非常好地执行它们的指定功能，但是一个改进是这些系统和其它系统的整合。另外的改进将产生这些系统在各种业务域内的协同操作能力。这种解决方案趋于为航空公司运营和飞行器相关行业提供成本有效性和灵活性。
在一个方面，提供了一种用于整合由基于地面的系统提供的与飞机操作有关的服务的方法。该方法包括：接收来自多个飞机服务功能体(function)的信息，确定哪个所接收的飞机操作信息可应用于每个飞机服务功能体，以及将可应用的飞机操作信息分发给每个飞机服务功能体。所述飞机服务功能体包括：航空公司、飞机、管理当局、维护修理组织和飞行器制造商，所接收的信息与飞机操作有关。
在另一个方面，一种网络架构被配置为整合和控制与基于地面的飞机操作有关的信息。该架构包括：彼此通信耦接的多个计算机系统、以及整合功能。所述计算机系统被编程为提供与多个飞机服务功能体有关的信息，所述飞机服务功能体包括航空公司、飞机、管理当局、维护修理组织和飞行器制造商中的两个或更多个。所述整合功能确定哪个所提供的信息可应用于所述两个或更多个飞机服务功能体中的每一个。所述整合功能还将可应用的信息分发给可应用的两个或更多个飞机服务功能体中的每一个。

图1是关于机场地面操作的域和关系的图示。
图2是解决方案提供商所具有的与图1所示的域的关系的图示。
图3是若干地面技术架构模式(pattern)的图示。
图4是电子化(e-Enabled)地面技术视图(view)组件和功能的图示。
图5是电子化地面产品技术视图。
图6是地面技术视图的单机产品模式的图示。
图7是与服务技术视图整合的电子化地面产品。
图8是电子化服务技术视图。
图9是电子化地面单机服务视图。
图10是电子化地面公共服务组织。
图11是战略(strategic)架构参考模型的图示。
图12是第一示例电子化地面架构的框图。
图13是第二示例电子化地面架构的框图。

下面描述用于在飞行器位于地面上时处理与该飞行器有关的信息的基于地面的网络和环境的各种实施例。这样的实施例包括提供电子化地面架构解决方案的方法和装置。这种解决方案与例如在飞行器的处理中涉及的各种实体之间的信息共享有关。如在这里使用的电子化是指使用通信中枢链路、网络技术和存储装置中的一个或多个传递电子信息并且使用该电子信息来提供有价值的用户服务。在一个方面，地面架构通过所提出的电子化飞行器信息处理解决方案的业务范围来定义，并且可以包括在这里被统称为业务域的飞行器制造商、航空公司、机场、维护、修理和大修(MRO)设施以及管理当局中的一个或多个。
存在针对为这些业务域服务的多种系统解决方案，但是它们没有被良好地互相整合或者与例如飞行器制造商的系统良好地整合。如这里所述，这些现有的系统解决方案可以提供电子化地面架构解决方案的基本部分，并且还可以提供关键接口点，以便向各种电子化地面架构整体解决方案贡献价值。这种地面架构解决方案提供用于将这些以前单机的或部分整合的系统解决方案整合的框架，从而允许贯穿各种业务域的协同操作能力。具体地，电子化地面架构解决方案定义用于将客户系统和/或供应商提供的系统互连的产品和服务调整选项，以便为航空公司运营和飞行器相关行业提供成本有效的信息收集和共享解决方案以及灵活性。
在一个实施例中，电子化地面架构出于可视化的目的而被组织为不同的等级。在最高的概念等级上，地面架构的操作视图概括该地面架构所支持的操作领域。在系统等级上，地面架构的系统视图提供逻辑业务功能支持。地面架构的技术视图提供物理地面技术替代品和实施示例以便实现业务功能支持。
上述业务域需要解决它们的业务的端到端范围的完整的信息共享解决方案，而不是小环境自动化。因此，电子化地面架构配置提供用于实际的和预测的客户需要的端到端解决方案。所理解的是，不同的客户在解决方案定义和限制(例如，是否通过产品和/或服务来提供解决方案)方面具有不同的需要。因此，电子化地面架构识别将有助于满足预期的多组客户需要的经调整的选项(option)和可重用的组件。
还理解的是，客户需要基于例如对于对企业和商业机会的外部威胁的感知以及企业的内部强弱而随着时间改变。为了满足这些改变的需要，电子化地面架构还提供可升级和可扩充的设计以允许客户受益于附加的电子化能力。这种设计可以在它们的使用期限内维持，使得可以灵敏地适应市场需求。因此，特定的电子化地面架构被配置为在全局环境中是健壮和可靠的，从而通过使采用成本最小来有效地容纳数目增大的客户，同时提供可升级和可扩充的设计。
在航空公司的环境中，电子化地面架构是一组设计解决方案，其跨越包括但不限于航空公司、机场、维护、修理和大修(MRO)公司、引擎原始设备制造商(OEM)、航空管理当局以及飞行器制造商的业务域。如在上面指出的，这些被统称为客户或业务域。电子化地面架构定义在利用由电子化系统提供的各种特性的同时跨越这些业务域的解决方案集合。
图1是关于机场地面操作的域和关系的图示。航空公司10向机场12提供要服务的航班(例如，需要包括维护、起飞和着陆的服务的飞机)，机场12提供用于航空公司10使用的设施。航空公司10运营飞机14，并且维护、修理和大修(MRO)公司16维护飞机14。管理当局18具有很多对于其它域的控制。图2是诸如飞行器制造商的解决方案提供商20所具有的、与图1所示的域的关系的图示。
地面架构技术视图提供代表电子化地面解决方案设计定义的最低等级(最详细)的细节等级。如这里所述，地面技术视图提供用于地面系统和地面整合的产品和服务部署选项以及特定的公共服务和定义。结果，电子化地面技术架构视图的基于地面的系统部分的一个实施例由功能组件和公共服务组成。
例如，功能组件包括电子化(供应商提供的)系统、供应商整合服务、防火墙、客户系统和客户整合。在这些组件内使用整合模式以使得电子化的供应商提供的系统能够彼此以及与客户系统协同操作。供应商提供的系统包括电子化系统(在供应商处作为服务或者在客户处作为产品)、防火墙(同样，在供应商处作为服务或者在客户处作为产品)、以及客户系统(例如，预定、添加燃料等)，它们是电子化解决方案的基本组件，如果它们发生故障，则该故障一定不能传播到电子化系统或服务。
可以以不同的方式组合这些整合模式以便满足不同的客户业务需要。例如，可以利用到客户整合的整合或者作为产品模型而在客户系统处实现客户应用到应用(“A2A”)整合组件。在这种产品模型实施例中，供应商电子化系统被部署在客户的位置处，被整合在一起，然后将该电子化系统与客户整合服务整合。然后，该客户整合服务将所述系统与供应商电子化整合功能整合。
在产品和服务模型实施例中，供应商电子化系统被部署在客户的位置处以及在供应商内部，并且被整合在一起。具体地，与客户整合服务整合的电子化系统以及在客户处和在供应商设施内部的供应商整合服务被整合以便允许电子化服务的供应商处和客户处的系统之间的协同操作能力。客户整合服务将所述系统与供应商电子化整合功能整合。
在实施例中，在客户的设施处，利用整合的系统，并且作为产品模型，供应商电子化系统被部署在客户的位置处，被整合在一起，例如，使用供应商的电子化整合功能而与每个客户系统整合。在产品和服务模型实施例中，供应商电子化系统被部署在客户的位置处以及部署在供应商的设施中，被整合在一起，例如，将电子化系统与供应商的整合服务整合。更具体地，将在客户处以及在诸如机身制造商的供应商内部的供应商的整合服务整合以便允许机身制造商处和他们的客户处的系统之间的协同操作能力。供应商整合服务还将客户系统与供应商电子化整合功能整合。
如同针对以下整合模式描述的那样，还可以提供企业对企业(“B2B”)整合组件。例如，对于具有简单整合的客户，作为服务模型，供应商电子化系统被安置(host)在供应商的设施处，与例如客户用户可通过因特网访问的客户系统整合在一起。客户系统通过共享信息来与电子化系统协同操作，并且通过使用共享文件结构而在操作上被分开，其中通过所述共享文件结构，每个系统可以异步地读取和写入数据文件。
对于具有简单消息管理器的客户，供应商电子化系统被安置在供应商的设施处，例如与客户用户可通过因特网访问的客户系统整合。客户系统通过共享信息来协同操作，并且通过使用在电子化系统和客户系统之间的转换最少的情况下存储和转发消息的整合设备(appliance)而在操作上被分开。
对于客户直接整合，作为服务模型，供应商电子化系统被安置在供应商处，与客户用户可通过因特网访问的客户系统整合。使用例如位于供应商的设施内的供应商整合服务来将这些客户系统与电子化系统整合。
对于具有整合后的服务的客户，作为服务模型，供应商电子化系统被安置在供应商处并与客户服务整合在一起，并且可由客户用户通过因特网来访问。例如，客户整合服务将所述系统与供应商电子化整合功能整合。更具体地，将供应商内的供应商整合功能与客户的整合功能整合，以允许供应商处的系统和客户处的系统之间的协同操作能力。
在最高的等级上，在图3中示出了完整的一组地面系统架构整合模式。具体参照图3，多个服务和产品通过因特网50(或专用IP网络)互连。它们包括供应商安置的服务52、包括被整合到客户整合中的产品和服务中的一个或两者的客户处的系统54、以及服务向客户系统的整合56。其它服务和产品可以包括消息管理器服务58、服务的客户直接整合60、其中客户已经使用整合服务的服务62、以及与现有的客户系统整合的客户处的产品或者产品和服务的安装64。
在图4中更详细地示出了图3的电子化地面技术视图组件和功能。图4包括关键(key)70，其图示了可用来为客户提供信息共享解决方案(整合模式)的各种组件(即，平台、防火墙、客户系统、供应商提供的电子化系统以及地面选项)。地面技术架构解决方案包括所有这些模式以便提供可能的最大的调整能力以满足客户选择。在这里详细描述每一个的功能。
对于电子化地面产品模型，当将电子化系统提供给客户并且部署在他们的内联网中时，它们是产品。这些产品可以由客户管理或者由供应商远程管理。客户处的供应商提供的电子化解决方案代表电子化系统产品的完整环境(包括硬件、操作系统、产品版本和替代选项)的规范。
典型地，电子化产品整合模式包括但不限于在客户处的具有到客户整合服务的整合的系统(例如，客户在适当位置具有的、私有的或从第三方提供的系统)、以及具有整合后的系统的客户处的系统。在图5中示出了地面技术视图的这种产品子集，图5是电子化地面产品技术视图100。如所示出的那样，有两个高等级电子化地面产品功能替代品，如图5所示。在示出为102的第一个高等级电子化地面产品功能替代品中，通过客户整合服务108而直接将电子化系统104和客户系统106互相整合。在示出为110的第二个高等级电子化地面产品功能替代品中，通过客户整合服务114整合客户系统112，并且通过供应商整合服务118整合供应商提供的系统116。还将客户整合服务114与供应商整合服务118整合。在任一替代品中，可以将电子化系统作为客户内联网120(或因特网)中的单机产品实现、整合的w/服务、和/或整合w/客户系统和产品提供给客户。
图6是单机产品整合模式150的图示。在各种实施例中，有两个高等级电子化单机替代品。第一个替代功能是不需要将一个或多个客户产品和服务互相整合或者与供应商提供的系统和整合服务整合的情况。在示出为152的这一情况中，至少对于客户业务系统156，不使用供应商整合服务154。使用供应商整合服务154来整合供应商提供的系统158。在第二替代功能中，存在多个要互相整合的产品。在被示出为160的这一情况中，供应商整合服务162不与通过客户整合服务166整合的非电子化客户系统164整合。使用供应商整合服务162来整合供应商提供的系统168。
在图7中示出了与服务整合模式200整合的产品，图7是与服务整合的电子化地面产品的图示。有三个与服务替代品整合的高等级电子化地面产品，其中，多个电子化产品需要互相整合，其中至少一个在供应商处，至少一个在客户处。被示出为202的第一替代功能是供应商整合服务整合多个供应商提供的系统203而没有非电子化客户系统的情况。在这里被称为“我的机群”服务的附加服务204被示出为位于功能202的供应商整合服务中。第二替代品206是将至少一个电子化系统208与非电子化客户系统210整合的情况。使用供应商整合服务212来整合供应商系统208，并且将非电子化(客户)系统210与客户的整合后的服务214整合。客户整合服务和供应商整合服务能够在需要时共享信息。第三替代品220是需要通过客户代理、例如供应商整合服务226将至少一个供应商提供的电子化系统222与非电子化客户系统224整合的情况。
与系统(客户和供应商二者)整合的产品而不是服务使用与图7所示相同的整合模式。
对于电子化地面服务选择，可以使得能够从电子化系统的供应商安置的位置使用所述电子化系统，此外，可以将电子化系统与客户电子化产品以及客户业务COTS和其它定制开发的系统整合。可以将因特网或其它通信设备(communication)用于客户对电子化系统的访问以及供应商和客户系统之间的整合。电子化地面服务整合模式包括但不限于整合的供应商安置的系统、具有简单整合的客户、具有简单消息管理器的客户、客户直接整合、以及具有整合服务的客户。
在图8中示出地面技术视图的服务子集，图8是电子化服务技术视图250。在一个示例功能中，供应商安置的系统252通过整合服务254而使用因特网256(或专用IP网络)来与其它网络系统通信。还包括合并了存放箱(dropbox)258的客户功能257、合并了用于多个客户系统的硬件整合设备256的客户功能260、包括直接整合的客户系统272的客户功能270、以及其中使用客户整合服务278整合客户系统276的客户功能274。
在图9中被表示为供应商安置的系统和整合模式300的单机服务涉及客户用户经由供应商整合服务304而使用因特网306和其它支持因特网协议的网络来访问电子化系统302，并且具有穿过供应商防火墙310的访问权。由图9的配置提供的功能有时候可以被称为电子化地面单机服务视图。
与产品整合模式整合的服务和与服务整合模式整合的产品(图7，与服务整合的电子化地面产品)相同，并且不对其进行进一步说明。类似地，如上所述，在地面技术视图中，与系统整合模式整合的服务代表服务整合选项的完整集合，其与图8所示的电子化服务技术视图相同。
如目前想到的那样，有四个与系统替代品整合的高等级电子化服务。第一个替代品是不需要互相整合的一个或多个电子化服务。在此情况中，不需要供应商整合服务。这由不具有供应商整合服务的供应商安置的系统和整合模式来描述。
另一个替代品是多个电子化服务需要互相整合的情况。在此情况中，供应商整合服务不需要与非电子化客户系统整合。这一替代品由供应商安置的系统和整合模式来描述。
第三个替代品是有一个或多个需要直接与非电子化客户系统整合的电子化服务的情况。这由客户直接整合模式来描述，并且不存在数据转换、排队等。
第四个替代品是一个或多个服务需要间接地与非电子化客户系统整合的情况。例如，如果客户指定的间接整合使用数据存放箱，则这由客户处的简单整合模式来描述。同样，不提供数据转换或排队。然而，如果客户指定的间接整合要求客户尚不具有的整合服务，则可以使用供应商部署的硬件整合设备，如客户处的简单消息管理器整合模式所描述的那样，其提供对于数据转换和排队的有限支持。此外，如果客户指定的间接整合要求使用现有的客户整合服务，则这由“客户w/代理”  整合模式来描述，该模式提供对于数据转换、排队等的复杂支持。
全部上述技术视图中的电子化系统由一个或多个如下所述的技术公共服务组成。公共服务提供使系统共享公共数据、功能和商业过程以便产生整合的端到端客户解决方案的基础。公共服务的示例包括但不限于数据服务(数据库、备份和存档)以及容器服务(网络服务器：在网站处运行的、响应于来自远程浏览器的HTTP请求而发送出网页的软件服务器进程；应用服务器：支持网络服务器并且提供基于网络的商业逻辑和网络服务器之间的联系的软件服务器；以及Java虚拟机(JVM)：供二进制代码执行而与操作系统无关的标准化的一致的运行时间环境)。
从系统的观点，公共的基于地面的电子化服务通过仅产生一次业务能力、以指定的经调整的可变性来设计、并且支持在所有受到影响的电子化领域上的改进，来提供高效可靠和可调整的端到端解决方案。公共的基于任务的接口用不同的观感(look-and-feel)替代现有系统接口以便向用户提供单一的解决方案。公共数据访问服务可以将多个电子化系统对数据的使用标准化。通过花费更多的时间和资源来维持公共服务，它们成为电子化解决方案的最可靠的组件(正如在制造工程中那样，在制造工程中，工具加工设计是比用机器制造零件更精确的数量级)。
公共服务提供用于使系统共享公共数据、功能和商业过程以便产生整合的端到端客户解决方案的基础。这些服务是：应用接口(其为到一个或多个电子化系统以及一个或多个电子化系统中的应用的用户接口)；本地服务(其为仅由一个电子化系统使用的业务能力)；系统范围的服务(其为多个电子化系统使用的业务能力或者要使用的候选者)；低等级服务(例如操作系统)；以及网络和计算基础结构服务(其为物理网络设备(例如路由器)和服务(例如互连))。
其它公共服务包括安全服务，其中，例如，供应商访问管理为供应商所开发的基于网络的应用提供一定等级的信息担保，所述应用针对在诸如第三方安置设施、航空公司或供应商的供应商网络外部的域内的部署。在这里描述的各个实施例将基于地面的系统松散地耦合到统一管理的鉴别、授权和审核机制中。此外，所述系统便利了身份和访问管理，并且允许域内的系统间单点登录以及跨域联合鉴别。另一个安全服务是数字签名服务。数字签名服务是用于统一管理不可否认性和数据完整性功能的途径。该服务具有签名产生和验证能力。
加密安全服务是用于统一管理保密性功能的途径。它提供了用于加密和解密某些类型的数据的方法。认证当局安全服务是在诸如航空公司和供应商的各种域内发放和管理信任证书以便与供应商产品和系统一起使用的标准手段。这种证书的示例是x.509证书。
其它公共服务包括资源管理服务和软件许可证管理，资源管理服务进一步包括资源管理。对于资源管理，安装在航空公司处、在客户处的平台上的产品将具有公共的一组管理、监控和支持所述系统和底层组件的远程能力。这一能力将能够在安装时配置以便支持客户的变化的网络安全策略和实现。
软件许可证管理是用于管理、跟踪和审核软件许可证的商业过程、商业协议和合同以及技术的组合，所述软件许可证与作为销售给客户或作为供应商安置的服务部署的供应商产品解决方案的一部分而开发、嵌入和再次销售的软件相关联。这包括诸如一般许可证管理、客户许可证协议、单独的许可证数据等的功能，所述一般许可证管理包括围绕内含协议或转售者协议的特定细节的捕捉和存储。此外，其提供跟踪哪个客户具有什么软件以及跨越客户群而主动管理软件许可证更新的能力。这减少了许可过度以及许可不足，并且提供收回未使用的许可证并淘汰过时合同的能力。它便利了与对于第三方软件提供商的内含义务和转售者义务相关联的管理和报告。
另一个公共服务包括提取/变换/加载(ETL)服务，其示例是数据传递。数据传递服务定义和提供用于通过计划性的和交互的接口而向和从供应商、其客户或供应商发送商业运营数据文件的公共服务。同步是另一个ETL服务，其允许数据的多个副本存在并且被保持最新。所述副本之一可以是其它副本与之同步的主副本。可以将该主副本重新分配为数据的另一个副本。此外，多于一个的副本可以是主副本，在该情况中，将所有副本(包括主副本)与所有主副本同步。
机群配置服务定义客户的机群或在所有产品之间共享的集群的MRO的视图。这是定义谁拥有和运营每架飞机的官方来源。软件加载服务是用于在制造期间以及在服务中将软件加载到飞机的公共配置管理机制。通知服务是使系统通过诸如电子邮件、无线设备、寻呼机等的各种方法向人们提供警告的公共服务。通知服务管理被通知的个人希望的设备类型和通知，并且处理通知的接受以及在需要时处理通知的逐步升级。
链接服务向系统外部的文档和网页提供松散耦合的链接资源(URL)，其允许为了不同的客户而将不同的产品安装到系统中并且支持高可用性要求。门户服务向电子化系统提供用于在电子化系统的前端产生一定等级的整合的公共的一组准则和服务。这些门户服务包括客户端服务、过程工作流、以及用户接口服务。
客户端服务通过定义COTS浏览器和管理系统呈现的插件来提供终端用户访问的一定等级的一致性。过程工作流通过向用户提供对跨越多个系统的过程进行导航的能力来支持复杂的商业过程流。用户接口服务定义系统为了它们的实现而要遵循的标准和准则。
可以排列和进一步分解上述所有服务，以便产生与图10所示的组织相似的组织，图10所示的组织是电子化地面公共服务组织350的示例。技术公共整合服务是将供应商电子化系统互相连接以及连接到客户系统的焦点。整合服务提供使系统在互相不了解的情况下交换数据和交易的能力。整合服务使得能够将系统和服务松散地互相耦合，并且按照用于不同客户需求的不同实现所要求的那样允许用第三方和客户系统代替供应商系统。
信息工作流被包含在整合服务层中。它定义和提供用于在系统正在交换数据时管理和协调数据和消息交互的公共服务。整合服务用来与功能性服务交互，并且通过对系统和服务的位置进行抽象来支持它们的高度可用性。抽象允许动态地移动系统和服务以便支持维护或无计划事件。
如所想到的那样，整合服务的组件包括但不限于整合代理、服务注册表、B2B网关、整合服务API、简单消息管理器和存放箱服务器。在各种实施例中，整合代理提供用于应用到应用整合的协议、消息转换和信息工作流，服务注册表包含可通过整合代理获得的服务--功能或系统--的列表。实际上，它是服务的电话簿。在实施例中，B2B网关是用于跨越防火墙的系统对系统交互的整合服务的功能。
整合服务API向系统提供一致的抽象层，从而允许整合代理在不同的客户配置中成为任选的。这允许系统在任一配置中使用相同的代码群来调用公共功能服务。简单消息管理器是提供系统和/或企业之间的简单异步消息整合的能力。它还提供消息转换和协议转换。存放箱服务是在企业对企业环境中提供批文件传递互换的能力。也可以在系统之间使用它。
图11是采用分层表示的提供用于指定解决方案架构的公共语言的战略架构参考模型(SARM)400的图示。SARM是供应商资助的对于开发充当较大网络中的节点的平台产品的准则的一个实施例。SARM允许经由标准商业基础(IP、HTTP、网络浏览、电子邮件等)进行的整合，并且允许利用商业技术进行的可协同操作的通信。
在图12和13中提供了用于提供代表性电子化系统发展的架构实施例的示例映射。还标识了技术和产品选择。意图是提供允许商业单元设计师从更物质化的实施观点来理解架构变化的一组架构和映射。例如，可以将地面架构组件配置为用于支持对于安置、性能和商业模型的不同客户需求的一组实现。
航空公司、机场、管理当局和MRO的域中的一个或多个可受益于这里描述的电子化整合机会。作为示例，这些域可以包括但不限于航空公司航班操作、机场操作、MRO、以及其它飞机维护操作。对于航空公司航班操作，飞行器调度、长途飞行训练、整合的航空公司操作中心、整合的航空公司航空站操作中心、以及维护操作都是通过这里描述的电子化过程改善的与飞行器有关的操作。
整合的航空公司操作中心包括例如燃料跟踪、机组调度、消息下载、飞行规划、航班跟踪、维护操作协调、航空站操作协调、情况了解、破坏防止和恢复、以及天气。整合的航空公司航空站操作中心包括例如情况了解、报到、登机门解决方案、行李解决方案、设备解决方案、员工解决方案、破坏防止和恢复。航空公司-维护操作包括例如航线、基地、组件维护规划和执行、整合材料管理、日志(电子)、情况了解、飞机健康管理、维护规划工具、飞机设计信息、破坏防止和恢复、以及维护设施建模和仿真。
对于包括例如航班、乘客和设施建模与仿真、无线基础设施设计和部署的机场操作，使用电子化架构的整合的机场操作中心为承租人和旅行者提供提高的效率。这种基础设施包括用于提供情况了解、破坏防止和恢复、以及航班追踪的能力。此外，与所有到达航班有关的信息以及天气是通过这种架构进行的信息共享也为用户提供提高的效率的功能。
图12是供应商安置的基于地面的架构450的一个实施例的框图。在架构450中，示出了提供给航空公司的飞机维护外购服务。在架构450中，依赖于MRO的全局网络以便依赖于供应商安置的公共系统来执行维护。
图13是其中系统位于客户位置处的产品电子化架构部署550的一个实施例的框图。在部署550中，系统位于客户(例如航空公司)的位置处，被整合在一起，并且还通过航空公司的整合代理而与航空公司的系统整合。
如上所述，地面架构包括用于支持和安置供应商电子化系统、提供用于整合那些系统的结构和框架、以及将该电子化系统与电子化地面业务域上的其它系统连接的基础设施。此外，电子化地面架构提供一组IT基础设施以及公共的可重用的服务以使得能够针对不同的客户需求配置不同的选项。底层的IT架构使得所述系统能够在这种环境中提供成本有效的解决方案和灵活性(可调整性)。
在基于地面的系统整合服务实施例中，通过允许网络、内联网或因特网上的数据共享的松散耦合来实现独立系统的整合。系统之间的这一耦合提供允许系统共享信息并且位于网络上、相同公司或不同公司内的不同网络上、或者甚至在飞机上的任何地方的能力。
对于运行时间功能，系统适配器规定将内部数据格式化为标准消息定义以便公布、并且规定由系统来整理所接收的消息。消息代理从所有系统接收所有公布的消息，其可以变换消息内的内部数据，保持对于每个消息的订阅列表、并且将原始的所公布的消息重新发送给每个订户。企业对企业(B2B)网关提供通常涉及防火墙导航的对于其它公司的网络的导航。商业过程工程(engineering)工作流引擎强制规定(enforce)哪些消息的商业规则是其它消息的先决条件，并且可以充当从独立的系统收集信息以执行单个系统不能执行的业务任务的工作流管理器。
对于操作功能，当中间件正在运行时，必须对其进行监视和管理以便确保高效地执行重要数据和过程。系统监视器提供对于系统、消息传输、B2B网关、以及整合代理的情况了解，包括状态、量、和所保证的传输。如果使用工作流引擎功能，则商业过程监视器提供对工作流引擎的情况了解，包括例外处理、过程量和其它方面。
在开发功能中，消息数据变换功能表示用于指定特定消息定义中的数据所需的改变的手段。这些改变可以包括改变消息内的信息、利用来自原始消息的数据来产生新消息、或者二者的组合。变换对于消息定义的所有实例可以是一般性的，或者可以是订户特有的。消息安排功能指定用于使消息有意义的所需的一个或多个先决消息、以及当没有满足先决条件时要采取的动作。商业过程工程建模器功能用来指定与系统的消息交互以及允许端到端商业场景/过程所需的处理。上述地面架构系统视图说明了操作组件，示出了它们的连接、域和关系。
尽管已经根据各种特定实施例描述了本发明，但是本领域技术人员将认识到可以以处于权利要求的精神和范围内的修改来实践本发明。