CN114760088B - 飞行计划数据管理方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种飞行计划数据管理方法、系统、电子设备及存储介质，基于区块链技术的去中心化架构构建了飞行计划数据管理流程，降低了飞行计划数据管理系统单点故障的风险。基于中国的通用航空场景飞行计划数据设计角色信息，增加了飞行计划管理系统对我国应用场景的适应性，提高了飞行计划管理系统的落地性。通过对飞行计划数据管理的客户端节点分发对应的角色信息，使得客户端节点只能调用其角色信息对应的智能合约，实现了飞行计划数据管理的角色分离，提高了飞行计划数据管理的数据可溯源性，为飞行计划数据的隐私保护提供了基础。

Description

飞行计划数据管理方法、系统、电子设备及存储介质

技术领域

本申请涉及数据管理技术领域，尤其涉及一种飞行计划数据管理方法、系统、电子设备及存储介质。

背景技术

我国的通用航空具有如下特点：航空器类型复杂，应用场景非常广泛；任务需求比较分散，飞行计划缺少规律性；基础设施相对落后等等。

目前飞行计划数据管理的业务流程体系存在着一些不足：飞行计划数据采用的中心化存储缺乏机密性保护；飞行计划数据处理环节不透明，且缺少对用户角色身份的管理；缺少飞行计划数据安全共享机制。

发明内容

有鉴于此，本申请的目的在于提出一种飞行计划数据管理方法、系统、电子设备及存储介质，用以解决或部分解决上述技术问题。

基于上述目的，本申请的第一方面提供了一种飞行计划数据管理方法，其特征在于，所述方法应用于飞行计划数据管理系统，飞行计划数据管理系统包括：证书节点、客户端节点、排序节点和区块链网络，所述证书节点、所述客户端节点、所述排序节点和所述区块链网络之间通信连接；

所述方法包括：

利用所述证书节点向所述客户端节点提供角色信息；

利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据；

控制所述客户端节点将所述飞行计划数据发送到所述排序节点；

通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据；

控制所述排序节点将所述区块数据发送到所述区块链网络；

通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理。

本申请的第二方面提供了一种飞行计划数据管理系统，包括：

证书节点处理模块，被配置为利用所述证书节点向所述客户端节点提供角色信息；

客户端节点处理模块，被配置为利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据，控制所述客户端节点将所述飞行计划数据发送到所述排序节点；

排序节点处理模块，被配置为通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据，控制所述排序节点将所述区块数据发送到所述区块链网络；

区块链网络处理模块，被配置为通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理。

本申请的第三方面提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面所述的方法。

本申请的第四方面提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行第一方面所述的方法。

从上面所述可以看出，本申请提供的飞行计划数据管理方法、系统、电子设备及存储介质，基于区块链技术的去中心化架构构建了飞行计划数据管理流程，降低了飞行计划数据管理系统单点故障带来的风险。基于中国的通用航空场景飞行计划数据设计角色信息，增加了飞行计划管理系统对我国应用场景的适应性，提高了飞行计划管理系统的落地性。通过对飞行计划数据管理的客户端节点分发对应的角色信息，使得客户端节点只能调用其角色信息对应的智能合约，实现了飞行计划数据管理的角色分离，提高了飞行计划数据管理的数据可溯源性，为飞行计划数据的隐私保护提供了基础。

附图说明

为了更清楚地说明本申请或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例的飞行计划数据管理方法的流程示意图；

图2为本申请实施例的提供角色信息的流程示意图；

图3为本申请实施例的飞行计划数据管理方法的应用场景示意图；

图4为本申请实施例的Hyperledger Fabric系统的运行流程示意图；

图5为本申请实施例的飞行计划数据管理方法的流程结构示意图；

图6为本申请实施例的区块链网络的工作流程示意图；

图7为本申请实施例的飞行计划申请方上传飞行计划的页面；

图8为本申请实施例的通航飞行服务方读取飞行计划的页面；

图9为本申请实施例的飞行计划审批方审批飞行计划的页面；

图10为本申请实施例的飞行计划申请方修改访问授权用户的页面；

图11为本申请实施例的飞行计划数据管理系统的结构示意图；

图12为本申请实施例的电子设备的硬件结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本申请进一步详细说明。

需要说明的是，除非另外定义，本申请实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

如背景技术所述，我国的通用航空具有如下特点：航空器类型复杂，应用场景非常广泛；任务需求比较分散，飞行计划缺少规律性；基础设施相对落后等等。目前飞行计划数据的业务流程体系存在着一些不足：

1.飞行计划数据采用的中心化存储缺乏机密性保护。通航飞行计划数据对于飞行任务的执行至关重要。目前飞行计划数据备份在相关管制单位所属服务器中，属于传统型中心化架构，无法保证飞行计划的完整性与不被篡改性。一旦中心服务器被恶意节点攻击，平台停止运转，将会对大量的飞行任务造成安全威胁。

2.飞行计划数据处理环节不透明，且缺少对用户角色身份的管理。空中管制单位分级较多，导致飞行计划的审批流程和用户角色的身份管理复杂。飞行计划的审批直接影响着后续飞行任务的执行和飞行服务的提供。目前的交互体系中，审批流程不对相关单位用户公开，无法对角色身份进行高效管理，难以做到对数据操作的追责和溯源。

传统的飞行计划数据的数据存储方式均为中心化架构，通常由受信任的权威中心进行数据的存储与管控。但是，中心化架构存在以下几点不足：

(1)易发生单点故障：在传统架构中，整个系统需要依赖于中心组织提供相应的服务与维护。一旦中心节点被恶意攻击，发生单点故障后，将导致整个系统瘫痪，后果极其严重。

(2)数据安全性较低：数据交由中心化的企业或个人进行管理，无法完全保证数据不被恶意篡改。

(3)运行情况不透明：中心服务器的运行信息不够透明，容易出现暗箱操作的质疑。

(4)成本高：中心化的网络涉及到系统的维护、保密、运营等等，需要较高的人力、财力和物力。

针对以上缺点，分布式存储技术应运而生。传统分布式存储与区块链并非同一概念，传统分布式存储在可靠性、透明性和扩展性都有了一定的提高，但它仍然存在一些缺点需要解决：分布式数据库由全局数据库管理系统控制，将数据分片后进行存储。分片使单个节点可以独立管理部分数据，对数据库系统的可靠性会产生一定影响。除此之外，当系统进行维护时对站点要求较高，并且无法满足数据处理操作透明和不可篡改的场景要求。

为了解决分布式存储过程中遇到的问题，区块链的概念由中本聪于2008年提出，最早的应用便是比特币。区块链是一种以区块为单位的链式数据结构，它的本质是一个分布式的点对点账本数据库，通过加密技术和分布式消息传输协议简化了账户对账过程，用去中心化的形式维护大量数据，并通过数字摘要对之前的交易历史进行校验，满足防篡改、可追溯性和操作透明等特点。因此，与传统加密技术相比，区块链技术可以降低数据追溯的复杂度，在保证数据安全的同时提高数据处理效率。下面对区块链技术的几个特征进行详细的描述：

(1)去中心化。区块链采用分布式的架构实现去中心化，使数据存储与维护不再依赖某一个中心化的管理机构，交易数据将存储在区块链网络中所有用户的账本之中。当有新的交易信息时，节点会进行点对点的传播，最终更新世界状态。

(2)防篡改性。在区块链中，每个区块都包含上一个区块的哈希值，计算当前区块的哈希值时，同时包含了上一个区块的哈希值，由此形成了链接关系。因此，一旦任何一个区块发生了变动，后面相连的所有区块数据的哈希值都会有所变动，所有参与用户都会发现数据被篡改，且不认可这种无效的数据。因此，区块链独特的数据结构保证了区块链中区块数据的不可篡改。

(3)开放透明。区块链可根据访问权限分为公有链、联盟链与私有链。公有链中，任何人都可以进行使用与维护；私有链由集中管理者进行管理限制，只有内部少数人可以使用；联盟链介于公有链与私有链之间，必须具有一定权限才能访问，由若干组织合作维护整条链，具有很好的使用价值。无论属于哪种区块链，数据都可以在参与用户之间进行开放，从而使整个系统高度透明，便于溯源与追责。

目前拟将区块链技术应用于通用航空飞行数据的文章很少，M.Dehez Clementi等提出了基于区块链的解决方案，用以解决欧洲空中交通管理系统中飞行计划不一致和隐私泄露的问题。此文章将用户分为三类：使用者(飞机或飞行员)、外部来源(外部雷达或天气传感器等)和批准人。飞行数据包括飞行数据与SO6文件(即雷达生成的航空信息)。整个架构的分层架构如下所示：顶层代表现实世界，表示飞行的三个阶段：起飞前、飞行中和飞行结束后；第二层为基础设施层，在地图中定位不同类别的节点；第三层为网络层，代表数字世界中的节点关系；底层是区块链数据结构，用于存储飞行数据。

具体的实现方法如下：将节点都用这样的集合表示：(ID,x(t),y(t),z(t))。x和y代表二维的角度，取值范围-180到180。z代表上下的高度，单位是米。工作流程如下：在起飞前，使用者将计划提交至批准人，同时批准人从外部来源收集天气信息，给出审批结果；在飞行任务中，批准人动态地接收外部来源传来的信息，与使用者随时沟通修改飞行计划；飞行任务结束后，将最终的飞行数据更新至区块链网络。

本申请的实施例提供一种飞行计划数据管理方法，可以应用于飞行计划数据管理系统。

参考图1，本实施例的方法包括：

步骤101、利用所述证书节点向所述客户端节点提供角色信息。

在该步骤中，证书节点提供客户端节点注册、证书颁发等用户管理与证书服务，客户端节点通过证书节点分发的身份证书确定角色。这样，利用角色信息明确了客户端节点在参与飞行计划数据管理流程中的分类，为后续客户端节点调用区块链网络中的智能合约提供可溯源的角色类别基础。角色信息是基于中国的通用航空场景飞行计划数据设计得到的，更适合我国的应用场景，具有更强的落地性。

步骤102、利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据。

在该步骤中，客户端节点基于智能合约完成飞行计划的上传、审批。这样，通过具有角色信息的客户端节点完成飞行计划的上传、审批，在完成飞行计划数据管理流程的过程中，通过参与飞行计划数据处理的客户端节点的角色信息实现了飞行计划数据管理流程中的可溯源性。

步骤103、控制所述客户端节点将所述飞行计划数据发送到所述排序节点。

在该步骤中，客户端节点将审批通过的飞行计划数据封装后发送到排序节点。这样，通过客户端节点将封装好的飞行计划数据发送到排序节点，为后续排序节点对飞行计划数据进行打包提供了数据基础。

步骤104、通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据。

在该步骤中，排序节点接收飞行计划数据以及封装好的背书结果，并将飞行计划数据进行排序后打包成新区块。这样，通过排序节点对客户端节点发送的飞行计划数据进行处理，便于后续区块链网络完成飞行计划数据的存储，同时基于排序节点对多个客户端节点发送的飞行计划数据按照预定规则进行排序管理，提高了飞行计划数据在飞行计划管理系统中的交易效率。

步骤105、控制所述排序节点将所述区块数据发送到所述区块链网络。

在该步骤中，通过排序节点将基于飞行计划数据打包完成的区块数据发送到区块链网络，为飞行计划数据在客户端节点和区块链网络之间交互提供了连接通道。

步骤106、通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理。

在该步骤中，区块链网络中的主节点接收由排序节点对飞行计划数据打包生成的区块数据，并通过协议将接收到的区块数据进行广播同步，更新世界状态。通过区块链网络的去中心化架构，区块链中的每个区块都存有全部飞行计划数据管理系统运行所需要的数据，降低了飞行计划数据管理系统单点故障带来的风险。

在一些实施例中，参考图2，步骤101具体包括：

步骤1011、通过所述客户端节点向所述证书节点发送登记注册请求。

步骤1012、利用所述证书节点基于所述登记注册请求向所述客户端节点发送身份证书。

步骤1013、通过所述客户端节点接收所述身份证书，并基于所述身份证书确定所述客户端节点对应的所述角色信息。

在上述方案中，通过HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求协议，客户端节点中的SDK(Software Development Kit，软件开发工具包)或者CLI(Command-Line Interface，命令行界面)向证书节点发送登记注册请求，注册节点中的CA(Certification Authority，证书颁发机构)通过RESTful接口基于客户端节点发送的登记注册请求向客户端节点发送身份证书，使得客户端节点获得合法的身份证书和密钥，客户端节点通过SDK或CLI读取合法的身份证书和密钥，并基于身份证书确定客户端节点对应的角色信息。

通过上述方案，采用对飞行计划数据管理的客户端节点分发对应的角色信息的方式，为后续客户端节点调用区块链网络中的智能合约提供可溯源的角色类别基础。

在一些实施例中，所述角色信息至少包括：飞行计划申请方角色、飞行计划审批方角色和通航飞行服务方角色。

在上述方案中，将参与飞行计划数据管理系统的客户端节点的角色分为飞行计划申请方(applicant)角色、飞行计划审批方(approver)角色和通航飞行服务方(user)角色三种，角色分类如表1所示。

表1

通过上述方案，利用角色信息明确了客户端节点在参与飞行计划数据管理流程中的分类，为后续客户端节点调用区块链网络中的智能合约提供可溯源的角色类别基础。

在一些实施例中，所述客户端节点至少包括：所述飞行计划申请方角色对应的第一客户端节点、所述飞行计划审批方角色对应的第二客户端节点和所述通航飞行服务方角色对应的第三客户端节点。

在上述方案中，第一客户端节点是指想要执行通航飞行任务的从业公司或个人，加入飞行计划数据管理系统后向系统提交航空器资料和飞行计划，等待审批结果。提交的飞行计划需要通过军民航协调联合审批，即根据飞行任务中的飞行区域交由对应的单位进行处理。第二客户端节点加入飞行计划数据管理系统后对飞行计划进行审批处理，并将审批结果保存在区块链网络中。第三客户端节点指的是提供气象、指挥、情报等服务的相关飞行服务站。第三客户端节点可以在区块链网络中查询本节点通过了审批的飞行计划数据，以便为飞行任务提供相应的帮助。通过在web服务文件夹目录下运行负责功能接口的go文件，开放第一客户端节点、第二客户端节点和第三客户端节点所对应的API(ApplicationProgramming Interface，应用程序接口)，客户端节点依据自身的角色信息发起对智能合约的调用。

通过上述方案，基于客户端节点的角色信息实现了飞行计划数据管理相关的智能合约的分类调用，进而为后续通过智能合约访问区块链网络中存储的数据提供可溯源的数据基础。

在一些实施例中，步骤103具体包括：

利用第一客户端节点调用预先存储在所述区块链网络中的第一智能合约；

利用第二客户端节点调用预先存储在所述区块链网络中的第二智能合约；

基于所述第一智能合约通过第一客户端节点接收所述飞行计划；

基于所述第二智能合约通过第二客户端节点接收所述飞行计划的审批结果；

将所述审批结果作为所述飞行计划数据。

在上述方案中，第一客户端节点和第二客户端节点通过智能合约对应的API(Application Programming Interface，应用程序接口)以及输入调用智能合约的参数完成飞行计划数据的管理。第一智能合约、第二智能合约和其他智能合约对应的功能、API和输入参数如表2所示。

表2

通过上述方案，通过具有角色信息的客户端节点完成飞行计划的上传、审批，在完成飞行计划数据管理流程的过程中，通过参与飞行计划数据处理的客户端节点的角色信息实现了飞行计划数据管理流程中的可溯源性。

在一些实施例中，所述飞行计划包括访问权限信息，基于所述访问权限信息通过所述第三客户端节点接收对所述飞行计划数据的查询请求。

在上述方案中，第一客户端节点在上传飞行计划时可以设定访问授权用户列表作为访问权限信息，并通过预先存储在区块链网络中的智能合约对访问权限信息进行添加和移除，调用智能合约的参数及API如表3所示。基于访问授权用户列表通过第三客户端节点接收对飞行计划数据的查询请求。

表3

通过上述方案，在采用证书节点管理不同种类客户端节点的基础上，为飞行计划数据设置了访问权限控制，提高了飞行计划数据管理系统的隐私性。

在一些实施例中，步骤106具体包括：

通过所述区块链网络接收所述区块数据；

通过所述区块链网络对一部分所述区块数据进行哈希运算，得到哈希值；

通过所述区块链网络将所述哈希值对应的所述区块数据替换为所述哈希值并存储替换后的所述区块数据。

在上述方案中，针对部分占用空间较大的飞行计划数据，将其存入IPFS(InterPlanetary File System，星际文件系统)，将IPFS为飞行计划数据生成的哈希值存入区块链网络中。IPFS是一个旨在创建持久且分布式存储和共享文件的网络传输协议。其工作原理是将所有用户的计算设备连接同一个文件系统，为每一个文件分配一个独一无二的哈希值，支持基于文件内容寻址。当查询文件的时候，IPFS网络根据文件的哈希值进行查找，即可得到文件内容。

通过上述方案，通过更大规模的区块链存储提高了飞行计划数据系统的防篡改性，区块链网络中只存储哈希值来代替存储数据本身的方法在解决区块链网络上存储空间昂贵的问题的基础上也可以保证飞行计划数据管理系统的安全性。

基于同一发明构思，在上述各个实施例方法对应实施方案的基础上，可以有如下具体实现情况。

本实施例适用于通用航空领域，应用场景如图3所示，图中block指的是区块链网络中的区块。

本实施例基于Hyperledger Fabric区块链平台实现。为了更好地理解本实施例的原理机制，先简要介绍Hyperledger Fabric系统的运行流程，如图4所示，图4中的gRPC通信消息指的是一种高性能、开源的通用RPC框架(Remote Procedure Call，远程过程调用)，Gossip指的是利用一种随机的方法将信息传播到整个网络中，并在一定时间内使得系统内的所有节点数据一致，CA指的是Certification Authority，证书颁发机构，HTTP指的是Hyper Text Transfer Protocol，超文本传输协议，SDK指的是Software DevelopmentKit，软件开发工具包CLI指的是Command-Line Interface，命令行界面，Orderer指的是排序节点。

(1)CA节点(对应于本申请中的证书节点)可基于RESTful接口提供用户注册、证书颁发等用户管理与证书服务。参与区块链的用户可以通过客户端节点登记信息，来获取合法的身份证书与密钥。

(2)客户端节点可以通过应用程序或CLI命令行终端，读取合法的证书和私钥，执行命令，并将消息发送至背书节点请求背书。

(3)当收集到足够多的背书结果后，将背书信息、模拟执行结果等封装并发送给Orderer排序节点请求排序。排序节点负责对交易消息进行排序后打包成块。

(4)生成的区块将会由排序节点发送至各个组织的主节点，再由主节点通过Gossip协议将消息在区块内进行同步，更新世界状态。

本实施例基于以上流程，设计出如图5所示的流程结构。客户端节点通过CA分发的身份证书确定角色后，通过SDK与区块链网络内部的智能合约进行交互，实现该角色对应的业务功能。上传的数据经过排序打包后形成区块链，存入区块链网络数据库和IPFS文件系统之中。

在本实施例中，将参与用户分为飞行计划申请方(applicant)、飞行计划审批方(approver)和通航飞行服务方(user)三种角色。飞行计划申请方(对应于本申请的第一客户端节点)是指想要执行通航飞行任务的从业公司或个人，加入飞行计划数据管理系统后向系统提交航空器资料和飞行计划，等待审批结果。提交的飞行计划需要通过军民航协调联合审批，即根据飞行任务中的飞行区域交由对应的单位进行处理。飞行计划审批方(对应于本申请的第二客户端节点)加入飞行计划数据管理系统后对飞行计划进行审批处理，并将审批结果保存在区块链网络中。通航飞行服务方(对应于本申请的第三客户端节点)指的是提供气象、指挥、情报等服务的相关飞行服务站。通航飞行服务方可以在区块链网络中查询本节点通过了审批的飞行计划数据，以便为飞行任务提供相应的帮助。

在本实施例中，飞行计划数据的基础交互功能包括：上传飞行计划、审批飞行计划、读取某飞行计划、获取当前所有飞行计划、添加访问授权用户、移除访问授权用户。在区块链技术中，业务逻辑均在智能合约中实现。

本实施例中负责基础交互功能的区块链网络的工作过程如图6所示，可以总结为以下几步：

1)在网络配置文件夹目录下执行命令：开启区块链网络，创建本实施例所使用的通道，并同时开启CA服务。

2)在通道内部署智能合约，用于实现业务逻辑功能。

3)在web服务文件夹目录下运行负责功能接口的go文件。此时，智能合约功能函数对应的API即可使用。

4)使用接口测试工具即可向web服务输入所需参数，并调用相应的功能。若命令为写操作，本发明将把输入参数序列化后存入账本中；若命令为读操作，本实施例将根据参数从数据库中对所需信息反序列化，并返回结果。

本实施例中第一客户端节点上传飞行计划的页面如图7所示，第三客户端节点读取飞行计划的页面如图8所示，第二客户端节点审批飞行计划的页面如图9所示，第一客户端节点修改访问授权用户的页面如图10所示。

需要说明的是，本申请实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种飞行计划数据管理系统。

参考图11，所述飞行计划数据管理系统，包括：

证书节点处理模块301，被配置为利用所述证书节点向所述客户端节点提供角色信息；

客户端节点处理模块302，被配置为利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据，控制所述客户端节点将所述飞行计划数据发送到所述排序节点；

排序节点处理模块303，被配置为通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据，控制所述排序节点将所述区块数据发送到所述区块链网络；

区块链网络处理模块304，被配置为通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理。

在一些实施例中，证书节点处理模块301具体被配置为：

通过所述客户端节点向所述证书节点发送登记注册请求；

利用所述证书节点基于所述登记注册请求向所述客户端节点发送身份证书；

通过所述客户端节点接收所述身份证书，并基于所述身份证书确定所述客户端节点对应的所述角色信息。

在一些实施例中，飞行计划管理装置中的角色信息至少包括：飞行计划申请方角色、飞行计划审批方角色和通航飞行服务方角色。

在一些实施例中，飞行计划管理装置中的客户端节点至少包括：所述飞行计划申请方角色对应的第一客户端节点、所述飞行计划审批方角色对应的第二客户端节点和所述通航飞行服务方角色对应的第三客户端节点。

在一些实施例中，客户端节点处理模块302具体被配置为：

利用第一客户端节点调用预先存储在所述区块链网络中的第一智能合约；

利用第二客户端节点调用预先存储在所述区块链网络中的第二智能合约；

基于所述第一智能合约通过第一客户端节点接收所述飞行计划；

基于所述第二智能合约通过第二客户端节点接收所述飞行计划的审批结果；

将所述审批结果作为所述飞行计划数据。

在一些实施例中，飞行计划管理装置中的所述飞行计划包括访问权限信息，基于所述访问权限信息通过所述第三客户端节点接收对所述飞行计划数据的查询请求。

在一些实施例中，区块链网络处理模块304具体被配置为：

通过所述区块链网络接收所述区块数据；

通过所述区块链网络对一部分所述区块数据进行哈希运算，得到哈希值；

通过所述区块链网络将所述哈希值对应的所述区块数据替换为所述哈希值并存储替换后的所述区块数据。

为了描述的方便，描述以上系统时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的系统用于实现前述任一实施例中相应的飞行计划数据管理方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的飞行计划数据管理。

图12示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的飞行计划数据管理，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本申请还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的飞行计划数据管理。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的飞行计划数据管理，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围(包括权利要求)被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本申请实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本申请实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (8)

1.一种飞行计划数据管理方法，其特征在于，所述方法应用于飞行计划数据管理系统，飞行计划数据管理系统包括：证书节点、客户端节点、排序节点和区块链网络，所述证书节点、所述客户端节点、所述排序节点和所述区块链网络之间通信连接；

所述方法包括：

利用所述证书节点向所述客户端节点提供角色信息；

利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据；

控制所述客户端节点将所述飞行计划数据发送到所述排序节点；

通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据；

控制所述排序节点将所述区块数据发送到所述区块链网络；

通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理；

所述利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据，包括：

利用第一客户端节点调用预先存储在所述区块链网络中的第一智能合约；

利用第二客户端节点调用预先存储在所述区块链网络中的第二智能合约；

基于所述第一智能合约通过第一客户端节点接收所述飞行计划；

基于所述第二智能合约通过第二客户端节点接收所述飞行计划的审批结果；

将所述审批结果作为所述飞行计划数据；

所述通过所述区块链网络接收并存储所述区块数据，包括：

通过所述区块链网络接收所述区块数据；

通过所述区块链网络对一部分所述区块数据进行哈希运算，得到哈希值，具体为，将区块数据中的一部分飞行计划数据存入星际文件系统，利用星际文件系统对所述一部分飞行计划数据对应的用户的计算设备连接同一个文件系统，为每一个飞行计划数据分配唯一的哈希值；

通过所述区块链网络将所述哈希值对应的所述区块数据替换为所述哈希值并存储替换后的所述区块数据。

2.根据权利要求1所述的方法，其特征在于，所述利用所述证书节点向所述客户端节点提供角色信息，包括：

通过所述客户端节点向所述证书节点发送登记注册请求；

利用所述证书节点基于所述登记注册请求向所述客户端节点发送身份证书；

通过所述客户端节点接收所述身份证书，并基于所述身份证书确定所述客户端节点对应的所述角色信息。

3.根据权利要求1所述的方法，其特征在于，所述角色信息至少包括：飞行计划申请方角色、飞行计划审批方角色和通航飞行服务方角色。

4.根据权利要求3所述的方法，其特征在于，所述客户端节点至少包括：所述飞行计划申请方角色对应的第一客户端节点、所述飞行计划审批方角色对应的第二客户端节点和所述通航飞行服务方角色对应的第三客户端节点。

5.根据权利要求4所述的方法，其特征在于，所述飞行计划包括访问权限信息，基于所述访问权限信息通过所述第三客户端节点接收对所述飞行计划数据的查询请求。

6.一种飞行计划数据管理系统，其特征在于，包括：

证书节点处理模块，被配置为利用所述证书节点向客户端节点提供角色信息；

客户端节点处理模块，被配置为利用所述客户端节点接收所述角色信息对应的飞行计划，得到飞行计划数据，控制所述客户端节点将所述飞行计划数据发送到排序节点；

排序节点处理模块，被配置为通过所述排序节点对所述飞行计划数据进行打包处理，得到区块数据，控制所述排序节点将所述区块数据发送到区块链网络；

区块链网络处理模块，被配置为通过所述区块链网络接收并存储所述区块数据，完成所述飞行计划数据的管理；

其中，客户端节点处理模块具体被配置为：

利用第一客户端节点调用预先存储在所述区块链网络中的第一智能合约；

利用第二客户端节点调用预先存储在所述区块链网络中的第二智能合约；

基于所述第一智能合约通过第一客户端节点接收所述飞行计划；

基于所述第二智能合约通过第二客户端节点接收所述飞行计划的审批结果；

将所述审批结果作为所述飞行计划数据；

区块链网络处理模块具体被配置为：

通过所述区块链网络接收所述区块数据；

通过所述区块链网络对一部分所述区块数据进行哈希运算，得到哈希值，具体为，将区块数据中的一部分飞行计划数据存入星际文件系统，利用星际文件系统对所述一部分飞行计划数据对应的用户的计算设备连接同一个文件系统，为每一个飞行计划数据分配唯一的哈希值；

通过所述区块链网络将所述哈希值对应的所述区块数据替换为所述哈希值并存储替换后的所述区块数据。

7.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可由所述处理器执行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至5任意一项所述的方法。

8.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行权利要求1至5任一所述方法。

Images