Airport control conflict resolution assistance method and system

Abstract

The application relates to the technical field of air traffic management, in particular to an airport control conflict resolution auxiliary method and system. The method comprises the following steps: acquiring multi-source heterogeneous air traffic control signals, and preprocessing and weightedly fusing the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system; acquiring historical conflict resolution success trajectory data to generate an AEM submodel special for an airport scene; based on the aircraft dynamic data, performing real-time conflict analysis and prediction according to the AEM submodel special for the airport scene to generate risk warning information; generating a control conflict resolution scheme according to the risk warning information, and outputting the expected effect of the control conflict resolution scheme. The application can solve the problem that, in the prior art, due to data heterogeneity, there is deviation in core data such as aircraft position and speed, and the problem that, due to manual operation, the adaptability of a complex conflict scene in the reflight and takeoff stages is poor.

Description

Technical Field

[0001] This application relates to the field of air traffic management technology, and in particular to an auxiliary method and system for resolving airport control conflicts. Background Technology

[0002] Currently, conflict resolution within airport control areas primarily relies on controllers' judgment and decision-making based on air traffic control automation systems, surface surveillance equipment, and their own experience. Controllers must simultaneously monitor the dynamic trajectories, speeds, altitudes, and other parameters of multiple aircraft, and, in conjunction with airport runway and taxiway layouts and airspace restrictions, formulate conflict resolution plans. This places extremely high demands on controllers' professional and emergency response capabilities.

[0003] Existing air traffic control automation systems can access air traffic control automation signals, surface surveillance radar signals, multi-point positioning signals, and some airborne signals to achieve real-time aircraft position monitoring. However, they lack specialized conflict analysis models and intelligent auxiliary tools for takeoff and go-around scenarios, leading to a series of problems. First, air traffic control automation signals, surface surveillance radar signals, multi-point positioning signals, and airborne signals exhibit data heterogeneity. Existing systems lack efficient signal fusion mechanisms, resulting in deviations in core data such as aircraft position and speed, affecting the accuracy of conflict assessment. Second, existing systems can only provide basic position warnings and lack professional conflict modeling and analysis tools, resulting in poor adaptability to complex conflict scenarios during go-around and takeoff phases.

[0004] Therefore, there is an urgent need to design an auxiliary method and system for resolving airport control conflicts. Summary of the Invention

[0005] Based on this, it is necessary to provide an airport control conflict resolution assistance method and system to address the above-mentioned technical problems. This method and system can solve the problems in the existing technology where the core data such as aircraft position and speed are deviated due to data heterogeneity, as well as the problem of poor adaptability to complex conflict scenarios during the go-around and takeoff phases due to manual operation.

[0006] The technical solution of this invention is as follows:

[0007] An airport control conflict resolution aid method, the method comprising:

[0008] Acquire multi-source heterogeneous air traffic control signals, and preprocess and weighted fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system;

[0009] Acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model and perform scenario-based adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model.

[0010] Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate risk warning information.

[0011] Based on the risk warning information, a regulatory conflict resolution plan is generated, and the expected effect of the regulatory conflict resolution plan is output.

[0012] Optionally, multi-source heterogeneous air traffic control signals are acquired, and the multi-source heterogeneous air traffic control signals are preprocessed and weighted fused to generate aircraft dynamic data in a unified coordinate system, including:

[0013] Acquire multi-source heterogeneous air traffic signals;

[0014] The multi-source heterogeneous air traffic control signal is subjected to denoising, deduplication, outlier removal and time synchronization calibration, and a preprocessed heterogeneous air traffic control signal is generated.

[0015] The preprocessed heterogeneous air traffic control signals are weighted and fused to generate aircraft dynamic data in a unified coordinate system.

[0016] Optionally, the preprocessed heterogeneous air traffic control signals are weighted and fused to generate aircraft dynamic data in a unified coordinate system, including:

[0017] Weights are assigned based on the preprocessed heterogeneous air tube signals;

[0018] The preprocessed heterogeneous air traffic control signals are weighted and fused according to the set weights to generate aircraft dynamic data in a unified coordinate system.

[0019] Optionally, historical conflict resolution success trajectory data is obtained, and this data is input into the AEM model for scenario adaptation and parameter optimization to generate an airport-specific AEM sub-model, including:

[0020] Acquire initial data of successful escape trajectory, preprocess the initial data of successful escape trajectory, and generate historical conflict successful escape trajectory data;

[0021] The historical conflict resolution trajectory data is input into the AEM model and adapted to the scenario and optimized for parameters to generate an AEM sub-model specific to the airport scenario.

[0022] Optionally, based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate risk warning information, including:

[0023] Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate encounter probability, conflict point location and conflict time window.

[0024] A basic risk warning is generated based on the encounter probability and the conflict time window;

[0025] Based on the location of the conflict point, the basic risk warning is modified to correct the risk scenario, and risk warning information is generated.

[0026] Optionally, the encounter probability is generated, including:

[0027] Acquire the aircraft's dynamic data and construct a relative motion model based on the airport scenario-specific AEM sub-model;

[0028] The encounter probability is generated based on the relative motion model.

[0029] Optionally, generate conflict point locations, including:

[0030] The minimum value is obtained by taking the derivative of the relative motion model, and the time corresponding to the minimum value is recorded as the conflict time.

[0031] Substituting the moment of conflict into the aircraft's trajectory equation, the coordinates of the conflict point are obtained.

[0032] Optionally, a conflict time window is generated, including:

[0033] Obtain the time interval of conflict when the distance between aircraft is less than the safe interval;

[0034] A conflict time window is generated based on the conflict time interval.

[0035] Optionally, a regulatory conflict resolution plan is generated based on the risk warning information, and the expected effects of the regulatory conflict resolution plan are output, including:

[0036] Based on the current conflict scenario corresponding to the risk warning information, similar conflict scenarios are selected from the historical trajectory database;

[0037] Based on the similar conflict scenarios, generate a regulatory conflict resolution solution and output the expected effect of the regulatory conflict resolution solution.

[0038] Optionally, an airport control conflict resolution assistance system is also provided, the system comprising:

[0039] The multi-source heterogeneous data processing module is used to acquire multi-source heterogeneous air traffic control signals, and to preprocess and weightedly fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system.

[0040] An airport-specific model generation module is used to acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model, and perform scenario-based adaptation and parameter optimization to generate an airport-specific AEM sub-model.

[0041] The risk warning information generation module is used to perform real-time conflict analysis and prediction based on the aircraft dynamic data and the airport scenario-specific AEM sub-model to generate risk warning information.

[0042] The conflict resolution solution generation module is used to generate a regulatory conflict resolution solution based on the risk warning information and output the expected effect of the regulatory conflict resolution solution.

[0043] Optionally, the multi-source heterogeneous data processing module is further configured to: acquire multi-source heterogeneous air traffic control signals; perform noise reduction, deduplication, outlier removal and time synchronization calibration on the multi-source heterogeneous air traffic control signals, and generate pre-processed heterogeneous air traffic control signals; and weight and fuse the pre-processed heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system.

[0044] Optionally, the multi-source heterogeneous data processing module is further configured to: set weights according to the preprocessed heterogeneous air traffic control signals; weight and fuse the preprocessed heterogeneous air traffic control signals according to the set weights, and generate aircraft dynamic data in a unified coordinate system.

[0045] Optionally, the airport-specific model generation module is further configured to: acquire initial data of successful escape trajectories, preprocess the initial data of successful escape trajectories, and generate historical conflict escape trajectory data; input the historical conflict escape trajectory data into the AEM model and perform scenario-specific adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model.

[0046] Optionally, the risk warning information generation module is further configured to: perform real-time conflict analysis and prediction based on the aircraft dynamic data and the airport scenario-specific AEM sub-model, and generate encounter probability, conflict point location and conflict time window; generate basic risk warning based on the encounter probability and the conflict time window; modify the risk scenario of the basic risk warning based on the conflict point location, and generate risk warning information.

[0047] Optionally, the risk warning information generation module is further configured to: acquire the aircraft dynamic data, construct a relative motion model based on the airport scenario-specific AEM sub-model, and generate an encounter probability based on the relative motion model.

[0048] Optionally, the risk warning information generation module is further configured to: differentiate the relative motion model to obtain the minimum value, and obtain the time corresponding to the minimum value, which is recorded as the conflict time; substitute the conflict time into the motion trajectory equation of the aircraft to obtain the coordinates of the conflict point.

[0049] Optionally, the risk warning information generation module is further configured to: obtain the conflict time interval where the distance between aircraft is less than the safety interval; and generate a conflict time window based on the conflict time interval.

[0050] Optionally, the conflict resolution solution generation module is further configured to: select similar conflict scenarios from the historical trajectory database based on the current conflict scenario corresponding to the risk warning information; generate a control conflict resolution solution based on the similar conflict scenarios; and output the expected effect of the control conflict resolution solution.

[0051] Optionally, a computer device is also provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps described in the above-described airport control conflict resolution assistance method.

[0052] Optionally, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps described in the above-described airport control conflict resolution assistance method.

[0053] The technical effects achieved by this invention are as follows:

[0054] The aforementioned airport control conflict resolution assistance method and system first acquires multi-source heterogeneous air traffic control signals, preprocesses and weights these signals to generate aircraft dynamic data in a unified coordinate system. Considering the differences in coordinate systems, sampling frequencies, and accuracy levels among the multi-source signals, the system unifies and fuses heterogeneous air traffic control automation signals, surface surveillance radar signals, multi-point positioning signals, and airborne signals to provide reliable data within the same data framework for subsequent model input. This addresses the problem of deviations in core data such as aircraft position and speed caused by data heterogeneity in existing technologies. Furthermore, it acquires historical successful conflict resolution trajectory data, inputs this data into the AEM model, and performs scenario-specific adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model. Based on the aircraft dynamic data and the airport scenario-specific AEM sub-model, it performs real-time conflict analysis and prediction, generating risk warning information. This introduces professional conflict modeling and analysis tools, enabling the optimization of conflict resolution schemes based on historical successful trajectories. This solves the problem of poor adaptability to complex conflict scenarios during go-around and takeoff phases caused by manual intervention in existing technologies. Attached Figure Description

[0055] Figure 1 This is a flowchart illustrating an airport control conflict resolution assistance method in one embodiment;

[0056] Figure 2 This is a block diagram of an airport control conflict resolution assistance system in one embodiment. Detailed Implementation

[0057] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0058] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0059] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0060] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0061] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0062] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0063] In one embodiment, a terminal is provided, the terminal being configured to: acquire multi-source heterogeneous air traffic control signals, preprocess and weightedly fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system; acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into an AEM model and perform scenario-specific adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model; based on the aircraft dynamic data, perform real-time conflict analysis and prediction according to the airport scenario-specific AEM sub-model to generate risk warning information; generate an air traffic control conflict resolution solution according to the risk warning information, and output the expected effect of the air traffic control conflict resolution solution.

[0064] The terminal may be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices.

[0065] In one embodiment, such as Figure 1 As shown, an airport control conflict resolution assistance method is provided, the method comprising:

[0066] Step S100: Acquire multi-source heterogeneous air traffic control signals, and preprocess and weighted fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system;

[0067] In this step, the unified coordinate system is preferably the WGS-84 coordinate system, so as to output the aircraft's three-dimensional position, true speed, heading and other data and maintain compatibility with the data interface of the existing air traffic control system.

[0068] When performing conflict analysis calculations, the aircraft dynamic data in the WGS-84 coordinate system is converted to the airport local coordinate system before being used in modeling calculations. The airport local coordinate system is defined as follows: with the airport runway center point as the origin, the X-axis extends along the runway centerline, the Y-axis is perpendicular to the runway centerline, and the Z-axis is the altitude direction. This eliminates the differences in coordinate references between different data sources (air traffic control automation, ADS-B, etc.) and unifies the position reference datum.

[0069] Step S200: Obtain historical conflict resolution successful trajectory data, input the historical conflict resolution successful trajectory data into the AEM model and perform scenario adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model;

[0070] Step S300: Based on the aircraft dynamic data, perform real-time conflict analysis and prediction according to the airport scenario-specific AEM sub-model, and generate risk warning information;

[0071] Step S400: Generate a regulatory conflict resolution plan based on the risk warning information, and output the expected effect of the regulatory conflict resolution plan.

[0072] In this embodiment, multi-source heterogeneous air traffic control signals are first acquired, and then preprocessed and weighted fused to generate aircraft dynamic data in a unified coordinate system. Considering that the multi-source signals have different coordinate systems, sampling frequencies, and accuracy levels, the air traffic control automation signals, surface surveillance radar signals, multi-point positioning signals, and airborne signals, which have data heterogeneity, are fused in a unified manner to provide reliable data under the same data framework for subsequent model input. This solves the problem of deviations in core data such as aircraft position and speed caused by data heterogeneity in the prior art. Furthermore, historical conflict resolution trajectory data is acquired, and this data is input into the AEM model and adapted to the scenario and optimized to generate an airport scenario-specific AEM sub-model. Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate risk warning information. This introduces professional conflict modeling and analysis tools to optimize conflict resolution schemes based on historical successful trajectories, solving the problem of poor adaptability to complex conflict scenarios during go-around and takeoff phases caused by manual intervention in the prior art.

[0073] In one embodiment, step S100: acquiring multi-source heterogeneous air traffic control signals, and preprocessing and weighted fusion of the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system, including:

[0074] Step S110: Acquire multi-source heterogeneous air tube signals;

[0075] Step S120: Perform noise reduction, deduplication, outlier removal and time synchronization calibration on the multi-source heterogeneous air traffic control signal, and generate a preprocessed heterogeneous air traffic control signal;

[0076] Step S130: Weight and fuse the preprocessed heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system.

[0077] In this embodiment, the multi-source heterogeneous air traffic control signals are first preprocessed (denoising, deduplication, outlier removal, and time synchronization calibration). Then, a weighted fusion algorithm is used to combine the positioning accuracy weights of each signal source in different areas (surface area and terminal area) to output aircraft dynamic data in a unified coordinate system. The positioning error is controlled within a preset threshold, providing data support for subsequent conflict analysis.

[0078] The multi-source heterogeneous air traffic control signals include air traffic control automation signals, ground signals, and airborne signals.

[0079] The air traffic control (ATC) signals include aircraft flight number, planned route, real-time and expected altitude, speed, heading, flight status (takeoff, go-around, cruise, landing), control sector affiliation information, and other related data.

[0080] The ground signals include surface surveillance radar signals and multi-point positioning signals. Specifically, the surface surveillance radar signals refer to the real-time and predicted positions, speeds, altitudes, and headings of aircraft on the airport surface, as well as signal-to-noise ratio and stability parameters. The multi-point positioning signals refer to the high-precision three-dimensional position information, position update frequency, and positioning error values ​​of aircraft in the airport terminal area and on the surface, suitable for supplementary monitoring of radar blind spots.

[0081] The airborne signals include the aircraft's airborne ADS-B signals (real-time position, altitude, speed, heading, vertical rate), engine status parameters, route deviation information fed back by the airborne navigation system, go-around trigger signals and cause identifiers.

[0082] In step S120, the denoising process includes: using the Kalman filter algorithm, establishing state equations and observation equations based on the noise characteristics of each signal source (such as Gaussian noise of radar signals and impulse noise of ADS-B signals), estimating the true value of the signal through iterative calculation, and filtering out random noise; additionally superimposing f-median filtering on the surface surveillance radar signal to eliminate salt-and-pepper noise interference and retain effective signals of positional changes (such as emergency turns of aircraft).

[0083] Deduplication includes: using the aircraft flight number + timestamp as a unique identifier, determining duplicate data from different signal sources at the same time (position deviation ≤ 0.5 meters is considered duplicate), retaining the data from the signal source with the highest positioning accuracy, and eliminating redundant data; for signals without flight numbers (such as general aviation aircraft), deduplication is performed using three-dimensional position + velocity vector as an auxiliary identifier.

[0084] Outlier removal includes: using the 3σ criterion combined with domain knowledge to determine outliers; marking and removing signals that exceed the allowable range of signal source positioning error (e.g., multi-point positioning signal error > 3 meters), whose speed changes exceed the physical limits of the aircraft type (e.g., instantaneous speed change of civil aviation passenger aircraft > 20 km / h), or whose altitude data jumps > 100 meters; while retaining outlier records for subsequent signal source status diagnosis.

[0085] Time synchronization calibration includes: using the GPS time synchronization protocol (UTC time) to add precise timestamps (accurate to the millisecond level) to the data of each signal source; for signals with delays (such as air traffic control automation signals with a delay of ≤200ms), time compensation is performed based on the signal transmission link delay model to ensure that the data of different signal sources are aligned at the same time, and the synchronization error is controlled within 10ms.

[0086] The preprocessed heterogeneous air traffic control signals are then weighted and fused to generate aircraft dynamic data in a unified coordinate system.

[0087] In one embodiment, step S130: weighted fusion of the preprocessed heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system, including:

[0088] Step S131: Set weights according to the preprocessed heterogeneous air tube signals;

[0089] Step S132: The preprocessed heterogeneous air traffic control signals are weighted and fused according to the set weights to generate aircraft dynamic data in a unified coordinate system.

[0090] In this embodiment, firstly, data standardization, that is, normalization processing, is performed, and corresponding methods are used for data of different dimensions, as follows:

[0091] Location data (latitude, longitude, and altitude) are normalized using min-max and mapped to the [0,1] interval. The formula is x'=(x-xmin) / (xmax-xmin) (xmax and xmin are the extreme values ​​of the airport control range).

[0092] Speed ​​and heading data are normalized using Z-score to eliminate the influence of dimensions. The formula is x'=(x-μ) / σ (μ is the mean and σ is the standard deviation).

[0093] Next, the weights are determined, specifically by adopting a dynamic weight allocation strategy, which calculates the weights in real time based on the positioning accuracy of each signal source in different areas. For example, for the surface area (runway, taxiway): the weight of the surface surveillance radar W1 = 0.6 × signal-to-noise ratio coefficient + 0.4 × stability coefficient, and the weight of the multi-point positioning signal W2 = 1 - W1.

[0094] The signal-to-noise ratio (SNR) coefficient is a coefficient obtained by normalizing and mapping the SNR parameter carried in the field surveillance radar signal, and is used to reflect the measurement quality of the radar signal within the current statistical window; the stability coefficient is a coefficient obtained by normalizing and mapping the stability parameter carried in the field surveillance radar signal, and is used to reflect the continuous reliability of the radar signal within the statistical window; both the SNR coefficient and the stability coefficient are calibrated based on historical data so that their values ​​fall within the [0,1] interval, and are used to determine the dynamic weights of multi-source fusion.

[0095] For the terminal area (within 10km of the runway): the air traffic control automation signal weight W3 = 0.5 × inverse positioning error coefficient + 0.5 × data update frequency coefficient, and the ADS-B signal weight W4 = 1 - W3. The inverse positioning error coefficient and the data update frequency coefficient are obtained by calibrating historical data to the [0,1] interval. The total weight is always 1.

[0096] Next, a fusion calculation is performed: the normalized data of the same type (such as position and velocity) are weighted and summed separately, using the following formula: ,in, It is a weighted sum. Let i be the weight of the i-th signal source. This is the normalized data.

[0097] Finally, inverse normalization is performed: the fused standardized data is restored to the actual physical quantities, and the three-dimensional position, true velocity, heading and other data in the unified WGS-84 coordinate system are output.

[0098] In one embodiment, step S200 involves acquiring historical conflict resolution trajectory data, inputting the historical conflict resolution trajectory data into the AEM model, and performing scenario-specific adaptation and parameter optimization to generate an airport-specific AEM sub-model, including:

[0099] Step S210: Obtain initial data of successful escape trajectory, preprocess the initial data of successful escape trajectory, and generate historical conflict successful escape trajectory data;

[0100] Step S220: Input the historical conflict resolution trajectory data into the AEM model and perform scenario-based adaptation and parameter optimization to generate an AEM sub-model specific to the airport scenario.

[0101] In this embodiment, based on the AEM (Aircraft / Airspace Encountered Model) commonly used in the TACS system, and combined with historical conflict resolution trajectory data between airport go-around and takeoff, go-around and go-around, and takeoff and takeoff in recent years, an airport-specific AEM sub-model is generated, providing a scenario-based conflict analysis model for subsequent conflict prediction, risk assessment and resolution scheme generation.

[0102] In step S210, data on go-around and takeoff conflict events and corresponding successful escape trajectories of domestic airports of different levels (large hub airports and medium-sized airports) over the past 5-10 years are collected, covering different weather conditions (sunny days, rain, snow, fog, strong winds, etc.), runway layout, and traffic density scenarios.

[0103] The successful escape trajectory data specifically includes aircraft spatiotemporal parameters (three-dimensional position, speed, heading, and vertical rate every 100ms), operational parameters (flight number, aircraft type, takeoff / go-around time, and runway number), environmental parameters (meteorological conditions, visibility, cloud height, wind direction and speed), conflict parameters (relative distance and speed between the conflicting parties, duration of the conflict), handling parameters (control instructions, instruction issuance time, aircraft response time, and trajectory adjustment range), and result parameters (whether the conflict was resolved, the safe interval after escape, and the fault-free operation duration).

[0104] The initial data of the successful escape trajectory is preprocessed, and the specific processing steps are as follows:

[0105] 1. Data alignment: Using the moment of the conflict as the time origin (t=0), the trajectory data from 5 minutes before the conflict to 5 minutes after the conflict are aligned along the time axis. The sampling frequency is uniformly 100ms / point. Missing data is supplemented by linear interpolation (missing rate ≤5%) to ensure the consistency of the data in the time dimension.

[0106] 2. Coordinate System 1: Convert all trajectory data into the airport's local coordinate system (with the runway center point as the origin, the X-axis extending along the runway centerline, the Y-axis perpendicular to the runway centerline, and the Z-axis representing altitude), eliminating coordinate system differences between different data sources (air traffic control automation, ADS-B, etc.) and unifying the position reference benchmark.

[0107] 3. Unit standardization: Standardize the units of core parameters, such as speed (km / h), altitude (meters), heading (degrees, 0°-360°), distance (meters), and time (seconds), to avoid the impact of dimensional differences on subsequent analysis.

[0108] 4. Abnormal trajectory removal: Remove trajectory distortion data caused by signal interruption or data error (such as position jump or speed abnormality), retain valid trajectories with clear conflict scenarios and complete handling processes (valid trajectory ratio ≥ 85%), and ensure data reliability.

[0109] 5. Conflict point coordinate extraction: Calculate the position coordinates of the two conflicting parties when the distance is minimized based on the trajectory data, and confirm the actual conflict point in combination with airport airspace restrictions (the horizontal interval must be <2km or the vertical interval <300m).

[0110] 6. Adjustment Quantity Extraction: Based on the aircraft status one minute before the conflict, extract the maximum speed adjustment quantity during the disengagement process. ), maximum height adjustment ( ), heading adjustment angle ( (), accurate to 1 km / h, 10 meters, 1°.

[0111] 7. Handling time extraction: Calculate the time difference from the issuance of control instructions to the resolution of the conflict (interval restored to safety standards), accurate to 0.1 seconds.

[0112] 8. Control command type extraction: By transcribing voice records and matching control logs, command types (heading adjustment, altitude adjustment, speed adjustment, return to base and diversion, etc.) are extracted and a correspondence between commands and trajectory adjustments is established.

[0113] After the above preprocessing, historical conflict resolution trajectory data is generated.

[0114] Next, in step S220, the preprocessed historical conflict resolution trajectory data is input into the AEM model to optimize the model parameters (aircraft encounter distance threshold, conflict risk level classification standard, trajectory adjustment constraints) to adapt it to the conflict characteristics of airport takeoff and go-around scenarios, thereby improving the model's ability to identify and analyze similar conflict scenarios.

[0115] Considering that the original AEM model is a general airspace model with parameters designed for the cruise phase, it does not match the airport takeoff / go-around scenario (small airspace, rapid changes in aircraft speed, and strong runway constraints on trajectory).

[0116] The optimized parameters can accurately capture the characteristics of airport scenario conflicts, such as reducing the encounter distance threshold to adapt to the dense airspace of the airport terminal area; adjusting the risk level classification standard, combining runway position weight, and assigning higher risk weight to conflicts close to the runway; and optimizing trajectory constraints to adapt to the dynamic characteristics and maneuver limits of aircraft during takeoff / go-around phases.

[0117] By accurately matching parameters with scene features, the model can quickly identify conflict patterns in similar scenes, improving the accuracy and relevance of identification and analysis.

[0118] Specifically, the steps for scenario-based adaptation and parameter optimization are as follows:

[0119] 1. Parameter initialization: Based on the default parameters of the TACS system AEM model, initial values ​​are set according to the characteristics of the airport scenario (e.g., the initial encounter distance threshold is set to 2.5km, and the initial horizontal safety interval is set to 2km).

[0120] 2. Dataset partitioning: The historical conflict resolution trajectory data are divided into a training set (for parameter optimization) and a validation set (for effect verification) in a 7:3 ratio to ensure that the two datasets cover different scenarios.

[0121] 3. Iterative Optimization: The gradient descent algorithm is used, with conflict prediction accuracy and scheme suitability as objective functions, to iteratively adjust model parameters. For example, the prediction accuracy on the validation set is calculated for every 0.1km adjustment of the encounter distance threshold until the accuracy reaches its peak. For the risk level classification criteria, the interval threshold and time threshold for each level are optimized through confusion matrix analysis.

[0122] 4. Constraint calibration: Combine the aircraft performance parameters (such as the maximum heading adjustment rate of Boeing 737 and the altitude adjustment range of Airbus A320) to optimize the trajectory adjustment constraints and ensure that the scheme generated by the model conforms to the physical limits of the aircraft.

[0123] 5. Parameter solidification: Solidify the optimized parameters (such as setting the encounter distance threshold for takeoff scenario to 2km and for go-around scenario to 1.8km) into the model to generate an AEM sub-model specific to the airport scenario.

[0124] In one embodiment, step S300: Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate risk warning information, including:

[0125] Step S310: Based on the aircraft dynamic data, perform real-time conflict analysis and prediction according to the airport scenario-specific AEM sub-model to generate the encounter probability, conflict point location and conflict time window;

[0126] Step S320: Generate a basic risk warning based on the encounter probability and the conflict time window;

[0127] Step S330: Based on the location of the conflict point, modify the basic risk warning scenario and generate risk warning information.

[0128] In this embodiment, real-time conflict analysis and prediction are performed based on the aircraft dynamic data and the airport scenario-specific AEM sub-model to generate encounter probability, conflict point location, and conflict time window; basic risk warning is generated based on the encounter probability and conflict time window; risk scenario correction is performed on the basic risk warning based on the conflict point location, and risk warning information is generated; this realizes the calculation of encounter probability, conflict point location, and conflict time window between aircraft in real time using the AEM model based on aircraft dynamic data under a unified coordinate system after multi-source fusion, and the classification of conflict risk levels (low risk, medium risk, high risk) is combined with airport runway and taxiway layout and airspace restrictions to generate risk warning information.

[0129] In one embodiment, step S310, generating the encounter probability, includes:

[0130] Step S3111: Obtain the aircraft dynamic data and construct a relative motion model based on the airport scene-specific AEM sub-model;

[0131] Step S3112: Generate the encounter probability based on the relative motion model.

[0132] In this embodiment, the aircraft's position P1(x1,y1,z1), P2(x2,y2,z2), speed (V1,V2), and heading (θ1, θ2) are extracted from the aircraft dynamic data to be calculated.

[0133] The relative motion model constructed based on the airport scene-specific AEM sub-model is as follows:

[0134]

[0135]

[0136]

[0137]

[0138] Where X1, Y1, and Z1 represent the square terms of relative displacement in the east-west, north-south, and vertical directions, respectively, and Δz is the vertical velocity.

[0139] The probability of an encounter is calculated as the percentage of time within the next 5 minutes when the distance ΔP(t) between the aircraft and the safe interval is less than the safe interval. The probability of an encounter ranges from 0 to 1.

[0140] In one embodiment, step S310, generating the conflict point location, includes:

[0141] Step S3121: Differentiate the relative motion model to obtain the minimum value, and obtain the time corresponding to the minimum value, which is recorded as the conflict time;

[0142] Step S3122: Substitute the time of conflict into the aircraft's trajectory equation to obtain the coordinates of the conflict point.

[0143] In this embodiment, the minimum value is obtained by taking the derivative of the relative motion model. The minimum value is found, which is the moment when the two aircraft are closest to each other, denoted as the conflict moment t0.

[0144] For the trajectory equation of the aircraft, at the reference time t=0, the dynamic data of the aircraft includes the dynamic data of the aircraft, specifically Pi=(xi, yi, zi), velocity Vi, heading θi, and vertical speed Δzi.

[0145] Extrapolating to the future second t, the equation of motion trajectory obtained using the kinematic model is calculated as follows:

[0146] xi(t) = xi + Vi*t*cosθi;

[0147] yi(t) = yi + Vi*t*sinθi;

[0148] zi(t) = zi + Δzi*t;

[0149] Therefore, once the moment of conflict is obtained, the coordinates P0(x0,y0,z0) of the conflict point can be obtained by substituting them into the motion trajectory equation.

[0150] In one embodiment, step S310, generating the conflict time window, includes:

[0151] Step S3131: Obtain the time interval of conflict when the distance between aircraft is less than the safe interval;

[0152] Step S3132: Generate a conflict time window based on the conflict time interval.

[0153] In this embodiment, the time interval [t_start, t_end] where ΔP(t) < the safe interval is determined and denoted as the conflict time interval. t_start is the moment of first entering the unsafe interval, and t_end is the moment of leaving the unsafe interval. The time window length Δt = t_end - t_start. The longer Δt is, the higher the risk of conflict.

[0154] In another embodiment, the basic risk warning includes high risk, medium risk, and low risk.

[0155] In step S320, the encounter probability is denoted as Pe, and a preliminary classification is performed based on the encounter probability (Pe) and the time window length (Δt), as follows:

[0156] Pe≥0.8 and Δt≥60s indicates high risk;

[0157] 0.5≤Pe<0.8 and 30s≤Δt<60s is considered medium risk;

[0158] A low risk is defined as Pe < 0.5 and Δt < 30s.

[0159] In step S330, scene weight correction is performed, as follows:

[0160] Based on the airport layout, for conflicts that are close to the runway (distance ≤1km) or taxiway intersections, the risk level is increased by one level (low risk → medium risk, medium risk → high risk); for conflicts under severe weather conditions (visibility <800 meters, gusts >15m / s), an additional probability weight of 0.2 is added.

[0161] Finally, the risk level is determined. Based on the overall assessment and scenario adjustments, the final risk level is determined and indicated by corresponding color codes (high risk → red, medium risk → yellow, low risk → green).

[0162] Furthermore, the risk warning information includes core elements: flight numbers, aircraft types, current positions / speeds / headings of both parties in the conflict; coordinates of the conflict point and the conflict time window (accurate to the second); risk level and color coding; and analysis of the causes of the conflict, such as "clash of takeoff runways" and "close approach of a go-around aircraft to a departing aircraft".

[0163] In one embodiment, step S400: generating a regulatory conflict resolution solution based on the risk warning information, and outputting the expected effect of the regulatory conflict resolution solution, including:

[0164] Step S410: Based on the current conflict scenario corresponding to the risk warning information, select similar conflict scenarios from the historical trajectory database;

[0165] Step S420: Generate a regulatory conflict resolution solution based on the similar conflict scenario, and output the expected effect of the regulatory conflict resolution solution.

[0166] In this implementation, for conflicts of different risk levels, appropriate solutions are generated by combining historical successful trajectories and model analysis results. These solutions include heading adjustment angles, altitude adjustment ranges, speed control recommendations, etc., and the implementation priority and expected effects of the solutions are marked.

[0167] The definition of model analysis results refers to the core conflict feature data output by the AEM model, including encounter probability, conflict point location, time window length, risk level, relative motion trend of aircraft, trajectory adjustment constraint boundaries (such as maximum adjustable heading / altitude), and available adjustment space in airport airspace (avoiding no-fly zones and runway protection zones).

[0168] The generation of a solution follows a complete process of scenario matching, constraint verification, parameter optimization, and backup options. The specific steps are as follows:

[0169] 1. Historical trajectory matching: Based on the current conflict scenario (aircraft type combination, conflict type, weather conditions, airport layout) corresponding to the risk warning information, retrieve successful cases with similarity ≥80% from the historical trajectory database, and extract the corresponding escape strategies (such as "heading adjustment + slight altitude increase") and parameter ranges (such as heading adjustment 5°-20°, altitude increase 30-100 meters).

[0170] 2. Model constraint verification: Substitute historical strategy parameters into the AEM model, and simultaneously combine them with scenario-based constraint parameters (aircraft performance limits, airport airspace restrictions, and weather adaptation standards) to verify whether the scheme meets three requirements: first, the risk can be eliminated within the conflict time window; second, the trajectory adjustment does not touch the restricted airspace and runway protection zone; and third, it conforms to the aircraft type's maneuverability (e.g., the maximum heading adjustment rate of Boeing 737 is ≤30° / min).

[0171] 3. Scheme Parameter Optimization: For strategies that have passed verification, the optimal parameters are calculated iteratively using the AEM model. Taking heading adjustment as an example, the adjustment is incremented from the minimum amount (1° each time), and the encounter probability, safety interval, and impact on surrounding flights are calculated in real time. The optimal solution is the parameter combination that "reduces the encounter probability to below 0.1, minimizes the adjustment range, and minimizes interference with airport operations," thereby generating a control conflict resolution scheme.

[0172] 4. Alternative Plan Generation: For high / medium risk conflicts, 2-3 differentiated alternative plans need to be generated (the main plan prioritizes heading / altitude adjustment, and alternative plans can include speed adjustment, takeoff / go-around delay, etc.) to ensure that if a single plan fails due to air traffic control delays, abnormal aircraft responses, or other reasons, a quick switch can be made.

[0173] For example, there is a conflict between go-around and departure at Shanghai Hongqiao International Airport (SHA) (Hongqiao Airport has two parallel runways, 18L / 36R and 18R / 36L, with a distance of 365 meters. It is one of the busiest hub airports in China. During peak hours, the takeoff interval on a single runway is only 90 seconds, which can easily lead to conflicts between the trajectories of go-around and departure aircraft).

[0174] Specific scenarios:

[0175] Flight A (Boeing 737-800) was operating a flight from Shanghai Hongqiao to Beijing. During its approach to runway 18L, the RVR (Runway Visual Range) suddenly dropped below 500 meters (below the landing standard), triggering a go-around. After the go-around, the aircraft climbed along the extended centerline of runway 18L at a speed of 260 km / h, an altitude of 200 meters, and a vertical climb rate of 3 meters per second.

[0176] Flight B (Airbus A320neo) was operating a flight from Shanghai Hongqiao to Guangzhou. It took off from the adjacent 18R runway at a speed of 275 km / h and an altitude of 180 meters. It was flying along the planned departure route (the extension of the centerline of runway 18R). The relative distance between the two aircraft continued to decrease. The AEM model calculated the probability of encounter to be 0.88, with a conflict time window of 75 seconds. Initially, it was classified as a medium-risk flight. However, due to the proximity of the conflict point to the core airspace of Hongqiao Airport (1.2 km from the runway end), the scenario weight was adjusted and upgraded to a high-risk flight. The conflict point was located 320 meters above the intersection of the extension of runway 18L and the departure route of runway 18R.

[0177] Main plan (heading adjustment + altitude adjustment): Instruct Flight B to adjust its heading 90° to the right (heading 270°, altitude 600 meters); Instruct Flight A to maintain its heading on the runway at an altitude of 900 meters, thus avoiding each other and flying separately while avoiding the restricted area on the east side of Hongqiao Airport. AEM model simulation predicts that after 42 seconds, the horizontal separation between the two aircraft will reach 4.6 km and the vertical separation will reach 300 meters, reducing the probability of encounter to 0.07. There will be no flight delays or subsequent traffic interference, meeting the operational requirements of Hongqiao Airport during peak hours.

[0178] Alternative plan (speed adjustment + departure route fine-tuning): After takeoff, flight B is instructed to reduce its speed by 30 km / h, maintain an altitude of 180 meters, and at the same time, slightly adjust its heading to the right by 8° to extend the intersection time between the departure route and the go-around route. The conflict resolution time is 58 seconds, with no chain delays to other flights. This plan is suitable for the scenario of dense ground taxi queues at Hongqiao Airport and avoids the impact of the main plan adjustment on the fuel consumption of the go-around aircraft.

[0179] 6. Implementation Priority Determination: A weighted scoring method is adopted, with the weights allocated as follows:

[0180] Timeliness of response (40%), impact on airport operations (30%), complexity of the solution (20%), and reliability (10%). Higher scores indicate higher priority: the primary solution must score ≥80 points, and alternative solutions must score ≥60 points.

[0181] In the example above, the main solution scored 86 points (40 points for timeliness, 28 points for impact, 12 points for complexity, and 6 points for reliability), and its priority is higher than that of the alternative solution (72 points).

[0182] 7. Expected Results Execution:

[0183] The simulation outputs core indicators based on the AEM model, including conflict resolution time (accurate to the second), final safe separation (horizontal / vertical), encounter probability reduced to the target value, flight delay duration (if any), and fuel consumption increment (estimated value). The expected outcome of the main scenario is: conflict resolution after 45 seconds, horizontal separation of 2.5 km, vertical separation of 400 meters, encounter probability of 0.08, no delay, and fuel consumption increment ≤ 5 kg. The expected outcome of alternative scenario 2 is: conflict resolution after 35 seconds, separation target met, flight A delayed by 10 seconds, and fuel consumption increment 8 kg.

[0184] In one embodiment, the method further includes: setting scenario-based constraint parameters to ensure that the conflict analysis and resolution schemes meet actual operational needs. These parameters can be flexibly configured according to different airport characteristics and operational scenarios. The core configuration content is as follows:

[0185] Airport basic parameters: number of runways, layout type (parallel runways, intersecting runways), taxiway network structure, runway safety separation standards, airport airspace range and boundary coordinates;

[0186] Operational constraints: takeoff / go-around standards under different meteorological conditions (visibility, cloud height, wind direction and speed), airport traffic peak threshold, and upper limit of air traffic control instruction response time;

[0187] Signal parameter thresholds: allowable positioning error range for each signal source, signal loss alarm threshold, and data update frequency requirements;

[0188] Conflict assessment parameters: minimum safe separation of aircraft (horizontal separation, vertical separation) in different scenarios, conflict warning advance time (configurable from 30 seconds to 5 minutes), and risk level classification threshold.

[0189] Parameter source explanation: The parameter source adopts a three-in-one model of "industry standard + actual measurement + empirical calibration":

[0190] Industry standards are based on core parameters such as airport basic parameters, minimum safe separation, and takeoff / go-around standards, and strictly follow industry standards such as the "Civil Aviation Air Traffic Management Rules" and the "Airport Operation Safety Management Regulations" to ensure compliance.

[0191] Actual measurement data: parameters such as runway / taxiway coordinates, airspace boundaries, and signal source positioning errors are obtained through actual measurements such as GPS mapping and signal link testing to ensure data accuracy (e.g., runway coordinate measurement error ≤ 0.5 meters).

[0192] Experience-based calibration supplement: Parameters such as meteorological adaptation parameters, early warning lead time, and signal loss alarm threshold are calibrated by combining the experience of pilot airport controllers and historical operational data. For example, the flow threshold is adjusted based on the actual measured data of airport flow peak to adapt to the actual operational load.

[0193] In another embodiment, based on the operating habits of tower controllers, a human-computer interaction scheme that is deeply integrated with the tower electrical interface is designed to realize the functions of visual display of conflict information, rapid retrieval of resolution solutions, and instruction feedback.

[0194] Specifically, the design requirements are as follows:

[0195] The interface adopts a 16:9 widescreen layout, with the main tower control interface on the left (accounting for 70%) and the conflict assistance bar on the right (accounting for 30%). The conflict pop-up is a floating design, centered, and does not obstruct the core area of ​​the main interface. The interface color scheme is mainly dark blue (main color) and white (text), with risk indicator colors (red / yellow / green) highlighted to meet the operation requirements of the control tower in low-light environments.

[0196] Interface layout design: The layout adopts a "main interface of the Tower Control System + conflict auxiliary pop-up" mode, and the conflict auxiliary information does not obscure the core content of the Tower Control System (flight progress sheet, runway status, and air traffic control instruction records). A conflict warning bar is set on the side of the Tower Control System interface, and conflict events are marked according to risk level (red, yellow, green). Clicking on the event will expand the details pop-up.

[0197] Visualized display content: The pop-up window displays information about the aircraft of both sides in the conflict (flight number, aircraft type, location coordinates), conflict point and time window, risk level, optimal resolution and alternative solutions generated by the AEM model, and simultaneously overlays airport runway and taxiway maps to intuitively present trajectory adjustment suggestions (the adjusted trajectory is marked with a dashed line, and the current trajectory is marked with a solid line).

[0198] Operational Function Design: Provides one-click confirmation of conflict resolution solutions, manual adjustment, and instruction issuance feedback functions. Controllers can modify the solutions generated by the model (adjust parameters such as heading and altitude), and the system automatically synchronizes the modified trajectory simulation results (updating the conflict resolution probability in real time). It supports conflict event recording and backtracking, automatically saves data of the entire conflict handling process (including instructions, trajectories, and feedback), and allows backtracking by time and flight number.

[0199] Interactive experience optimization: Interface response latency ≤0.5 seconds, supports shortcut key operations (such as Ctrl+R to switch risk level display, Ctrl+S to call up the optimal solution), alarm prompts adopt dual reminders of sound + visual, the sound frequency increases with the risk level (2Hz for high risk, 1Hz for medium risk, and 0.5Hz for low risk), and the visual reminder flashes the corresponding risk color mark in sync to avoid controllers missing key information.

[0200] In one embodiment, the method further includes: establishing a multi-dimensional testing system to verify the reliability of system functions through simulated scenario testing, historical data backtracking testing, and on-site trial operation testing, thereby forming a continuous optimization and iteration mechanism.

[0201] The test plan is designed as follows:

[0202] Simulated scenario testing: Construct simulated scenarios with different airport layouts (parallel runways, intersecting runways), weather conditions (sunny day, heavy fog, strong wind), and traffic density (peak / off-peak / low peak). Incorporate typical takeoff and go-around conflict cases (such as simultaneous takeoffs from intersecting runways, and conflicts between go-around aircraft and departing aircraft) to test the system's conflict warning accuracy, the rationality of the generated solutions, and the interface response speed.

[0203] Historical data backtesting: Using historical data of past conflict events (selecting 500+ typical cases), the consistency between the system analysis results and the actual handling solutions is compared to verify the adaptability of the AEM model;

[0204] On-site trial operation test: Deploy the system in the control towers of 2-3 pilot airports of different levels, combine with actual operation scenarios, and run it continuously for 3 months to collect operator operation feedback and system operation data to test the stability and practicality of the system in a real environment.

[0205] The optimization iteration mechanism is as follows:

[0206] Based on the error data and operational feedback collected during the testing process, the signal fusion algorithm, AEM model parameters, human-machine interface layout, and scene configuration parameters were optimized in a targeted manner. A system operation log analysis mechanism was established to regularly collect statistics on indicators such as conflict warning accuracy and solution adoption rate, so as to continuously improve system performance.

[0207] In one embodiment, this application, based on the core framework of the TACS system's AEM model, reconstructs and optimizes parameters for airport takeoff and go-around scenarios. It introduces historical successful trajectory data to train the model, adds specialized logic for identifying go-around trigger conditions and predicting takeoff runway conflicts, optimizes the conflict encounter probability calculation algorithm, and combines the spatial constraint parameters of the airport airspace structure adjustment model. This enables the model to accurately identify typical scenarios such as takeoff conflicts at intersecting runways and conflicts between go-around aircraft and departing aircraft, achieving a conflict prediction accuracy of ≥95%.

[0208] The logic for identifying the trigger conditions for resuming flights is as follows:

[0209] ① Collect airborne go-around signals, altitude data, heading data, meteorological data, and air traffic control instructions; ② Set trigger condition thresholds: altitude ≤ decision altitude (e.g., 60 meters), heading deviation from runway centerline > 5°, vertical speed < 0, receiving air traffic control go-around instructions or airborne go-around signals; ③ If any two or more of the above conditions are met and the duration is ≥ 3 seconds, it is determined as a go-around trigger; ④ Simultaneously identify the go-around cause (severe weather, runway incursion, equipment failure), and combine meteorological data and runway status data to assist in the determination.

[0210] Takeoff runway conflict prediction logic: ① Extract takeoff queues, takeoff intervals, aircraft speeds, and heading data for each runway; ② Calculate the relative distance and time difference between adjacent takeoff aircraft. If the takeoff interval on the same runway is <2 minutes, or the relative distance between aircraft taking off from intersecting runways is <1.5km within the next 2 minutes; ③ Combine runway layout to determine if there is any intersection or overlap in trajectories. If the above conditions are met, a takeoff runway conflict is predicted; ④ For parallel runways, additionally check if the horizontal separation is <3km to avoid conflicts due to insufficient separation.

[0211] Encounter probability algorithm optimization: Introduce scenario weight factors. Specifically, for takeoff / go-around scenarios, add runway weight (1.2 for near runway and 0.8 for far runway) and weather weight (1.3 for severe weather and 1.0 for normal weather). Correct the encounter probability calculation formula: P = P × runway weight × weather weight.

[0212] Optimize the relative motion model: Consider the aircraft's acceleration characteristics during takeoff and climb characteristics during the go-around phase, and correct the speed parameters (the speed during takeoff is calculated using a uniform acceleration model, and the vertical rate during the go-around phase is calculated using a fixed climb rate) to improve the accuracy of motion trajectory prediction.

[0213] Iterative calibration of algorithm parameters: Based on historical conflict cases, the interval threshold and time coefficient in the algorithm are adjusted to ensure that the consistency between the calculated encounter probability and the actual conflict occurrence is ≥95%; through validation set testing, the algorithm convergence speed is optimized to ensure that the real-time calculation delay is ≤100ms.

[0214] Typical scenario recognition logic: Construct an airport airspace structure model. Specifically, input the coordinates and attributes of runways, taxiways, no-fly zones, and airspace boundaries, divide different functional areas (take-off climb zone, go-around protection zone, and approach zone), and set flight constraints for each area (such as the altitude range of the climb zone and the heading restrictions of the go-around zone).

[0215] Extract scene feature parameters: For takeoff conflicts on intersecting runways, extract feature parameters (intersection angle of the two runways, difference in heading of the takeoff aircraft, whether the conflict point is in the intersection area); for conflicts between go-around and departing aircraft, extract feature parameters (climb altitude of the go-around aircraft, flight path of the departing aircraft, and relative headings of the two).

[0216] Constraint parameter matching: Real-time conflict data is matched with airspace structure model and scene feature parameters. If the heading difference between aircraft taking off from intersecting runways is ≤30° and the conflict point is in the runway intersection area, it is determined to be an intersecting runway takeoff conflict. If the difference between the climb altitude of the go-around aircraft and the altitude of the departing aircraft is <300 meters and the relative distance is <1.8km, it is determined to be a go-around and departing aircraft conflict.

[0217] Scenario-specific strategy invocation: After identifying typical scenarios, the corresponding exclusive analysis strategy is automatically invoked (such as prioritizing the heading adjustment scheme for cross-runway conflicts) to improve the targeting of the analysis.

[0218] In one embodiment, an integrated interactive design technology for the tower control interface is also employed. Specifically, a component-based interface development model is used to design interactive plugins that are compatible with different tower control system versions, achieving seamless integration of conflict assistance functions with the existing tower control interface and avoiding interference from system modifications to existing control procedures. Through visualization rendering technology, conflict trajectories and suggested solutions are overlaid with airport maps and flight progress data, enabling controllers to handle conflicts without switching operating scenarios, thus improving decision-making efficiency.

[0219] In one embodiment, a scenario parameter database is established to store the basic configurations, operational constraints, and meteorological adaptation parameters for different airports. This allows the system to automatically call the corresponding parameter configurations based on airport type, operating period, and meteorological conditions. Combined with machine learning algorithms, the system automatically optimizes conflict judgment thresholds and solution generation priorities based on historical operational data, enabling it to adapt to the operational needs of different scenarios and improve its adaptability in complex environments.

[0220] Data preprocessing: Collect historical operational data (including conflict event data, scheme implementation data, and control feedback data), remove invalid data, and label core features (scenario type, conflict characteristics, threshold parameters, scheme priority, and implementation effect).

[0221] Model selection and training: The random forest algorithm is used to build an optimized model, with scene type and conflict characteristics as input variables and conflict judgment threshold and solution priority as output variables. The model is trained with 70% of historical data, and hyperparameters such as the number and depth of decision trees are optimized to make the model prediction accuracy ≥90%.

[0222] Conflict detection threshold optimization: The model predicts the optimal threshold range based on the input scenario data (e.g., the horizontal safety interval threshold in foggy weather can be optimized from 2km to 2.5km); after adding 100 new running data in each batch, the model is retrained and the threshold parameters are dynamically updated to ensure adaptation to scenario changes.

[0223] Solution priority optimization: The model combines historical solution adoption rates, handling effects, and control feedback to adjust priority weights (e.g., if the heading adjustment solution has an adoption rate of 90% in a certain scenario, its weight is increased); the implementation effect of solutions in the current scenario is statistically analyzed in real time, and priorities are dynamically sorted to ensure that the optimal solution is placed at the top.

[0224] Effect verification and feedback: Verify the optimization effect through trial operation. If the accuracy of conflict warning is improved by ≥5% and the adoption rate of the solution is improved by ≥10%, then the optimization parameters are fixed; otherwise, backtrack and adjust the model hyperparameters until the expected effect is achieved.

[0225] In summary, this application achieves a breakthrough in the accuracy of multi-source signal fusion. Specifically, by adopting a full-process solution of "preprocessing-dynamic weighted fusion-deviation correction", the aircraft position positioning error is controlled to ≤5 meters. Compared with the existing technology (positioning error ≥8 meters), the accuracy is improved by 37.5%, providing accurate data support for conflict analysis and avoiding misjudgments caused by data deviation.

[0226] In addition, the accuracy of conflict prediction has been greatly improved. Specifically, through scenario-based optimization of the AEM model and training on historical trajectories, the accuracy of conflict prediction is ≥95%, with an accuracy of 97.5% in the pilot scenario at Hongqiao Airport, far exceeding the existing technology (≤85%). It can also issue an early warning 2 minutes in advance, giving controllers sufficient time to respond.

[0227] In addition, the efficiency of handling is significantly improved: the system takes ≤1 second to generate a solution and the interface response delay is ≤0.5 seconds. Combined with the seamless integration design of the tower power interface, controllers do not need to switch between interfaces. The decision delay is reduced from ≥3 seconds in the existing technology to ≤1 second, and the handling efficiency is improved by 66.7%.

[0228] On the other hand, through intelligent solution generation and visualization functions, the workload of controllers in manual judgment, parameter calculation and information retrieval is reduced. After pilot verification at Hongqiao Airport, the manual intervention time for controllers in handling single conflicts has been reduced by 40%, effectively alleviating the work pressure during peak hours and reducing the probability of human error.

[0229] It also improves airport operational efficiency. Specifically, it generates optimal solutions for high-risk conflicts, avoiding flight delays caused by ineffective adjustments. During the pilot period at Hongqiao Airport, the incidence of takeoff / go-around conflicts during peak hours decreased by 60%, and the average time saved per conflict handling was 10-15 seconds, thus improving the overall operational capacity of the airport.

[0230] Furthermore, it achieves cost savings in operations: the optimized escape plan can reduce the magnitude of aircraft trajectory adjustments, saving an average of 5-8 kg of fuel per conflict. Based on the fact that Hongqiao Airport handles more than 200 conflict incidents annually, it can save an average of 1000-1600 kg of fuel per year. At the same time, it reduces the probability of diversions and return flights due to conflicts, further reducing operating costs.

[0231] In addition, it enables flexible adaptation to multiple scenarios: it supports different airport layouts such as parallel runways and intersecting runways, and can dynamically adjust parameters according to weather conditions and traffic density. It can adapt to the peak operation needs of large hub airports such as Hongqiao and Pudong, as well as the low traffic scenarios of small and medium-sized airports, solving the problem of rigid adaptation of existing technologies.

[0232] It has the advantages of easy integration and promotion: it adopts a non-intrusive tower-electric interface integration solution, which does not require modification of the existing air traffic control system, resulting in low deployment cost and short cycle; it forms a standardized implementation process and adaptation manual, which can be quickly promoted to airports of different levels across the country and has broad application prospects.

[0233] In terms of safety redundancy and reliability assurance, it has multiple fault tolerance mechanisms: it has fault tolerance capabilities such as signal source switching, model degradation, and emergency plan backup, effectively responding to emergencies such as signal interruption and model anomaly, and the system's continuous operation stability is ≥99.5%, ensuring the safety of air traffic control operations.

[0234] It also enables full-process traceability: automatically records data of the entire conflict handling process (including signals, trajectories, plans, and instructions), supports retrieval and backtracking by time and flight number, provides complete data support for accident analysis, controller training, and system optimization, and improves the air traffic control safety management system.

[0235] In one embodiment, such as Figure 2 As shown, an airport control conflict resolution assistance system is also provided, the system comprising:

[0236] The multi-source heterogeneous data processing module is used to acquire multi-source heterogeneous air traffic control signals, and to preprocess and weightedly fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system.

[0237] An airport-specific model generation module is used to acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model, and perform scenario-based adaptation and parameter optimization to generate an airport-specific AEM sub-model.

[0238] The risk warning information generation module is used to perform real-time conflict analysis and prediction based on the aircraft dynamic data and the airport scenario-specific AEM sub-model to generate risk warning information.

[0239] The conflict resolution solution generation module is used to generate a regulatory conflict resolution solution based on the risk warning information and output the expected effect of the regulatory conflict resolution solution.

[0240] In one embodiment, the multi-source heterogeneous data processing module is further configured to: acquire multi-source heterogeneous air traffic control signals; perform denoising, deduplication, outlier removal and time synchronization calibration on the multi-source heterogeneous air traffic control signals, and generate preprocessed heterogeneous air traffic control signals; and weight and fuse the preprocessed heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system.

[0241] In one embodiment, the multi-source heterogeneous data processing module is further configured to: set weights according to the preprocessed heterogeneous air traffic control signals; weight and fuse the preprocessed heterogeneous air traffic control signals according to the set weights, and generate aircraft dynamic data in a unified coordinate system.

[0242] In one embodiment, the airport-specific model generation module is further configured to: acquire initial data of successful escape trajectories, preprocess the initial data of successful escape trajectories, and generate historical conflict escape trajectory data; input the historical conflict escape trajectory data into the AEM model and perform scenario-specific adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model.

[0243] In one embodiment, the risk warning information generation module is further configured to: perform real-time conflict analysis and prediction based on the aircraft dynamic data and the airport scenario-specific AEM sub-model, and generate encounter probability, conflict point location and conflict time window; generate basic risk warning based on the encounter probability and the conflict time window; modify the risk scenario of the basic risk warning based on the conflict point location, and generate risk warning information.

[0244] In one embodiment, the risk warning information generation module is further configured to: acquire the aircraft dynamic data, construct a relative motion model based on the airport scenario-specific AEM sub-model, and generate an encounter probability based on the relative motion model.

[0245] In one embodiment, the risk warning information generation module is further configured to: differentiate the relative motion model to obtain the minimum value, and obtain the time corresponding to the minimum value, denoted as the conflict time; substitute the conflict time into the motion trajectory equation of the aircraft to obtain the coordinates of the conflict point.

[0246] In one embodiment, the risk warning information generation module is further configured to: obtain the conflict time interval where the distance between aircraft is less than the safety interval; and generate a conflict time window based on the conflict time interval.

[0247] In one embodiment, the conflict resolution solution generation module is further configured to: select similar conflict scenarios from the historical trajectory database based on the current conflict scenario corresponding to the risk warning information; generate a regulatory conflict resolution solution based on the similar conflict scenarios; and output the expected effect of the regulatory conflict resolution solution.

[0248] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0249] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0250] This application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0251] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0252] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to execute the steps described in the various method embodiments above.

[0253] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above-described embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0254] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0255] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0256] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0257] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0258] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0259] One embodiment of this application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above-described methods.

[0260] The computer device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the above description is an example of a computer device and does not constitute a limitation on the computer device. It may include more or fewer components than described above, or a combination of certain components, or different components, such as input / output devices, network access devices, etc.

[0261] The processor referred to can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0262] In some embodiments, the memory may be an internal storage unit of the computer device, such as a hard drive or RAM. In other embodiments, the memory may be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory may include both internal and external storage units of the computer device. The memory is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory can also be used to temporarily store data that has been output or will be output.

[0263] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0264] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for assisting in resolving airport control conflicts, characterized in that, The method includes: Acquire multi-source heterogeneous air traffic control signals, and preprocess and weighted fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system; Acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model and perform scenario-based adaptation and parameter optimization to generate an airport scenario-specific AEM sub-model. Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate risk warning information. Based on the risk warning information, a regulatory conflict resolution plan is generated, and the expected effect of the regulatory conflict resolution plan is output.

2. The airport control conflict resolution auxiliary method according to claim 1, characterized in that, Acquire multi-source heterogeneous air traffic control signals, and preprocess and weightedly fuse these signals to generate aircraft dynamic data in a unified coordinate system, including: Acquire multi-source heterogeneous air traffic control signals; The multi-source heterogeneous air traffic control signal is subjected to denoising, deduplication, outlier removal and time synchronization calibration, and a preprocessed heterogeneous air traffic control signal is generated. The preprocessed heterogeneous air traffic control signals are weighted and fused to generate aircraft dynamic data in a unified coordinate system.

3. The airport control conflict resolution auxiliary method according to claim 2, characterized in that, The preprocessed heterogeneous air traffic control signals are weighted and fused to generate aircraft dynamic data in a unified coordinate system, including: Weights are assigned based on the preprocessed heterogeneous air tube signals; The preprocessed heterogeneous air traffic control signals are weighted and fused according to the set weights to generate aircraft dynamic data in a unified coordinate system.

4. The airport control conflict resolution auxiliary method according to claim 1, characterized in that, Acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model, and perform scenario-specific adaptation and parameter optimization to generate an airport-specific AEM sub-model, including: Acquire initial data of successful escape trajectory, preprocess the initial data of successful escape trajectory, and generate historical conflict successful escape trajectory data; The historical conflict resolution trajectory data is input into the AEM model and adapted to the scenario and optimized for parameters to generate an AEM sub-model specific to the airport scenario.

5. The airport control conflict resolution auxiliary method according to claim 1, characterized in that, Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model, generating risk warning information, including: Based on the aircraft dynamic data, real-time conflict analysis and prediction are performed according to the airport scenario-specific AEM sub-model to generate encounter probability, conflict point location and conflict time window. A basic risk warning is generated based on the encounter probability and the conflict time window; Based on the location of the conflict point, the basic risk warning is modified to correct the risk scenario, and risk warning information is generated.

6. The airport control conflict resolution auxiliary method according to claim 5, characterized in that, Generate the encounter probability, including: Acquire the aircraft's dynamic data and construct a relative motion model based on the airport scenario-specific AEM sub-model; The encounter probability is generated based on the relative motion model.

7. The airport control conflict resolution auxiliary method according to claim 6, characterized in that, Generate conflict point locations, including: The minimum value is obtained by taking the derivative of the relative motion model, and the time corresponding to the minimum value is recorded as the conflict time. Substituting the moment of conflict into the aircraft's trajectory equation, the coordinates of the conflict point are obtained.

8. The airport control conflict resolution auxiliary method according to claim 7, characterized in that, Generate conflict time windows, including: Obtain the time interval of conflict when the distance between aircraft is less than the safe interval; A conflict time window is generated based on the conflict time interval.

9. The airport control conflict resolution auxiliary method according to claim 8, characterized in that, Based on the risk warning information, a regulatory conflict resolution plan is generated, and the expected effects of the regulatory conflict resolution plan are output, including: Based on the current conflict scenario corresponding to the risk warning information, similar conflict scenarios are selected from the historical trajectory database; Based on the similar conflict scenarios, generate a regulatory conflict resolution solution and output the expected effect of the regulatory conflict resolution solution.

10. An airport control conflict resolution assistance system, characterized in that, The system includes: The multi-source heterogeneous data processing module is used to acquire multi-source heterogeneous air traffic control signals, and to preprocess and weightedly fuse the multi-source heterogeneous air traffic control signals to generate aircraft dynamic data in a unified coordinate system. An airport-specific model generation module is used to acquire historical conflict resolution trajectory data, input the historical conflict resolution trajectory data into the AEM model, and perform scenario-based adaptation and parameter optimization to generate an airport-specific AEM sub-model. The risk warning information generation module is used to perform real-time conflict analysis and prediction based on the aircraft dynamic data and the airport scenario-specific AEM sub-model to generate risk warning information. The conflict resolution solution generation module is used to generate a regulatory conflict resolution solution based on the risk warning information and output the expected effect of the regulatory conflict resolution solution.

Images