CN116868254A - 生成用于飞行器操作的动态清单 - Google Patents

Abstract

在一些实施例中，提供了一种包括用户设备和约束管理系统的系统。约束管理系统包括一个或多个处理器和至少一个计算机可读介质。计算机可读介质在其上存储有逻辑，该逻辑响应于一个或多个处理器的执行而使得约束管理系统执行动作，该动作包括：接收飞行计划信息；查询约束数据存储以取回与飞行计划信息相关的初始的约束定义集合；基于来自初始的约束集合的约束定义与清单项目集合的比较而生成用于呈现清单的信息；以及向用户设备发送用于呈现清单项目集合的信息以供呈现。在一些实施例中，飞行计划信息包括计划飞行区域和计划飞行时间段。

Description

生成用于飞行器操作的动态清单

相关申请的交叉引用

本申请要求2021年2月26日提交的美国专利申请第17/187613号的优先权，该申请通过引用整体结合于此。

技术领域

本公开总体上涉及飞行器操作，具体地但不排他地，涉及操作无人机(unmannedaerial vehicle，UAV)。

背景技术

飞行器(aircraft)的使用，包括用于娱乐目的和用于商业目的，正变得越来越普遍。随着操作飞行器的成本的持续下降以及操作便捷性的提高，许多新驾驶员(pilot)正开始参与飞行操作。新驾驶员进入的一个障碍——并且即使有经验的驾驶员也要不断努力的——是能够恰当地确保计划的飞行不违反任何飞行约束。即使当驾驶员能够在给定的飞行之前恰当地回顾针对计划飞行区域的所有相关飞行约束时，目前也没有办法使驾驶员保持被告知计划与起飞之间的相关飞行约束的改变。越来越多地使用具有小型仅触摸接口的移动设备只会加剧这些问题。

所期望的系统可以允许有经验的驾驶员和新手驾驶员即使在使用具有小型仅触摸接口的移动设备时也都容易地计划飞行以避免违反飞行约束。还期望的系统将监视相关飞行约束的改变，并且在飞行之前和/或飞行期间检测到改变时主动通知驾驶员。

发明内容

在一些实施例中，提供了其上存储有逻辑的非暂时性计算机可读介质。该逻辑响应于约束管理系统的一个或多个处理器的执行而使得约束管理系统执行用于自动生成飞行约束的通知的动作。该动作包括：由约束管理系统接收飞行计划信息，其中，飞行计划信息包括计划飞行区域和计划飞行时间段；由约束管理系统查询约束数据存储，以取回与飞行计划信息相关的初始的约束定义集合；由约束管理系统基于来自初始的约束定义集合的约束定义与清单项目集合的比较而生成用于呈现清单的信息；以及由约束管理系统向用户设备发送用于呈现清单的信息以供呈现。

在一些实施例中，提供了其上存储有逻辑的非暂时性计算机可读介质。该逻辑响应于计算设备的一个或多个处理器的执行而使得计算设备执行动作，该动作包括：由计算设备接收定义飞行计划信息的至少一部分的输入，其中，飞行计划信息包括计划飞行区域和计划飞行时间段；由计算设备向约束管理系统发送飞行计划信息；由计算设备从约束管理系统接收用于呈现与飞行计划信息相关的飞行约束状况的清单的信息；以及由计算设备呈现清单。该动作还包括：响应于在计划飞行时间段之前从约束管理系统接收到指示飞行约束状况已经改变的通知，由计算设备从约束管理系统接收用于呈现与飞行计划信息相关的飞行约束状况的更新的清单的信息；以及由计算设备呈现更新的清单。

在一些实施例中，提供了一种包括用户设备和约束管理系统的系统。该约束管理系统包括一个或多个处理器和至少一个其上存储有逻辑的计算机可读介质。该逻辑响应于一个或多个处理器的执行而使得约束管理系统执行动作，该动作包括：由约束管理系统接收飞行计划信息，其中，飞行计划信息包括计划飞行区域和计划飞行时间段；由约束管理系统查询约束数据存储，以取回与飞行计划信息相关的初始的约束定义集合；由约束管理系统基于来自初始的约束定义集合的约束定义与清单项目集合的比较而生成用于呈现清单的信息；以及由约束管理系统向用户设备发送用于呈现清单的信息以供呈现。

附图说明

参考以下附图描述了本发明的非限制性和非穷尽性的实施例，其中，除非另有说明，否则在各个视图中，相同的附图标号指的是相同的部分。并非所有元素实例都有必要被标记，以免在适当情况下使附图混乱。附图不一定按比例绘制，相反，重点在于说明所描述的原理。为了容易识别任何特定元素或动作的讨论，附图标号中的一个或多个最高有效数字是指首次引入该元素的图号。

图1是根据本公开各个方面的用于管理飞行操作的系统的示意图示。

图2是示出根据本公开各个方面的约束管理系统的非限制性示例实施例的方面的框图。

图3A-图3C是示出根据本公开各个方面的提供动态飞行清单的方法的非限制性示例实施例的流程图。

图4A-图4C是根据本公开各个方面的由用户设备做出的对清单项目集合的呈现的非限制性示例实施例的图示。

图5是示出根据本公开各个方面的用于更新存储的约束定义的程序的非限制性示例实施例的流程图。

图6和图7示出了根据本公开各个方面的飞行器的非限制性示例。

具体实施方式

图1是根据本公开各个方面的用于管理飞行操作的系统的示意图示。如图所示，系统100包括希望在操作区域102(示出为俯视地图视图)内操作飞行器104的驾驶员108。典型地，在操作区域102内驾驶飞行器将服从由地方当局、国家当局、许可机构和其他实体发布的各种规定。然而，这些各种规定通常不能以易于回顾的格式张贴，特别是对于使用诸如智能电话或其他移动设备的用户设备106进行通信的驾驶员108。

在本公开的实施例中，提供了约束管理系统110，其收集与驾驶员108在操作区域102中对飞行器104的使用相关的飞行约束，并且提供允许用户设备106以易于在用户设备106上消费的格式呈现约束信息的信息。此外，约束管理系统110继续监视计划飞行的约束信息以检查任何改变，并且如果约束以有意义的方式改变，则将向用户设备106发送通知，从而允许驾驶员108提前很久计划飞行，而不必重复地复查计划来确保计划飞行仍然是可允许的。

图2是示出根据本公开各个方面的约束管理系统的非限制性示例实施例的方面的框图。图示的约束管理系统110可以由任何计算设备或计算设备集合来实现，包括但不限于台式计算设备、膝上型计算设备、移动计算设备、服务器计算设备、云计算系统的计算设备和/或它们的组合。约束管理系统110被配置为通过确定在计划飞行时间段期间与计划飞行区域相关的约束并提供与那些约束相关联的信息以呈现给用户来生成动态清单。在一些实施例中，约束管理系统110还被配置为在计划飞行时间段之前和计划飞行时间段期间监视所确定的约束的改变，并且在检测到改变的情况下通知用户。

如图所示，约束管理系统110包括一个或多个处理器202、一个或多个通信接口204、约束数据存储208、用户数据存储218和计算机可读介质206。

在一些实施例中，处理器202可以包括任何合适类型的通用计算机处理器。在一些实施例中，处理器202可以包括为特定计算任务优化的一个或多个专用计算机处理器或AI加速器，包括但不限于图形处理单元(graphical processing units，GPU)、视觉处理单元(vision processing unit，VPT)和张量处理单元(tensor processing unit，TPU)。

在一些实施例中，通信接口204包括适于在组件之间提供通信链路的一个或多个硬件和/或软件接口。通信接口204可以支持一种或多种有线通信技术(包括但不限于以太网、火线和USB)、一种或多种无线通信技术(包括但不限于Wi-Fi、WiMAX、蓝牙、2G、3G、4G、5G和LTE)和/或其组合。

如图所示，计算机可读介质206在其上存储有逻辑，该逻辑响应于一个或多个处理器202的执行而使得约束管理系统110提供用户管理引擎220、约束采集引擎212、约束计算引擎210、约束分析引擎214和环境信息引擎216。

如本文所使用的，“计算机可读介质”是指实现能够以易失性或非易失性的方式存储信息以供计算设备的处理器读取的任何技术的可移动或不可移动的设备，包括但不限于：硬盘驱动器；闪存；固态驱动器；随机存取存储器(random-access memory，RAM)；只读存储器(read-only memory，ROM)；CD-ROM、DVD或其他磁盘存储装置；盒式磁带；磁带；以及磁盘存储器。

在一些实施例中，用户管理引擎220被配置为创建和管理存储在用户数据存储218中的用户记录。用户记录可以包括信息，诸如驾驶员的驾驶员属性、由驾驶员操作的飞行器的飞行器属性、驾驶员的联系信息(包括但不限于可以向其发送通知的一个或多个地址)和/或其他信息。

在一些实施例中，约束采集引擎212被配置为从表示约束信息的其他来源中取回信息，并且将对应的约束定义存储在约束数据存储208中。在一些实施例中，约束采集引擎212可以提供允许将约束信息直接输入到约束管理系统110中的用户接口，并且可以基于输入到用户接口中的约束信息来创建和存储约束定义。

在一些实施例中，环境信息引擎216被配置为从外部来源中取回瞬态环境信息，包括但不限于天气状况信息和/或天气预测信息。在一些实施例中，约束计算引擎210被配置为计算基于来自其他来源的瞬态信息(诸如由环境信息引擎216采集的信息)的约束定义，并且将计算的约束定义存储在约束数据存储208中。

在一些实施例中，约束分析引擎214被配置为生成和发送用于呈现清单项目列表的信息。在一些实施例中，约束分析引擎214被配置为确定在计划飞行时间段期间哪些约束定义与给定的计划飞行区域相关，并且将用于呈现清单项目列表的信息基于相关的约束定义。在一些实施例中，约束分析引擎214还可以被配置为在计划飞行时间段之前和计划飞行时间段期间继续监视可能相关的更新的约束定义，并且当检测到改变时，向存储在用户数据存储218中的用户记录中的联系信息发送通知。

下面提供了对这些组件中的每一个的配置的进一步描述。

如本文所使用的，“引擎”是指体现在硬件或软件指令中的逻辑，它可以用一种或多种编程语言来编写，包括但不限于C、C++、C#、COBOL、JAVATM、PHP、Perl、HTML、CSS、JavaScript、VBScript、ASPX、Go和Python。引擎可以被编译成可执行程序或者用解释编程语言来编写。软件引擎可以是可从其他引擎或自身调用的。一般来说，本文描述的引擎是指可以与其他引擎合并或者可以被拆分成子引擎的逻辑模块。引擎可以由存储在任何类型的计算机可读介质或计算机存储设备中的逻辑来实现，并且可以被存储在一个或多个通用计算机上并由其执行，从而创建被配置为提供引擎或其功能的专用计算机。引擎可以由编程到专用集成电路(application-specific integrated circuit，ASIC)、现场可编程门阵列(field-programmable gate array，FPGA)或其他硬件设备中的逻辑来实现。

如本文所使用的，“数据存储”是指被配置为存储供计算设备访问的数据的任何合适的设备。数据存储的一个示例是在一个或多个计算设备上执行并且可以通过高速网络访问的、高度可靠的高速关系数据库管理系统(database management system，DBMS)。数据存储的另一个示例是键值存储。然而，可以使用能够响应于查询而快速地且可靠地提供存储的数据的任何其他合适的存储技术和/或设备，并且计算设备可以是本地可访问的而不是通过网络可访问的，或者可以作为基于云的服务来提供。数据存储还可以包括以有组织的方式存储在计算机可读存储介质(诸如硬盘驱动器、闪存、RAM、ROM或任何其他类型的计算机可读存储介质)上的数据。本领域的普通技术人员将认识到，在不脱离本公开的范围的情况下，本文描述的分离的数据存储可以被组合成单个数据存储，和/或本文描述的单个数据存储可以被分离成多个数据存储。

图3A-图3C是示出根据本公开各个方面的提供动态飞行清单的方法的非限制性示例实施例的流程图。在方法300中，约束管理系统110有助于生成示出了计划飞行是否将遵守计划飞行区域中的各种飞行约束的动态清单，并且在计划飞行时间段之前有改变的情况下还继续监视飞行约束。通过这样做，约束管理系统110有助于驾驶员108提前计划飞行器操作，而不必在计划飞行时间段之前重复地手动确认计划仍然有效。

方法300从开始框前进到框302，在框302，驾驶员108向约束管理系统110的用户管理引擎220提供一个或多个驾驶员属性。在框304，用户管理引擎220在约束管理系统110的用户数据存储218中为驾驶员108创建用户简档(user profile)，并且在框306，用户管理引擎220将驾驶员属性存储在用户简档中。

驾驶员属性可以包括与确定给定的飞行约束是否将会适用于驾驶员108相关的驾驶员108特性。例如，这些驾驶员属性可以包括但不限于驾驶员108持有的许可类型、驾驶员108持有的许可的许可号、驾驶员108持有的飞行小时数、驾驶员108最近飞行的时间、驾驶员108先前获得的授权数量、驾驶员108的当前位置、驾驶员108的年龄以及驾驶员108的当地时间。驾驶员属性还可以包括与约束管理系统110的操作更直接相关的一条或多条数据，包括但不限于驾驶员108访问约束管理系统110的用户名/密码、与驾驶员108相关联的联系信息、驾驶员108的用户设备106的地址信息、通知服务的设备令牌以及驾驶员108的通信偏好。通过存储驾驶员108的联系信息和/或地址信息，约束管理系统110将能够在检测到为计划飞行确定的约束的改变时发送通知以呈现给驾驶员108。

在框308，驾驶员108向用户管理引擎220提供一个或多个飞行器属性，并且在框310，用户管理引擎220将飞行器属性存储在用户简档中。在一些实施例中，用户管理引擎220可以在用户数据存储218(或另一个数据存储)中创建分离的飞行器记录，并且可以将用户简档与飞行器记录相关联。与约束管理系统110的操作相关的任何飞行器属性可以由驾驶员108提供，包括但不限于以下各项中的一个或多个：飞行器模型、飞行器类型(例如，固定翼、旋翼等)、飞行器注册号、飞行器重量或质量、飞行器有效载荷容量、飞行器最大操作速度、飞行器最小操作速度、飞行器最小转弯半径、飞行器最小操作高度，飞行器最大操作高度、飞行器照明配置、飞行器通信能力、飞行器通信地址以及一个或多个飞行器自主级别。

在子例程框312，约束管理系统110更新存储在约束管理系统110的约束数据存储208中的约束定义。在方法300的初始执行时，约束数据存储208可以是空的，并且在子例程框312处执行的程序可以向约束数据存储208添加初始的约束定义集合。如果约束数据存储208已经包括一个或多个约束定义，则在子例程框312处执行的程序可以修改或移除现有的约束定义以及添加新的约束定义。在子例程框312，可以使用任何合适的程序来更新约束定义，包括但不限于图5所示并在下面进一步详细描述的程序500。

在框314，驾驶员108从用户设备106向约束管理系统110发送飞行计划信息，该飞行计划信息包括计划飞行区域和计划飞行时间段。在一些实施例中，约束管理系统110与用户简档相关联地存储飞行计划信息，使得约束管理系统110将能够使用用户简档中的联系信息与驾驶员108关于计划飞行进行通信。

在一些实施例中，用户设备106呈现允许驾驶员108以任何合适的二维或三维格式指定计划飞行区域的用户接口。在一些实施例中，用户接口允许驾驶员108指定地图上的点和点周围的半径，以定义计划飞行区域。在一些实施例中，用户接口允许驾驶员108在地图上绘制计划飞行区域的边界。在一些实施例中，用户接口允许驾驶员108指定开始位置、结束位置以及开始位置与结束位置之间的可选航路点集合来定义路径，并且所定义的路径周围的边距被用作计划飞行区域。在一些实施例中，用户接口允许驾驶员108为计划飞行区域的各个部分指定一个或多个高度下限或上限，使得计划飞行区域是三维体积。在一些实施例中，驾驶员108可以不指定任何计划高度信息。

在一些实施例中，计划飞行时间段可以由计划飞行开始时间和计划飞行结束时间、计划飞行开始时间和计划飞行持续时间或者以任何其他合适的方式来指定。在一些实施例中，计划飞行区域的各个部分可以与计划飞行时间段相关联，在某计划飞行时间段中，预计飞行器104在计划飞行区域的某部分内，使得计划飞行区域可以被认为是四维体积。

在框316，约束分析引擎214从约束数据存储208中取回与计划飞行区域和计划飞行时间段相关的初始的约束定义集合。在一些实施例中，约束数据存储208使用用以压缩要搜索的几何信息的S2技术来存储约束定义，并且使用S2技术来寻找影响与计划飞行区域相交的区域的约束定义。在一些实施例中，约束分析引擎214可以简化初始搜索，以便生成更小的数据集来与计划飞行区域和计划飞行时间段的详尽细节进行比较。例如，约束分析引擎214可以基于计划飞行区域的二维投影来搜索约束数据存储208，以便降低初始查询的复杂性，然后可以将有限的结果集合与计划飞行区域的完全三维表示和/或基于计划飞行时间段进行比较。

在一些实施例中，约束分析引擎214可以不仅基于计划飞行区域和计划飞行时间段，而且基于存储在与驾驶员108相关联的用户简档中的一条或多条信息(诸如驾驶员属性或飞行器属性)，来取回初始的约束定义集合(以及下面讨论的更新的约束定义集合)。例如，可以为具有第一许可状态的第一驾驶员108取回与具有不同许可状态的第二驾驶员108不同的约束定义。作为另一个示例，对于质量高于给定阈值的第一飞行器104和对于质量低于给定阈值的第二飞行器104，可以取回不同的约束定义。对于具有不同驾驶员属性的驾驶员和对于具有不同飞行器属性的飞行器，这将导致如下面讨论的多个清单项目集合的不同呈现。

在一些实施例中，飞行计划信息还可以包括与飞行相关的其他信息，包括但不限于要执行的飞行类型(例如，娱乐飞行、商业非许可飞行、商业许可飞行、递送或紧急飞行)。即使对于相同的飞行器104和/或驾驶员108，要执行的飞行的类型也可以改变为给定飞行取回的约束定义，或者为给定飞行呈现的清单项目。在一些实施例中，用户设备106可以提供允许驾驶员108指定飞行类型的用户接口元素。

在框318，约束分析引擎214基于初始的约束定义集合生成用于呈现清单项目集合的信息。在一些实施例中，清单项目集合可以指示在计划飞行区域或其一部分内存在或不存在各种类型的约束。例如，清单项目集合可以包括计划飞行区域是否包括永久受限空域、火灾隐患、受控机场/进场路径/离场路径、非受控机场、危险区域、海洋公园、禁飞区、直升机场、具有仪表进场的直升机场、国家公园或受限区域。

如果初始的约束定义集合包括一个或多个这些类型的项目，则相关联的清单项目可以用指示失败的颜色(诸如红色)或用指示失败的图标(诸如X)来呈现，或者用指示警告的颜色(诸如黄色)或用指示警告的图标(诸如感叹号)来呈现(例如，如果存在指示禁飞区的约束定义，则“禁飞区”清单项目可以用红色X来呈现)。对于初始的约束定义集合中不包括约束定义的清单项目，相关联的清单项目可以用指示成功的颜色(诸如绿色)或者用指示成功的图标(诸如复选标记)来呈现(例如，如果不存在指示禁飞区的约束定义，则“禁飞区”清单项目可以用绿色复选标记来呈现)。

方法300然后前进到继续终端(“终端A”)。

方法300从终端A(图3B)前进到框320，在框320，约束分析引擎214向用户设备106发送用于呈现清单项目集合的信息。在一些实施例中，约束分析引擎214可以向用户设备106发送初始的约束定义集合本身，并且用户设备106可以将初始的约束定义集合与清单项目进行比较，以确定与呈现中的每个清单项目相关联的颜色/图标。在一些实施例中，约束分析引擎214可以进行比较，并且可以向用户设备106发送清单项目状态以供呈现。

在框322，用户设备106呈现计划飞行区域的清单项目集合。图4A-图4C示出了根据本公开各个方面的由用户设备做出的对清单项目集合的呈现的非限制性示例实施例。

图4A示出了清单项目集合指示没有约束定义被包括在清单项目的初始的约束定义集合中的示例。在图4A中，用户设备106显示地图402和清单404。清单404与由大头针(pin)406在地图402上指示的特定位置相关联。地图402示出了由约束分析引擎214取回的约束边界408，但是因为大头针406在约束边界408之外，所以清单404不反映与约束边界408相关联的约束定义。如图所示，清单404中的每个清单项目不与由大头针406指示的位置的约束定义相关联，因此清单404中的每个清单项目包括复选标记以指示成功。清单404还包括指示所有清单项目通过的标题，并且大头针406包括复选标记以进一步指示所有清单项目通过。通过点击清单404底部的箭头，可以获得和访问更多的清单项目。

在一些实施例中，清单404中的项目的特定状态可以通过移动由大头针406指示的位置来改变。在一些实施例中，驾驶员108可以将大头针406拖动到地图402的不同部分，以检查其他位置的约束。在一些实施例中，驾驶员108可以在大头针406下滚动地图402，以检查其他位置的约束。

图4B示出了大头针406已经被移动到约束边界408内的示例。出于图4B的目的，与约束边界408相关联的约束定义指示在其中操作飞行器之前需要批准的受限空域，并且应该警告驾驶员108在约束边界408内操作。相应地，当大头针406在约束边界408内时，大头针406内的复选标记已经改变为感叹号。此外，清单404的标题已经变成“谨慎使用”，并且“受限空域”清单项目现在与感叹号而不是清单404中的复选标记相关联。“受限空域”清单项目也已经增加了与约束有关的附加信息。该信息可以作为约束定义的一部分来提供。

图4C示出了大头针406已经被移动到约束边界408内的另一个示例。出于图4C的目的，多个约束定义与约束边界408相关联：指示空域需要批准的图4B的约束定义，以及指示位置与受控机场相关联的另一个约束定义。因为在受控机场附近不允许飞行器操作，所以大头针406现在显示X，并且清单404的标题已经变成“禁飞”。“受控空域”清单项目现在与清单404中的X相关联，并且“受限空域”清单项目关联于与图4B相同的感叹号。人们将注意到，由于“受控机场”约束的更高严重性，“受控机场”清单项目已经被排序到清单404的顶部，随后是警告清单项目，随后是成功清单项目。通过为清单项目提供通过/警告/失败状况的清楚指示，通过在大头针406上和清单404的标题中提供总体通过/警告/失败指示，以及通过对清单404重新排序以将最高严重性的问题放在顶部，呈现在用户设备106上的接口有助于克服用户设备106上可用的小型显示空间和用户设备106上相对较不精确的基于触摸的输入，从而仍然提供与计划飞行区域相关的飞行约束的高度有用的回顾。

回到图3B，在判定框324，做出关于计划飞行是否已经起飞的确定。在一些实施例中，这可以通过约束分析引擎214将当前时间与计划飞行时间段进行比较来进行。在一些实施例中，这可以通过约束分析引擎214从飞行器104接收遥测信息并基于遥测信息确定计划飞行已经开始来进行。在这些实施例中，如果计划飞行时间段已经开始但是遥测信息没有指示飞行已经开始，则约束分析引擎214可以基于当前时间更新计划飞行时间段。

如果飞行还没有起飞，则判定框324的结果为否，并且方法300前进到子例程框326。在子例程框326，约束管理系统110更新存储在约束数据存储208中的约束定义。在子例程框326，可以使用任何合适的技术来更新存储在约束数据存储208中的约束定义，包括但不限于图5所示并且将在下面进一步详细讨论的程序500。典型地，子例程框326的动作类似于图3A的子例程框312的动作。

在框328，约束分析引擎214基于计划飞行时间段之前剩余的时间等待一段时间，并且在框330，约束分析引擎214从约束数据存储208中取回与计划飞行区域和计划飞行时间段相关的更新的约束定义集合。可以使用与在框316处用于取回初始的约束定义集合的技术类似的技术来取回更新的约束定义集合。

在较高级别，方法300以随时间增加的速率重复地检查与计划飞行区域和计划飞行时间段相关的更新的约束定义。通过在框328处基于计划飞行时间段之前剩余的时间等待一段时间，当具有最新的信息不太重要时，方法300可以在计划飞行时间段之前很久的时间节约计算和通信资源，并且当具有最新的信息更重要时，方法300可以优先考虑更接近于计划飞行时间段的信息的准确性和及时性。

例如，在一些实施例中，约束分析引擎214在框328处等待的时间量随着当前时间越接近于计划飞行时间段的起始而减少，使得框328之后的动作发生得越频繁，当前时间越接近于计划飞行时间段的起始。在一些实施例中，约束分析引擎214等待的时间量可以在计划飞行时间段之前指数衰减。在一些实施例中，约束分析引擎214等待的时间量可以基于直到计划飞行时间段达到最小阈值时间量的时间量而缩减，这时，该时间量将保持在最小阈值时间量。

在一些实施例中，可能不需要获得减少约束分析引擎214在框328处等待的时间量的益处。例如，当前时间与计划飞行时间段之间的时间量可能足够小，使得随时间改变检查更新的约束定义的频率的益处可能不明显。作为另一个示例，由约束管理系统110管理的飞行器104、驾驶员108或计划飞行的数量可能足够小，使得节省计算能力和/或通信带宽可能是不必要的。作为又一个示例，约束管理系统110可用的计算能力和/或通信带宽可能足够大，使得通过减少约束分析引擎214等待的时间量而获得的益处可能不会明显提高约束管理系统110的性能。在这样的实施例中，在方法300的多次迭代中，约束分析引擎214可以在框328处等待恒定的时间量。

在判定框332，做出关于初始的约束定义集合与更新的约束定义集合之间是否有任何改变的确定。在一些实施例中，约束分析引擎214可以存储初始的约束定义集合的记录，并且可以将更新的约束定义集合与存储的初始的约束定义集合进行比较，以确定是否有任何改变。在一些实施例中，更新的约束定义集合可以仅包括自框316处的前一次查询以来新存储在约束数据存储208中的或在约束数据存储208中更新的约束定义，因此判定框332处的确定可以基于更新的约束定义集合是否为空。

如果初始的约束定义集合与更新的约束定义集合之间没有改变，则判定框332的结果为否，并且方法300返回到判定框324以继续监视约束定义的改变。否则，如果初始的约束定义集合与更新的约束定义集合之间有改变，则判定框332的结果为是，并且方法300前进到框334。

在框334，约束分析引擎214基于更新的约束定义集合生成用于呈现更新的清单项目集合的信息。在一些实施例中，信息及其生成可以类似于上面在框318处描述的用于呈现清单项目集合的信息的生成，但是使用更新的约束定义集合(或者初始的约束定义集合与更新的约束定义集合的组合，在更新的约束定义集合仅包括新的/更新的约束定义而不是所有相关的约束定义的情况下)。

在框336，约束分析引擎214向用户设备106发送通知。约束分析引擎214可以使用任何合适的技术或技术组合来向用户设备106发送通知，包括但不限于由用户设备106的操作系统支持的推送通知(包括但不限于苹果推送通知服务(Apple Push Notificationservice，APN)通知或谷歌云消息传递通知)、针对应用的SMS消息、电子邮件和HTTP推送。在一些实施例中，用于向用户设备106发送通知的寻址信息、设备令牌和/或其他信息被存储在用户简档中以供在框336处使用。

在框338，约束分析引擎214向用户设备106发送用于呈现更新的清单项目集合的信息。在一些实施例中，用于呈现更新的清单项目集合的信息可以被包括在框336中发送的通知中。在一些实施例中，框336中发送的通知可以仅仅指示信息的存在，并且用户设备106可以响应于接收到通知而从约束分析引擎214取回用于呈现更新的清单项目集合的信息。

方法300然后返回到判定框324，以监视对约束定义的进一步改变。在随后的迭代中，当确定在新更新的约束定义集合中是否有任何改变时，也将在判定框332处考虑更新的约束定义集合。

返回到判定框324，如果确定飞行已经起飞，则判定框324的结果为是，并且方法300前进到继续终端(“终端B”)。在一些实施例中，前行到终端B可以是可选的。在这样的实施例中，方法300可以在判定框324的结果为是的情况下终止，或者可以在计划飞行时间段开始时终止。

方法300从终端B(图3C)前进到框340，在框340，飞行器104向约束管理系统110发送遥测信息。在一些实施例中，遥测信息可以包括关于飞行器104的状态的信息，包括但不限于定位、高度、姿态和/或速度信息。

在判定框342，做出关于飞行是否完成的确定。在一些实施例中，判定框342处的确定可以基于所报告的飞行器104的速度、高度和定位是否指示飞行器104已经着陆和/或到达计划飞行区域的计划结束位置。在一些实施例中，判定框342处的确定可以基于驾驶员108是否已经向用户设备106提供的用户接口指示飞行已经完成。

如果确定飞行没有完成，则判定框342的结果为否，并且方法300前进到框344。在框344，约束分析引擎214将遥测信息与飞行计划信息进行比较，并且在判定框346，做出关于遥测信息是否与飞行计划信息匹配的确定。在一些实施例中，比较包括约束分析引擎214将遥测信息的定位、高度和/或其他要素与计划飞行区域和计划飞行时间段进行比较，以确定在计划飞行时间段期间定位、高度和/或其他要素是否仍在计划飞行区域内。

如果确定遥测信息与飞行计划信息匹配，则判定框346的结果为是，并且方法300返回到框340以监视进一步的遥测信息。否则，如果确定遥测信息与飞行计划信息不匹配，则判定框346的结果为否，并且方法300前进到框348。

在框348，约束分析引擎214更新飞行计划信息以包含遥测信息。在一些实施例中，约束分析引擎214可以更新计划飞行区域以包括由遥测信息指示的飞行器104的定位/高度。在一些实施例中，约束分析引擎214可以更新计划飞行区域，以包括该定位/高度加上由遥测信息指示的定位/高度周围的预定半径或体积。在一些实施例中，约束分析引擎214可以在确定要添加到计划飞行区域的区域或体积时考虑飞行器104的姿态和速度(例如，约束分析引擎214可以在飞行器104的行进方向上添加更多的区域，而在其他方向上添加更少的区域)。

在一些实施例中，约束分析引擎214可以更新计划飞行时间段，以至少包括由遥测信息指示的当前时间。在一些实施例中，约束分析引擎214可以更新计划飞行时间段，以不仅包括由遥测信息指示的当前时间，还包括预定的附加时间量。在一些实施例中，约束分析引擎214可以更新计划飞行时间段，以包括由遥测信息指示的当前时间和飞行中剩余的预测时间量。可以使用任何合适的技术来确定飞行中剩余的预测时间量，包括但不限于确定飞行器104的电池中剩余的带电量或者确定飞行器104从其当前定位到达飞行终点将花费的时间量。

在框350，约束分析引擎214从约束数据存储208中取回与更新的飞行计划信息相关的新的约束定义集合。在一些实施例中，使用与框316中用于取回初始的约束定义集合和/或框330中用于取回更新的约束定义集合的技术类似的技术来取回新的约束定义集合。

在判定框352，做出关于新的约束定义集合与初始的约束定义集合之间是否有任何改变的确定。同样，在一些实施例中，使用与在判定框332处描述的技术类似的技术进行确定，但是将新的约束定义集合与初始的约束定义集合进行比较。在一些实施例中，如果在判定框332处确定更新的约束定义集合具有改变，则在判定框352处的比较可以在新的约束定义集合与初始的约束定义集合和更新的约束定义集合的组合之间执行。

如果确定新的约束定义集合与初始的约束定义集合之间没有改变，则判定框352的结果为否，并且方法300再次返回到框340以监视进一步的遥测信息。否则，如果新的约束定义集合与初始的约束定义集合之间有改变，则判定框352的结果为是，并且方法300前进到框354。

在框354，约束分析引擎214基于新的约束定义集合生成用于呈现新的清单项目集合的信息。在框356，约束分析引擎214向用户设备106发送通知，并且在框358，约束分析引擎214向用户设备106发送用于呈现新的清单项目集合的信息。框354-框358的动作类似于上面在框334-框338中讨论的那些动作，因此为了简洁起见，这里不再详细讨论。一个不同之处在于，在一些实施例中，如果在新的清单项目集合中有任何清单项目被新指示为失败，则约束分析引擎214可以采取附加的动作，包括但不限于向飞行器104发送命令以立即着陆或以其他方式使得失败的清单项目被解决。

方法300然后返回到框340，以监视进一步的遥测信息。

图5是示出根据本公开各个方面的用于更新存储的约束定义的程序的非限制性示例实施例的流程图。图5所示的程序500是适用于上述方法300的子例程框312和/或子例程框326的程序的非限制性示例。在程序500中，约束管理系统110从各种来源中采集约束定义，并且在适当时添加/更新存储在约束数据存储208中的约束定义。

每个约束定义可以包括定义相关联的飞行约束的各种特征。例如，在一些实施例中，每个约束定义可以定义由约束覆盖的区域或体积。作为另一个示例，在一些实施例中，每个约束定义可以包括约束的开始时间和结束时间，或者约束生效的一天中的时间段。作为又一个示例，在一些实施例中，每个约束定义可以包括约束的类型，其中，该类型指定约束定义表示什么状况。

许多不同类型的约束可以由约束定义来表示。作为一些非限制性示例，约束的类型可以包括临时或永久的禁飞区(其中不允许任何操作)、火灾隐患(其中不允许造成火灾风险的操作)、受控机场/进场路径/离场路径(其中可以约束无许可的操作，但是可以允许有许可的和允许的操作)、非受控机场(其中可以约束无许可的操作，但是可以允许有许可的操作)、危险区域、海洋公园、直升机场、具有仪表进场的直升机场、国家公园或者对飞行器操作的任何其他类型的约束。在一些实施例中，每种类型的约束与上述清单项目相关联。

程序500从开始框前进到框502，在框502，约束采集引擎212经由用户接口接收手动约束定义集合。在一些实施例中，约束采集引擎212可以生成用户接口，该用户接口可以接受来自用户的输入，以使用任何合适的技术来定义手动约束定义。作为一个非限制性示例，约束采集引擎212可以呈现地图接口，该地图接口允许用户选择点和半径、绘制轮廓或者以任何其他方式使用地图指定约束定义的区域。该接口还可以允许用户指定约束定义的高度上限和/或下限、约束定义生效的时间段以及约束定义的类型。

在框504，约束采集引擎212从一个或多个第三方数据源中取回外部约束定义集合。在一些实施例中，约束采集引擎212可以查询一个或多个第三方数据源(诸如政府机构或飞行计划信息的商业来源)，以获得外部约束定义。

在框506，环境信息引擎216从一个或多个数据源中收集瞬态环境信息，并且在框508，约束计算引擎210基于瞬态环境信息确定计算的约束定义集合。在一些实施例中，瞬态环境信息可以包括过去天气状况信息、当前天气状况信息和/或未来天气预测信息，并且计算的约束定义集合可以包括基于天气信息的约束类型。作为非限制性示例，环境信息引擎216可以取回指示预计给定区域在给定时间经历大风的天气预测信息。约束计算引擎210然后可以创建一种类型的约束定义，以指示在给定区域内在某个重量下操作飞行器是危险的或是被禁止的。

在框510，约束采集引擎212基于手动约束定义集合、外部约束定义集合和计算的约束定义集合来更新约束数据存储208的内容。在一些实施例中，约束采集引擎212可以将手动约束定义、外部约束定义和计算的约束定义的格式标准化为约束数据存储208所使用的匹配格式。

在一些实施例中，在将约束定义添加到约束数据存储208之前，约束采集引擎212可以检查约束数据存储208是否已经包括该约束定义。如果约束数据存储208还不包括给定的约束定义，则约束采集引擎212可以简单地将给定的约束定义添加到约束数据存储208。如果约束数据存储208确实包括给定的约束定义，则约束采集引擎212可以检查以确认在约束定义的存储版本与给定的约束定义之间是否有任何差异。如果没有差异，则约束采集引擎212可以跳过将给定的约束定义添加到约束数据存储208，但是如果有差异，则约束采集引擎212可以或者更新存储的约束定义以匹配给定的约束定义，或者可以删除存储的约束定义并用给定的约束定义替换它。在一些实施例中，当添加或更新存储在约束数据存储208中的约束定义时，约束采集引擎212可以包括时间戳，从而允许约束分析引擎214能够取回在给定时间之后添加或更新的约束定义。

程序500然后前进到结束框，并且将控制返回给它的调用者。

图6和图7示出了根据本公开各个方面的飞行器的非限制性示例。无人机(UAV600)的图示实施例是垂直起降(vertical takeoff and landing，VTOL)无人机(UAV)，其包括分别用于提供水平推进和垂直推进的分离的推进单元612和推进单元608。UAV 600是固定翼飞行器，顾名思义，具有机翼组件624，当由推进单元612水平推进时，机翼组件624可以基于机翼形状和飞行器的向前空速而生成升力。图6是UAV 600的透视俯视图，而图7是UAV600的仰视图。

UAV 600的图示实施例包括机身620。在一个实施例中，机身620是模块化的，并且包括电池模块、航空电子模块和任务有效载荷模块。这些模块可彼此拆卸，并且可彼此机械固定以连续形成机身620或UAV主体的至少一部分。

电池模块包括用于容纳为UAV 600供电的一个或多个电池的空腔。航空电子模块容纳UAV 600的飞行控制电路，其可以包括处理器和存储器、通信电子设备和天线(例如，蜂窝收发器、Wi-Fi收发器等)以及各种传感器(例如，全球定位传感器、惯性测量单元(inertial measurement unit，IMU)、磁性罗盘等)。任务有效载荷模块容纳与UAV 600的任务相关的设备。例如，任务有效载荷模块可以包括用于保持和释放外部连接的有效载荷的有效载荷致动器。在另一个实施例中，任务有效载荷模块可以包括用于携带照相机/传感器设备(例如，相机、镜头、雷达、LIDAR、污染监视传感器、天气监视传感器等)的相机/传感器设备固定架。

UAV 600的图示实施例还包括位于机翼组件624上的水平推进单元612，每个水平推进单元612可以包括用于推进UAV 600的马达、轴件、马达固定座和螺旋桨。UAV 600的图示实施例包括固定到机翼组件624的两个悬臂组件606。

悬臂组件606的图示实施例均包括悬臂壳体618、垂直推进单元608、印刷电路板616和稳定器602，悬臂设置在悬臂壳体618中。垂直推进单元608均可以包括用于提供垂直推进的马达、轴件、马达固定座和螺旋桨。垂直推进单元608可以在UAV 600下降(例如，到递送位置)或上升(例如，跟随递送)的悬停模式期间使用。UAV 600可以包括稳定器602(或尾翼)，以在飞行期间稳定UAV的偏航(左转或右转)。在一些实施例中，UAV 600可以被配置为用作滑翔机。为此，UAV 600可以关闭其推进单元并滑行一段时间。

在飞行期间，UAV 600可以通过控制其俯仰、侧滚、偏航和/或高度来控制其运动的方向和/或速度。例如，稳定器602可以包括用于控制UAV的偏航的一个或多个方向舵604，并且机翼组件624可以包括用于控制UAV的俯仰的升降舵和/或用于控制UAV的侧滚的副翼610。作为另一个示例，同时增加或降低所有螺旋桨的速度可能导致UAV 600分别增加或降低其高度。UAV 600还可以包括用于感测UAV 600周围环境的组件，包括但不限于音频传感器622和音频传感器614。

图示的固定翼飞行器可以有许多变体。例如，具有更多机翼的飞行器(例如，具有四个机翼的“x翼”构型)也是可能的。尽管图6和图7示出了一个机翼组件624、两个悬臂组件606、两个水平推进单元612以及每个悬臂组件606的六个垂直推进单元608，但是应该理解的是，UAV 600的其他变体可以用更多或更少的这些组件来实现。

应该理解，本文提到的“无人”飞行器或UAV可以等同地适用于自主和半自主的飞行器。在完全自主的实施方式中，飞行器的所有功能都是自动化的；例如，经由响应来自各种传感器的输入和/或预定信息的实时计算机功能进行预编程或控制。在半自主的实施方式中，飞行器的一些功能可以由人类操作员控制，而其他功能自主地执行。此外，在一些实施例中，UAV可以被配置为允许远程操作员接管原本可以由UAV自主控制的功能。此外，给定类型的功能可以在一个抽象级别被远程控制，而在另一个抽象级别被自主执行。例如，远程操作员可以控制UAV的高级导航决策，诸如指定UAV应该从一个位置行进到另一个位置(例如，从郊区的仓库到附近城市的递送地址)，而UAV的导航系统自主地控制更细粒度的导航决策，诸如在两个位置之间采取的特定路线、在导航路线时实现路线规划和避开障碍物的特定飞行控制等等。在一些实施例中，UAV 600可以完全由远程驾驶员控制，而几乎没有自主能力。

在前面的描述中，阐述了许多具体细节，以提供对本公开的各种实施例的透彻理解。然而，相关领域的技术人员将会认识到，在没有一个或多个具体细节的情况下，或者利用其他方法、组件、材料等，也可以实践本文描述的技术。在其他情况下，没有详细示出或描述公知的结构、材料或操作，以避免模糊某些方面。

在整个说明书中提到“一个实施例”或“实施例”意味着结合该实施例描述的特定的特征、结构或特性被包括在本发明的至少一个实施例中。因此，短语“在一个实施例中”或“在实施例中”在整个本说明书中各处的出现不一定都是指同一实施例。此外，在一个或多个实施例中，特定的特征、结构或特性可以以任何合适的方式进行组合。

一些或所有框在每个方法流程图中出现的次序不应被认为是限制性的。相反，受益于本公开的本领域普通技术人员将理解，与一些框相关联的动作可以以未示出的各种次序执行，或者甚至并行执行。

上面解释的过程是就计算机软件和硬件而言来描述的。所描述的技术可以构成体现在有形或非暂时性机器(例如，计算机)可读存储介质中的机器可执行指令，当该机器可执行指令由机器执行时，将使得机器执行所描述的操作。另外，这些过程可以体现在硬件(诸如专用集成电路(“ASIC”)或其他)内。

本发明的图示实施例的以上描述，包括摘要中描述的内容，并不旨在穷举或将本发明限制于所公开的精确形式。虽然为了说明的目的在本文中描述了本发明的具体实施例和示例，但是相关领域的技术人员将会认识到，在本发明的范围内各种修改是可能的。

根据以上详细描述，可以对本发明进行这些修改。以下权利要求中使用的术语不应被解释为将本发明限制于说明书中公开的特定实施例。相反，本发明的范围将完全由下面的权利要求来确定，这些权利要求将根据权利要求解释的既定原则来解释。

Claims (20)

1.一种其上存储有逻辑的非暂时性计算机可读介质，所述逻辑响应于约束管理系统的一个或多个处理器的执行而使得所述约束管理系统执行用于自动生成飞行约束的通知的动作，所述动作包括：

由约束管理系统接收飞行计划信息，其中，所述飞行计划信息包括计划飞行区域和计划飞行时间段；

由约束管理系统查询约束数据存储，以取回与飞行计划信息相关的初始的约束定义集合；

由约束管理系统基于来自初始的约束定义集合的约束定义与清单项目集合的比较而生成用于呈现清单的信息；以及

由约束管理系统向用户设备发送用于呈现清单的信息以供呈现。

2.根据权利要求1所述的非暂时性计算机可读介质，其中，所述动作还包括：

由约束管理系统重新查询约束数据存储，以取回与飞行计划信息相关的更新的约束定义集合；

由约束管理系统将更新的约束定义集合与初始的约束定义集合进行比较；以及

由约束管理系统响应于检测到更新的约束定义集合与初始的约束定义集合之间的差异而向用户设备发送通知。

3.根据权利要求2所述的非暂时性计算机可读介质，其中，所述动作还包括：

以随时间增加的速率周期性地重复至少重新查询和比较动作，直到计划飞行时间段。

4.根据权利要求3所述的非暂时性计算机可读介质，其中，所述动作还包括：

在计划飞行时间段期间继续周期性地重复至少重新查询和比较动作。

5.根据权利要求1所述的非暂时性计算机可读介质，其中，所述飞行计划信息包括驾驶员的标识；以及

其中，查询所述约束数据存储以取回与飞行计划信息相关的初始的约束定义集合包括：查询约束数据存储以获取与来自同驾驶员相关联的用户简档的一个或多个驾驶员属性或一个或多个飞行器属性相关的约束定义。

6.根据权利要求5所述的非暂时性计算机可读介质，其中，所述一个或多个驾驶员属性包括许可状态、驾驶员最近飞行的时间、驾驶员的先前授权数量、驾驶员的当前位置、驾驶员的年龄和驾驶员的当地时间中的至少一个。

7.根据权利要求1所述的非暂时性计算机可读介质，其中，所述动作还包括：

由约束管理系统从至少一个第三方系统接收约束定义；以及

由约束管理系统将约束定义存储在约束数据存储中。

8.根据权利要求1所述的非暂时性计算机可读介质，其中，所述动作还包括：

由约束管理系统从至少一个第三方来源接收环境信息；

由约束管理系统基于环境信息生成约束定义；以及

由约束管理系统将约束定义存储在约束数据存储中。

9.根据权利要求8所述的非暂时性计算机可读介质，其中，所述环境信息包括过去天气状况信息、当前天气状况信息和未来天气预测信息中的至少一个。

10.根据权利要求1所述的非暂时性计算机可读介质，其中，所述动作还包括：

由约束管理系统从飞行器接收与飞行计划信息相关联的遥测数据；

由约束管理系统将遥测数据与飞行计划信息进行比较；以及

响应于确定遥测数据指示飞行器正在计划飞行区域之外操作：

由约束管理系统更新飞行计划信息，以覆盖包括由遥测数据指示的位置的飞行区域中的操作；

由约束管理系统重新查询约束数据存储，以取回与更新的飞行计划信息相关的新的约束定义集合；

由约束管理系统基于来自新的约束定义集合的约束定义与清单项目集合的比较而生成用于呈现新清单的信息；以及

由约束管理系统向用户设备发送用于呈现新清单的信息以供呈现。

11.一种其上存储有逻辑的非暂时性计算机可读介质，所述逻辑响应于计算设备的一个或多个处理器的执行而使得所述计算设备执行动作，所述动作包括：

由计算设备接收定义飞行计划信息的至少一部分的输入，其中，所述飞行计划信息包括计划飞行区域和计划飞行时间段；

由计算设备向约束管理系统发送飞行计划信息；

由计算设备从约束管理系统接收用于呈现与飞行计划信息相关的飞行约束状况的清单的信息；

由计算设备呈现清单；以及

响应于在计划飞行时间段之前从约束管理系统接收到指示飞行约束状况已经改变的通知：

由计算设备从约束管理系统接收用于呈现与飞行计划信息相关的飞行约束状况的更新的清单的信息；以及

由计算设备呈现更新的清单。

12.根据权利要求11所述的非暂时性计算机可读介质，其中，所述动作还包括：

由计算设备以随时间增加的速率周期性地从约束管理系统接收通知。

13.根据权利要求11所述的非暂时性计算机可读介质，其中，所述动作还包括：

在计划飞行时间段开始之后，由计算设备从约束管理系统接收与飞行计划信息相关联的飞行器已经离开计划飞行区域的通知；以及

由计算设备从约束管理系统接收用于呈现与更新的飞行区域相关的飞行约束状况的新清单的信息。

14.根据权利要求11所述的非暂时性计算机可读介质，其中，呈现所述清单包括：

由计算设备响应于接收到指示第一飞行类型的输入而呈现第一清单；以及

由计算设备响应于接收到指示第二飞行类型的输入而呈现第二清单。

15.一种系统，包括：

用户设备；以及

约束管理系统，包括一个或多个处理器以及至少一个其上存储有逻辑的计算机可读介质，所述逻辑响应于所述一个或多个处理器的执行而使得所述约束管理系统执行动作，所述动作包括：

由约束管理系统接收飞行计划信息，其中，所述飞行计划信息包括

计划飞行区域和计划飞行时间段；

由约束管理系统查询约束数据存储，以取回与飞行计划信息相关的初始的约束定义集合；

由约束管理系统基于来自初始的约束定义集合的约束定义与清单项目集合的比较而生成用于呈现清单的信息；以及

由约束管理系统向用户设备发送用于呈现清单的信息以供呈现。

16.根据权利要求15所述的系统，其中，所述动作还包括：

由约束管理系统重新查询约束数据存储，以取回与飞行计划信息相关的更新的约束定义集合；

由约束管理系统将更新的约束定义集合与初始的约束定义集合进行比较；以及

由约束管理系统响应于检测到更新的约束定义集合与初始的约束定义集合之间的差异而向用户设备发送通知。

17.根据权利要求16所述的系统，其中，所述动作还包括：

以随时间增加的速率周期性地重复至少重新查询和比较动作，直到计划飞行时间段。

18.根据权利要求17所述的系统，其中，所述动作还包括：

在计划飞行时间段期间继续周期性地重复至少重新查询和比较动作。

19.根据权利要求15所述的系统，其中，所述飞行计划信息包括驾驶员的标识；并且

其中，查询约束数据存储以取回与飞行计划信息相关的初始的约束定义集合包括查询约束数据存储以获取与驾驶员的属性相关的约束定义。

20.根据权利要求15所述的系统，还包括飞行器，并且其中，所述动作还包括：

由约束管理系统接收来自飞行器的遥测数据；

由约束管理系统将遥测数据与飞行计划信息进行比较；以及

响应于确定遥测数据指示飞行器正在计划飞行区域之外操作：

由约束管理系统更新飞行计划信息，以覆盖包括由遥测数据指示的位置的飞行区域中的操作；

由约束管理系统重新查询约束数据存储，以取回与更新的飞行计划信息相关的新的约束定义集合；

由约束管理系统基于来自新的约束定义集合的约束定义与所述清单项目集合的比较而生成用于呈现新清单的信息；以及

由约束管理系统向用户设备发送用于呈现新清单的信息以供呈现。