Airplane head-on conflict detection method and system for airport taxiway network

Abstract

The application discloses an aircraft head-on conflict detection method and system for an airport taxiway network, and solves the problems of false positives and false negatives, unstable determination and difficult engineering landing of traditional detection. The method comprises the following steps: constructing a taxiway network node-edge topology graph, constructing a space index for edge geometric points; predefining a conflict rule; acquiring real-time trajectory points of an aircraft and matching the real-time trajectory points to a topology edge to determine the direction of the aircraft; dynamically maintaining an edge occupation table, and detecting whether there is a head-on conflict based on the edge occupation table and the conflict rule. The application scheme can realize accurate and rapid binding of trajectory-edge, improve detection accuracy and real-time performance, the rule is configurable, the system is easy to integrate, and is suitable for real-time detection of aircraft head-on conflicts in an airport taxiway network.

Description

Technical Field

[0001] This application relates to the field of air traffic management technology, specifically to a method and system for detecting head-on collisions of aircraft in airport taxiway networks, applicable to real-time detection and alarm of head-on collisions of aircraft in areas such as taxiways, connecting taxiways, and apron taxiways in airport areas. Background Technology

[0002] Airport taxiing operations are a crucial part of air traffic operations. Aircraft need to perform taxiing, turning, merging, and other maneuvers in the taxiway network. During this process, ground targets are dense, taxiing paths are complex and intersecting, and factors such as noise in ADS-B / radar trajectory data and inconsistencies in airport geometry data can affect the risk of head-on collisions between aircraft. Therefore, it is necessary to rely on efficient detection methods to achieve collision early warning.

[0003] Traditional airport aircraft conflict detection mainly relies on manual visual monitoring or simple alarm methods based on "distance thresholds." These methods have several technical drawbacks: First, the false alarm rate is high. Aircraft on different taxiways but in close spatial positions, or when their trajectory data drifts briefly, are prone to triggering distance threshold alarms, resulting in invalid alarms. Second, the risk of missed alarms is high. If aircraft taxiing towards each other on the same taxiway segment have already formed an actual head-on conflict risk even if the distance has not reached the threshold, alarms cannot be triggered in time. Third, the implementation is difficult. Traditional methods cannot achieve high-throughput, low-latency real-time detection in large-scale taxiway networks, and the rules are fixed, which does not support flexible configuration by airports according to actual operational needs, resulting in poor interpretability of detection results. Summary of the Invention

[0004] The purpose of this application is to overcome the shortcomings of the prior art and provide an aircraft head-on collision detection method and system for airport taxiway networks. This method enables accurate and rapid binding of real-time aircraft trajectories with taxiway topology edges, stably determines the aircraft's direction of travel along the taxiway, and completes high-speed head-on collision detection through configurable masking rules. This effectively reduces false alarm and false negative rates, improves detection stability, and meets the high throughput and low latency requirements of large-scale taxiway networks. Furthermore, the detection system is easy to configure and interpretable, and can be directly integrated into the airport's existing operational alarm platform.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, this application provides a method for detecting head-on collisions between aircraft in an airport taxiway network, comprising the following steps: Construct a topology graph of an airport taxiway network. The topology graph includes multiple nodes and multiple edges connecting the nodes. The nodes are taxiway topology intersections or endpoints, and the edges are taxiways. Each edge contains a sequence of geometric points, and each edge is assigned a logical direction vector. Create a spatial index for the geometric points of each edge; A predefined conflict rule is provided, which includes edge pairs that may conflict and a direction combination mask corresponding to each edge pair. The direction combination mask is used to indicate whether the direction combination of two aircraft on the edge pair constitutes a head-on conflict. Obtain the real-time trajectory points of the aircraft; Based on the spatial index, the real-time trajectory point is matched with the edge of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph; If the aircraft is currently located on one of the edges, determine the direction of travel of the aircraft on the edge it is currently on; Construct and dynamically maintain an edge occupancy table, which records the aircraft currently occupying each edge and its direction of travel; Based on the edge occupancy table and the conflict rules, the existence of head-to-head conflict is detected: for each pair of occupied edges in the edge occupancy table, if the edge pair exists in the conflict rules, the direction combination mask corresponding to the edge pair is obtained, and the direction combination mask is compared with the respective travel directions of the two aircraft. If they match, it is determined that a head-to-head conflict has occurred.

[0007] Optionally, establishing a spatial index for the geometric points of each edge includes: Project the points in the geometric point sequence of each edge onto a planar coordinate system, and construct a KD-tree index for all projected points.

[0008] Optionally, the step of performing nearest neighbor matching between the real-time trajectory point and the edges of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph includes: Project the real-time trajectory points onto the planar coordinate system, find the K nearest neighbor points in the KD tree index, and select the edge belonging to the point with the smallest distance as a candidate edge. If the minimum distance between the real-time trajectory point and the candidate edge is less than a preset threshold, then it is determined that the aircraft is currently located on the candidate edge.

[0009] Optionally, determining the aircraft's direction of travel on the current edge includes: Obtain the displacement vector of the aircraft between two consecutive trajectory points on the current edge; Calculate the magnitude of the displacement vector. If the magnitude of the displacement vector is less than the displacement threshold, then directly set the direction of travel to unknown. If the magnitude of the displacement vector is greater than or equal to the displacement threshold, then obtain the logical direction vector of the current edge; Calculate the dot product of the displacement vector and the logical direction vector, and determine the direction of travel based on the sign of the dot product; If the aircraft changes its location on a different edge during the calculation of the displacement vector, the magnitude of the displacement vector, or the dot product, the direction of travel is set to unknown.

[0010] Optionally, the maintenance edge occupancy table further includes: Set a Time-To-Live (TTL) for each aircraft's occupancy record. If no new trajectory point is updated within the TTL, remove the aircraft from the edge occupancy table.

[0011] Optionally, the direction combination mask is a 4-bit binary mask, which corresponds to four direction combinations of the two aircraft on the edge pair: forward-forward, forward-reverse, reverse-forward, and reverse-reverse; a bit in the mask being 1 indicates that the corresponding direction combination constitutes a head-on collision.

[0012] Optionally, the comparison based on the respective travel directions of the two aircraft and the direction combination mask includes: Map the directions of travel of the two aircraft to index values, with 0 for the forward direction and 1 for the reverse direction; Calculate the combined index = (first aircraft index << 1) | second aircraft index; Check if the bit corresponding to the combination index in the direction combination mask is 1. If it is, it is determined to be a head-to-head collision.

[0013] Optionally, the detection of whether a head-to-head conflict exists further includes: When a head-on collision is detected, an alarm message containing the identifiers of the colliding aircraft and the time is generated; however, only one alarm is output for the same pair of aircraft at the same time.

[0014] Secondly, this application provides an aircraft head-on conflict detection system for airport taxiway networks, used to implement the method described in the first aspect, the system comprising: The topology graph construction module is used to construct a topology graph of the airport taxiway network. The topology graph includes multiple nodes and multiple edges connecting the nodes. The nodes are taxiway topology intersections or endpoints, and the edges are taxiways. Each edge contains a sequence of geometric points. The spatial index module is used to create spatial indexes for the geometric points of each edge; The rule configuration module is used to predefine conflict rules. The conflict rules include edge pairs that may conflict and a direction combination mask corresponding to each edge pair. The direction combination mask is used to indicate whether the direction combination of two aircraft on the edge pair constitutes a head-on conflict. The trajectory acquisition module is used to acquire the real-time trajectory points of the aircraft; The matching module is used to perform nearest neighbor matching between the real-time trajectory point and the edge of the topology graph based on the spatial index, and determine whether the aircraft is currently located on one of the edges of the topology graph; The direction determination module is used to determine the direction of travel of the aircraft on the edge it is currently on if the aircraft is currently located on one of the edges. The occupancy table maintenance module is used to build and dynamically maintain the edge occupancy table, which records the aircraft currently occupying each edge and its direction of travel. The conflict detection module is used to detect whether there is a head-to-head conflict based on the edge occupancy table and the conflict rules: for each pair of occupied edges in the edge occupancy table, if the edge pair exists in the conflict rules, the direction combination mask corresponding to the edge pair is obtained, and the direction combination mask is compared with the respective travel directions of the two aircraft. If they match, it is determined that a head-to-head conflict has occurred.

[0015] Optionally, the system further includes: The alarm output module is used to deduplicat conflict alarms and output standardized JSON format alarm information, which includes at least the conflict type, alarm time and flight conflict information.

[0016] Compared with the prior art, this application has the following beneficial effects: 1. Upgrade the conflict detection from "point-to-point distance" to a structured decision model of "edge constraint + direction combination", which effectively reduces false alarms and false negatives.

[0017] 2. Nearest neighbor matching is used to quickly assign trajectory points to taxiway edges, meeting the high throughput and low latency requirements of large-scale airports.

[0018] 3. The conflict rules are represented by a directional combination mask, and only bitwise operations are performed online for judgment, which is efficient and the rules are easy to maintain. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Furthermore, these drawings and textual descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to specific embodiments.

[0020] Figure 1 A flowchart illustrating an aircraft head-on collision detection method for airport taxiway networks provided in this application embodiment; Figure 2 This is a schematic diagram of the structure of an aircraft head-on collision detection method system for airport taxiway networks provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] The core technical approach of this application is as follows: offline completion of taxiway network topology construction, KD tree spatial index establishment, and mask conflict rule definition; online completion of real-time trajectory data processing, trajectory-edge matching, direction determination, and edge occupancy maintenance; and finally, high-speed head-on conflict detection and standardized alarms are achieved through lightweight bit operations. All offline configuration data is stored in structured files, and the online detection process adopts a "single aircraft independent state machine" processing mode to ensure the independence and efficiency of data processing.

[0023] Example 1 This embodiment provides a method for detecting head-on collisions between aircraft in airport taxiway networks. This embodiment details the specific execution steps of this detection method, where key parameters are set based on actual airport surface operation requirements, such as… Figure 1 As shown, the method in this embodiment specifically includes the following steps: Step S1: Construct an airport taxiway network topology map and store structured data.

[0024] Specifically, the topology graph includes multiple nodes and multiple edges connecting the nodes.

[0025] Nodes are topological intersections or endpoints of taxiways. They are in key-value pair format, with the key being the node ID and the value containing attributes such as latitude and longitude coordinates (lon, lat), node type (intersection / free_end / regular), and a list of connecting edge numbers. Edge: A continuous taxiway segment (including connecting taxiways and apron taxiway segments), using key-value pairs. The key is the edge number (ID), and the value includes: a sequence of geometric points (composed of latitude and longitude coordinates, such as [[lon1,lat1],[lon2,lat2],...]), a logical direction vector (a unit vector fitted from the direction of the geometric point sequence), and optional content (such as edge type, taxiway name, speed limit, direction constraints, etc.).

[0026] The above topology graph data is stored in JSON format as an airport_graph.json file. The file contains three core parts: metadata (including generation time, storage time, etc.), nodes (node ​​dictionary), and edges (edge ​​dictionary).

[0027] In this way, the airport taxiway network is transformed from a physical geometric form into structured topology data, providing a core foundation for the subsequent binding of trajectory points to taxiway edges and the determination of topology constraints for head-on conflicts. By defining a logical direction vector for each edge, a standardized basis is provided for determining the direction of aircraft travel along the edge, fundamentally solving the problem of false alarms and missed alarms caused by the lack of topological association and reliance on spatial distance in traditional detection methods. At the same time, the structured file storage method facilitates the airport to flexibly update the topology data according to the taxiway network modification.

[0028] Step S2: Create a spatial index for the geometric points of each edge.

[0029] By constructing a spatial index, the time complexity of matching trajectory points to taxiway edges can be reduced to O(logN), achieving fast matching in sublinear time. This solves the problems of large number of geometric points, low efficiency of traditional traversal matching methods, and inability to meet real-time detection requirements in large-scale taxiway networks.

[0030] Specifically, the implementation method of step S2 may include: projecting the points in the geometric point sequence of each edge onto a planar coordinate system, and constructing a KD-tree (k-dimensional tree) index for all projected points.

[0031] More specifically, this step can be achieved using the script tools / build_kdtree.py, the core of which is to convert geographic coordinates to planar coordinates and construct a KD tree. The specific process is as follows: Step S21: Traverse the geometric point sequence of all edges in airport_graph.json, and convert each latitude and longitude point (lon, lat) into plane rectangular coordinates (x, y) through the WGS84 (geocentric coordinate system used by the Global Positioning System) to UTM (Universal Transverse Mercator Grid System) projection algorithm, thus solving the problem of complex calculation of spherical geographic coordinate distance; Step S22: Collect all projected planar points to form a point cloud array pts_xy, and record the meta information of each point (including the edge number, the index of the point in the geometric sequence, and the original latitude and longitude). Step S23: Construct a KD tree index object kdt based on the point cloud array pts_xy, and store pts_xy, meta, and kdt in pickle format as an airport_edges_kdtree.pkl file to enable fast nearest neighbor lookup for trajectory points.

[0032] Thus, this step simplifies the distance calculation logic between trajectory points and taxiway edge geometric points by converting spherical latitude and longitude coordinates to UTM planar coordinates. In addition, by constructing a KD-tree spatial index, the time complexity of matching trajectory points to taxiway edges is reduced to O(logN), achieving fast matching in sublinear time. This solves the problems of large number of geometric points, low efficiency of traditional traversal matching methods, and inability to meet real-time detection requirements in large-scale taxiway networks. At the same time, the index data is stored in pickle format, enabling fast loading and retrieval of the index and improving the online operating efficiency of the system.

[0033] Step S3: Predefine conflict rules.

[0034] The conflict rules provide the core basis for the lightweight bit operation determination in subsequent online detection. Specifically, the conflict rules include edge pairs that may conflict and a direction combination mask corresponding to each edge pair. The direction combination mask is used to indicate whether the direction combinations of two aircraft on edge pairs that may conflict constitute a head-on conflict.

[0035] In some embodiments, this step predefines conflict edge pairs and corresponding mask rules based on the actual intersection and opposite operation rules of the airport taxiway network, and stores them as a JSON file, for example, named taxiway_constraints_bitmask.json.

[0036] In practical implementation, a key-value pair format of "source edge → list of conflicting neighboring edges" can be used, where the key is the source edge number and the value is the list of conflicting neighboring edges, and each element in the list is [target edge number, direction combination mask]. It can be stored in JSON format, as shown in the example below: { "src_edge_id": [ ["tgt_edge_id_1", mask_1], ["tgt_edge_id_2", mask_2] ] } Here, `src_edge_id` represents the ID of the "source edge," which is the starting edge for collision detection. `tgt_edge_id_1` and `tgt_edge_id_2` represent the IDs of the target edge, which is another edge that may collide with the source edge. `mask_1` and `mask_2` are direction combination masks used to specify which direction combinations will be judged as collisions.

[0037] In practice, the direction combination mask can be a 4-bit binary mask, with the encoding rule as follows: the 4 bits of the mask correspond to the four direction combinations of the two aircraft on the edge pair. For example, from the least significant bit to the most significant bit, they are: Bit0: Aircraft a forward (+1) vs Aircraft b forward (+1); Bit1: Aircraft a forward (+1) vs Aircraft b reverse (-1); Bit2: Aircraft a reverse (-1) vs Aircraft b forward (+1); Bit3: Aircraft a reverse (-1) vs Aircraft b reverse (-1); A bit in the mask being 1 indicates that the combination of directions constitutes a head-on collision, while a bit being 0 indicates that the operation is safe. For example, when the mask is 0b1100, only the combination of aircraft a in reverse and b in forward direction, or aircraft a in reverse and b in reverse direction, constitutes a collision.

[0038] Based on this step, the head-to-head conflict rules of the airport taxiway network are encapsulated in a structured and configurable manner. For example, the conflict logic of the directional combination of two aircraft can be encoded using a 4-bit binary mask, thus realizing the digital expression of the conflict rules. In addition, the "source edge → conflicting adjacent edge list" organization form facilitates the rapid retrieval of potential conflicting edge pairs on a certain taxiway edge, reducing the retrieval time of online detection. At the same time, the structured JSON file storage method allows airport operation and maintenance personnel to flexibly add, modify, and delete conflict rules according to actual taxiway operation rules (such as one-way taxiway and interchange passage rules), solving the problems of rigid rules and difficult engineering implementation in traditional detection methods, and providing core rule basis for lightweight bit operation judgment in subsequent online detection.

[0039] The above three steps constitute the offline phase, which involves offline completion of taxiway network topology construction, spatial index establishment, and mask conflict rule definition, laying the foundation for subsequent online detection.

[0040] Next, online head-on collision detection is performed. The online detection process adopts a "single aircraft independent state machine" processing mode to ensure the independence and efficiency of data processing. Specifically, it includes the following steps: Step S4: Obtain the real-time trajectory points of the aircraft.

[0041] To achieve head-on collision detection, the real-time trajectory points of the aircraft are first required. Specifically, the processing system can obtain aircraft trajectory messages from the real-time push data of the airport's unified location service platform through a Kafka consumer. The message contains a data_list array, where each record represents a single trajectory sample of a single aircraft. Next, the core information of each trajectory record is parsed: the aircraft identifier (vid) and latitude and longitude. Latitude and longitude parsing follows a priority order, first reading the vinfo.trackpositionwgs84 field (formatted as "lat,lon,..."), and if this field is not present, reading the coord field (formatted as "lon,lat,..."). Then, the system employs an asyncio dual-task model, consuming the trajectory data to an in-memory queue, running in parallel with subsequent collision detection loops to ensure real-time data processing.

[0042] This step enables standardized, high-throughput access to real-time aircraft trajectory data at airports. Real-time push data is received via a Kafka distributed message queue, adapting to the high-frequency trajectory sampling requirements of multiple aircraft at airports. Furthermore, priority rules for latitude and longitude resolution are established to ensure the accuracy and consistency of trajectory coordinate data, providing reliable raw data for subsequent trajectory point matching and direction determination. An asyncio dual-task model is employed to achieve parallel operation of trajectory data consumption and conflict detection, avoiding trajectory data accumulation and detection latency caused by single-task blocking, thus meeting the low-latency requirements for airport surface conflict detection.

[0043] Step S5: Matching real-time trajectory points with edges of the topology graph. Specifically, based on spatial indexing, the real-time trajectory points are matched with the nearest neighbors of the edges of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph.

[0044] The purpose of this step is to accurately bind the real-time trajectory points of the aircraft to the topological edges of the airport taxiway network, realizing the transformation of trajectory data from "spatial points" to "topological elements", and providing accurate edge attribution information for subsequent direction determination and conflict detection based on topological edges.

[0045] The specific implementation process of step S5 is as follows: Step S51: Project the real-time trajectory points onto a plane coordinate system. For example, project the latitude and longitude (lon, lat) of the real-time trajectory points onto UTM plane rectangular coordinates (x, y). Step S52: Find the K nearest neighbors in the KD tree index; for example, call the K nearest neighbor query interface of the KD tree index to find the 4 nearest neighbors near the trajectory point (K_NEIGH=4). Step S53: Select the edge belonging to the point with the smallest distance as a candidate edge; specifically, calculate the planar distance between the real-time trajectory point and its four nearest neighbors, select the point with the smallest distance, and determine the edge of the taxiway to which it belongs as a candidate edge. Step S54: If the minimum distance between the real-time trajectory point and the candidate edge is less than a preset threshold, the aircraft is determined to be currently located on the candidate edge. For example, the preset threshold (THR_MET) can be set to 15.0m. If the minimum distance is less than 15.0m, the aircraft is determined to be currently located on the candidate edge, and the edge number is recorded; if the minimum distance is greater than or equal to 15.0m, the aircraft is determined to be out of the network (i.e., not located on any edge), and the edge number is set to empty.

[0046] In this way, K-nearest neighbor queries can narrow down the range of candidate edges, and combined with the set distance threshold (e.g., THR_MET=15.0m) for filtering, it can effectively avoid mismatching of aircraft off-grid trajectories (such as within parking stands or on runways) or trajectory points that are spatially close but belong to different taxiway edges, thus solving the misjudgment problem caused by the lack of topological association in traditional point-to-point matching; at the same time, it is consistent with the coordinate system of the KD-tree index, ensuring the accuracy of distance calculation and matching efficiency.

[0047] Step S6: Determine the aircraft's direction of travel along the edge. Specifically, if step S5 determines that the aircraft is currently located on one of the edges, then this step is executed to determine the aircraft's direction of travel on the edge it is currently on.

[0048] This step accurately determines the aircraft's actual direction of travel along the taxiway edge, providing a reliable directional basis for subsequent mask collision detection based on direction combinations.

[0049] In some embodiments, step S6 determines the aircraft's direction of travel on the current edge, specifically including: Step S61: Obtain the displacement vector between two consecutive trajectory points of the aircraft on the current edge; for example, extract the UTM plane coordinates (x0, y0) of the trajectory point of the previous frame from the aircraft's status record, and calculate the displacement vector between the current frame and the previous frame. =(x x0,y y0); Step S62: Calculate the magnitude of the displacement vector If the magnitude of the displacement vector is less than the displacement threshold, it indicates that the trajectory point may have drifted due to noise or detection error. In this case, the direction of travel is set to unknown to avoid misjudgment of direction. The displacement threshold can be set to 0.15m to filter out small displacements caused by trajectory noise and avoid incorrect direction judgment caused by trajectory point drift. Step S63: If the magnitude of the displacement vector is greater than or equal to the displacement threshold, then obtain the logical direction vector of the current edge. And calculate the displacement vector Δp ​​and the logical direction vector. dot product ; Step S64: Determine the direction of travel based on the sign of the dot product; the determination rule is: if If ≥0, then the aircraft's direction of travel is determined to be positive (+1); if If the value is less than 0, the direction of travel is determined to be reversed (-1). In this way, by performing a dot product operation between the displacement vector and the unit vector of the edge logical direction, the direction determination can be standardized and adapted to the geometric orientation of all taxiway edges.

[0050] It should be noted that when calculating the displacement vector... , Magnitude of the displacement vector Or dot product During the process, if the aircraft changes its location on a different edge or the magnitude of its displacement vector is less than the displacement threshold, the direction of travel is set to unknown. This completely avoids the jitter problem in direction determination and solves the problem of unstable determination results caused by uneven trajectory point intervals and noise in traditional direction determination methods.

[0051] Step S7: Construct and dynamically maintain an edge occupancy table. This edge occupancy table records the aircraft currently occupying each edge and its direction of travel.

[0052] In practical implementation, the system constructs two core data structures to manage edge occupancy status: an aircraft dictionary (recording the real-time status of each aircraft, including VID, current edge number, last frame plane coordinates, last update time, and direction of travel) and an edge_occupants dictionary (i.e., an edge occupancy table, where the key is the edge number and the value is a set of aircraft identifiers on that edge), and continuously maintains these data structures. Specific maintenance process: When an aircraft first connects, if there is no record of the vid in the aircraft dictionary, the aircraft state is initialized. If there is a corresponding edge number, the vid is added to the edge in edge_occupants. Edge switching update: If the current edge number of the aircraft is inconsistent with that of the previous frame, if there was an edge number in the previous frame, then the vid is deleted from the original edge set of edge_occupants. If the original edge set is empty, then the key-value pair of the edge is deleted. If there is an edge number now, then the vid is added to the new edge set of edge_occupants. Real-time status updates: After acquiring a new trajectory point, the aircraft's last frame plane coordinates, last update time, and direction of travel are updated to ensure real-time status updates.

[0053] In this way, dynamic, accurate, and real-time management of airport taxiway edge occupancy status can be achieved, providing real and effective edge occupancy data for subsequent conflict detection. By recording the full state of a single aircraft through an aircraft dictionary and adopting a "single aircraft independent state machine" processing mode, the independence of aircraft state updates is guaranteed, avoiding interference from multiple aircraft states. Through a real-time update mechanism during edge switching, the consistency between the edge occupancy table and the actual position of the aircraft is guaranteed. When the original edge set is empty, the table entry is deleted, simplifying the edge occupancy table data and further improving the efficiency of subsequent edge pair traversal.

[0054] In addition, in some embodiments, maintaining the edge occupancy table may also include setting a time-to-live (TTL) for each aircraft's occupancy record, and removing the aircraft from the edge occupancy table if no new trajectory point is updated within the TTL.

[0055] Specifically, the system iterates through the aircraft dictionary in real time. If the difference between the last update time of an aircraft and the current time is greater than 20 seconds (TTL=20 seconds), the state record of the aircraft is deleted, and the corresponding vid is removed from the edge set in edge_occupants. This avoids invalid conflict detection caused by "ghost occupation" (the aircraft has left an edge but the system still records its occupation), reduces the amount of system computation, and improves detection efficiency.

[0056] Step S8: Head-to-head conflict detection based on conflict rules.

[0057] The purpose of this step is to implement the core business operations of this application, enabling high-speed and accurate detection of head-on collisions between aircraft in the airport taxiway network.

[0058] In practice, based on the edge occupancy table and conflict rules, the existence of head-to-head conflict is detected: for each pair of occupied edges in the edge occupancy table, if the edge pair exists in the conflict rules, the direction combination mask corresponding to the edge pair is obtained, and the direction combination mask is compared with the respective travel directions of the two aircraft. If they match, it is determined that a head-to-head conflict has occurred.

[0059] The core of this step is edge pair filtering, direction index mapping, and bitwise mask matching. Only valid conflicting edge pairs are judged to reduce invalid calculations. The specific process is as follows: First, obtain the neighboring edges that may conflict, specifically including: Step S81: Traverse the source edges and filter conflicting neighbor edges.

[0060] Iterate through all source edges in edge_occupants. If the source edge number exists in the key of taxiway_constraints_bitmask.json, retrieve its corresponding list of conflicting neighbor edges.

[0061] Step S82: Filter out occupied conflicting neighbor edges.

[0062] For each target edge in the conflicting adjacent edge list, if the target edge number exists in edge_occupants, it means that both the source edge and the target edge are occupied by the aircraft, forming a valid conflicting edge pair, and proceeding to the subsequent judgment.

[0063] By using two layers of edge pair filtering (filtering edge pairs with predefined conflict rules and filtering edge pairs that are both occupied), invalid decision calculations are greatly reduced, and detection efficiency is improved.

[0064] Step S83: Compare aircraft pairwise.

[0065] Traverse the aircraft identifiers in the source and target edges, exclude self-comparisons of the same aircraft, and determine the direction combination for each pair of aircraft (vid_a, vid_b).

[0066] Next, the two aircraft, a and b, are compared with their respective directions of travel and direction combination masks, specifically including: Step S84: Direction index mapping.

[0067] Obtain the travel directions of two aircraft (dir_a, dir_b). If either direction is unknown, skip that pair of aircraft. Exclude aircraft pairs with unknown directions to avoid incorrect conflict determinations due to missing direction information.

[0068] If the directions of travel of both aircraft are known, then the directions are mapped to index values: forward (+1) is mapped to 0, and reverse (-1) is mapped to 1, thus obtaining the direction index values ​​idx_a and idx_b of the two aircraft.

[0069] Step S85: Calculate the composite index.

[0070] The direction combination index is calculated using bitwise operations: = (First aircraft index << 1) | Second aircraft index; specifically, it can be represented as: bit_index=(idx_a<<1)∣idx_b.

[0071] Where bit_index is the direction combination index.

[0072] The "<<" operator represents the left shift operator. `idx_a<<1` means shifting the binary representation of `idx_a` one bit to the left. If `idx_a = 0`, the result after the left shift is still 0 (binary 00); if `idx_a = 1`, the result after the left shift is 2 (binary 10). This step is equivalent to placing the value of `idx_a` in the most significant bit (the second bit).

[0073] The symbol “∣” represents the bitwise OR operator. That is, it performs a bitwise OR operation between the left-shifted result and idx_b. The value of idx_b is 0 or 1, and it occupies the least significant bit (the first bit). The resulting binary number is exactly (idx_a<<1) | idx_b, and its value range is: 0 (binary 00): idx_a=0, idx_b=0 (a positive, b positive); 1 (binary 01): idx_a=0, idx_b=1 (a is positive, b is negative); 2 (binary decimal): idx_a=1, idx_b=0 (a reversed, b forward); 3 (binary 11): idx_a=1, idx_b=1 (a reversed, b reversed).

[0074] Step S86: Mask Bitwise Matching: Obtain the 4-bit binary mask corresponding to the edge pair. Perform bitwise operations to determine if the corresponding bit is 1. If the result is 1, the pair of aircraft is determined to have a head-on collision; if the result is 0, the operation is deemed safe. The calculation formula is: (mask>>bit_index)&1 Here, mask is a set of switches represented in binary, namely a direction combination mask (4-bit binary mask). For example, mask = 0b0110 (decimal 6) represents binary 0110, and from the least significant bit to the most significant bit (bit0~bit3), the values ​​are: bit0=0, bit1=1, bit2=1, bit3=0.

[0075] ">>" represents the right shift operator. `mask>>bit_index` means shifting the binary representation of the mask by `bit_index` positions to the right. This is equivalent to moving the original `bit_index`-th bit to the least significant bit (bit 0).

[0076] "&" represents the bitwise AND operator. &1 means only the least significant bit (bit0) is retained, and other higher bits are ignored. Since the binary of 1 is...0001, the result of the bitwise AND operation of any number with 1 is the least significant bit of that number.

[0077] In this way, the traveling direction is mapped to an index value, and mask matching is completed through bitwise operations, achieving constant-time conflict determination and meeting the high-throughput and low-latency detection requirements in large-scale taxiway networks and multi-aircraft scenarios; the determination is made based on predefined mask rules, ensuring the interpretability of conflict detection and solving the problems of fuzzy determination logic and unexplainable results in traditional distance threshold detection methods.

[0078] Step S9: Conflict alarm generation and duplicate removal output.

[0079] Specifically, after detecting whether there is a head-on conflict based on the above steps, the method further includes: when a head-on conflict is detected, an alarm message containing the conflict aircraft identifier and time is generated; among them, only one alarm is output for the same pair of aircraft at the same moment.

[0080] The specific implementation process is as follows: Alarm message assembly: After detecting a head-on conflict, assemble a standardized alarm message, including the conflict type (head-on conflict), alarm time (current time, in the format of "YYYY-MM-DD HH:MM:SS"), and conflict aircraft identifiers (vid_a, vid_b); Conflict pair duplicate removal: Create a reported_pairs set, sort the vids of the conflict aircraft alphabetically / numerically, and form a sorted tuple (such as (vid1, vid2), vid1 < vid2) as the unique identifier; if the identifier already exists in the set, skip this alarm; if it does not exist in the set, add the identifier to the set and generate an alarm; Standardized output: The alarm message is printed and output in JSON format. An example is as follows: {"type":"head-on conflict","time":"2026-01-28 12:34:56","message":"Flight MU1111 and Flight MU2222 have a head-on conflict"} This format can be directly connected to the airport alarm platform and log platform. The system also supports real-time output of the taxiway occupancy status (including aircraft identifiers and traveling direction arrows → / ←) and conflict alarms on the console, which is convenient for debugging and manual monitoring.

[0081] Based on the above methods, standardized, integrable, and traceable conflict alarm information can be generated, enabling effective output of detection results to the airport operations and maintenance end. By sorting the conflicting aircraft identifiers to form unique identifiers, duplicate alarms for the same conflict pair (AB and BA) at the same time are avoided, reducing the workload of airport monitoring personnel and preventing invalid alarms from interfering with manual monitoring. The alarm information is output in a standardized JSON format, achieving seamless integration with the airport's existing alarm and log platforms without additional format conversion, reducing system integration costs and solving the problems of non-standard alarm information and high engineering integration difficulty in traditional detection methods. The real-time output function of the console facilitates system debugging and temporary manual monitoring, improving the system's usability.

[0082] In summary, the method described in this embodiment can achieve accurate and rapid binding of real-time aircraft trajectories with taxiway topology edges, stably determine the aircraft's direction of travel along the taxiway, and complete high-speed head-on collision detection through configurable masking rules, effectively reducing false alarm and false negative rates, improving detection stability, while meeting the high throughput and low latency requirements of large-scale taxiway networks. Furthermore, the detection system is easy to configure and interpret, and can be directly integrated into the airport's existing operational alarm platform.

[0083] Example 2 This embodiment provides an aircraft head-on collision detection system for airport taxiway networks. It implements the detection method of Embodiment 1. The system adopts a modular and asynchronous design, is deployed on an airport server, and can seamlessly interface with a unified location service platform and an airport alarm platform, such as... Figure 2 As shown, the system includes a topology map construction module 100, a spatial indexing module 110, a rule configuration module 120, a trajectory acquisition module 130, a matching module 140, a direction determination module 150, an occupancy table maintenance module 160, a conflict detection module 170, and an alarm output module 180. The functions and interaction relationships of each module are as follows: Topology Graph Construction Module 100: Its core function is to construct the node-edge topology graph of the airport taxiway network. It supports manual input or import of airport taxiway geometric data, automatically generates the attribute information and relationships of nodes and edges, and finally stores the topology graph as an airport_graph.json structured file. At the same time, it fits a logical direction vector for each edge to provide a basis for direction determination.

[0084] Spatial Index Module 110: This module is used to build a spatial index for the geometric points of each edge. Specifically, this module can call the airport_graph.json file generated by the topology graph construction module to complete the projection conversion from latitude and longitude to UTM, build a KD-tree spatial index and store it as airport_edges_kdtree.pkl; it also provides a KD-tree nearest neighbor query interface to provide indexing services for the matching module.

[0085] Rule Configuration Module 120: Used to predefine conflict rules. Specifically, this module provides a visual rule configuration interface, allowing airport operations personnel to add, delete, and modify conflicting edge pairs, configuring a 4-bit binary mask for each edge pair; after configuration, it automatically generates a taxiway_constraints_bitmask.json file, providing the rule basis for the conflict detection module.

[0086] The trajectory acquisition module 130 is used to acquire the real-time trajectory points of the aircraft. Specifically, this module serves as the system's input interface, connecting to the airport's unified location service platform's real-time push data through a Kafka consumer. It parses and filters the trajectory data, pushing valid trajectory data to an in-memory queue. An asynchronous consumption mode, using asyncio, ensures high-throughput data access.

[0087] Matching module 140: Based on spatial indexing, this module performs nearest neighbor matching between real-time trajectory points and edges of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph. Specifically, this module calls the KD-tree query interface of the spatial indexing module to project the trajectory points parsed by the trajectory acquisition module onto the UTM plane, completes the matching of trajectory points with taxiway edges, outputs the aircraft's current edge number (or off-grid identifier), and passes it to the direction determination module and the occupancy table maintenance module.

[0088] Direction determination module 150: When an aircraft is currently located on one of the edges of the topology graph, it determines the aircraft's direction of travel on that edge. Specifically, this module receives the edge number from the matching module and the trajectory coordinates from the trajectory acquisition module, calculates the aircraft's displacement vector, combines it with the logical direction vector of the edge to determine the direction of travel, outputs the direction of travel (+1 / -1 / unknown), and passes it to the occupancy table maintenance module and the conflict detection module.

[0089] Occupancy Table Maintenance Module 160: This module is used to build and dynamically maintain an edge occupancy table, which records the currently occupied aircraft and their direction of travel on each edge. Specifically, this module is the core of the system's state management. It builds and maintains an aircraft dictionary and an edge_occupants table, receives edge numbers from the matching module and the direction of travel from the direction judgment module, and performs real-time updates of aircraft status, edge switching updates, and TTL expiration cleanup. It provides real-time and accurate edge occupancy status data for the conflict detection module.

[0090] Conflict Detection Module 170: This module is used to detect head-to-head conflicts based on the edge occupancy table and conflict rules. It is the core business module of the system. It receives edge occupancy table data from the occupancy table maintenance module, calls the mask conflict rules from the rule configuration module, performs edge pair filtering, direction index mapping, bitwise mask matching, and finally outputs the head-to-head conflicting aircraft pairs, which are then transmitted to the alarm output module.

[0091] Alarm Output Module 180: This module deduplicates conflict alarms and outputs standardized JSON-formatted alarm information. Specifically, it receives conflicting aircraft pairs from the conflict detection module, assembles and deduplicates the alarm information, and generates standardized JSON-formatted alarm information. It provides multi-terminal output interfaces, supporting console output, log file storage, and integration with airport alarm platforms, while also supporting real-time push notifications of alarm information. The alarm information must include at least the conflict type, alarm time, and flight conflict information.

[0092] In practice, the engineering implementation details of this system are as follows: Asynchronous parallel processing: The system entry script adopts an asyncio dual-task model, namely consumer_loop (trajectory data consumption) and detection_loop (collision detection). The two tasks run in parallel and data interaction is achieved through a memory queue to avoid the increase in latency caused by single-task blocking. Modular code structure: The core system code is encapsulated into multiple utility classes, including TaxiwayTracker (track tracking, integrated matching, direction judgment, and occupation table maintenance functions), ConflictMonitor (conflict detection, implementing mask rule matching), and dataCollector (data collection, implementing Kafka consumption). Each utility class is decoupled, which facilitates maintenance and expansion. Debugging and monitoring: The system provides console output by default, which prints the occupancy status of the taxiway edges in real time (aircraft identification and direction of travel for each edge) and conflict alarm information. It supports setting log levels (INFO / WARN / ERROR) to facilitate troubleshooting. Scalability: All system configuration parameters (number of K nearest neighbors, distance threshold, displacement threshold, TTL time) are centralized in the utils / config.py configuration file, allowing airports to flexibly modify them according to actual operational needs; at the same time, the system reserves GUI visualization interface and RESTful API interface, which can be quickly expanded into an airport surface monitoring visualization platform.

[0093] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0094] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0096] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0097] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0098] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0099] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0100] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for detecting head-on collisions between aircraft in an airport taxiway network, characterized in that, Includes the following steps: Construct a topology graph of an airport taxiway network. The topology graph includes multiple nodes and multiple edges connecting the nodes. The nodes are taxiway topology intersections or endpoints, and the edges are taxiways. Each edge contains a sequence of geometric points, and each edge is assigned a logical direction vector. Create a spatial index for the geometric points of each edge; A predefined conflict rule is provided, which includes edge pairs that may conflict and a direction combination mask corresponding to each edge pair. The direction combination mask is used to indicate whether the direction combination of two aircraft on the edge pair constitutes a head-on conflict. Obtain the real-time trajectory points of the aircraft; Based on the spatial index, the real-time trajectory point is matched with the edge of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph; If the aircraft is currently located on one of the edges, determine the direction of travel of the aircraft on the edge it is currently on; Construct and dynamically maintain an edge occupancy table, which records the aircraft currently occupying each edge and its direction of travel; Based on the edge occupancy table and the conflict rules, the existence of head-to-head conflict is detected: for each pair of occupied edges in the edge occupancy table, if the edge pair exists in the conflict rules, the direction combination mask corresponding to the edge pair is obtained, and the direction combination mask is compared with the respective travel directions of the two aircraft. If they match, it is determined that a head-to-head conflict has occurred.

2. The method according to claim 1, characterized in that, The process of establishing a spatial index for the geometric points of each edge includes: Project the points in the geometric point sequence of each edge onto a planar coordinate system, and construct a KD-tree index for all projected points.

3. The method according to claim 2, characterized in that, The step of performing nearest neighbor matching between the real-time trajectory point and the edges of the topology graph to determine whether the aircraft is currently located on one of the edges of the topology graph includes: Project the real-time trajectory points onto the planar coordinate system, find the K nearest neighbor points in the KD tree index, and select the edge belonging to the point with the smallest distance as a candidate edge. If the minimum distance between the real-time trajectory point and the candidate edge is less than a preset threshold, then it is determined that the aircraft is currently located on the candidate edge.

4. The method according to claim 1, characterized in that, Determining the direction of travel of the aircraft on the current edge includes: Obtain the displacement vector of the aircraft between two consecutive trajectory points on the current edge; Calculate the magnitude of the displacement vector. If the magnitude of the displacement vector is less than the displacement threshold, then directly set the direction of travel to unknown. If the magnitude of the displacement vector is greater than or equal to the displacement threshold, then obtain the logical direction vector of the current edge and calculate the dot product of the displacement vector and the logical direction vector. The direction of travel is determined by the sign of the dot product; If the aircraft changes its location on a different edge during the calculation of the displacement vector, the magnitude of the displacement vector, or the dot product, the direction of travel is set to unknown.

5. The method according to claim 1, characterized in that, The maintenance edge occupancy table also includes: Set a Time-To-Live (TTL) for each aircraft's occupancy record. If no new trajectory point is updated within the TTL, remove the aircraft from the edge occupancy table.

6. The method according to claim 1, characterized in that, The direction combination mask is a 4-bit binary mask, which corresponds to four direction combinations of the two aircraft on the edge pair: forward-forward, forward-reverse, reverse-forward, and reverse-reverse. A bit in the mask being 1 indicates that the corresponding direction combination constitutes a head-on collision.

7. The method according to claim 6, characterized in that, The comparison based on the respective travel directions of the two aircraft and the direction combination mask includes: Map the directions of travel of the two aircraft to index values, with 0 for the forward direction and 1 for the reverse direction; Calculate the combined index = (first aircraft index << 1) | second aircraft index; Check if the bit corresponding to the combination index in the direction combination mask is 1. If it is, it is determined to be a head-to-head collision.

8. The method according to claim 1, characterized in that, The detection of whether a head-on conflict exists also includes: When a head-on collision is detected, an alarm message containing the identifiers of the colliding aircraft and the time is generated; however, only one alarm is output for the same pair of aircraft at the same time.

9. A head-on collision detection system for airport taxiway networks, characterized in that, include: The topology graph construction module is used to construct a topology graph of the airport taxiway network. The topology graph includes multiple nodes and multiple edges connecting the nodes. The nodes are taxiway topology intersections or endpoints, and the edges are taxiways. Each edge contains a sequence of geometric points. The spatial index module is used to create spatial indexes for the geometric points of each edge; The rule configuration module is used to predefine conflict rules. The conflict rules include edge pairs that may conflict and a direction combination mask corresponding to each edge pair. The direction combination mask is used to indicate whether the direction combination of two aircraft on the edge pair constitutes a head-on conflict. The trajectory acquisition module is used to acquire the real-time trajectory points of the aircraft; The matching module is used to perform nearest neighbor matching between the real-time trajectory point and the edge of the topology graph based on the spatial index, and determine whether the aircraft is currently located on one of the edges of the topology graph; The direction determination module is used to determine the direction of travel of the aircraft on the edge it is currently on if the aircraft is currently located on one of the edges. The occupancy table maintenance module is used to build and dynamically maintain the edge occupancy table, which records the aircraft currently occupying each edge and its direction of travel. The conflict detection module is used to detect whether there is a head-to-head conflict based on the edge occupancy table and the conflict rules: for each pair of occupied edges in the edge occupancy table, if the edge pair exists in the conflict rules, the direction combination mask corresponding to the edge pair is obtained, and the direction combination mask is compared with the respective travel directions of the two aircraft. If they match, it is determined that a head-to-head conflict has occurred.

10. The system according to claim 9, characterized in that, Also includes: The alarm output module is used to deduplicat conflict alarms and output standardized JSON format alarm information, which includes at least the conflict type, alarm time and flight conflict information.

Images