Patent Application
20190236966
Some embodiments disclosed herein relate to unmanned vehicles and, more particularly, to systems and methods implementing or using a centralized registry to manage unmanned vehicle traffic.
Unmanned vehicles (“UVs”), such as autonomous automobiles, drones or pilotless aircraft, cargo ships, and submarines, have several commercial and consumer uses (e.g., package delivery, imaging, or long-range inspection). It may be important, however, to coordinate the movement paths of multiple UVs with respect to each other, with respect to restricted airspace (e.g., around an airport), with respect to piloted aircraft, etc. Note that the utility offered by UVs may need to be balanced with the risk inherent in automated systems moving near people, other vehicles, and property. Manually coordinating UV traffic can be a complex and error-prone task, especially there are a substantial number of vehicles.
One approach to coordinating this type of traffic would be to have UVs communicate with each other to avoid collisions. Similarly, every UV might be equipped to radar or similar sensors to detect and locally avoid other UVs. Although these types of systems are possible, widespread implementation may be unlikely due to safety concerns. For example, all UVs would need to be fully equipped with the appropriate hardware and software components providing sense-and-avoid functionality, and failure of any of the devices could lead to dangerous situations.
It may therefore be desirable to achieve improved and computerized ways to efficiently and accurately facilitate management of unmanned aerial system traffic.
According to some embodiments, a centralized registry data store may contain electronic records that represent movement plan contracts for a UV. A centralized registry platform may receive information about a potential movement plan contract for a UV and dynamically create a potential multi-dimensional, time-indexed “volume” representing the potential movement plan contract. As used herein, the term “volume” may in some cases refer to an area (e.g., when the UV is associated with an autonomous vehicle or cargo ship). The centralized registry platform may then automatically compare the potential multi-dimensional, time-indexed volume with another volume representing another movement plan contract that was previously registered with the centralized registry platform. Based on a result of the comparison, the centralized registry platform may dynamically register the potential movement plan contract in the centralized registry data store.
Some embodiments comprise: means for receiving information about a potential movement plan contract for a UV; means for dynamically creating a potential multi-dimensional, time-indexed volume representing the potential movement plan contract; means for automatically comparing the potential multi-dimensional, time-indexed volume with another volume representing another movement plan contract that was previously registered with the centralized registry platform; and, based on a result of the comparison, means for dynamically registering the potential movement plan contract in the centralized registry data store, wherein the centralized registry data store contains electronic records that represent movement plan contracts for UVs.
Technical effects of some embodiments of the invention are improved and computerized ways to efficiently and accurately facilitate management of unmanned vehicle traffic. With these and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.
One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
It may therefore be desirable to achieve improved and computerized ways to efficiently and accurately facilitate UV traffic management. For example,
The centralized registry platform 150 and/or other elements of the system 100 might be, for example, associated with a Personal Computer (“PC”), laptop computer, a tablet computer, a smartphone, an enterprise server, a server farm, and/or a database or similar storage devices. According to some embodiments, an “automated” centralized registry platform 150 may automatically manage UV traffic. As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the centralized registry platform 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The centralized registry platform 150 may store information into and/or retrieve information from data stores, including the centralized registry data store 110. The data stores might, for example, store electronic records representing movement contracts, UV characteristics, operator identifiers, etc. The data stores may be locally stored or reside remote from the centralized registry platform 150. Although a single centralized registry platform 150 is shown in
As will be described, the system 100 may efficiently and accurately facilitate management of UV traffic. Note that the system 100 of
At 210, the system may receive information about a potential movement plan contract for a UV (e.g., representing a path the UV plans to travel). For example, a centralized registry platform may receive a potential Unmanned Aerial System (“UAS”), Unmanned Aerial Vehicle (“UAV”), or drone flight plan contract from an operator. According to other embodiments, the UV might be associated with, for example, an autonomous automobile (e.g., a passenger car or truck), cargo ship, submarine, etc.
At 220, the system may dynamically create a potential multi-dimensional, time-indexed volume representing the potential movement plan contract. In the case of an autonomous automobile or cargo ship, for example, the time-indexed volume might be two-dimensional while in the case of a drone or submarine, the time-indexed volume might be three-dimensional. At 230, the system may automatically compare the potential multi-dimensional, time-indexed volume with another volume representing another movement plan contract that was previously registered with the centralized registry platform.
Based on a result of the comparison, at 240 the system may dynamically register the potential movement plan contract in a centralized registry data store. Note that in some embodiments the centralized registry data store may be cloud-based and contain electronic records that represent movement plan contracts for UVs. The dynamically registered movement plan contract might include, for example an operator identifier, an equipment identifier, movement plan locations, an airspace identifier, behavioral attributes (e.g., a minimum or maximum drone speed), etc.
According to some embodiments, the centralized registry may further facilitate validation, in substantially real-time, of consistency of vehicle actions and dynamics relative to registered behavior. For example,
The operator may then use a display 400 such as the one illustrated in
Another display 500 with a map 510 may be presented after the system automatically compares a potential multi-dimensional, time-indexed volume 550 with another volume 560 (e.g., represented by a dotted line in
The distributed in-memory data grid short-term storage and synchronization services 620 may, according to some embodiments, let the system 600 scale and enable inter-service communication using event publish/subscribe interfaces. For example, multiple instance of the movement monitoring module 614 may execute on separate computing machine instances. In some cases, a movement plan request or a telemetry update may get routed to a specific instance of computing machine for processing, and updates made to the data structure by the target machine may be synchronized across other machines that are part of the same registry computing cluster using an in-memory data grid. Similarly, a service may raise (or publish) an event when certain conditions are encountered. That event may be replicated across other machine instances that are part of the registry computing cluster. Any other service that has subscribed to this event may also be notified, irrespective of the machine instance on which the subscriber service is executing.
Note that the in-memory data grid may store various data structures described herein for short-term purposes. To durably persist these data items, the persistent long-term storage 640 may use database systems. Note that various database systems may efficiently index and store this data on computing disks. The system 600 may use the data retrieval and archival services 630 provided by the various database system to execute appropriate queries to move appropriate datasets from the persistent long-term storage 640 to the in-memory grid. Similarly, the system 600 may use appropriate storing services to move the data from the in-memory grid storage to the persistent long-term storage 640.
In this way, embodiments may realize a collaboration for safe unmanned movement operations using logically centralized registry software that executes in a secure cloud computing environment and that provides various services to integrate with software executing on a UV or software executing on a controller system that can interface to a UV (or both). According to some embodiments, three core modules and several data structures may enable registry users to request and register movement plans, in advance or on-demand, monitor movement conformance in real-time, and/or flexibly manage airspace as a collection of dynamic volumes whose accessibility can be prescribed through actions of movement or airspace planning.
In some embodiments, registry software supports safe operations of unmanned aerial traffic through: (i) dynamic registration of operators, equipage, movement plans, airspaces and their behavioral attributes, and (ii) the validation in real-time of consistency of vehicle actions/dynamics relative to the registered behavior. Note that the illustration of
A centralized registry may implement a work flow that takes as input a movement operator request for a movement plan using a movement planning module. For example,
The scheduled traffic data store 720 may contain all of the planned UV traffic over a certain airspace for any given time in the future. The local atmospheric conditions data store 730 may interface with various weather service data providers to store current and predicted atmospheric conditions over any airspace. In the case of an unmanned submarine, the system may instead access ocean current information, tide data, etc. The UV data store 740 may represent a database of UV capabilities and feature sets. This might include, for example, UV weight, size, movement characteristics, maximum airtime, on-board movement control and navigation software, on-board sense-and-avoid capabilities, etc. The UV data store 740 may also map specific UV instances in the marketplace to stored UV capabilities and/or feature sets.
The movement planning module 750 may include a movement plan specification service 752 that allows a movement operator to request a movement plan. A movement plan request might include, for example, a starting location, an ending location, and a series of waypoints specified using geo-coordinates. Further, a movement plan may include timing, maneuvering, and speed constraints on the path's start, end, or middle waypoints. According to some embodiments, each movement plan is associated with a UV type. Once a movement plan request is received by the system 700, it can be logged and a request for movement plan event may be generated. The event may be shared, for example, via the distributed in-memory data grid or other peering external interfaces.
The movement planning module 750 may also include a trajectory computation service 754 that computes airspace volume along a path that meets the input movement plan constraints. The trajectory computation service 754 may also computes a time-window for the UV to be at a specific path-segment, the segment length and time-window both being configurable settings.
The path, the airspace volume along the path, and/or the timing information may collectively be referred to as a “trajectory.” Note that the system 700 may use several methods to compute a trajectory for a given movement plan. For example,
If the is no problem at 814, the impact of local atmospheric conditions (e.g., wind direction and speed) along the trajectory may be considered at 816. If there is a problem at 816, the movement plan may be modified at 850. If the is no problem at 816, the system may ensure that the trajectory respects the maximum and minimum height constraints for any requested movement plan (also considering the terrain across the path) at 818. If there is a problem at 818, the movement plan may be modified at 850.
If the is no problem at 818, the system may ensure that the trajectory maintains safe distance from vertical obstacles at 820. If there is a problem at 820, the movement plan may be modified at 850. If the is no problem at 820, the system may compare the trajectory against airspace restrictions and any UV operational restrictions that might be in place at 822. If there is a problem at 822, the movement plan may be modified at 850. If the is no problem at 822, the system may consider corridor-based lane assignments at 824 (if specific corridors are in use and applicable for a specific movement plan). If there is a problem at 824, the movement plan may be modified at 850.
If the is no problem at 824, the system may optimize the trajectory path elements in terms of speed, distance, energy consumption, etc. at 826. If there is a problem at 826, the movement plan may be modified at 850. Similarly, if the is no problem at 826, the system may select a trajectory (from a potentially large set of options) to economize use of airspace at 828. If there is a problem at 828, the movement plan may be modified at 850. According to some embodiments, the system may optionally consider the inclusion of contingency paths and maneuvers to allow the unmanned aircraft to accommodate unplanned scenarios during movement.
Finally, if the is no problem at 828, the system may ensure that the potential trajectory is conflict-free with other planned trajectories at 830. That is, no two trajectories should have overlapping airspace volume for an overlapping movement duration. If there is a problem at 830, the movement plan may be modified at 850. If the service cannot find a conflict-free trajectory, it may issue an appropriate warning/error message to the movement operator.
If there is no problem at 830 (that is, all of the requirements described with respect to
A centralized registry may implement a work flow that offers conformance monitoring and conflict detection and resolution services for safe UV movement operations using a movement monitoring module. For example,
The movement monitoring module 950 may also access a surveillance and telemetry data store 920. For example, a service may collect real-time location data from UV systems and store them in this data store 920. Note that the data collection might occur in multiple different ways. For example, the system 900 may provide interfaces so that UV real time location updates can be directly streamed to the system 900 using cellular or satellite communication systems. Optionally, an UV can stream location updates to other relay systems, including ground control stations that have direct communication links to the UV. As another example, the system 900 might ingest location update data streams from other commercial or governmental aggregation services (that might include, for example, telemetry for both manned and unmanned aerial systems).
The movement monitoring module 950 may include a conformance monitoring service to compare UV location update time-series data with the approved contract to ensure conformance. Upon detecting trajectory deviation beyond a contract specification, the system 900 may issue an alert. According to some embodiments, the system 900 may also issue an updated contract that may solve the out-of-conformance problem. Note that the system 900 might be configured such that the alert is issued immediately upon detection of a variation or might instead be set to trigger only when the variation results in a minimum loss of separation between the given UV and another adjacent UV.
The movement monitoring module 950 may also include a conflict detection and resolution service that searches conflicts in movement paths between both manned and unmanned aerials systems that are operating in a common airspace (e.g., conflicts that would likely result in a collision). Note that not all loss of separations might result in a collision, so the system 900 may make a distinction between loss of separation for a short period versus loss of separation that will probably result in a collision in the very near future. Upon detecting a high likelihood of collision, the service 954 may issue an appropriate alert notification with instructions to one or all the parties involved in the loss of separation. According to some embodiments, the system 900 may also issue commands in the form of a revised contract to one or more vehicles associated with the conflict. The instructions might be based, for example, upon the capabilities of the UV involved in the conflict. For example, one UAV might receive course-correction instructions while another receives directives to execute a default evasive maneuver.
The movement monitoring module 950 may also include an alert notifications service that listens for various events raised by other services. Upon detecting a new event, this service 956 may communicate an appropriate notification to the UV based upon how the UV is connected to the registry. According to some embodiments, a UV may be directly connected to the registry software or may be connected via a relay ground station that is in the administrative control of the movement operator.
A centralized registry may implement a work flow that manages the lifecycle of corridors, permanent and temporary airspace restrictions, and sharing of the airspace situational awareness with the subscribed users using airspace management module. For example,
The airspace management module 1150 may include a corridor management service 1152 to enable the ingestion of corridor definition from external data sources, the creation of new corridors, and the editing and deleting of existing corridors. As used herein, the term “corridor” might refer to, for example, an airspace above certain terrestrial geometry.
The airspace management module 1150 may also include an airspace constraint management service 1154 used by regulators and asset owners (who may have a right-of-way over the airspace above their assets) to provide temporary or permanent restrictions associated with certain types of UV traffic. For example, an Aviation Authority might prohibit movements in the proximity of public and private airports or may put temporary restrictions on movements over a stadium holding a public event.
The airspace management module 1150 may also include an airspace information dissemination service 1156 associated with terrain, obstacles, corridor definitions, airspace constraints, surveillance and telemetry, and local atmospheric conditions that may be disseminated to movement operators who subscribe to this information. The subscriptions might be, for example, specific to geographic areas and this service 1156 might appropriately push out updates periodically. The frequency of updates might depend on a subscription type. The system 1100 might support, for example, on-demand and batch updates. According to some embodiments, on-demand updates might be pushed out to subscribers as soon as they occur. In contrast, batch updates might be grouped over a configurable period and then pushed out collectively to a subscriber.
In this way, embodiments described herein may comprise a tool that facilitates the management of UV traffic and may be implemented using any number of different hardware configurations. For example,
The processor 1310 also communicates with a storage device 1330. The storage device 1330 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 1330 stores a program 1312 and/or network security service tool or application for controlling the processor 1310. The processor 1310 performs instructions of the program 1312, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1310 may implement a cloud-based, centralized registry data store may contain electronic records that represent movement plan contracts for UVs. The processor 1310 may initially receive information about a potential movement plan contract for a UV and the processor 1310 may dynamically create a potential multi-dimensional, time-indexed volume representing the potential movement plan contract. The processor 1310 may then automatically compare the potential multi-dimensional, time-indexed volume with another volume representing another movement plan contract that was previously registered with the centralized registry platform. Based on a result of the comparison, the 1310 processor may dynamically register the potential movement plan contract in the centralized registry data store.
The program 1312 may be stored in a compressed, uncompiled and/or encrypted format. The program 1312 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 1310 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the platform 1300 from another device; or (ii) a software application or module within the platform 1300 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The movement plan identifier 1402 may be, for example, a unique alphanumeric code identifying a UV trip. According to some embodiments, the centralized registry data store 1400 may further contain identifiers associated with a specific operator. In this case, only an authorized party (e.g., the U.S. Department of Defense) might be allowed to access and/or query the information. The movement plan trajectory 1404 might define the path of the trip, such as by listing a time-indexed series of geographic waypoints or a multi-dimensional ground referenced path. The UV type 1406 might indicate a model or manufacturer of a drone and may, according to some embodiments, be linked to one or more behavioral characteristics of the vehicle (e.g., a maximum or minimum speed). The status 1408 might indicate that the trip is over (“complete”), in movement (and whether or not an alert currently exists), approved and “registered,” determined to be in conflict, etc. For example, in
Some embodiments described herein may incorporate a mechanism to synchronize key information across registries so that safe and efficient UV operations can be realized at a global scale. For example,
According to some embodiments, authoritative registry instances 1510 may be responsible for one or more geo-political domains and execute all the component registry services described earlier. Since domains may overlap or a domain may be covered by multiple authoritative registries, information important for safe UV operations needs to be synchronized so that a single authoritative view can be presented for movement planning, monitoring, and airspace management. There may be multiple information sharing approaches to realize this synchronization. In some embodiments, this may be accomplished by using a broadcast and publish subscriber information exchange mechanisms as follows:
a) Each authoritative registry is connected, and always stays connected, to at least one other authoritative registry;
b) Each authoritative registry periodically broadcasts its domain of interest, and broadcast messages are propagated using the peering links established in (a);
c) Set of authoritative registries with overlapping domains establish a publish/subscribe link to exchange information using one of many filtering criteria. As an example, the filtering may be based upon geographic regions represented/modeled as circles or polygons; and
d) Using the links established in (c), the authoritative registries may always maintain a consistent view of data related to movement planning, movement monitoring, and dynamic airspace constraints.
According to some embodiments, client registry instances 1520 may interface to an authoritative registry and might not execute the full suite of component registry services described herein. In some cases, they may rely on an appropriate authoritative registry for conflict-free trajectory planning. Besides trajectory planning, these client registries may also subscribe to additional services from an authoritative registry for movement monitoring and airspace constraint management.
By allowing for the federation of multiple authoritative registries, information synchronization approaches including broadcast and publish/subscribe interfaces, and distributed collaboration between client and the corresponding authoritative registry, the system 1500 may achieve a global scale.
Thus, some embodiments described herein may provide technical advantages and enable collaboration between various movement operators and regulatory agencies so that unmanned aerial traffic can be safely regulated and safe unmanned movement operations can be realized. Embodiments may facilitate safe unmanned movement operations as the current approaches for managing air traffic will not scale for the very large number of expected unmanned movements. By providing a method and a system for the distributed collaboration and coordination between movement operators and regulators, embodiments help ensure that airspace can be safely and effectively timeshared.
The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., some of the information described herein may be combined or stored in external systems). Moreover, although embodiments have been described with respect to specific types of data, note that embodiments might be associated with other types of data, including other type of vehicles, automobiles, submarines, etc. Similarly, the displays shown and described herein are provided only as examples, and other types of displays and display devices may support any of the embodiments. For example,
The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
