基于区块链的飞行对象信息共享能力

Posted 2021-04-26 战略前沿技术

微信：tech99999 邮箱：[e-mail]

来源：防务快讯

简介：本文介绍了区块链技术用于共享飞行信息的概念和原型。为所有利益相关方提供访问完整、一致和最新的飞行信息的权限，这有助于提高航空运行的效率。目前飞行信息交换方法有限，仍无法为所有利益相关方提供“飞行对象”（flight object）概念的完整解决方案。一个完整的解决方案需要集中管理存储数据（不适合国际环境）或分布式账本。分布式账本是区块链技术的核心，促使区块链技术成为实现飞行对象概念的理想之选。作者已经证明，通过演示基于Tendermint的原型（开源的区块链），区块链技术可以提供完整的飞行对象解决方案。本文所演示的解决方案还具有其他优势，例如可靠的完整性以及基于任务的更新权限。原型性能表明，区块链技术将提供足够的速度和能力来支持全球航空运行，从而优化飞行规划协商、基于航迹的运行和国际流量管理未来概念。本文在结论部分探讨了将飞行对象共享能力作为实际国际航空解决方案基础的必要措施。

1、引言

飞行对象为各利益相关方提供完整、一致和最新的飞行信息的这一想法早已提出。2000年，MITRE的一篇论文将飞行对象定义为“单次飞行的通用信息元素集合，并且可以通过电子方式提供给国家空域系统（NAS）用户和空中交通管理（ATM）服务提供商使用。”而且，2003年欧洲航空安全组织（EUROCONTROL，以下简称欧控）发布的论文中也提到了这一概念：“对于已规划、当前正在运行或已经发生的飞行，其飞行对象包含该飞行的最新已确认信息”。本文介绍了向空中交通管理服务提供商（ASP）、飞机运行商、防空部队和机场当局等利益相关方提供可互操作的飞行对象，作为一种“减少工作量、提高资源利用效率和避免延迟”的手段。到目前为止，飞行对象仍然是国际民用航空组织（ICAO）全球空中交通管理概念的重要组成部分。尽管飞行对象概念具有重要意义，但却从未实现过。虽然在特定的空中交通管理服务提供商系统中实现了飞行对象概念，但都是其他空中交通管理服务提供商或空域用户无法访问的内部解决方案。尽管国际空中交通管理服务提供商和空域用户之间存在飞行信息数字化交换解决方案，但是交换的信息有限，并且这些方法不能确保所有参与者都可以访问完整、一致且最新的信息。本文的目的是展示如何通过应用区块链技术完全实现飞行对象的概念。

2、问题陈述

2.1 传统飞行信息共享

多年来，飞行信息生命周期一直保持相对不变。当前的流程主要由国际飞行运行商在航空固定电信网络或空中交通服务消息处理系统（AMHS）上发送消息来“提交”飞行计划。消息包括已提交的飞行计划（FPL）的修改、延迟和取消等。这些消息用大写字母、数字和标点符号编码，反映了其电传打字的传统。图1是一个已提交飞行计划的示例。在这一示例中可以看到飞行呼号（UAL43）、飞机类型（B763表示这是一架波音767-300飞机），并提供有关飞行规则、飞机装备等更多详细信息的字符。再往下看，可以了解该飞行计划在00:30从丹佛（KDEN）出发，巡航速度为459节（N0459），高度为32,000英尺（F320），遵循从机场直飞（DCT）到DBL航路点的航线。

图1 传统飞行计划（FPL）示例

每个空中交通管理服务提供商通过接收或传输飞行计划修改信息来管制和管理飞行信息的各个要素。在某些情况下，信息通过语音通信传输或者需要人工解释。在其他情况下，信息在空中交通服务中进行点对点传输。由于空中交通服务消息格式受到限制，只能以电子方式传输有限的信息。例如，在传统飞行计划消息中，没有办法提供完整的航迹，也没有办法传达沿航线各点的约束条件（例如，海拔限值范围、拥堵的可能性或时间约束条件）。另一个限制是，空中交通服务消息仅发送给特定的收件人，而非发送给所有利益相关方。每个系统都只能访问自身信息或由另一个系统指定发送过来的信息。仅在发生特定事件时，飞行信息才会传达给邻近飞行。所有这些限制的最终导致无法保证所有利益相关方都拥有完整、一致和最新的飞行信息。

国际民用航空组织发布的《全球空中交通管理运行概念》将问题概括为“在空中交通管理、机场运行商和飞机运行商之间进行实时信息交换的设施有限，导致对实时事件和用户运行需求变化的响应不够理想。”国际民用航空组织针对基于航迹运行的计划提供了更多关于这些限制的详细信息，例如“缺乏信息共享”、“参与者和自动化系统之间的信息差异”以及“使用公共信息无法保持单一、一致的航迹”。国际民用航空组织提出：全球空中交通管理运行概念对数据的要求超出了现有飞行规划规定所能支持的范围，包括系统的信息共享、提供早期规划数据、航迹管理、协同决策（CDM）以及需要机器可读性和信息明确性的高度自动化支持。

2.2 目前正在进行的改进工作

克服全球空中交通管理系统的局限性是国际航空界的共同目标。国际民用航空组织关于空中交通管理系统要求的手册指出：“通过动态协商已达成4D航迹协议，空中交通管理系统不会遇到“瓶颈”。随着4D航迹与自动化工具相结合，潜在的空中交通管理系统瓶颈将越来越容易预测。”

为改善国际飞行信息共享能力，使4D航迹可用，可采取的初始措施包括：协作环境下的飞行和流量信息（FF-ICE）和飞行信息交换模型（FIXM）。FF-ICE使用FIXM中所包含信息，包括一系列国际飞行管理协作概念，FIXM是不断发展的飞行信息结构化模型。与传统的空中交通服务消息相比，飞行信息交换模型提供了更丰富、更完整的结构来展示飞行信息。在FIXM中，“飞行”是一个复杂的数据结构，根据其他数据结构构建，包括飞机起飞、到达、规划航线等。这些结构的每一个结构反过来又是由其他结构构成的复杂数据结构。FIXM的飞行结构也可能包含航迹信息。FIXM航迹十分复杂，包含爬升和下降剖面图和时刻表，以及多达2000个元素的数组，这些元素表示飞机随时间变化的状态预测以及在航线上的位置。航迹结构还适用于航线上任何点的约束条件。这种表示复杂的结构化飞行信息的能力使空域用户和空中交通管理服务提供商可以交换FF-ICE概念所需的其他信息。对初始FF-ICE概念进行演示，使用基于FIXM的消息来交换飞行信息，而该消息以根据可扩展标记语言（XML）进行格式化。

尽管FIXM信息内容对传统空中交通服务消息格式进行了重大改进，但如何在不同系统之间共享这些内容仍然是个问题。最初，FF-ICE概念由空中交通管理服务提供商的自动化系统实现，将基于FIXM的消息分别发送给其他自动化系统，就像当前以点对点方式发送空中交通服务消息一样。将来，FF-ICE可能会扩展为使用全球全系统信息管理（SWIM）概念公开/订阅范例。这将允许空中交通管理服务提供商通过发布适当的FIXM消息通知所有受影响的利益相关方飞行信息更改，这些消息将由全系统信息管理分发给所有订阅者。无论是使用点对点消息还是使用公开/订阅消息，航空标准机构都需要制定规则，以确定哪些机构应将哪些消息发送给哪些其他机构以及何时发送这些消息。当前，国际民用航空组织第4444号文件定义了为国际飞行发送空中交通服务消息的规则。这些规则相对简单，但是随着FF-ICE逐渐引入基于航迹的运行等概念，信息交换将变得更加动态化和复杂，消息传输规则需要重新审查，并且可能需要修订或扩展。这些规则不仅必须适应预期的场景，而且还必须处理所有可能的“错误路径”，解决消息传输失败、系统崩溃和重新启动以及无法预测甚至恶意破坏等方式导致系统异常等问题。当尝试处理不断变化的动态和复杂场景时，确保规则可以正确处理所有可能出错的事项将变得越来越困难。

基于空中交通服务的消息传递方法（传统或基于FIXM的方法）的另一个更为严重的问题是软件复杂性。如图2左侧所示，通过这种方法，每个空中交通管理应用程序都使用由消息传递服务提供商定义的消息传递应用程序接口（API）来发送和接收空中交通服务或FIXM消息。空中交通管理应用程序必须包含业务逻辑（例如，航线或航迹协商和管理），该业务逻辑会对飞行信息进行更改，并对其他系统所进行的更改做出反应。通过消息传递方法，空中交通管理应用程序还包含在需要时使用消息传递应用程序接口生成消息的逻辑。虽然消息传输的基本细节隐藏在应用程序接口中，但是用于确定发送哪些消息以及何时发送消息的信息交换逻辑仍与业务逻辑处于同一应用程序中。这增加了应用程序的复杂性和实施新的运行概念的难度，但不影响消息传输逻辑。

图2 消息传递方法与飞行对象方法对比

通过定义飞行对象应用程序接口，明确将业务逻辑与信息交换逻辑分开，可以避免消息传递方法的复杂性。在图2的右侧说明了这种方法。通过这种方法，空中交通管理应用程序访问一个定义明确的应用程序接口，该接口允许读取和写入飞行对象，并且信息交换逻辑封装在该应用程序接口中。问题是要找到一种适合航空的方式来实现这种飞行对象应用程序接口方法。

2.3分布式一致性

为了解决上文提出的问题，需要“提供和接收飞行与流量（FF）信息的全球一致机制和接口”。这一机制应将“业务逻辑”应用软件的飞行规划和流量管理等性能区分，确保所有参与者拥有包含完整一致信息的软件。

可以考虑通过提供一个包含完整飞行信息集的集中式数据库来解决该问题，所有参与者都可以远程访问该数据库，以便更新和读取该数据库数据，如图3所示。但是，这在国际环境下并不是一个可行的解决方案，因为需要管制和操作数据库的中央设备，需要拥有技术能力来管理对国际航空有效运行至关重要的运行系统。中央设备还需要资金，并且需要得到全球空中交通管理服务提供商和空域用户的信任和接受。无论是私人还是政府的服务提供商，国际航空界都不可能选择和资助单一服务提供商在全球范围内担当这一角色。此外，数据库管理员能够管制国际飞行信息内容，并管理哪些机构可以访问这些信息。由于政治、经济和技术方面的严峻挑战，本文认为集中式飞行对象数据库对于国际航空不是可行或理想的解决方案。

图3 飞行对象数据库解决方案

本文认为，空中交通管理服务提供商、空域用户和其他国际航空利益相关方可以采用一种自主运行的解决方案。本文寻求一种解决方案，使每个参与者都可以管制自己的飞行对象存储实例，并采用某种国际标准化的方式来保持所有实例之间的一致性，如图4所示。这样的解决方案将允许每个利益相关方操作自身系统来维护其飞行对象实例，或者选择一个服务提供商来代表他们执行这一功能。在这一解决方案中，利益相关方不需要就飞行对象中央数据库运行商达成协议并对其赋予信任。然后，问题就变为：如果允许每个参与者管制自己的飞行对象实例，那么如何确保这些实例保持一致？

保持在整个网络中分布的一组独立实例之间的信息一致性是在计算机科学中经过充分研究的问题，被称为“分布式一致性”。“分布式一致性协议”算法可以解决形式化属性证明的分布式一致性问题。分布式一致性协议解决方案为各方提供了自己的共享信息副本，并通过连接实例的通信网络协议来保持一致性。如果可以将分布式一致性协议应用于飞行对象问题，则可以创建图4所示的理想体系结构，并且可以通过保持应用程序业务逻辑（体现在自动化系统中）和信息共享逻辑（体现在分布式一致性协议中）之间的明确区分来实现这一目的。下一部分将介绍如何使用区块链技术来实现这一目标。

图4 分布式一致性协议飞行对象解决方案

3、基于区块链技术的飞行对象解决方案

3.1 什么是区块链？

对区块链概念的完整解释不属于本文的范畴，本文仅向不熟悉这项技术的读者提供简短的介绍。区块链是确保分发信息的完整性的技术。区块链是指将信息划分成多个区块，每个区块都包含前一个区块的安全哈希。“哈希（hash）”将这些区块链接到一条链中，以便可以轻松检测或拒绝对任何区块的任何更改。区块链解决方案的另一个基本要素是分布式一致性协议，使参与者就区块的内容达成协议。区块链中包含的信息称为“分布式账本”。在原始的区块链应用程序比特币中，数字账本跟踪虚拟“硬币”从一个所有者到另一个所有者的转移。随着比特币获得成功，基于比特币使用的区块链技术的变更版本、其他数字货币和应用程序也被引入。

3.2 为何将区块链用于飞行对象？

尽管对分布式一致性算法进行了深入研究，但这些算法很复杂且难以实现。在过去，为任何给定应用程序实现这些算法一直是一项艰巨的任务。但是，随着区块链的出现，这种情况已经发生变化。如上文所述，每个区块链的核心是分布式一致性协议，该协议在不需要任何中央存储设施的情况下，也可维护分布式账本。多重区块链可作为开源软件使用，并被设计为可扩展用于不同的应用程序。这提供了具有鲁棒性且经测试的解决方案，可将其应用于需要分布式账本的任何地方。对于国际飞行信息共享，分布式账本可以是一组飞行对象，而区块链可以为所有利益相关方提供强有力的保证，确保他们可以完整、一致地访问信息。区块链还可保证信息的完整性，确保重要的飞行对象信息不会被破坏或篡改。区块链提供了易于应用的技术基础，非常适合解决飞行对象问题。

3.3 飞行对象共享能力

图5说明了飞行对象共享能力概念。飞行对象共享能力并非单一实体；相反，它是由多个实例体现的分布式能力。每个实例都包含一个状态机，用于维护包含FIXM结构信息的飞行对象。状态机处理飞行对象的创建、删除和更新的事项。使用基于区块链的分布式一致性协议在所有实例之间沟通各种事项，确保每个状态机以相同的顺序接收完全相同的事项集。图5显示了FIXM的javascript对象简朴（JSON）格式，而不是更常见的XML格式。JSON与XML的选择将在下文讨论。

图5 飞行对象共享能力（FOSC）概念

在这个概念中，飞行对象共享能力的每个实例都支持了一个或多个利益相关方自动化系统的应用程序接口。利益相关方可能包括飞行运行中心、机组人员、提供空中交通管制和流程管理功能的空中交通管理服务提供商、进行太空发射、监视和回收的机构以及执行防空职能的军事机构。

3.4 概念验证原型

作为任务导向型研究活动的一部分，MITRE团队通过创建原型来测试飞行对象共享能力概念的可行性。实施原型的第一步是选择需要构建的区块链软件。本文选择Tendermint的原因如下：

1）基于私有的许可模型，在该模型中，区块链节点具有已知身份，确定可以更新飞行对象的终端用户名单，并执行这一规则。

2）包含一个拜占庭容错（BFT）一致性协议，该协议在面对网络故障、节点崩溃和错误或恶意破坏（无单点故障）时非常可靠。

3）提供高性能和可扩展性，适用于飞行对象事项的快速处理。

4）软件是开源的且可扩展，可将飞行对象逻辑与内部区块链逻辑分开实现。

选择区块链后，对其进行扩展，允许终端用户应用程序向区块链提交飞行对象事项（创建、更新和删除），并维持区块链节点内的飞行对象状态。图6说明了原型的主要组成部分。

图6 概念验证的实施

飞行对象共享能力的一个实例包括实现由Tendermint核心提供的分布式一致性协议的核心区块链功能。应用程序区块链接口（ABCI）服务器是一个开源组件，允许Tendermint针对特定应用程序扩展功能。在案例中，特定应用程序的功能是指用于维护飞行对象状态的飞行对象状态机（FOSM）。终端用户应用程序使用由飞行对象客户端模块提供的应用程序接口事项以创建、更新或删除飞行对象。该接口还支持订阅过滤器，只要与应用程序有关的飞行发生变化，该过滤器就会通知终端系统。这种“通知推送”模型意味着终端系统无需持续问询即可确定何时有新信息可用。相反，终端系统可以使用根据FIXM元素指定的订阅过滤器来记录感兴趣的飞行信息，例如飞行运行商、进场和离场、飞机标识符等等。该应用程序接口还允许应用程序向Tendermint节点查询飞行对象信息。

飞行对象状态机通过处理Tendermint一致性协议从终端用户应用程序收到的事项来维护飞行对象的状态。飞行对象状态机会执行规则来确定可以更改哪些终端用户事项。BFT一致性协议可确保每个节点对每个事项做出相同的决定，从而确保状态信息的一致性。原型的规则相对简单，要求：每个事项必须由已知终端系统（例如航空公司或空中交通管理服务提供商）签名；只有负责飞行的航空公司才能更新飞行信息；只有空中交通管理服务提供商才能在飞行对象中更新其“协议”状态信息；以及适用于测试的其他规则。

对于原型，本文将事项处理规则写入了状态机代码中。但是，这种方法并不建议用于形成解决方案。扩展性将允许用户使用机器可处理的访问管制语言（例如可扩展访问管制标记语言（XACML））将规则加入状态机中。

区块链使用加密哈希来提供强大的完整性保证。飞行对象事项区块以每秒一次的速率提交给链路。然后，飞行对象状态机使用Merkle树计算应用程序状态的哈希值，Merkle树包含状态存储区中所有飞行对象的序列化格式。应用程序状态哈希成为区块头部（block header）的一部分，然后对区块头部本身进行哈希处理并将其链接到下一个区块。Tendermint分布式一致性协议可确保所有实例计算相同的区块头部，从而确保所有实例都具有相同的应用状态。终端系统还可以检查区块哈希，以验证飞行对象状态机实例或存档接收的数据完整性。例如，在基于已存档数据进行事件分析时，强大的完整性保证非常重要。

在创建原型时，存储、传输和加密功能的序列化飞行对象格式需要进行设计。FIXM是飞行对象信息内容的抽象模型，以通用标记语言（UML）进行定义。基于FIXM的FF-ICE原型采用了FIXMUML模型的标准XML表示。而本文原型使用了FIXM的JSON表示。将终端用户应用程序编写为基于浏览器的图形用户界面（GUI），基于浏览器的支持，JavaScript成为图形用户界面编程语言的自然选择。还使用飞行对象状态机的JavaScript来扩大图形用户界面和飞行对象状态机之间的代码复用。选择JavaScript作为编程语言后，JSON成为代表FIXM的自然选择。本文考虑了一些高效的序列化格式，例如Apache Avro和Google协议缓冲区（protobufs）（在Tendermint内部使用），但最终选择了JavaScript飞行对象数据结构的简单JSON序列化。以前使用一种开源库，可提供确定的JSON形式，这对于确保区块链中哈希值的确定性非常重要。对于生产环境，XML表示将与FF-ICE中使用FIXM的方式更加一致。针对飞行对象的优化序列化格式开展更多研究具有重要意义。

4、演示和终端用户应用程序

为了演示国际航空的飞行对象共享能力，本文根据FF-ICE概念创建了演示。演示中，一家航空公司正在对某一国际飞行进行规划（假设从旧金山飞往新加坡）。航空公司飞行运行中心使用飞行对象共享能力向航线上的空中交通管理服务提供商提供早期规划的航线信息，从空中交通管理服务提供商接收可能影响该飞行的约束条件反馈，并相应地调整航线。

图7说明了演示场景。首先从飞行运行中心创建已规划航线的飞行对象开始。已登记关注重点（例如，关注飞往其国际机场的航班）的空中交通管理服务提供商，将会获得相应的飞行通知；然后向应用程序接口查询飞行对象数据。然后，空中交通管理服务提供商使用应用程序接口来更新飞行对象，以表明该航线可接受。然而，随着场景变化，会出现影响飞行的约束条件（例如，拥堵、恶劣天气、军事活动等）。空中交通管理服务提供商使用该信息更新飞行对象，从而触发飞行运行中心调整规划航线。这一场景以飞行运行中心确定提交飞行计划结束。但是，该场景可以扩展，以演示飞行对象共享能力在整个飞行生命周期中共享飞行信息的情况，从而未来的FF-ICE版本可实现一些更复杂的场景。

图7 演示场景

尽管图7仅显示了飞行运行中心与空中交通管理服务提供商共享的飞行对象，但演示具有多个实例，这些实例通过Tendermint区块链分布式一致性协议保持一致。

为了进行演示，本文创建了一个名为“飞行管理”的应用程序，该应用程序具有不同的模式，可以代表空中交通管理服务提供商和飞行运行中心使用的自动化系统。飞行管理程序并非旨在真实地模拟飞行运行中心或空中交通管理服务提供商的自动化功能。它只是一个演示工具，提供图形用户界面和足够的功能，允许操作员使用飞行对象客户端应用程序接口访问飞行对象共享能力来执行一些飞行管理功能。图8中的屏幕截图显示了在飞行运行中心选择新航线来回避约束条件的场景中飞行管理程序的图形用户界面，图中显示新加坡空中交通管理服务提供商表示已同意该航线。

图8 飞行管理程序图形用户界面

在图8中，蓝线表示已提交的飞行对象。绿线和红线显示了正在规划的飞行航线。（该航线在新加坡空域显示为绿色，而在其他空域显示为红色，因为在演示场景中，此时新加坡已同意该航线，但其他空中交通管理服务提供商尚未同意。）

5、性能

5.1  性能测试概述

在基础Tendermint软件上发布的测试性能表明核心软件可以在数十个节点上支持高更新率（每秒数千个事项）。但是，区块链应用程序的性能取决于应用程序的具体情况，因此本文进行了一些测试，以衡量原型飞行对象共享能力的性能。性能测试是根据区块链节点数量以及飞行对象事项处理速率来衡量飞行对象更新延迟。更新延迟是从一个节点发起飞行对象事项（创建、更新或删除）到另一节点接收到飞行已更新并获取新数据的通知为止的过程时间。

本文使用图9所示的测试框架进行了测量。该测试框架包括一个测试管制应用程序和数量可变的测试节点。测试节点通过消息代理从测试管制应用程序接收指令和配置数据，并且通过同一代理报告测试结果（测得的飞行对象更新延迟）。每个测试节点都生成飞行对象事项，并且每个事项都通过Tendermint进行分发，由其他每个节点接收。

图9 性能测试框架

每个测试节点包括：

1）飞行对象编写器应用程序，以可配置的速率创建、更新和删除飞行对象；

2）飞行对象读取器应用程序，用于接收飞行对象已更新的通知，获取更新的飞行对象数据，计算并报告端到端延迟；

3）配置和管制节点的测试管制代理；

4）建立在Tendermint核心上的飞行对象状态机区块链实例，该实例通过区块链发送事项。

每个测试节点都在Docker容器中运行，从而可以轻松使很多节点实例化，但仍受到基础架构的计算能力限制。

5.2  性能随着区块链节点数量变化

图10显示了节点数变化测试的平均延迟时间。运行测试时，以每分钟26个的速率生成飞行对象事项，包括每分钟创建12个飞行对象、更新2个飞行对象和删除12个飞行对象。这些参数的选择如下：

1）据国际航空运输协会（IATA）和美国运输部的统计数据，每天约有1.6万次国际飞行，每分钟约12次飞行。

2）每次飞行都会创建一个飞行对象，并最终将其删除，从而导致每分钟创建12个飞行对象的同时删除12个飞行对象。

3）运行中飞行的更新次数将取决于如何使用飞行对象以及需要发布更新的变化类型。由于美国大约有六分之一的飞行会发生延误，因此在这一测试中每分钟更新两次，以表示用于飞行前规划，而每次飞行延误都会产生一次更新。如果将飞行对象用于更复杂的基于航迹的运行的飞行中协商，则会出现更高的更新事项处理速率。（下文将描述以更高的更新速率进行的测试。）

图10中的结果表明，延迟随着节点数量的增加而大致呈线性增长，在100个节点处具有良好的性能（延迟6秒）。

图10 延迟时间与节点数

国际民用航空组织成员国目前不到200个。由于每个节点都可以支持许多终端用户，因此有100个节点（由技术更为先进的国际民用航空组织成员国或服务提供商进行区域管制）可以为整个国际航空界提供支持。另一方面，国际民用航空组织的每个成员国都希望运行其自己的节点，而航空公司和其他实体也希望运行节点，这可能导致需要支持全球数百个甚至数千个节点。由于测试环境的限制，本文仅对100个区块链节点进行测试。如果存在上限，则需要进行大规模性能测试。

5.3 性能随事项处理速率的变化

图11显示了对于固定数量的节点（50个节点），随着飞行对象更新速率的增加而测得的延迟。延迟随着创建、更新和删除事项处理速率的增加而平稳提高，直到每分钟超过400个事项的时间点为止。超过这一时间点，延迟会急剧增加，表明软件或网络已过载。这可能是由于原型中存在限制，因为其他使用Tendermint的实验已经证明了更高的事项处理速率，其上限大约为每秒1万个事项。

图11 延迟时间与事项处理速率

想要确定并消除原型中的瓶颈，还需要做更多的工作。但是，即使每分钟400个事项也足以支持国际飞行对象共享。每分钟估计约有1600次国际飞行，则每分钟400个事项可使每个飞行对象平均每4分钟更新一次。由于仅在需要重新协商航迹时才会发生更新，因此这一速率似乎足以支持全球基于航迹的运行（TBO）概念。

5.4 网络注意事项

性能测试在局域网环境中使用虚拟网络运行，没有评估可用的基础网络带宽和延迟对结果的影响。但是测量了每个节点消耗的带宽。对于图10所示的测试，以每分钟26个事项的速度，每个节点消耗的总接收和传输带宽范围从5个节点约205kb/s到100个节点约532kb/s。对于图11所示的测试，在有50个节点的情况下，每个节点消耗的总接收和传输带宽范围为每分钟13个事项的205kb/s到每分钟416个事项的1228kb/s。

5.5 性能结果总结

通过使用JavaScript编写在Node.js中运行的快速概念验证原型代码，使用JSON序列化进行哈希和事项处理，在中央处理器和内存资源适中的节点上运行，不仅仅针对性能进行分析或优化，可以实现性能目标。通过使用编译语言程序的最优生产实施方案实现更高效、紧凑的序列化信息并在更高性能的服务器上运行，肯定可以获得更强大的性能。

性能测量结果推动对基于区块链的解决方案进行扩展以支持现实世界航空运行的能力评估。需要进行进一步研究以及更详细的运行概念和方案开发来确定所需的规模和性能水平。但是，通过快速原型获得的结果初步表明，针对全球航空运行所需的规模，可以使用生产质量执行方案以获得适合的性能。

6、通往实际运行的道路

6.1 运行与管理模型

图12提供了一个模型，说明如何部署基于区块链的飞行对象解决方案。这一模型设想飞行对象共享能力区块链节点将由利益相关者或服务提供商（可能是商业实体）部署和运行，并由各种用户应用程序终端系统使用。在图中，椭圆形表示飞行对象共享能力区块链节点，矩形表示应用程序。区块链节点和应用程序可以部署在云计算环境中或在专用系统上运行，可进行任意组合，唯一的要求是可以通过Internet协议网络进行通信。

图12 一种部署模型

图12中描述的部署模型预想了不同类型的参与者。在这张图的底部是由空中交通管理服务提供商管制的区块链节点，由空中交通管理服务提供商自己运行，也可以由代表空中交通管理服务提供商的其他服务提供商运行。由于空中交通管理服务提供商被公认为是国际航空的权威实体，因此有必要将空中交通管理服务提供商管制的节点指定为在一致性算法中具有表决权的“验证节点”。将表决节点限制为空中交通管理服务提供商的节点，意味着Tendermint的BFT一致性算法被多于三分之二的空中交通管理服务提供商接受为有效的事项才可以用于更新飞行对象。空中交通管理服务提供商自动化系统将使用飞行对象客户端应用程序接口连接到空中交通管理服务提供商区块链节点以访问飞行对象中的信息。图中黑色部分是指为主动的飞行对象共享能力参与者服务的区块链节点，其中可能包括飞行运行中心、普通航空用户、军事和执法部门以及其他空域用户。对飞行运行中心自动化进行投资的大型航空公司等成熟用户，可以选择运行自己的区块链节点。其他用户可能选择通过服务提供商运行的区块链节点以基于云计算的飞行对象服务的形式来访问飞行对象。主动的飞行对象用户具有已知的身份和角色，从而可以根据飞行对象状态机访问管制规则，提交适当的事项以创建、更新和删除飞行对象。图中黄色显示的部分，是指被动的参与者，例如研发（R＆D）组织和飞行信息服务提供商，这些参与者不需要创建或更新飞行信息，但需要接收飞行信息以进行安全和性能分析或提供飞行状态和跟踪等功能。被动节点可以由“轻型”区块链节点支持。除了不同的主动和被动参与者之外，整个生态系统还需要另一种元素：管理实体，在图12中用红色表示。该实体的工作是发布或认证“管理材料”，其中包括终端系统和飞行对象共享能力区块链节点身份、角色、密钥和规则。这将允许验证节点确保仅由授权用户以授权方式修改飞行对象。为了使飞行对象区块链随着时间不断发展变化、添加新用户甚至新信息以及飞行对象状态机处理，本文建议应将管理材料通过管理应用程序提交给区块链并进行传播。这也解决了在所有节点之间协调变更的问题。Tendermint将确保所有节点以相同顺序接收这些管理更新事项。管理更新结果也应包含在应用程序状态哈希中，以确保所有节点均以相同的方式处理管理更新。

6.2 标准化

利益相关方可以创建有限参与者的飞行对象共享能力。例如，一个空中交通管理服务提供商和空域用户可以创建和运行飞行对象共享能力，并使用它来支持该空中交通管理服务提供商及其用户之间的协作计划。这可能是在实际运行中测试该技术的初步尝试，也可能是单一国家或地区的运行解决方案。长期目标是形成一个单一的全球解决方案，以使飞行信息可用于在任何需要的地方。标准化的实现使利益相关方无需在不同地区支持多种不可互操作的方案。

国际民用航空组织已经意识到现有飞行信息交换方法（基于点对点的文本消息）的局限性，并正在推广FF-ICE和FIXM以改进现有方法。国际民用航空组织的全系统信息管理概念设想取代传统的点对点消息传输，并支持发布/订阅消息交换模式，允许交换更多的飞行信息，但是这种方法不能完全实现飞行对象的概念，并且不能保证每个相关实体都可以获得完整一致的飞行信息。除了全系统信息管理以外，国际民用航空组织希望使用基于区块链的飞行对象共享能力，作为提供信息技术基础结构以支持未来FF-ICE版本的一种手段。

MITRE团队使用Tendermint（已获得Apache许可的开源软件包）以及获得Apache或类似许可的其他开源软件包开发飞行对象共享能力原型。经批准，MITRE的飞行对象共享能力原型软件可以通过许可获得，或者作为开源软件用于未来概念的探索，或者作为生产服务的起点。

7、结论

概念验证原型表明，通过让每个参与者发布共享飞行对象的更新并在共享飞行对象发生变化时接收通知来构建FF-ICE场景，而不是通过传递消息。原型的飞行对象结构基于FIXM，而演示的场景使用FF-ICE概念。因此，原型的成功为我们提供了信心，即基于区块链的飞行对象共享能力可以作为未来FF-ICE版本的可行基础。与当前正在开发的解决方案相比，这一能力将提供更具鲁棒型、更安全和更通用的解决方案。需要注意的是，在当前设计中，终端用户应用程序与所有消息传递和一致性逻辑完全独立，仅使用飞行对象客户端来更新飞行对象并在飞行对象发生变化时接收通知。将飞行协商业务逻辑与飞行信息共享机制分离，使基于区块链的飞行对象共享能力成为一个良好平台，用于构建未来航空应用程序。

一网打尽系列文章，请回复以下关键词查看：
创新发展：习近平 | 创新中国 | 创新创业 | 科技体制改革 | 科技创新政策 | 协同创新 | 科研管理 | 成果转化 | 新科技革命 | 基础研究 | 产学研 | 供给侧
热点专题：军民融合 | 民参军 | 工业4.0 | 商业航天 | 智库 | 国家重点研发计划 | 基金 | 装备采办 | 博士 | 摩尔定律 | 诺贝尔奖 | 国家实验室 | 国防工业 | 十三五 | 创新教育 | 军工百强 | 试验鉴定 | 影响因子 | 双一流 | 净评估
预见未来：预见2016 |预见2020  | 预见2025 | 预见2030  | 预见2035 | 预见2045  | 预见2050
前沿科技：颠覆性技术 | 生物 | 仿生 | 脑科学 | 精准医学 | 基因 |  基因编辑 | 虚拟现实 | 增强现实 | 纳米 | 人工智能 | 机器人 | 3D打印 | 4D打印 | 太赫兹 | 云计算 | 物联网 | 互联网+ | 大数据 | 石墨烯 | 能源 | 电池 | 量子 | 超材料 | 超级计算机 | 卫星 | 北斗 | 智能制造 | 不依赖GPS导航 | 通信 | 5G | MIT技术评论 | 航空发动机 | 可穿戴 | 氮化镓 | 隐身 | 半导体 | 脑机接口 | 传感器
先进武器：中国武器 | 无人机 | 轰炸机 | 预警机 | 运输机 | 直升机 | 战斗机 | 六代机 | 网络武器 | 激光武器 | 电磁炮 | 高超声速武器 | 反无人机 | 防空反导 | 潜航器
未来战争：未来战争 | 抵消战略 | 水下战 | 网络空间战 | 分布式杀伤 | 无人机蜂群 | 太空战 | 反卫星
领先国家：美国 | 俄罗斯 | 英国 | 德国 | 法国 | 日本 | 以色列 | 印度
前沿机构：战略能力办公室 | DARPA | 快响小组 | Gartner | 硅谷 | 谷歌 | 华为 | 阿里 | 俄先期研究基金会 | 军工百强
前沿人物：钱学森 | 马斯克 | 凯文凯利 | 任正非 | 马云 | 奥巴马 | 特朗普
专家专栏：黄志澄 | 许得君 | 施一公 | 王喜文 | 贺飞 | 李萍 | 刘锋 | 王煜全 | 易本胜 | 李德毅 | 游光荣 | 刘亚威 | 赵文银 | 廖孟豪 | 谭铁牛 | 于川信 | 邬贺铨
全文收录：2017文章全收录 | 2016文章全收录 | 2015文章全收录 | 2014文章全收录
其他主题系列陆续整理中，敬请期待……