NextGen的基础设施项目

一、概述

为NWP分类1的主要目标之一是在可能的情况下配合和/或利用新兴NextGen的基础设施。本节提供了三个关键基础设施的概述方案，FTI, SWIM, 和NNEW，并确定了地区

潜在影响的数值预报体系结构。如在第1.2.2节所述，FTI的，SWIM，NNEW提供包括物理网络，一般的信息管理，以及天气的具体信息基础设施堆栈的NWP管理层次。这些讨论从最低层开始，不断堆栈中。 二、 FAA的电信基础设施 2.1.功能

FTI的提供互联网协议（IP）为基础的网络通信，包括多余的和容错的网络主干（图3）。正如图中所示，主干于航线交通管制中心（航管）和终端管制中心（TRACONS）目前建立顶部Sprint和AT＆T租用线路连接不同的用户。这些用户的位置在节点被称为的身影，是FTI的使用全网状拓扑（黄色）连接或连接在至少有两个节点全网状（以绿色显示。设计意图是来支持监测数据和重要的气象数据的可靠性要求较高的水平。

FTI的连接提供一个固定的带宽保证，带宽反映各方面的要求。在网络上的任何两点之间的终端到终端的延迟范围在250毫秒，主要由监测社会的需求驱动的要求。FTI的是目前在过渡到光纤主干网，预计将增加在核心网络的可用带宽至少一个量级的过程。最大月底至年底，在网络上的任何两点之间的数据包延迟，预计显着降低（<100毫秒）。

2.2 差距

FTI的提供高可靠性的连接，但目前不提供有区别的消息优先于这些连接通信流手段。在物理网络层面，目前还没有手段区分，例如，高优先级的风切变，从低优先级的（大）天气反射数据消息流量。这是有问题的，因为流量可以从低优先级用户边缘路由器队列溢出和介绍不可接受的延迟，更高优先级的流量。如果是气象数据提供气象数据消费者，流量分类和优先级之间使用一个单一的FTI的连接必须处理仅在应用程序级别。

这是一个最理想的解决方案，软件的复杂性和网络带宽的使用效率方面。另一种方法，单独的链接使用不同的通信类是可能的，但不是一个好的长期从成本角度考虑的解决方案。

FTI的计划目前正在评估的使核心FTI的网络流量优先级的可能性。在一定程度上是FTI的用户社区，特别是大批量的气象数据的社区，以帮助推动需求。进入具体要求及可能的解决方案，跨越不仅FTI的层，而且SWIM和NNEW层以及调查研究，目前正在进行中的NNEW计划的背景下，

第二个潜在的差距存在于FTI的和其他外部网络之间的边界。巩固政府组织和外部网络之间的连接数量可管理性和安全性的原因是政府的政策规定。总体目标是，以减少互连节点的数量少于70。美国联邦航空局目前已被分配这些网络节点，FTI的计划是在选定的地点设立网关的过程。这些网关支持的吞吐量初步测量结果表明，相对较低的整体吞吐量传递大网格天气数据所需要的带宽相比，在及时设置。FTI的和SWIM项目目前正在研究这个问题。再次，它是由天气提供者和消费者，以帮助推动整体带宽要求。 2.3. FTI对NWP体系结构的影响

可用性的成本效益，可靠，高带宽，在NAS和NAS与政府和商业供应商之间的通信是一个重要的长期数值预报系统架构的驱动程序。昂贵的和/或低可靠性的通信链路驱动处理架构更分布式的模式，在处理有关特定地区的利益，在当地进行。由于通信成本的降低，其可靠性的增加，更集中的模式，成为吸引力维护，可扩展性和数据融合的机会的原因。

天气系统的延迟预算通常以秒为单位，而不是毫秒。例如，一个更严格的延迟要求的气象数据，是风切变数据（ITWS，TDWR，ASR的天气系统处理器（WSP））目前指定的检测时间，10秒的顺序要求时间显示控制器，并传达给驾驶员。这是FTI的提供单一链路上的延迟边界内。ASR-9天气通道数据存在类似的情况 - 有一个5秒的窗口，在其中传输控制器将显示30秒更新后一代的最终产品。再次，这是不是特别苛刻的要求，为现代通信链路。

今天是在一个单一的通信线路，FTI的旅行，因为它存在一个单一的产品能够满足天气交通延迟要求。当被认为是一个单一的连接上的可用带宽竞争的多种产品，然而，缺乏交通FTI的分类成为一个集中现有能力的障碍。如果不解决这个缺点在1段时间框架，数值预报必须继续支持分布式体系结构，与本地处理高优先级，低延迟的产品，例如风切变。当地加工约束如果FTI的供应商在NWP的段2的时间框架中实现流量分类，将在很大程度上消失了，甚至高优先级的天气数据的集中处理选项开放。

FTI的网关吞吐量建筑的影响方面，我们认为这是一个相对较小的问题，在NWP的1分类时间框架应解决。组织间的数据传输近似的要求，但是，需要指定要在相对短期内使FTI的网关是适当大小。 3. 全系统信息管理 3.1. 功能

在下一节中描述的游泳基础设施和n新的基础设施都围绕面向服务的架构（SOA）的概念为基础。长期建筑本身一样，SOA是一个广义的术语，往往要在多个上下文中使用。从下一代的角度来看，也许最重要的单一建筑约束SOA的实施是该功能模块化和组合的，特别是在广域网（WAN）规模。从数值预报的角度来看，这种建筑方法本身以及分布式或集中式处理解决方案，以及两个配套组合。

SWIM是为了提供共同的标准，如通讯，监控，NextGen的参与者和安全的服务。SWIM分类1中，此功能主要是通过商业支持的开源保险丝Progress软件公司的软件套件提供，提供的附加功能，而且，SWIM，实施方案（SIPS）之间共享。进展FUSE软

件套件是基于一套从Apache基金会的开源产品。下面列出了一些主要产品。

保险丝的Message Broker。此产品的基础上的Apache 的活动MQ的消息项目，提供消息代理骨干符合Java消息服务（JMS）规范。它提供了一些内置功能，实现时间敏感的和可靠的消息传输。它还提供了基于Java管理扩展（JMX）在较低的水平来支持信息流量的监测监控挂钩。

保险丝调解路由器。基于Apache Camel的项目，该产品包括一个可扩展的核心消息传递框架和一套可以在这一框架内，实施企业集成模式的各种预建组件。在数值天气预报的背景下，该产品是为实现容错的和负载均衡的数据传播解决方案，以及提供消息的抽象层，不仅支持的JMS有用的，但其他的传输协议，如超文本传输协议（HTTP）和可扩展消息和出席协议（XMPP）。

保险丝的企业服务总线（ESB的保险丝）。基于Apache的ServiceMix的，本产品提供的服务实现基于Java的运行时环境。保险丝ESB支持服务部署一个模块化的，动态的方法，基于开放系统网关互连规范（OSGi的）。这项技术在理论上是支持热插拔的软件升级能力，虽然在多大程度上是实际的和/或必要的尚未确定。保险丝ESB还支持集群负载均衡的目的，功能为NWP有可能成为重要的，如果是使用较为集中的拓扑部署多个实例。

保险丝总部。基于Hyperic公司总部产品，该产品提供了一个监测基础设施能够监测多种开箱的制度条件。它也可扩展，轻松容纳更多的监测投入，遵守与支持监控协议（例如，JMX的）

从一个互操作性的角度来看，重要的是要注意，这些产品与SOA标准相一致，如简单对象访问协议（SOAP），Web服务描述语言（WSDL），可扩展标记语言（XML）和HTTP。美国联邦航空局在使用这些普通产品的鼓励，而不是规定，以鼓励使用一个共同的代码基础。在NWP的实施，包括其他组织的情况下，互操作性不应该受到影响，如果其他SOAP产品套件使用。换句话说，标准是关键，而不是产品的符合性。 3.2差距

JMS标准，虽然在SOA应用广泛使用，不支持“上线”的标准 - 这是标准化的应用程序编程接口（API）的水平只。这个问题可能会在未来得到解决，如果用户社区的要求上线的标准，但在此期间，适配器将需要使用，如果使用JMS实现混合。

虽然FUSE Message Broker的软件提供了一个支持流分类的水平，这是尚未清楚，如果实施，将是足够强大，以满足数值预报的消息延迟要求。这是一个潜在的差距，需要后续评估确认，将流量分类信息传播到物理网络层的产品的能力。

保险丝产品线相关的监测技术，有针对性的对SOA基础设施，而不是大规模的加工基础设施。相关的监测技术与加工集群（例如，神经节），将需要桥保险丝监测技术，如果游泳是有效监管的NWP处理组件。游到监视NWP的资源，如果没有计划，那么这是不是一个问题。

3.3SWIM对NWP体系结构的影响

SWIM是基于SOA的概念，而这又反过来影响NWP的架构。SOA鼓励组合的设计，允许在分布式和集中式元件分割方面的灵活性。对于数值预报，居住在美国联邦航空局域的一部分，SWIM的保险丝产品线的选择，当然鼓励在接口边界的基于Java的实现。部分驻留在其他组织的数值预报是自由地使用他们所选择的执行，只要执行是符合通用的SOA标准。