Multi-uav real-time space-time relationship calculation method based on high-performance language development

Abstract

The application provides a multi-unmanned aerial vehicle real-time space-time relationship calculation method based on high-performance language development, which constructs an event-driven architecture of a data access layer, an event coordination layer, a calculation engine, and a storage and release layer, the calculation engine is realized by using a high-performance compiled language of Go, Rust or C++, state data is isolated according to flight ID, and a lock-free / low-lock design is adopted. The method realizes the whole-process adaptation of flight path plan initialization, regular position update calculation and diversion processing calculation through standardized event flow conversion, completes three-dimensional space distance calculation in combination with a WGS84 ellipsoid, designs double-ETA calculation logic before and after take-off, realizes waypoint arrival judgment and state conversion based on a configurable three-dimensional distance threshold. The application realizes second-level real-time 4D profile calculation, supports multi-unmanned aerial vehicle concurrency and dynamic diversion, has strong system decoupling and good scalability, and provides accurate real-time space-time data support for unmanned aerial vehicle traffic management, conflict early warning and post-analysis.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) operation management technology, and in particular to a method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language. Background Technology

[0002] In the scenario of low-altitude drone operation and supervision, regulators and airport operators need to accurately grasp the time-space four-dimensional relationship of each drone and obtain real-time information such as estimated time of arrival (ETA), actual time of arrival, and waypoint passing status, so as to carry out drone traffic management, conflict early warning and post-event analysis.

[0003] Existing technologies for calculating the spatiotemporal relationship of UAVs mainly fall into three categories: Solution A uses scripting / interpreted languages ​​such as Python to poll data through message queues or databases and calculate ETA in batches. This is simple to implement but has limited single-machine throughput and real-time performance, and multi-machine expansion relies on additional scheduling and state synchronization; Solution B uses Java and enterprise middleware, with the calculation module tightly coupled to the business logic. In multi-UAV scenarios, thread and lock contention is significant, and latency and resource consumption increase rapidly with scale; Solution C only implements simple ETA calculation for a single or a small number of UAVs, does not support multi-segment or rerouting processing, and lacks multi-machine concurrency and unified event pipeline design.

[0004] The above solutions share several drawbacks: insufficient real-time performance and throughput, making it difficult to meet the requirements for second-level real-time 4D profile calculations; poor scalability with multiple UAVs, leading to latency jitter and decreased throughput when concurrency increases; lack of effective support for rerouting and multi-segment operations, making it unable to handle dynamic route changes; a single method for calculating spatiotemporal relationships, resulting in low accuracy in ETA estimation; imperfect arrival determination and state machine, prone to misjudgments or duplicate updates; and high system architecture coupling, making it difficult to independently expand or replace each component. Summary of the Invention

[0005] The purpose of this invention is to provide a real-time spatiotemporal relationship calculation method for multiple UAVs based on a high-performance language, aiming to solve the technical problems of low real-time performance, poor scalability, lack of support for flight path changes, and single calculation model in spatiotemporal relationship calculation in multi-UAV scenarios, so as to achieve low latency and high throughput real-time spatiotemporal relationship calculation, while improving the scalability and maintainability of the system.

[0006] According to one objective of the present invention, this invention provides a method for real-time spatiotemporal relationship calculation of multiple unmanned aerial vehicles (UAVs) based on a high-performance language. It constructs an event-driven architecture comprising a data access layer, an event coordination layer, a calculation engine, and a storage and publishing layer. Each layer is sequentially connected to form a pipeline of access → coordination → calculation → storage / publishing. The calculation engine is implemented using a high-performance compiled language. The method includes the following steps: S1: The data access layer receives route plans, route status, and position / crossing point reports from multiple UAVs, converts them into internal events, and sends them to the event coordination layer; S2: The event coordination layer parses the data type of the internal event. If it is a route plan update event, step S3 is executed; if it is a position / passing point update event, step S4 is executed. S3: The calculation engine updates the route plan and status cache of the corresponding flight. If it is the first initialization of the flight, it calls the pre-departure logic of the ETA calculation unit to generate the initial estimated arrival time of each waypoint, writes it into the arrival status cache, and optionally publishes the initial pass-through report, and returns to step S1. S4: The calculation engine determines whether there is flight change data. If it exists, proceed to step S5; otherwise, proceed to step S6. S5: The calculation engine merges the original route and the rerouted route segment into a new route sequence through the rerouting processing unit, performs ETA calculation and arrival determination on the merged route in sequence, updates the arrival status cache and generates a complete transit report, and executes step S7. S6: The calculation engine calculates the remaining cumulative distance of the route to the first unreached waypoint based on the real-time position of the UAV and the current route plan, calls the takeoff logic of the ETA calculation unit to update the ETA, determines the arrival status based on the three-dimensional distance threshold through the arrival determination and state machine unit and completes the state transition from PLANNED to EN_ROUTE to ARRIVED, summarizes and forms a passing point report, and executes step S7. S7: The storage and publishing layer stores the transit report, ETA, drone trajectory, and arrival information, and publishes the ETA and transit report to the message queue for downstream systems to consume, then returns to step S1.

[0007] Furthermore, the high-performance compiled language is Go, Rust, or C++; the computing engine isolates the status data of each UAV by flight ID and adopts a lock-free / low-lock design to achieve concurrent computing of multiple UAVs.

[0008] Furthermore, the computing engine incorporates a cache unit and a computing unit. The cache unit includes a route plan and status cache, an arrival status cache, and a location history cache. The computing unit includes a spatial distance calculation unit, an ETA calculation unit, an arrival determination and state machine unit, and a rerouting processing unit.

[0009] Furthermore, the spatial distance calculation unit is based on the WGS84 ellipsoid, uses the horizontal Haversine formula to calculate the horizontal arc length between two points, combines the height difference between the two points to synthesize the three-dimensional spatial straight-line distance, and outputs the calculation result in meters.

[0010] Furthermore, the ETA calculation unit implements two sets of calculation logic: pre-takeoff and post-takeoff. Pre-takeoff logic: based on the start time of the route plan, the three-dimensional spatial distance of each segment is accumulated in the order of the route, and the initial ETA of each waypoint is calculated by combining the cruise speed and the time buffer coefficient. Post-takeoff logic: based on the current time, the sum of the straight-line distance from the current position of the UAV to the first unreached waypoint and the cumulative distance of the route from the first unreached waypoint to the subsequent unreached waypoints is calculated, and the real-time ETA is calculated by combining the sliding average speed of the position history cache and the safety factor.

[0011] Furthermore, the arrival determination and state machine unit is configured with an adjustable three-dimensional distance threshold to construct a geofence. The three-dimensional distance between the UAV and the current waypoint is obtained through the spatial distance calculation unit. If the distance is less than or equal to the threshold, the UAV is determined to have entered the geofence. Combined with the arrival status of the previous waypoint, the waypoint status is uniformly converted, and the actual arrival time is recorded. The three-dimensional distance threshold supports differentiated configuration according to waypoint type. The threshold for airport take-off and landing points is 50-100 meters, and the threshold for ordinary waypoints is 100-150 meters. The arrival determination and state machine unit can also add time-assisted determination rules. If the UAV's ETA exceeds the expected transit time and the status is EN_ROUTE, it is determined that the UAV has arrived at the waypoint.

[0012] Furthermore, the rerouting processing unit reads the rerouting two-dimensional array and the original transit report, and merges the original route and the rerouting route segment into a new route sequence in time and space order; for each waypoint of the merged route, it calls the spatial distance calculation unit, the ETA calculation unit, the arrival determination and state machine unit, updates the arrival state cache, and generates a complete transit report containing the original route and the rerouting route.

[0013] Furthermore, the data access layer supports one or more combinations of Redis subscription / polling, MQTT, Kafka, HTTP callback, or proprietary protocols to parse and transform the accessed non-standardized data into standardized internal events containing flight IDs, data types, and data content.

[0014] Furthermore, the event coordination layer uses an event bus and observer pattern to decouple events, calls the corresponding interface of the computing engine according to the data type of the internal events, and forwards the results returned by the computing engine to the storage and publishing layer; the event coordination layer and the computing engine interact through interface calls, and the computing engine provides standardized interfaces for updating route plans, processing position updates, processing rerouting, and obtaining flight arrival status.

[0015] Furthermore, the storage and publishing layer adopts an interface abstraction design, and the storage medium supports one or more combinations of Elasticsearch, MySQL, InfluxDB, MongoDB or Redis, and the message queue supports one or more combinations of Kafka, RabbitMQ or Redis. The storage and publishing layer persists or caches the drone trajectory and arrival information, publishes ETA and pass-through reports to the message queue, and writes back core status data to the cache medium as needed.

[0016] The technical solution of this invention constructs a four-layer event-driven architecture and uses a high-performance compiled language to develop a computing engine, forming a standardized access-coordination-computation-storage / publishing pipeline to achieve efficient real-time spatiotemporal relationship calculation for multiple UAVs. It supports initial ETA generation for route planning initialization, handles real-time ETA calculation and waypoint state transitions for routine position updates, and can also complete route merging and recalculation after rerouting, achieving state isolation and concurrent processing for multiple UAVs. It effectively solves the problems of low real-time performance, poor scalability, and lack of support for dynamic rerouting in existing technologies, achieving second-level 4D profile calculation, adapting to the dynamic operation requirements of UAVs, while ensuring the storage and efficient publication of calculation results, providing accurate and real-time spatiotemporal data support for UAV traffic management and conflict early warning. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a system principle block diagram according to an embodiment of the present invention; Figure 2 This is a block diagram of the computing engine in an embodiment of the present invention; Figure 3 This is the main flowchart for real-time spatiotemporal relationship calculation in an embodiment of the present invention.

[0019] In the diagram: 101. Data Access Layer; 102. Event Coordination Layer; 103. Computing Engine; 104. Storage and Publishing Layer; 201. Route planning and status cache; 202. Arrival status cache; 203. Position history cache; 204. Spatial distance calculation unit; 205. ETA calculation unit; 206. Arrival determination and state machine unit; 207. Rerouting processing unit. Detailed Implementation

[0020] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0022] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified. Furthermore, the terms "installed," "connected," and "linked" should be interpreted broadly; for example, they may refer to a fixed connection, a detachable connection, or an integral connection; they may refer to a mechanical connection or an electrical connection; they may refer to a direct connection or an indirect connection through an intermediate medium; and they may refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0023] Example 1 like Figures 1-3 As shown, a real-time spatiotemporal relationship calculation method for multiple UAVs based on a high-performance language is proposed. This method includes constructing an event-driven architecture comprising a data access layer 101, an event coordination layer 102, a calculation engine 103, and a storage and publishing layer 104. The layers are sequentially connected to form a pipeline of access → coordination → calculation → storage / publishing. The calculation engine is implemented using a high-performance compiled language. The method includes the following steps: S1: The data access layer receives route plans, route status, and position / crossing point reports from multiple UAVs, converts them into internal events, and sends them to the event coordination layer; S2: The event coordination layer parses the data type of the internal event. If it is a route plan update event, step S3 is executed; if it is a position / pass point update event, step S4 is executed. S3: The calculation engine updates the route plan and status cache for the corresponding flight. If it is the first initialization of the flight, it calls the pre-departure logic of the ETA calculation unit to generate the initial estimated arrival time (ETA) for each waypoint, writes it to the arrival status cache, and optionally publishes the initial pass-through report, and returns to step S1. S4: The calculation engine determines whether there is flight change data. If it exists, proceed to step S5; otherwise, proceed to step S6. S5: The calculation engine merges the original route and the rerouted route segment into a new route sequence through the rerouting processing unit. It then performs ETA calculation and arrival determination on the merged route in sequence, updates the arrival status cache, generates a complete transit report, and executes step S7. S6: The calculation engine calculates the remaining cumulative distance of the route to the first unreached waypoint based on the real-time position of the UAV and the current route plan. It calls the takeoff logic of the ETA calculation unit to update the ETA. The arrival status is determined by the arrival judgment and state machine unit based on the three-dimensional distance threshold, and the state transition from PLANNED to EN_ROUTE to ARRIVED is completed. The results are summarized to form a passing point report, and step S7 is executed. S7: The storage and publishing layer stores the transit report, ETA, drone trajectory, and arrival information, and publishes the ETA and transit report to the message queue for downstream systems to consume, then returns to step S1.

[0024] Specifically, the high-performance compiled language is Go, Rust, or C++. The computing engine isolates the status data of each UAV by flight ID and adopts a lock-free / low-lock design to achieve concurrent computing of multiple UAVs.

[0025] The computing engine has built-in cache and computing units. The cache unit includes route planning and status cache, arrival status cache, and position history cache. The computing unit includes spatial distance calculation unit, ETA calculation unit, arrival determination and state machine unit, and rerouting processing unit.

[0026] The spatial distance calculation unit is based on the WGS84 ellipsoid. It uses the horizontal Haversine formula to calculate the horizontal arc length between two points, combines the height difference between the two points to synthesize the three-dimensional straight-line distance, and outputs the calculation results in meters.

[0027] The ETA calculation unit implements two sets of calculation logic: pre-takeoff and post-takeoff. Pre-takeoff logic: Based on the start time of the route plan, the three-dimensional spatial distance of each segment is accumulated in the order of the route, and the initial ETA of each waypoint is calculated by combining the cruise speed and the time buffer coefficient. Post-takeoff logic: Based on the current time, the sum of the straight-line distance from the current position of the UAV to the first unreached waypoint and the cumulative distance of the route from the first unreached waypoint to the subsequent unreached waypoints is calculated, and the real-time ETA is calculated by combining the sliding average speed of the position history cache and the safety factor.

[0028] The arrival determination and state machine unit is configured with an adjustable three-dimensional distance threshold to construct a geofence. The three-dimensional distance between the UAV and the current waypoint is obtained through the spatial distance calculation unit. If the distance is less than or equal to the threshold, the UAV is determined to enter the geofence. Combined with the arrival status of the previous waypoint, the waypoint status is uniformly converted and the actual arrival time is recorded.

[0029] The three-dimensional distance threshold supports differentiated configuration according to waypoint type. The threshold for airport take-off and landing points is 50-100 meters, and the threshold for ordinary waypoints is 100-150 meters. The arrival determination and state machine unit can also add time-assisted determination rules. If the UAV's ETA exceeds the expected passing time and the state is EN_ROUTE, it is determined that the waypoint has been reached.

[0030] The rerouting processing unit reads the rerouting two-dimensional array and the original transit report, and merges the original route and the rerouting route segments into a new route sequence in time and space order; for each waypoint of the merged route, it calls the spatial distance calculation unit, ETA calculation unit, arrival determination and state machine unit to update the arrival status cache and generate a complete transit report containing the original route and the rerouting route.

[0031] The data access layer supports one or more combinations of Redis subscription / polling, MQTT, Kafka, HTTP callback, or proprietary protocols to parse and transform the incoming non-standardized data into standardized internal events containing flight ID, data type, and data content.

[0032] The event coordination layer uses an event bus and observer pattern to decouple events. It calls the corresponding interface of the computing engine according to the data type of the internal events and forwards the results returned by the computing engine to the storage and publishing layer.

[0033] The storage and publishing layer adopts an interface abstraction design. The storage medium supports one or more combinations of Elasticsearch, MySQL, InfluxDB, MongoDB or Redis, and the message queue supports one or more combinations of Kafka, RabbitMQ or Redis. The storage and publishing layer persists or caches the drone trajectory and arrival information, publishes ETA and pass-through reports to the message queue, and writes back the core status data to the cache medium as needed.

[0034] The event coordination layer and the computing engine interact through interface calls. The computing engine provides standardized interfaces for updating route plans, processing location updates, processing rerouting, and obtaining flight arrival status.

[0035] Specifically, in the multi-UAV real-time spatiotemporal relationship calculation method based on high-performance language provided by this invention, the event-driven architecture, which includes a data access layer, an event coordination layer, a computing engine, and a storage and publishing layer, is described in detail below: Data Access Layer 101: Receives flight plans, flight status, and position / passage reports from multiple drones. Data access can be achieved through Redis subscription / polling, MQTT, Kafka, HTTP callback, or proprietary protocols, and the accessed data is transformed into internal events that the computing engine can consume. Event Coordination Layer 102: Generates internal events such as route plan updates, position updates, and route status changes based on the type of access data. It uses an event bus and observer pattern to achieve decoupling and drives the computing operations of the downstream computing engine and the publishing operations of the storage publishing layer. Computing Engine 103: This is the core computing unit of the system. It isolates the status data of each UAV by flight ID and has built-in route planning and status cache 201, arrival status cache 202, position history cache 203, as well as spatial distance calculation unit 204, ETA calculation unit 205, arrival determination and state machine unit 206, and rerouting processing unit 207 to realize ETA calculation, arrival determination, status update and rerouting processing of multiple UAVs. Storage and Publishing Layer 104: Writes the drone's trajectory and arrival information to storage media such as Elasticsearch and MySQL, and publishes ETA, pass-through reports, and trajectory messages to message queues such as Kafka and Redis for downstream systems to consume. The storage and publishing interface adopts an abstract design, which supports flexible replacement of implementation schemes.

[0036] The core computational process of the computing engine includes: Route plan initialization: When a UAV route plan update event is received, the route plan and status cache are updated. If it is the first initialization of the flight, the pre-takeoff logic of the ETA calculation unit is called to generate the initial ETA for each waypoint, write it to the arrival status cache, and optionally publish the initial pass-through report. Regular position update calculation: When there is no rerouting data, the remaining cumulative distance to the first unreached waypoint is calculated based on the real-time position of the UAV and the current route plan. The ETA calculation unit is called to update the ETA after takeoff. The arrival status is determined by the arrival judgment and state machine unit based on the three-dimensional distance threshold, and the state transition from PLANNED to EN_ROUTE to ARRIVED is completed. Rerouting processing calculation: When rerouting data is detected, the rerouting processing unit merges the original route and the rerouting route segment into a new route sequence. ETA calculation and arrival determination are performed on the merged route in sequence, the arrival status cache is updated, and a complete transit report containing the original route and the rerouting route is generated. Output results: Synchronize the calculated ETA, passing point reports, and status information to the storage and publishing layer to complete the data storage and publishing.

[0037] The spatiotemporal calculation model of this invention is based on the WGS84 ellipsoid. The spatial distance calculation unit uses the horizontal Haversine formula plus altitude difference to calculate the three-dimensional spatial distance between two points. The ETA calculation unit implements two sets of logic before takeoff and after takeoff. Before takeoff, the initial ETA is calculated by accumulating the spatial distance of each segment according to the route sequence based on the planned start time and combining the cruise speed and time buffer coefficient. After takeoff, the real-time ETA is calculated by accumulating the distance of the remaining route and the sliding average speed of the position history based on the current time. The arrival determination and state machine unit constructs a geofence based on a configurable three-dimensional distance threshold, combines the arrival status of the previous waypoint to complete the unified conversion of the UAV waypoint status, and records the actual arrival time.

[0038] Example 2 like Figures 1-3 As shown, this embodiment is a method for real-time spatiotemporal relationship calculation of multiple drones based on Go language, Redis+MQTT data access, and Kafka+Elasticsearch+MySQL storage. The specific implementation is as follows: 1. System Architecture Deployment: A distributed system consisting of a data access layer 101, an event coordination layer 102, a computing engine 103, and a storage and publishing layer 104 is constructed. Each layer is deployed independently and communicates with the network. The computing engine 103 is developed in Go language and uses coroutines to achieve high-concurrency processing. It uses sync.Map by flight ID to achieve lock-free storage of state data, ensuring low latency under multiple drone concurrency.

[0039] 2. Data Access Layer 101 Implementation By subscribing to online_flighttask:{flightID}, the route status key, and the location / pass report key through the Redis client, the flight plan and static status data of the drone can be obtained by polling. Subscribe to drone location topics via an MQTT client to receive real-time dynamic location / pass-through reports from the drone; The incoming route plan JSON, status change information, and location / passage payload are parsed and standardized, and transformed into internal events containing flight ID, data type, and data content, which are then sent to the event coordination layer 102.

[0040] 3. Event Coordination Layer 102 Implementation Deploy the Coordinator service, which receives internal events from the data access layer 101 within the process and achieves event decoupling based on the event bus and observer pattern; Parse the data type of the event. If it is a route plan update event, call the UpdateFlightPlan interface of the calculation engine 103; if it is a position / pass point update event, call the ProcessPositionUpdate interface of the calculation engine 103; if a change of route event is detected, call the ProcessRouteChange interface of the calculation engine 103. The calculation results, such as ETA, arrival status, and passing point reports, returned by the calculation engine 103 are received and forwarded to the storage and publishing layer 104.

[0041] 4. The Calculation Engine 103 implements the deployment of the Calculation Service, which includes a built-in caching unit and a calculation unit. The specific implementation and interaction flow of each unit are as follows: Cache Units: ① Route Plan and Status Cache 201: Adopts a mapping structure of flight ID → route plan information, storing a list of waypoints (including latitude, longitude, and altitude, waypoint type), cruising speed, planned start time, etc., and populates data from Redis deserialized data and updates it in real time; ② Arrival Status Cache 202: Adopts a two-layer mapping structure of flight ID → (waypoint / airport ID → arrival status), each arrival status includes a status enumeration (PLANNED / EN_ROUTE / ARRIVED), estimated / actual / initial estimated arrival time, three-dimensional distance, last calculated time, waypoint latitude, longitude, and altitude, etc.; ③ Location History Cache 203: Adopts a mapping structure of flight ID → recent location record list, each location record includes latitude, longitude, and altitude, collection time, with a maximum of 1000 records, used to calculate the moving average speed.

[0042] Calculation Units: ① Spatial Distance Calculation Unit 204: Implements a three-dimensional distance calculation function based on the WGS84 ellipsoid. It takes two points as input (latitude, longitude, and altitude), calculates the horizontal arc length using the Haversine formula, and combines the altitude difference with the Pythagorean theorem to synthesize the spatial straight-line distance, outputting the calculation result in meters; ② ETA Calculation Unit 205: Implements two core functions: calculateETAFromBegin (before takeoff) and calculateETA (after takeoff). Before takeoff, based on the planned start time, it accumulates the spatial distances of each segment according to the route sequence, and calculates the initial ETA for each waypoint by combining the cruise speed and a time buffer coefficient of 0.05; after takeoff, based on the current time, it calculates the straight-line distance from the current position to the first unreached waypoint, the sum of the route accumulation distances from the first unreached waypoint to subsequent unreached waypoints, and calculates the real-time ETA by combining the sliding average speed of the position history cache 203 with a safety factor of 0.03; ③ Arrival Decision and State Machine Unit 206: Implements the checkArrivalStatus function, configures the three-dimensional distance threshold to 100 meters, obtains the three-dimensional distance between the UAV and the current waypoint through the spatial distance calculation unit 204, and determines that the UAV has entered the geofence if the distance is ≤100 meters; combined with the arrival status of the previous waypoint, completes the state transition from PLANNED to EN_ROUTE to ARRIVED, and if the arrival is determined, records the actual arrival time and updates the arrival status cache 202; ④ Rerouting Processing Unit 207: Implements the ProcessRouteChangePoints and organizeRouteSegments functions, reads the rerouting two-dimensional array (multiple route segments) and the original transit report from Redis, and merges them into a new route sequence according to the time and spatial order of the route segments; calls the spatial distance calculation unit 204, ETA calculation unit 205, and arrival decision and state machine unit 206 for each waypoint of the merged route, updates the arrival status cache 202 and generates a complete transit report array containing the original route and the rerouting route.

[0043] Core calculation process: ① Step 301: Data access layer 101 receives the route plan, route status, or position / passage data of a flight and converts it into an internal event; ② Step 302: Event coordination layer 102 determines the data type. If it is a route plan update, step 303 is executed; if it is a position / passage report, step 304 is executed; ③ Step 303: Calculation engine 103 updates the route plan and status cache 201 for the flight. If it is the first initialization, it calls calculateETAFromBegin to generate the initial ETA and writes it to the arrival status cache 202. Optionally, an initial passage report is published; ④ Step 304: Calculation engine 103 reads the rerouting key from Redis and determines whether rerouting data exists. If it exists, step 305 is executed; otherwise, step 306 is executed; ⑤ Step 305: Rerouting processing unit 207 merges the original route and the rerouting route segment, executes ETA calculation and arrival determination in sequence, updates the arrival status cache 202 and generates a passage report, and sends the result to event coordination layer 102; ⑥ Step 306: The calculation engine 103 traverses each waypoint. Waypoints that have been reached are skipped directly. For waypoints that have not been reached, the spatial distance calculation unit 204 calculates the remaining cumulative distance of the route, calls calculateETA to obtain the real-time ETA, and updates the status and actual arrival time through the arrival judgment and state machine unit 206, and summarizes them to form a waypoint report; Step 307: The calculation engine 103 sends the waypoint report and ETA to the event coordination layer 102, and the storage and publishing layer 104 completes the subsequent operations.

[0044] 5. Storage and Publishing Layer 104 Implementation Write drone trajectory data into Elasticsearch by flight ID and time shards to support fast trajectory query and visualization; Arrival information (waypoint ID, arrival status, actual / estimated arrival time) is written to MySQL, and a joint index of flight ID and waypoint ID is created to ensure data persistence and transactionality. The ETA, overrun reports, and trajectory messages are published to a designated topic in Kafka for consumption by downstream systems such as drone monitoring platforms and traffic management systems. Core status data (such as current waypoint status and latest ETA) is written back to Redis as needed for other systems to query quickly.

[0045] Example 3 like Figures 1-3 As shown, this embodiment is a method for calculating the real-time spatiotemporal relationship of multiple drones based on Rust language, Kafka data access, and Redis+InfluxDB storage. It is a variation of embodiment 2, with the core architecture and calculation logic being the same as embodiment 2. The main changes are as follows: 1. Development Language and Concurrency Implementation: The computing engine 103 is developed using the Rust language. Based on Rust's ownership model and lightweight threads, it achieves lock-free concurrency, further improving memory safety and throughput performance under high concurrency. 2. Data Access Layer 101: The Redis and MQTT access methods are cancelled, and Kafka is used as the sole data access source. The UAV's flight plan, status change, and position / passage report are all sent to different topics in Kafka. Data Access Layer 101 achieves high-availability data consumption through Kafka consumer groups and transforms the accessed data into internal events. 3. Storage and Publishing Layer 104: Write the drone's trajectory and real-time status data into InfluxDB to adapt to the efficient storage and query of time-series data, and meet the time-series analysis needs of drone operation data; Instead of storing data in MySQL, arrival information is written to a Redis hash structure, using flight:{flightID}:arrival:{waypointID} as the key, to store arrival status, actual / estimated arrival time, and other information, thereby improving data read speed. Retain the Kafka publishing functionality and publish ETA and point-of-failure reports to the original topic to ensure compatibility with downstream systems.

[0046] 4. Arrival determination strategy: Based on the fixed distance threshold in Example 2, a differentiated threshold configuration for waypoint type is added. The distance threshold for airport take-off and landing points is set to 50 meters, and the distance threshold for ordinary waypoints is set to 150 meters, thereby improving the accuracy of arrival determination.

[0047] Example 4 like Figures 1-3 As shown, this embodiment is a method for calculating the real-time spatiotemporal relationship of multiple drones based on C++ language, HTTP callback + proprietary protocol data access, and MongoDB + RabbitMQ storage. It is another variation of embodiment 2. The core architecture and calculation logic remain unchanged, and the main changes are as follows: 1. Development Language and Deployment Method: The Computing Engine 103 is developed in C++, and achieves high concurrency and low memory usage based on multi-threading and memory pool technology. It is compiled into an executable file and deployed directly on the physical machine to improve the system's response speed. 2. Data Access Layer 101: For drones within the airport, the route plan and status update are received via HTTP callback, and the drone scheduling system actively pushes the data to the REST interface of the data access layer 101. For low-altitude flying drones, a self-developed proprietary protocol is used to achieve data access, and the location data is transmitted in real time based on the UDP protocol to reduce transmission latency. The accessed data is verified and standardized, and converted into an internal event format consistent with that of Example 2.

[0048] 3. Storage and Publishing Layer 104: The drone's trajectory, arrival information, and flight plan are all written into MongoDB using a document-oriented storage structure, which is suitable for the mixed storage needs of drone unstructured and structured data. The Kafka publishing method was cancelled, and RabbitMQ was used as the message queue. ETA and point-of-flight reports were sent to the RabbitMQ exchange, and downstream systems could consume messages on demand by binding to different queues. 4. ETA Calculation and Arrival Determination Optimization: A wind speed correction coefficient is added to the ETA calculation unit 205 to adjust the average speed based on the real-time wind speed data of the UAV flight area, further improving the accuracy of ETA estimation. A time-assisted determination rule is added to the arrival determination and state machine unit 206. If the UAV's ETA exceeds the expected time to reach the waypoint by 30 seconds and the state is EN_ROUTE, it is automatically determined that the waypoint has been reached, thus avoiding arrival determination delays caused by the UAV detouring.

[0049] In the above embodiments, Embodiment 2 is the preferred embodiment, which realizes all the technical solutions of the present invention. Embodiments 3 and 4, without deviating from the core concept of the present invention, have made adaptive adjustments to data access, storage and publishing, and calculation details, and can all realize low-latency and high-throughput calculation of real-time spatiotemporal relationships of multiple UAVs, which are within the protection scope of the present invention.

[0050] Compared with the prior art, the present invention has the following beneficial effects: Significantly improved real-time performance and throughput: The computing engine is implemented using a high-performance compiled language, combined with state isolation by flight dimension and lock-free / low-lock design, supporting second-level ETA state updates under high-frequency position updates. The latency and throughput performance in multi-drone concurrent scenarios is far superior to scripting languages ​​or traditional Java monolithic implementations. Supports multiple drones and dynamic rerouting: Under the same architecture, it enables unified management of multiple drones, waypoints, and airports. When rerouting, it generates a complete pass-through report by merging route segments and recalculating the sequence, without the need to build a separate system for rerouting, and adapts to the dynamic route change requirements of drones in actual operation. Spatiotemporal calculations are more in line with actual operation: By using the calculation method of accumulating distance of remaining route + speed / time buffer and two sets of ETA logic before / after takeoff, combined with geofence arrival determination based on three-dimensional spatial distance, the accuracy of ETA estimation is greatly improved, making the four-dimensional trajectory of the UAV closer to the actual operating state. The system is highly scalable and maintainable: It adopts an event-driven architecture and interface abstraction design to decouple the data access, computing, storage and publishing links. Each link can be independently replaced with alternative implementation schemes and horizontally scaled, which facilitates system operation and maintenance and subsequent function expansion. Unified arrival determination and status management: Construct a standardized waypoint state machine and configurable arrival thresholds to achieve consistent determination of arrival events and full lifecycle status traceability under multiple waypoints and multiple UAVs, avoiding misjudgment and duplicate updates.

[0051] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for calculating real-time spatiotemporal relationships among multiple UAVs based on a high-performance language, characterized in that: An event-driven architecture is constructed, comprising a data access layer, an event coordination layer, a computing engine, and a storage and publishing layer. These layers are sequentially connected to form a pipeline of access → coordination → computing → storage / publishing. The computing engine is implemented using a high-performance compiled language. The method includes the following steps: S1: The data access layer receives route plans, route status, and position / crossing point reports from multiple UAVs, converts them into internal events, and sends them to the event coordination layer; S2: The event coordination layer parses the data type of the internal event. If it is a route plan update event, step S3 is executed; if it is a position / passing point update event, step S4 is executed. S3: The calculation engine updates the route plan and status cache of the corresponding flight. If it is the first initialization of the flight, it calls the pre-departure logic of the ETA calculation unit to generate the initial estimated arrival time of each waypoint, writes it into the arrival status cache, and optionally publishes the initial pass-through report, and returns to step S1. S4: The calculation engine determines whether there is flight change data. If it exists, proceed to step S5; otherwise, proceed to step S6. S5: The calculation engine merges the original route and the rerouted route segment into a new route sequence through the rerouting processing unit, performs ETA calculation and arrival determination on the merged route in sequence, updates the arrival status cache and generates a complete transit report, and executes step S7. S6: The calculation engine calculates the remaining cumulative distance of the route to the first unreached waypoint based on the real-time position of the UAV and the current route plan, calls the takeoff logic of the ETA calculation unit to update the ETA, determines the arrival status based on the three-dimensional distance threshold through the arrival determination and state machine unit and completes the state transition from PLANNED to EN_ROUTE to ARRIVED, summarizes and forms a passing point report, and executes step S7. S7: The storage and publishing layer stores the transit report, ETA, drone trajectory, and arrival information, and publishes the ETA and transit report to the message queue for downstream systems to consume, then returns to step S1.

2. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 1, characterized in that, The high-performance compiled language is Go, Rust, or C++; the computing engine isolates the status data of each UAV by flight ID and adopts a lock-free / low-lock design to achieve concurrent computing of multiple UAVs.

3. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 1, characterized in that, The computing engine has a built-in cache unit and a computing unit. The cache unit includes a route plan and status cache, an arrival status cache, and a location history cache. The computing unit includes a spatial distance calculation unit, an ETA calculation unit, an arrival determination and state machine unit, and a rerouting processing unit.

4. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 3, is characterized in that, The spatial distance calculation unit is based on the WGS84 ellipsoid and uses the horizontal Haversine formula to calculate the horizontal arc length between two points. It combines the height difference between the two points to synthesize the three-dimensional straight-line distance and outputs the calculation result in meters.

5. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 3, characterized in that, The ETA calculation unit implements two sets of calculation logics before takeoff and after takeoff: the logic before takeoff is: based on the start time of the route plan, the three-dimensional spatial distance of each segment is accumulated in the order of the route, and the initial ETA of each waypoint is calculated by combining the cruise speed and the time buffer coefficient. Post-takeoff logic: Based on the current time, calculate the sum of the straight-line distance from the UAV's current position to the first unreached waypoint and the cumulative distance from the first unreached waypoint to subsequent unreached waypoints. Combine the sliding average speed from the location history cache with the safety factor to calculate the real-time ETA.

6. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 3, characterized in that, The arrival determination and state machine unit is configured with an adjustable three-dimensional distance threshold to construct a geofence. The three-dimensional distance between the UAV and the current waypoint is obtained through the spatial distance calculation unit. If the distance is ≤ the threshold, it is determined that the UAV has entered the geofence. By combining the arrival status of the previous waypoint, a unified conversion of waypoint status is completed, and the actual arrival time is recorded; the three-dimensional distance threshold supports differentiated configuration according to waypoint type, with the threshold for airport take-off and landing points being 50-100 meters and the threshold for ordinary waypoints being 100-150 meters; the arrival determination and state machine unit can also add time-assisted determination rules, if the UAV's ETA exceeds the expected passing time and the status is EN_ROUTE, it is determined that the waypoint has been reached.

7. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 3, characterized in that, The rerouting processing unit reads the rerouting two-dimensional array and the original transit report, and merges the original route and the rerouting route segment into a new route sequence in time and space order; for each waypoint of the merged route, it calls the spatial distance calculation unit, the ETA calculation unit, the arrival determination and state machine unit, updates the arrival state cache, and generates a complete transit report containing the original route and the rerouting route.

8. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 1, characterized in that, The data access layer supports one or more combinations of Redis subscription / polling, MQTT, Kafka, HTTP callback, or proprietary protocols to parse and transform the non-standardized data into standardized internal events containing flight ID, data type, and data content.

9. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 1, characterized in that, The event coordination layer uses an event bus and observer pattern to decouple events. It calls the corresponding interface of the computing engine according to the data type of the internal events and forwards the results returned by the computing engine to the storage and publishing layer. The event coordination layer and the computing engine interact through interface calls. The computing engine provides standardized interfaces for updating route plans, processing position updates, processing rerouting, and obtaining flight arrival status.

10. The method for calculating the real-time spatiotemporal relationship of multiple UAVs based on a high-performance language according to claim 1, characterized in that, The storage and publishing layer adopts an interface abstraction design. The storage medium supports one or more combinations of Elasticsearch, MySQL, InfluxDB, MongoDB, or Redis, and the message queue supports one or more combinations of Kafka, RabbitMQ, or Redis. The storage and publishing layer persists or caches the drone trajectory and arrival information, publishes ETA and pass-through reports to the message queue, and writes back core status data to the cache medium as needed.

Images