Invented by Jeffrey Bosworth, Textron Innovations Inc
The Textron Innovations Inc invention works as follows
The invention relates to “Systems, Methods and Non-Transitory Computer Readable Storage Media for Airspace Management within an Airspace Region at a Node of a Peer-to-Peer Network having a Multiple of Nodes and Maintaining a Blockchain containing a Current Deconflicted Flight Schedule for the Area”. One method involves receiving requests for airspace reservation, each including flight data, from nodes via the peer-to-peer network. Compiling the data to identify conflicts, validating flight data of requests that don’t conflict with the deconflicted schedule and creating validated reservations.
Background for Node in a Blockchain Airspace Management System
Conventional air-traffic control systems” assist aircraft to take off from an airdrome of departure, such as a small airfield for general aviation, a large airport, or a military base, transit through controlled and uncontrolled airspace, and land at a destination. Ground-based air traffic controllers guide aircraft in controlled airspace such as airports and high-volume traffic areas. Air traffic controllers can also provide advice to aircraft flying in uncontrolled airspace. Air traffic control’s primary goal is to avoid collisions and to organize and speed up the flow of traffic. This is done by providing information to pilots and other forms of support. Air traffic control enforces rules for traffic separation that require aircraft to keep a minimum of space around them at all times in order to avoid collisions.
Traditionally, visual control of airspace by air traffic controllers in a tower has been the main method for controlling the airspace around an airport. Air traffic controllers, for example, are responsible both for the separation of aircraft on the runways and taxiways of an airport and in the surrounding airspace, such as 5-10 miles from the airport. Air traffic volume will increase as new air transportation forms are introduced, and as consumers rely on them more. This is true for both currently controlled and non-controlled airspace. A centralized system in which humans are a major part of the service provisioning, like traditional air traffic controls, is also susceptible to single-point failures, due, for instance, to data integrity problems and human error. In order to improve airspace management, it is necessary to develop a system that doesn’t rely on central data or systems. It should also be immune from single point failure.
The present disclosure is directed, in a first aspect to a system of airspace management within a region. The system is operated within a network of peer-to-peer nodes. The system contains a blockchain that includes the current flight schedule deconflicted for the airspace area. Each node has a non-transitory computer-usable storage resource, and a processor that is communicably connected to it. The processor executes the application code stored in the storage resources that are configured to allow the node to: receive one or more airspace reservation requests from other nodes via the peer-to-peer network; compile flight plan information to identify conflicts with the requests for reservations of airspace and the deconflicted current flight schedule; validate flight plan for requests for reservations of airspace that do not conflict the deconflicted current flight schedule, to generate validated airspace accommodations; create a “block” containing validated reservations;
In some embodiments, a node can be configured to accept a certain number of requests to reserve airspace before compiling flight plan data. In some embodiments, the node can be configured to accept requests for airspace reservation for a certain period of time before compiling flight plan data. In some embodiments, requests for airspace bookings may include options to prioritize airspace bookings. In these embodiments, node can be configured to optimize validated airspace bookings based on the prioritised airspace options included in the requests for reservations. In certain embodiments, a node can be configured to add the block permanently and irreversibly to the blockchain. In some embodiments, the node can be configured to broadcast to other nodes the newly deconflicted airspace schedule. In certain embodiments, the network node can be configured to reject requests for airspace reservation that are in conflict with the deconflicted flight plan of the blockchain.
In certain embodiments, flight plan data for each request for airspace reservation may include departure airdrome data, departure time, data on the airspace corridor, data on arrival airdrome data, and data on arrival time. In certain embodiments, the validation of an airspace reservation that corresponds to a request for reservations can include flight plan data. In some embodiments, the validated airspace booking that corresponds with a request of airspace reservations can include updated flight plan data. In certain embodiments at least some nodes can be flight control computers for unmanned aircraft. In certain embodiments, some nodes could be computer systems operated by pilots for manned aircraft. In some embodiments, a plurality of nodes can include an air taxi.
The method includes receiving one or more requests for airspace reservations from other nodes over the peer-to-peer network, each request for airspace reservations including flight plan data; compiling the flight plan data to identify conflicts between the requests for airspace reservation and the current deconflicted schedule; validating the flight plans of the requests for airspace reservations that do not conflict with the current deconflicted schedule to generate validated airspace bookings; creating a block containing the validated airspace bookings; and interlink The method comprises receiving one or multiple requests for reservations of airspace from other nodes via the peer-to-peer network. Each request for reservations includes flight plan information. Compiling flight plan data is used to identify conflicts with the current schedule. Validating flight plan for those requests that are not in conflict with the schedule generates validated reservations.
The method can also include a number of predetermined requests for reservations before compiling flight data, receiving the requests for reservations for a certain time period prior to compiling flight data, optimizing reservations based on the priority airspace options included in the requests for reservations, permanently and irrevocably adding the block into the blockchain and broadcasting the deconflicted new flight schedule to other nodes via the peer-to-peer network.
The computer-readable instructions include instructions configured to cause the computer to receive one or more requests for airspace reservations from other nodes over the peer-to-peer network, each request for airspace reservations including flight plan data; compile the flight plan data to identify conflicts between the requests for airspace reservation and the current deconflicted schedule; validate the flight plans of the requests for airspace reservations that do not conflict with the current deconflicted schedule to generate validated airspace bookings; create a block containing the validated The computer-readable instruction set includes instructions that cause the computer receives one or more requests from other nodes on the peer-to peer network for airspace reservation, with each request including flight data. Compile the flight data to identify conflicts with the requests and current deconflicted schedule. Validate the flight data of the valid airspace reservation requests that do not conflict. Create a block that contains the validated reservations. Interlink the block to the blockchain so that it contains a deconflicted new flight schedule.
While the following discussion will go into detail about the various embodiments, it is important to note that the disclosure contains many inventive concepts which can be applied in different contexts. The embodiments described herein are only illustrative, and do not limit the scope of this disclosure. To ensure clarity, some features of a real implementation may not be included in the disclosure. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developer’s specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. It will also be understood that a complex and lengthy development effort would be routine for anyone with ordinary knowledge of the art who has the benefit of the disclosure.
Referring to FIG. In Figure 1, an airspace area with air taxi services has been schematically shown and is generally called 10. Airspace region 10 can be located over any geographic area, such as a metropolitan area that includes one or more cities like the Dallas/Fort Worth Metroplex. The term airspace region can be used to refer to an airspace managed by the blockchain airspace system disclosed herein. Airspace region 10 in the illustrated embodiment includes airports 12, 14 and 16 that provide air passenger or air cargo services. Preferably, each airport 12, 14, 16, provides air traffic services near the airport. Flights to and from airports 12, 14 16 usually have well-defined routes of arrival and departure. The controlled airspace, as well as the associated arrival and departure routes, may be separate from or included in the blockchain airspace-management system disclosed here.
While the flights that depart or arrive at airports 12, 14 and 16 are usually long-range flights, arriving or departing an airport outside the airspace area 10, the primary focus of this embodiment of the Blockchain airspace management system illustrated is on air taxi services. Short and medium-range flights depart and land within the airspace zone 10. Other embodiments of the air taxi service, however, could allow certain flights to depart or arrive outside an airspace area. The air taxis in the present disclosure can takeoff or land without runways, and they are preferably vertical-takeoff and landing aircraft. The air taxis in the present disclosure can, for example, use a vertical lift mode or helicopter mode to takeoff and land and a forward thrust mode or airplane mode that uses wing-borne flight, for high speed, extended range, and/or efficient flight. Air taxis can also be configured to fly in helicopter mode, including for takeoffs and landings.
In the illustration, air taxis transport people between microairdromes in airspace region 10. Air taxi 18 provides air passenger transport between microairdromes 20 and 22 along airspace route 24. Air taxis 26, 34 provide air passenger transport between microairdromes 28 and 30 along airspace route 32. Microairdromes can be located anywhere that is suitable and/or desirable for an air taxi takeoff and landing. Microairdromes can be designated permanently in areas such as parking lots, parking structures, buildings, or residential neighborhoods. They may also have similar designations to helipads. Microairdromes can also be designated as areas temporarily used by air taxis such as driveways. Air taxis can be pilot-operated, remotely operated or autonomously controlled aircraft. The air taxis are preferably equipped with digital flight control computers to manage flight operations and can be nodes in the blockchain airspace system.
In the illustrated embodiment, the air taxis provide safe, efficient, low noise and environmentally-friendly air passenger transportation between microairdromes on a short to medium range basis. FIG. FIG. Air taxis in airspace region 10 should be kept apart by a minimum of space at all times to ensure safety. Air taxis 18 and 26 travel in different airspace zones 24, 32, for example. While air taxis 26 and 34 travel in the same airspace, they are separated by their time. The airspace is used in a random manner, unlike the traffic patterns at airports. Arrival and departure corridors are relatively constant. In such conditions, conventional air traffic control systems cannot effectively organize and accelerate the flow of traffic.
In the current embodiments, this high-volume and diverse air traffic is managed using a blockchain airspace system. This system receives requests for reservations of airspace, validates reservations that are not in conflict, and maintains a secure flight schedule for the air taxi services within airspace region 10. Each air taxi, for example, is preferably a network node that receives requests from other nodes within the network to reserve airspace within airspace area 10. Nodes can then compete with each other to create and distribute an updated deconflicted airspace schedule. The competition involves compiling flight data from requests to identify conflicts with a current deconflicted schedule maintained in the Blockchain, validating flight data of requests that don’t conflict with the deconflicted schedule to generate validated reservations for airspace, creating a blocked containing validated reservations for airspace, and linking the block to the blockchain so that the blockchain contains a new deconflicted schedule for airspace area 10 that is broadcasted to other nodes via the peer-to-peer network.
Referring to FIG. A systems diagram 2 is shown, which illustrates the components of a Blockchain airspace management system. The system 50 shown in the illustration is a peer-to-peer network with a number of nodes 52, 54, 56, 58, denoted by node 1, node 2 and node 3. . . Node N represents any number of nodes in system 50. Nodes 52 to 58 can communicate over a network 60 such as the Internet, PKI, or a secure intranet. Each node 52-58 executes a Blockchain Reservation Application 62 (BCRA), which together forms the blockchain airspace system 50. The BCRA maintains a deconflicted flight plan for airspace area 10 on a blockchain. The blockchain airspace management system 50 offers significant advantages over traditional air traffic systems, including the removal of single point failures through disintermediation. The blockchain airspace management 50 system also maintains a flight schedule which is accurate, complete, and timely. “The use of blockchain airspace system 50 creates not only data transparency, but also data safety as the validated airspace reservations in the blockchain airspace system 50 cannot be changed or deleted.
As best seen in FIG. Node 52, the peer-to-peer network, will be described in greater detail. Node 52 represents the other nodes in blockchain airspace system 50 such as nodes 56, 58. Therefore, to maximize efficiency, certain features are only disclosed with respect to node 52. A person of ordinary skill will be able to fully understand the other nodes from the information provided herein. Node 52 comprises a computing device 70, such as a mobile phone, laptop, tablet, server, embedded system, computing system, flight control computer or other hardware platform. Computing machine 70, for example, may be a distributed computer system that is configured to operate using multiple computing elements connected via a bus or data network. Computing machine 70 is responsive to an application module 72, which may include one or more software or hardware elements, including operating system applications, kernel space applications, and user space applications. These are designed to assist computing machine 70 to perform the various processing functions and methods presented herein, like BCRA 62. Computing machine 70 in the illustrated embodiment includes various internal components or attached components, such as a CPU 74, a bus system 76, memory system 78, storage medium 80, input/output interfaces 82, and a network 84 interface for communication with external networks like network 60, GPS networks, and cellular networks.
Processor 74 can be designed to run code instructions to perform operations and functionality described in this document, manage request flows and address mappings and perform calculations and create commands. Processor 74 can be configured to monitor the operation of other components within computing machine 70. Processor 74 can be a general-purpose processor, processor core, multiprocessor (ASIC), microcontroller (DSP), controller (ASIC), state machine (gated logic), discrete hardware components (DHC), any other processing unit or any combination thereof. Processor 74 can be a single processor, multiple processors, a processing core, many processing cores or special purpose cores. In certain embodiments, the processor 74, together with other components, may be a virtualized computing device executing in one or more computing machines.
System memory 78 can include non-volatile memory such as read only memory (ROM), programable read only memory (PROM), eraseable programmable memory (EPROM), or flash memory. It may also include any other device that is capable of storing data or instructions with or without power. System memory 78 can also include volatile memory such as random-access memory (RAM), static random-access memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), or other types. System memory 78 can be implemented with a single memory or multiple memory modules. Although system memory is shown as part of computing device 70, those skilled in the art would recognize that system memories 78 can be separated from computing device 70 without departing the scope of subject technology. “It should be understood that system memory may also include or work in conjunction with a non-volatile device, such as storage medium 80.
Storage media 80 can include a hard drive, a floppy disc, a compact disk read-only memory CD-ROM, a digital versatile disk (DVD), Blu-ray, a magnetic cassette, a Flash memory, another non-volatile device memory, a Solid State Drive (SSD), a magnetic storage device or optical storage device. It could also be an electrical storage device or semiconductor storage device. Storage media 80 can store data, applications, program modules and operating systems. Storage media 80 can be connected or part of computing machine 70. Storage media 80 can also be a part of other computing machines in communication with computing device 70, such as servers or database servers.
Applications module 72 may comprise one or more hardware or software elements configured to facilitate computing machine 70 with performing the various methods and processing functions presented herein. Applications module 72 may include one or more algorithms or sequences of instructions, such as an instance of blockchain reservation application 62, stored as software or firmware in association with system memory 78, storage media 80 or both. Storage media 80 may therefore represent examples of machine or computer readable media on which instructions or code can be stored for execution by processor 74. Machine or computer readable media may generally refer to any medium or media used to provide instructions to processor 74. Such machine or computer readable media associated with applications module 72 may comprise a computer software product. It should be appreciated that a computer software product comprising applications module 72 may also be associated with one or more processes or methods for delivering applications module 72 to computing machine 70 via a network, any signal-bearing medium, or any other communication or delivery technology. Applications module 72 may also comprise hardware circuits or information for configuring hardware circuits such as microcode or configuration information for an FPGA or other PLD. In one exemplary embodiment, applications module 72 may include algorithms capable of performing the functional operations described by the flow charts and computer systems presented herein for blockchain airspace management system 50.
The “Input/output interface (I/O), 82” may be configured in a way that it couples to one or multiple external devices to receive data and send data back to them. These external devices, along with various internal devices, can be referred to as peripheral devices. I/O interfaces 82 can include electrical and physical connections to connect peripheral devices with computing machine 70 or processor 74. I/O Interface 82 can be configured to transmit data, addresses and control signals from peripheral devices to computing machine 70 or processor 74. I/O interfaces 82 can be configured to implement standard interfaces such as small computer systems interface (SCSI), serial attached SCSI (SAS), Fiber Channel, PCI, PCI Express (PCIe), parallel bus, serial bus, advanced technology connected (ATA), Serial ATA (SATA), Universal serial bus (USB), Thunderbolt and FireWire. I/O Interface 82 can be configured to only implement one bus or interface technology. I/O interfaces 82 can be configured to implement more than one interface or bus technology. I/O interfaces 82 can be configured to work with system bus 76, as part of it, or in combination with it. I/O interface may include buffers to buffer transmissions between external devices and/or internal devices.
