ASPaeroFlow: Decomposition Heuristics for Joint Air Traffic Flow & Capacity Management

arXiv:2608.09315 · cs.AI · Submitted 2026-08-10 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Paper Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "ASPaeroFlow: Decomposition Heuristics for Joint Air Traffic Flow & Capacity Management".

Jane: The paper was written by Alexander Beiser, Markus Hecher, Nysret Musliu, Georg Trausmuth and Stefan Woltran from TU Wien and University of Potsdam and CNRS, Artois University (CRIL) and Frequentis AG.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Paper summary: Tom: Welcome back to the channel, everyone. Today we're looking at ASPaeroFlow: Decomposition Heuristics for Joint Air Traffic Flow and Capacity Management, from a team spanning TU Wien, Potsdam, the CNRS in France, and Frequentis, an air traffic technology company.

Jane: And this paper tackles a deceptively simple problem. Airspace is divided into sectors, each with a capacity ceiling set by what controllers can handle, and flights create demand. When demand exceeds capacity, you have an overload, and somebody has to resolve it.

Lu: The twist is that the fixes come in two families that have been treated separately. You can touch the flows — delay a flight, reroute it. Or you can touch the structure — split a busy sector into smaller ones. The paper argues that doing one while assuming the other is fixed creates a circular dependency.

Meng: Their solution is a joint model where both families are available, plus a heuristic called ASPaeroFlow that keeps the computation tractable. It decomposes the global problem around overloaded sectors, solves each local piece exactly with Answer Set Programming, and iterates until every overload is cleared.

Tom: The headline results are pretty remarkable. The ablation study shows that restructuring airspace reduces overloads by roughly a factor of three, while delaying and rerouting have smaller, more localized effects.

Jane: That runs against the operational habit of leaning heavily on delays, which is what the current deployed tools mostly do. And they also show simultaneous optimization beating sequential pipelines whenever restructuring alone doesn't finish the job.

Lalam: From where I sit, the bigger picture is that exact optimization models for this problem die on medium-sized instances. This work offers a viable middle ground — local exactness inside a global heuristic — and it's validated on industry-sized data with tens of thousands of flights.

Lu: There are twelve algorithmic variants benchmarked across three instance families, plus a statistical significance analysis. The paper is careful about where each variant wins and where it doesn't.

Meng: The small synthetic instances are still dominated by an exact ASP approach, and honestly that's a good sanity check for the heuristic's quality.

Tom: Let's go back to page one then, where the paper frames the operational problem and lays out the contribution. There's a schematic there that ties the whole idea together.

Page 1: Tom: So with the thesis on the table, page one gives us the abstract plus the opening of the introduction, and right away you get the operational definitions. Demand is the number of flights intending to traverse a sector, and capacity is the maximum number the sector can safely handle.

Jane: And that ceiling is set by human factors. Controllers have to keep separation between aircraft, so an overloaded sector genuinely threatens safety. That's why the paper insists demand must remain below capacity at all times — it's not a soft preference, it's the hard constraint.

Lu: What I like is the direct attack on the current operational algorithm, CASA. It allocates slots first-come, first-served, and earlier studies show that scheme delivers unsatisfactory results compared to proper optimization models. So there's a real gap between what's deployed and what's possible.

Meng: The contribution list has three items. The heuristic itself, which iteratively handles overloaded sectors through instance-space decomposition and local exact solving. A data generator that produces realistic industry-sized instances on real-world navpoint graphs. And a benchmark suite with an ablation study across small, literature, and large instances.

Lalam: There's a sentence in there that jumps out at me — joint modeling makes algorithms for isolated subproblems comparable against a joint benchmark. Right now the DAC literature and the ATFM literature each have their own benchmarks, and you can't compare the benefits of the two action families. This is a step toward a common yardstick.

Jane: Figure 1 is the visual anchor of the whole paper. It shows the operational setting on the left — weather, human factors, filed flight plans — then the joint ATFCM abstraction in the middle, and then the ASPaeroFlow loop on the right, repeatedly decomposing around overloaded sectors.

Tom: That loop is the essence. As long as overload is positive, you decompose, you solve locally, you accept improvements, and you update the instance.

Lu: And they're explicit that this only partially addresses the gap — exact joint models remain intractable for medium and large instances. The heuristic is a bridge, not a replacement.

Meng: One more detail from the author list — Frequentis is a real industry partner, so the research questions are grounded in actual operational practice rather than purely academic scenarios.

Tom: The next page walks through the related work, and it's a revealing split between the airspace configuration community and the flow optimization community. Let's see how they characterize those two research lines.

Page 3: Tom: Page three is the literature tour, and the split the paper describes is dramatic. Dynamic Airspace Configuration spans genetic algorithms, Voronoi diagrams, graph methods, machine learning, even integer programming. Flow optimization has its own long tradition with fairness models and lexicographic objectives.

Jane: Complexity results are where it gets serious. They cite the classic result that restricting yourself to delaying aircraft is already NP-hard. So even the most conservative version of the problem — no rerouting, no restructuring — is computationally brutal.

Lu: And then there's the operational baseline again, CASA, working on first-planned-first-served principles. The paper positions it as a heuristic that simply delays aircraft, which is why it underperforms models that can also reroute and reshape the airspace.

Meng: What stood out to me is the observation that most existing methods integrate DAC as a fixed input to ATFM. You optimize flows within a frozen sector layout. The joint model they build on relaxes that, but exact methods struggle on small instances, leaving the joint agenda stuck.

Lalam: Then we get to the choice of technology. Answer Set Programming is a logic-based paradigm — you write rules, and the solver finds stable models. The paper highlights natural modeling, rapid prototyping, and future Explainable eye integration, since in a safety-critical setting being able to justify a decision with rules is a real asset.

Lu: But they're upfront about ASP's weakness — the grounding bottleneck. The solver instantiates all variables before solving, and that can explode. Their answer is to embed ASP inside a decomposition heuristic, which directly attacks that bottleneck.

Tom: The preliminaries section then sets up the formal vocabulary. A navpoint graph with Euclidean or geodesic distances, trajectories as simple paths with increasing timestamps, and the ASP constructs they rely on — choice rules for search spaces, aggregates for counting, soft constraints for optimization.

Jane: There's a small code snippet that shows the flavor. You count flights in a sector, compare against capacity, and flag overload. Then a weak constraint minimizes that overload with a priority level. It's remarkably compact.

Meng: Compact and readable — that readability argument comes up again and again, and it matters when the tool has to be audited by people who aren't logic programmers.

Tom: We now have the toolbox. The next pages define the joint ATFCM model precisely — how sectors get configured, how aircraft are modeled, and how demand is measured. That's where the mathematics gets concrete.

Page 5: Tom: The model becomes concrete on this page, and the first thing that stands out is the aircraft-level detail. A flight is a trajectory on the navpoint graph, but an aircraft is something richer — it has a velocity and a set of flights, because one physical plane can fly several legs in a day.

Jane: That means a delay on an early leg can propagate to later legs. The aircraft model makes that coupling visible, which is a significant step beyond treating each flight as an independent entity.

Lu: The solution definition has a clever property — the time horizon may be expanded beyond the original one, and the paper notes an instance is always solvable. So the model has a built-in guarantee that some solution exists, even if it requires stretching time.

Meng: The hard constraint is straightforward. For every timestep and every sector, demand must not exceed capacity. And the demand calculation has a specific convention — a flight traversing an edge spends half its time in the departure sector and half in the arrival sector.

Lalam: That half-time convention is worth pausing on. Demand becomes a smoothed occupancy measure rather than a snapshot of positions, which reflects how controllers actually see aircraft moving through a sector over a duration.

Tom: The running example on this page illustrates the three action families beautifully. There's an overload at sector S1 at time eleven, and the options are delay the flight, reroute it through a different branch of the graph, or split the overloaded sector into two smaller ones.

Jane: The restructuring option actually increases capacity — splitting S1 into S1A and S1B raises the combined capacity from five to six. That's the DAC mechanism operating alongside the flow measures.

Lu: Formally, an ATFCM instance bundles the graph, the time granularity, the initial sector configuration, the capacities, and the aircraft set. A solution gives you new timesteps, a new sector configuration, and adjusted trajectories, with the requirement that airport sectors stay atomic and en-route sectors stay connected.

Meng: The connectivity requirement is an operational realism touch. You can't just draw arbitrary geometric shapes — sectors have to remain coherent for the controllers working them.

Tom: And the optimization objective comes into view right after this — five lexicographic levels starting with arrival delay and ending with reconfigurations. The structure of that objective is what makes exact solving so painful, and it drives the whole decomposition strategy.

Page 7: Tom: Now we reach the heart of the contribution — the decomposition heuristic itself. The authors argue that exact methods suffer from combinatorial explosion, made worse by that five-level lexicographic objective that requires sequential bounding. Their alternative is Algorithm 4 point 1, the ASPaeroFlow loop.

Jane: The loop reads like classic local search. Compute the total overload, which they define as the sum of exceedances across all sectors and timesteps. If it's zero, terminate. Otherwise decompose the instance around the first overloaded sector, earliest in time, and solve that local piece exactly with ASP.

Lu: The acceptance rule is what keeps the search meaningful. A candidate solution is only accepted if it strictly reduces the overload sum. If it doesn't improve, the parameters get adjusted to broaden the search, so every accepted step makes progress on the primary objective.

Meng: Table 1 gives the bounds, and they are surprisingly small. Two flights per local subproblem. A delay window of five timesteps. Three alternative routes per flight. Two sector split options for the overloaded sector.

Tom: Two flights feels almost minimalist, but there's logic behind it. The local subproblem should contain the flights that actually contribute to the overload — the dominant contributors — while keeping the grounding stable for the ASP solver.

Jane: And the empirical tuning story is interesting. Raising the flight limit or the partition limit drastically increases solving time, while the routing and delay bounds are more forgiving. They tuned the parameters where the computational pain actually lives.

Lalam: The philosophical point here is local exactness. Each subproblem is solved exactly under the lexicographic objective, and the decomposition decides which slice of the global problem the solver sees. That's what makes the approach scalable without abandoning optimization quality locally.

Lu: The parameter adjustment mechanism is the termination safeguard. After ten non-improvement steps, the flight limit drops to one, and the delay window rolls forward. If even a single flight can't be improved, the algorithm stops and reports a residual overload.

Meng: So the tool is honest — it will tell you when it couldn't fully resolve the overloads, rather than pretending every instance is solvable within its action bounds.

Tom: Next comes the correctness analysis, which is the right thing to ask after seeing an algorithm like this. They prove termination and validity under an operational feasibility assumption — let's look at that.

Page 9: Tom: Page nine is the correctness section, and it's a model of how to argue about a heuristic honestly. The foundation is the operational feasibility assumption — every sector has atomic capacity at least one, so any single flight can in principle be flown alone.

Jane: Under that assumption, Theorem 14 states that if the algorithm produces output, that output is a valid solution. The proof is a contradiction argument — suppose the algorithm terminated early with residual overload after reducing to a single flight. Then you could always shift that flight's start time past the arrival of every other flight, which would clear the overload.

Lu: That's the crux. Delaying the sole remaining flight past the others means the sector sees only that one aircraft, and capacity one suffices. The local optimization would find that improvement, so terminating without it would contradict the optimality of the local search.

Meng: Theorem 16 covers termination. Each iteration either strictly reduces overload, which resets the parameter bounds, or expands them. The flight limit eventually becomes one, and then the exhausted condition becomes reachable, so the loop cannot cycle forever.

Lalam: What I appreciate is Observation 15, which is the flip side. Without the operational feasibility assumption, the heuristic can return an incorrect solution — because the bounded reroute options and bounded partition options may simply miss the feasible fix. The authors state that limitation explicitly.

Tom: That kind of caveat matters in a safety-critical application. The guarantee is conditional, and the condition is spelled out — no zero-capacity sectors.

Jane: The validity argument also covers the individual solution components. The generated trajectories are valid, exactly one trajectory gets selected per flight, subsequent flights can't overlap, and the sector partitions stay connected.

Lu: They also argue that the local ASP encoding correctly tracks overloads and side objectives, using precomputed information from the decomposition for things the local view can't see.

Meng: So we have a strong local guarantee and an explicit global limitation. That's a fair trade to present to an operator who needs to know when to trust the tool.

Tom: With the theory settled, the paper moves to the experimental design — twelve benchmark variants, three instance families, and a careful setup. Let's look at that on the next page.

Page 11: Tom: This page launches the experimental campaign, and it's elaborate. Twelve variants are benchmarked, spanning the initial do-nothing baseline, two exact approaches, a family of ASPaeroFlow configurations, and the operational CASA baseline.

Jane: The exact approaches are ASP-P, the bounded action exact model from the earlier joint ATFCM work, and a MIP model that maps state-of-the-art ATFM formulations into the joint framework. The tell is in the table notes — the MIP selects optimal bounded reroutings and delays, but it has no sectorization action at all.

Lu: The notation is systematic once you decode it. Subscripts r and d indicate rerouting and delaying. A superscript p means possible repeated delaying when stuck. So ASPaeroFlowr,dp combines rerouting with repeated delaying and no DAC, while the plain r,d variant balances all three action families.

Meng: There's also an ATFM-only family — flow measures without restructuring — and a sequential variant that runs sectorization first and flow optimization second, which mirrors standard collaborative decision-making in operations.

Tom: The search space comparison in Table 2 is the clearest justification of the whole approach. The global search space scales with the number of flights in the exponent, while the local search space per iteration is constant — two flights, one sector, tiny bounds.

Jane: You trade completeness for tractability, and that trade is precisely quantified.

Lalam: The instance families on the next page are what make the claims credible. Small grids from the joint model paper, literature benchmarks from Agustín and colleagues, and then the large scenarios — real navpoint graphs, up to thirty-one thousand flights, with capacity scaled from full down to ten percent.

Lu: The large set uses real topographies — central Europe, the DACH region, the wider European network, and the US — built by merging open data sources. The generator is a contribution in itself, since open data in this domain is scarce.

Meng: There's a practical setup detail too. The whole campaign ran on a CPU cluster with an eighteen hundred second timeout and a thirty-five gigabyte memory limit, and those limits shape what counts as solvable.

Tom: And the results on the following page show where each variant lands — which configurations win, how the exact approaches behave on small instances, and where the scalability gap really opens up.

Page 13: Tom: Here are the numbers, and they're layered. On the overall tournament across nearly nineteen hundred instances, the ASPaeroFlow variants take the majority of wins, and CASA barely registers.

Jane: But the small instances tell a different story — exact methods shine there. ASP-P wins 83 of the 200 small instances, while the best heuristic variant wins 51 and CASA wins just 4. So on small problems, exactness still matters, and the heuristic is competitive rather than dominant.

Lu: The paper digs into why ASP-P beats MIP on the slightly larger small instances. ASP-P uses an average of 188 sector changes, while MIP uses zero — it structurally cannot restructure airspace. On the tiny EA-3x3 graph there's no room for DAC, and MIP does better. On EUR-10x10, with ten sectors to play with, ASP-P takes the lead.

Meng: That contrast is a clean demonstration of the joint hypothesis. When restructuring is available and useful, a model that can use it beats one that can't, even with the added complexity.

Lalam: The scaling results on real topographies are the headline for me. Exact methods run into timeouts or memory limits, while the ASPaeroFlow variants solve instances down to twenty percent of nominal capacity. The flow-only methods stall at forty percent — that gap doubles exactly where operations get hardest.

Tom: And there's a timing detail that matters operationally. The CASA and ATFM-only variants are slower on the large graphs, while the ASPaeroFlow variants hold roughly constant execution time, because the decomposition keeps the per-iteration cost flat.

Jane: The statistical layer is rigorous too. A Friedman test across the twelve variants shows significant differences, then pairwise Wilcoxon tests with Holm-Bonferroni correction, and every pair comes out significant. The rank hierarchy puts the r,dp variant first, the sequential variant second, and the r,d variant third.

Lu: One subtlety I noticed — on the literature instances, the ATFM-only methods do well, because those generated instances have little or no possibility for DAC. The industrial instance in that set is different, with plenty of reconfiguration options, and the joint methods pull ahead there.

Meng: There's even a quirk about negative delays on those instances — the filed path isn't necessarily the optimal one, so the model can find a better route that arrives earlier than planned.

Tom: That all sets up the deepest question in the paper — sequential versus simultaneous optimization, and which action family actually drives the reductions. Let's close with those analyses.

Page 15: Tom: This last substantive page settles two debates. First, sequential versus simultaneous optimization. On the surface, the full dataset shows no statistically significant difference between the two — the sequential variant actually wins more tournament instances overall.

Jane: But the paper splits the data, and that changes the picture completely. Restricting to the 1318 instances where sequential optimization fails to solve via DAC alone, the simultaneous r,d variant wins 864 times against 441, with 13 draws — and that difference is significant at the 0 point 001 level.

Lu: So the exact statement is nuanced. When restructuring alone resolves everything, sequential is perfect — it achieves zero arrival delay because it never touches the flows. But when DAC alone fails, sequential defaults to a flow-only fallback that performs worse than the joint approach.

Meng: The ablation study in Table 5 identifies the driver. Restructuring reduces overload from roughly fourteen thousand nine hundred down to fifty-two hundred — about a factor of three. Delaying brings it down to around ninety-nine hundred, and rerouting is inconclusive within the error bars.

Lalam: The explanation is structural, and I think it's the deepest insight in the paper. A sector split at one time point persists — it changes capacity for later timesteps and clears future overloads. A delay or reroute is localized in time, and through the aircraft model it risks propagating a conflict to a later leg of the same aircraft.

Jane: That propagation risk is exactly what the aircraft model predicted. Fix an overload on leg one by delaying, and leg two now departs late. The local heuristic may have solved one problem while seeding another.

Tom: The conclusion then frames the contributions — a computationally viable heuristic for joint ATFCM that scales exact ASP to industry-sized instances, plus the finding that DAC is the primary overload-reduction driver, and the conditional advantage of simultaneous optimization.

Lu: And they name two future directions — stochastic disruptions like weather, where the deterministic model is limited, and Explainable eye integration so automated decisions come with rule-based justifications.

Meng: That Xeye direction fits the ASP choice perfectly. The model is already a set of rules, so extracting explanations is a natural next step rather than a retrofit.

Tom: Let's wrap up the whole discussion now and think about what this means for the field.

Conclusion: Tom: So, pulling it all together — ASPaeroFlow is a decomposition heuristic for the joint traffic management problem. It takes the exact power of Answer Set Programming and wraps it in a loop that attacks overloaded sectors one at a time.

Jane: The main findings form a clear hierarchy. Restructuring airspace is the biggest lever, by a wide margin. Delaying helps but stays localized. Rerouting alone is the hardest to pin down. And simultaneous optimization earns its keep whenever restructuring alone doesn't finish the job.

Lu: The paper's positioning is careful — it doesn't claim to replace exact methods. On small instances, exact ASP still wins. It claims a computational middle ground, and the data supports that claim across nearly nineteen hundred instances.

Meng: The practical impact is real because of the deployment context. The operational baseline CASA performs poorly, and having an industry partner on the author list gives the work a direct path toward operational consideration.

Lalam: For the wider research community, the contribution is twofold. A scalable recipe for joint ATFCM that others can build on, and an honest evaluation methodology — twelve variants, three instance families, statistical significance testing, open data and code. That sets a high bar for future work in this area.

Tom: There are clear limitations too, and the paper states them plainly — no global optimality guarantee, potential violations of unmodeled operational constraints, weather and tactical interventions left out, and a heuristic that can miss solutions when capacities hit zero.

Jane: The future directions are inviting. Stochastic disruptions would make the model robust to the weather uncertainty they set aside, and Explainable eye integration could turn the ASP rule set into actual explanations for controllers and flow managers.

Lu: I'd love to see the data generator get formal statistical validation against historical flight distributions — they mention that as planned work, and it would strengthen an already impressive instance portfolio.

Tom: It's a strong paper to close on. The core message for anyone listening — the bottleneck in joint ATFCM is computational, and clever decomposition can push exact methods much further than people assumed.

Jane: And the finding that sector restructuring beats flow measures should give operators pause before they default to delays.

Tom: That's all from us on this one. Thanks to the authors for sharing the code and data, and to our listeners for tuning in. We'll be back with the next paper soon.

Alexander Beiser, Markus Hecher, Nysret Musliu, Georg Trausmuth, Stefan Woltran

TU Wien · University of Potsdam · CNRS, Artois University (CRIL) · Frequentis AG

cs.AI

Submitted: 2026-08-10

Updated: 2026-08-11

Comments: To cite this contribution, please cite the ATMOS 2026 paper not the arXiv version; the arXiv version includes the supplementary material. Experimental results are available at: https://doi.org/10.5281/zenodo.21869481

DOI: 10.4230/OASIcs.ATMOS.2026.13

Code: https://github.com/alexl4123/ASPaeroFlow-Optimizer

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 75/100

The gist: ASPaeroFlow: Decomposition Heuristics for Joint Air Traffic Flow & Capacity Management Abstract While mathematical models act as vital decision support systems for operational Air Traffic Flow and

Key concepts

Air Traffic Flow & Capacity Management (ATFCM): ATFCM is the process of balancing air traffic demand with sector capacity. Demand is the number of flights in a sector, and capacity is the maximum safe number. When demand exceeds capacity, an overload occurs, and actions like delaying flights, rerouting, or splitting sectors are used to resolve it.
Answer Set Programming (ASP): ASP is a logic-based programming paradigm where problems are described with rules, and a solver finds stable models (solutions). It allows compact, readable encodings and supports optimization via weak constraints, but can suffer from a grounding bottleneck on large instances.
Decomposition heuristic: A heuristic that breaks a large, complex problem into smaller, more manageable subproblems. In ASPaeroFlow, the global ATFCM problem is decomposed around overloaded sectors, each subproblem is solved exactly with ASP, and the algorithm iterates until all overloads are cleared or it stops with a residual overload.
Lexicographic objective: An optimization objective with multiple levels of priority, where higher-priority criteria are optimized first, and lower-priority criteria are only considered when higher ones are tied. In this paper, the objective has five levels, starting with arrival delay and ending with reconfigurations, making exact solving challenging.

Terminology

Answer Set Programming — 16× in this paper
Benchmark — 16× in this paper · explained in 2 episodes
Ablation — 14× in this paper · explained in 1 episode
Local Optimization — 14× in this paper · explained in 2 episodes
Ablation study — 12× in this paper · explained in 1 episode
Air Traffic Flow Management — 11× in this paper
Dynamic Airspace Configuration — 8× in this paper
Air Traffic Flow and Capacity Management — 6× in this paper
Grounding — 6× in this paper · explained in 3 episodes
Answer Set Programming (ASP) — 5× in this paper · explained in 1 episode
Explainable AI (XAI) — 4× in this paper · explained in 7 episodes
Objective Function — 3× in this paper · explained in 2 episodes
Abstraction — 2× in this paper · explained in 1 episode
Clustering — 2× in this paper · explained in 2 episodes
Interpretability — 2× in this paper · explained in 15 episodes
Central Europe — 1× in this paper
Computer-Assisted Slot Allocation — 1× in this paper
Fidelity — 1× in this paper · explained in 2 episodes

Summary

ASPaeroFlow: Decomposition Heuristics for Joint Air Traffic Flow & Capacity Management

Abstract

While mathematical models act as vital decision support systems for operational Air Traffic Flow and Capacity Management (ATFCM), existing approaches isolate Air Traffic Flow Management (ATFM) from Dynamic Airspace Configuration (DAC). This separation introduces an unresolved circular dependency between fixed-demand and fixed-capacity assumptions. Although joint optimization resolves this gap, the enlarged search space renders exact models computationally intractable for medium- to large-scale instances. To bridge this gap, we propose ASPaeroFlow: a heuristic for the joint ATFCM; it combines instance-space decomposition heuristics with a local exact approach using Answer Set Programming. We benchmark ASPaeroFlow from small to industry-sized instances and compare it with exact and alternative approaches. The results indicate that (1) the heuristic provides a computational middle ground between exact methods and operational baselines; (2) simultaneous optimization can outperform sequential optimization on joint ATFCM; and (3) an ablation study indicates that DAC has a larger impact on solution quality than flow measures.

Introduction

Operational Air Traffic Flow and Capacity Management (ATFCM) aims to balance demand and capacity to ensure the safe and efficient flow of air traffic. Demand is the number of flights intending to traverse through a sector, while capacity is the maximum number of flights a sector can safely handle. Sector capacity is limited by human factors, as Air Traffic Controllers (ATCs) are responsible for ensuring separation between aircraft. Overloading a sector means that more flights are in the sector than can be handled by ATCs. To ensure safety, demand must remain below capacity at all times.

Automated decision support systems help operational ATFCM by optimizing on mathematical models, which suggest aircraft reroutings, delayings, or sector restructurings to optimize airspace usage. However, the operationally used algorithm Computer-Assisted Slot Allocation (CASA), which works according to a First-come, First-served scheme, has been shown to yield unsatisfactory results compared to more sophisticated optimization models. To circumvent this limit, state-of-the-art (SOTA) work proposes mathematical models for optimizing ATFCM. Still, SOTA approaches can be largely grouped into one of two classes: work focusing on the aircraft-level (so-called Air Traffic Flow Management (ATFM)) via delays and reroutes and work focusing on the sector-level (so-called Dynamic Airspace Configuration (DAC)). Treating ATFM and DAC separately introduces unresolved circular dependencies and makes it hard to compare the actual benefits of ATFM/DAC. In contrast, Joint ATFCM methods would (1) resolve the circular dependency between fixed-capacity and fixed-demand assumptions, (2) render algorithms for isolated subproblems comparable against a joint benchmark, and (3) enable simultaneous optimization paradigms, which exploit the enlarged search space. However, while joint ATFCM models exist, their enlarged search space renders them computationally intractable for medium- and large-scale instances when solved exactly. Therefore, the primary research gap is the lack of scalable joint ATFCM methods for industry-sized instances.

Contributions

This paper partially addresses this gap by proposing ASPaeroFlow: a heuristic for joint ATFCM which optimizes ATFM and DAC simultaneously. In detail, the contributions are as follows:

ASPaeroFlow: We propose heuristics that derive 0-overload solutions from initial flight schedules and sector configurations. The approach employs an iterative instance-space decomposition to partition global airspace overloads into localized, timestep-specific subproblems. These tractable instances are solved exactly via the Logic Programming technique Answer Set Programming (ASP), leveraging its expressive rule-based modeling and native integration of soft constraints for domain-specific optimization.
Data Generator: We generate realistic industry-sized (large) instances on real-world navpoint graphs for scaling analysis.
Benchmarks & Ablation: We evaluate ASPaeroFlow in small to large instances, and other instances from the literature. ASPaeroFlow bridges the scalability challenge of exact models while significantly outperforming operational baselines. Further, the experiments suggest that simultaneous optimization outperforms sequential approaches when DAC alone does not suffice, and an ablation study highlights DAC as the primary driver for overload reduction.

Related Work

Dynamic Airspace Configuration (DAC) constructs airspace from atomic blocks, distinguishing it from free-partitioning DAS. Automated sector design utilizes genetic algorithms, Voronoi diagrams, graph methods, machine learning, and MIP. Heuristics for sector design exist: sectors should be connected; flights should stay in a sector for a minimum amount of time and not re-enter. Joint ATFCM constructs composite sectors (containing multiple atomic sectors) from atomic sectors (which represent exactly one navpoint vertex). ASPaeroFlow ensures connected sectors. Flow Optimization (ATFM) aims at routing network flow (aircraft) optimally, while adhering to side constraints. The operationally used Computer Assisted Slot Allocation (CASA) heuristics work according to the First Planned - First Served principle and delays aircraft. Optimization models addressing delay and rerouting explore fairness, lexicographic objectives, and computational aspects. It was shown that the restriction to delaying is already N P-hard. Crucially, most existing methods integrate DAC solely as a fixed input to ATFM; the recently proposed joint ATFCM model circumvents this, however, joint sequential or simultaneous optimization for industry-sized instances remains an open challenge, as exact methods struggle already on small instances. Answer Set Programming (ASP) is a symbolic-AI paradigm rooted in logic programming offering exact optimization with high interpretability, deployed for example in industrial scheduling. Regarding aviation, proposals for the usage of ASP for efficient drone scheduling or optimization for mission schedules on vertiports exist. We use ASP for several reasons, including its natural problem modeling, rapid prototyping, and future Explainable AI (XAI) integration potential. To circumvent ASP's primary scalability limitation — the grounding bottleneck — we embed it within a problem-decomposition heuristic.

Joint ATFCM Model

The Joint ATFCM model is presented with the following definitions:

Navpoint Graph: The navpoint graph G = (V, E) is an undirected graph, where each vertex is labeled with spatial geodesic coordinates. We distinguish between airports and en-route vertices, where with airport(G) and en-route(G) we denote the respective sets. Let d: V 2 → R be the distance function.
Time model: Tgran discretizes time into Tgran −timesteps per hour. We assume one-day instances; then the set of timesteps T is T:= t t ∈ N, 0 ≤ t ≤ Tgran · 24.
Sector Configuration: A sector i is a set of vertices sec(i, t) ⊆ V, identified by a representative sector vertex i ∈ V, where i ∈ sec(i, t) ensures the sector index directly corresponds to one of its contained vertices. ATC-teams have a fixed capacity and have a fixed location, implying atomic capacities of vertices ci for i ∈ V (t = 0): cap(i, 0) = ci. A composite sector has capacity cap(i, t) = maxj∈sec(i,t) cap(j, 0), simulating that the best ATC-team of a region takes command.
Flight Model: Flights f ∈ F are modeled as trajectories on the navpoint graph. Let f ∈ F be a flight and fid be its flight id: f = (idf, ((v0, t0), (v1, t1),..., (vn, tn))).
Aircraft Model: We map flights to aircraft (as a single physical aircraft can have multiple flights per day, meaning a delay in an early flight can propagate downstream): an aircraft a ∈ A is a three tuple (ida, va, Fa), where ida is the unique id, va is the velocity, and Fa is its set of flights.
ATFCM Instance: An ATFCM instance is I = (G, Tgran, T, sec, cap, A), where G is a navpoint graph, Tgran defines the time granularity, T the timesteps, sec the initial sector configuration, cap the atomic capacities, and A the aircraft. We denote with F the set of filed flights. All ids are unique.
ATFCM Solution: The ATFCM solution is given by: S = (T, SEC, A), where T are the solution timesteps, SEC is the solution DAC, and A are the solution aircraft. T might be expanded beyond the initial T (an instance is always solvable). The flown flights f ∈ F = (ida,va,Fa)∈A Fa may be delayed. If a flight is delayed and/or rerouted, this is indicated by rf = 1. Sectors in SEC are allowed to be changed. We require that airport sectors remain atomic and en-route sectors remain connected to partially accommodate operational requirements.
Optimization Problem: A solution S is optimized according to efficiency (Arrival Delay, Active en-route sectors, and Navpoint-sector changes) and stability/fairness (Reroutes/delays and Reconfigurations) soft constraints. An accepted solution S is strictly preferred to S′ (S ≺ S′) if its objective tuple is lexicographically smaller: (Kd, K#s, Kds, Kr, Kc)S ≺lex (...)S′. The individual criteria to be minimized are defined as follows: Kd is Arrival Delay, K#s is Active Sectors, Kds is Navpoint-sector changes, Kr is Reroutes/delays, and Kc is Reconfigurations.

New Decomposition Heuristics

Although some large-scale ATFM models can be solved exactly by exploiting inherent structures, we expect that integrating DAC introduces dense coupling constraints. These constraints likely create structural difficulties that prevent scaling exact solution approaches to medium- and large-scale instances. Moreover, the required sequential bounding for the five-level lexicographic objective severely degrades solver performance. Consequently, exact methods suffer from combinatorial explosion, rendering multi-objective exact solving computationally intractable even for relatively small instances. To ensure operational feasibility, we propose a heuristic approach: ASPaeroFlow. ASPaeroFlow decomposes the problem around the next overloaded sector, building a bounded local subproblem containing only the most relevant flights and the overloaded sector. Specifically, we cap (i) the number of considered flights (fmax), (ii) the delay window per flight (dmax), (iii) the number of alternative routes per flight (rmax), and (iv) the number of partition options for the overloaded sector (pmax). An exact solver then selects the best local solution under our lexicographic objective, and the procedure iterates until all overloads are resolved. The chosen local bounds balance search-space exploration with solver runtimes. Empirically, increasing the flight limit (fmax > 2) or the partitioning limit (pmax > 2) drastically increases solving times. Conversely, the routing (rmax) and delay (dmax) bounds are computationally more forgiving; the chosen parameters were determined via empirical parameter tuning to ensure rapid local convergence while maintaining high solution quality.

Optimization Loop

The overall algorithm is shown in Algorithm 4.1. In Lines (1)–(2) we do pre-processing steps, by converting the instance to the internal matrix representation M and computing the overloads. We consider as overloads the sum of exceedances: Ko = t∈T,i∈V max 0, q(i, t) − cap(i, t). The algorithm iteratively solves overloads until Ko = 0 (Line (3)). The decomposed instance I is computed by instance space decomposition (Line (4) — Algorithm 4.2), which is then given with the encoding E to the local optimization procedure (Line (5)). The local optimization procedure computes a new candidate solution M′. A correct local optimization encoding selects among its available choices the solution that reduces the magnitude of overload the most, followed by adhering to the criteria in Definition 13. The candidate solution M′ is accepted if it has less overloads (Lines (6)–(8)). Otherwise, the parameters of the decomposition are adapted to allow for other solutions to be explored to ensure termination (Line (12)).

Instance Space Decomposition

Algorithm 4.2 shows our instance decomposition approach. We reduce the search space, by limiting the number of investigated flights fmax, the delay dmax, the alternative routes rmax, and the possible DAC partitions pmax (Line (1)). Line (2) obtains the time t and sector s of the first overloaded sector (lexicographically time and sector-wise). In Line (3) we limit the search space to fmax flights. The next part in Lines (4)–(12) is to generate the instance for each of the fmax flights, by computing the alternatives rmax and considering the maximum delay dmax. This is followed by the generation of the instance for DAC, where we consider pmax partitions (Lines (13)–(16)), ranging from the current configuration p = 1 to a partition of the sector s into pmax parts. Finally, we combine the instance in Line (17) and return it.

Reroute Generation: We compute the rmax routes (Algorithm 4.2 in Line 7), using an iterative algorithm that computes the shortest routes on G between departure and destination airports. On each iteration the current shortest path p is penalized and a diverse set of routes is ensured by only accepting a path p if its Jaccard similarity to any other already considered path p′ is small enough: pp′ ∩p ∪p < jm, where jm = 0.6. Let w(p) be the path weight, then each edge e of e ∈ p is penalized by wt+1 (e) ← wt (e) + 0.1 w(p) p, where w0 (e) = d(e).

Alternative Airspace Configurations: The pmax graph partitions are computed in Algorithm 4.2 in Line (15) by an iterative breadth-first search algorithm. We partition a sector s into p sectors (s1,..., sp = S) of approximate size sec(s,t) p iteratively. Assuming we generated S = i − 1 sectors so far, we add a new sector si via two steps: first, we select a seed ∈ sec(s, t) ∪sj ∈S sec(sj, t) vertex and add it to the new sector si = seed. Second, we add vertices v ∈ sec(s, t) ∪sj ∈S sec(sj, t) to si in a breadth-first manner (ensuring connection of si) until sec(si, t) > sec(s,t) p; then we add si to S.

Adjust Parameters: If search stalls, adjustParameters expands the temporal horizon using a rolling delay (+5 timesteps). After 10 non-improvement steps, the flight limit reduces to fmax = 1. Assuming any flight can be routed in isolation, the algorithm terminates and returns M (Line 10) if fmax = 1, the subsequent step yields no improvement, and the single flight f remains unroutable due to absolute capacity limits (e.g., zero-capacity sectors).

Correctness

A brief argument for correctness of the algorithm is provided. Let I be an instance of the optimization problem and let S be the set of solutions. For the following proofs, we take the operational assumption that all filed flights can be flown in principle; meaning that ∀v ∈ V: cap(v, 0) ≥ 1. We refer to this as operational feasibility. Operational feasibility guarantees that a single flight from an overloaded sector can always be delayed to reduce the magnitude of overload—consequently, if delaying the single flight does not lead to a reduction in overload magnitude, the algorithm can safely terminate.

Theorem 14: Let I be an instance of the optimization problem and let the operational feasibility assumption hold. Then, for any correct encoding E, if ASPaeroFlow (Algorithm 4.1) produces an output, its output is a valid solution.

Observation 15: Let I be an instance of the optimization problem. For any correct encoding E without assuming operational feasibility, Algorithm 4.1 may return an incorrect solution.

Theorem 16: Let I be an instance of the optimization problem. Then, for any correct encoding E, ASPaeroFlow (Algorithm 4.1) terminates.

Local Optimization via ASP

An encoding in ASP is described. Conceptually, ASP is similar to Boolean satisfiability, but allows for more natural problem modeling, rapid integration of changed problem definitions, and directly provides minimization statements. The detailed generation of facts, trajectory guesses, and structural mappings are deferred to the appendix. The optimization objectives are treated as follows: the minimization of the magnitude of overload is the primary objective – as the ASP model operates locally and cannot solve global overloads. Besides that, we minimize lexicographically according to the ATFCMOP T problem. Lines (1) and (2) describe minimization of overloads, while Line (3) describes minimization of arrival delay. By construction, Line (4) minimizes both the number of sectors and navpoint-sector changes. Finally, Line (5) minimizes reroutes/delays and Line (6) minimizes divergences from sec.

Lemma 17: The ASP encoding is a correct local optimization encoding.

Benchmarks and Experiments

To demonstrate the operational feasibility of our approach, we design our computational experiments to evaluate three primary dimensions: (i) the solution quality of our decomposition heuristic relative to exact models, (ii) the scalability of the approach compared to related heuristic approaches across progressively larger, real-world-sized scenarios, and (iii) the effects of integrating DAC into ATFM via an ablation study. To quantify these dimensions, we extract the following evaluation metrics: computational performance (execution time and peak RAM usage) and model metrics (unresolved overloads, Kd, K#s, Kds, Kr, Kc).

Benchmarked Variants

We benchmarked 12 variants. One (Initial) is our baseline, if no action is performed. The exact solvers comprise ASP-P, which is ASPrp,dp,sp — a bounded action exact model which balances time to first and time to best solution — and MIP, a mapping of state-of-the-art ATFM MIP formulations to the joint ATFCM model (meaning it selects optimal bounded reroutings and delays, but has no sectorization actions). ASPaeroFlow comprises the remaining nine variants under various parameter configurations. Variants executing joint optimization of ATFM and DAC are denoted as ASPaeroFlow, while restricted variants optimizing only ATFM are denoted as ATFM. Subscripts r ∈ r, ¬r and d ∈ d, dp indicate whether rerouting or delaying is permitted. To simulate operational baselines, we include CASA, a greedy First-Come, First-Served simulation restricting optimization to single-flight delays (fmax = 1). Furthermore, the ASPaeroFlowseq sequential variant models standard collaborative decision-making by separating the pipeline: optimizing sectorization first, followed by a ATFCMr,d flow optimization.

Experiment Scenarios and Setup

We conducted benchmarks on three sets of instances: Small, SOTA, and Large.

The Small scenario: Regarding traffic density, we vary the number of flights F ∈ 10, 20,..., 100. For each F, we evaluate three distinct random seeds. En-route vertices possess a fixed capacity of 1, while airport capacities are assumed to be unconstrained. Time is partitioned into 1-hour timesteps (Tgran = 1).
SOTA Instances: The SOTA instances are standard benchmarks in the literature. Instances c01, c02, and c03 are randomized scenarios designed to test comprehensive ATFCM features. BLO instances are similarly randomized, where mBLO represents specific modifications (we do not possess mBLO2). The IC instance reflects an industry case, capturing a typical day of flight schedules and paths for a segment of the European ATM network. Following related literature, time is partitioned into 15-minute intervals (Tgran = 4).
Large instances: The large scenario considers larger graphs with more flights per day. The number of flights are F ∈ 1000, 1778, 3162, 5623, 10000, 17782, 31622 flights, where for each F we consider three seeds (11904657, 150699, 42), and capacity is relative to nominal capacity (optimal weather/staffing). We scale atomic sector capacities uniformly from 100% down to 10% in 10% decrements (P · 1.0 → P · 0.1). We set Tgran = 4 (as for SOTA).
Technical Setup: We implemented the heuristics in Python (3.13.7), and used Clingo (5.8.0) for ASP and Gurobi (13.0.0 build v13.0.0rc1) for MIP computation. All experiments were conducted on the Copperhead CPU Cluster at TU Wien, with 2x Intel Xeon Silver 4314 CPUs, 512GB RAM, and Ubuntu 22.04 (Kernel 5.15.0-131-generic). We considered a TIMEOUT of 1800s and a MEMOUT of 35GB.

Results and Discussion

Heuristic vs. Exact Approaches: We show the number of solved instances (#S) and tournament wins (#W) in Table 4. While for the small experiments, the ASP-P variant achieves strong results (#W: 83), the ASPaeroFlowr,dp variant achieves competitive results (#W: 51), while CASA wins only #W: 4. However, this is mostly due to the fact that even for small instances, the ASP-P approach runs into computational solving bottlenecks — even on the small instances, ASP-P is not able to solve all instances in the time limit. Comparing these methods on instances, which ASP-P solves to 0 overload, ASPaeroFlowr,dp achieves a lower arrival delay (an average value of 25.62 ± 2.25) compared to CASA (an average value of 64.83 ± 10.19). MIP achieves worse results compared to ASP for solved small instances on arrival delay (an average value of 5.28 ± 0.52), but is overall able to solve slightly more instances (#S: 263 vs. #S: 207). We emphasize that this should not be interpreted as ASP being in general a better solving technology than MIP; rather, the two approaches operate in fundamentally different feasible decision spaces. Specifically, we attribute the difference in results to ASP-P's ability to utilize DAC actions, where ASP-P uses on average Kds = 188.00 ± 8.60, compared to 0 for MIP. A similar behavior can also be seen when comparing the results of MIP and ASP-P for EA-3x3 and EUR-10x10. EA-3x3 is a tiny graph with effectively no possibility for DAC (V = 16 with max S = 3), whereas for EUR-10x10 the possiblities for DAC are plenty (V = 117 with max S = 10). As expected, MIP performs better on EA-3x3, whereas ASP-P performs better on EUR-10x10.

Scaling and Heuristic Approaches: In Figure 3 we show the scaling results comparing nominal capacity. The full scaling results comparing graph and flights size are available in the supplementary material. For the navpoint and flights scaling results, we compare 4 heuristic approaches on 10% nominal capacity (more in the supplementary material), where ASPaeroFlowr,d and ASPaeroFlowseq are able to solve more instances with lower arrival delay than CASA/ATFMr,d. Interestingly, just comparing these results we can see that simultaneous optimization of ASPaeroFlowr,d achieves competitive results compared to ASPaeroFlowseq, as is able to solve more instances on sizes V ∈ CE − G, U SA − G, CE, whereas ASPaeroFlowseq achieves better results on V ∈ EU R−G, DACH. This behavior can also be seen in Figure 3, where nominal capacity alterations are shown for large graphs (V ∈ CE, DACH, EUR, USA): the ASPaeroFlow variants use approximately an equal execution time, whereas CASA/ATFM-variants are slower. Furthermore, we can observe that the results are instance-dependent and while ASPaeroFlow-variants are able to solve instances with nominal capacity ≥ 20%, the methods relying on ATFM-measures are only able to solve instances ≥ 40%. On the SOTA scenarios, we show the strongest results in Table 6. ASPaeroFlowr,dp, ASPaeroFlowseq, ATFMr,dp, and ATFMr,d achieve the strongest results. The strong results for the ATFM only methods can be explained by studying the differences between the instances. While the generated instances BLOX, c0X, and mBLOX have little to no possibility for DAC, the industrial instance IC allows for plenty of reconfiguration. Therefore, the results of BLOX, c0X, and mBLOX, are similar, where the ATFM methods have a slight edge as they are (implicitly) more likely to consider reroutes — which also explains results of negative delay, which happen as for the SOTA instances the filed path is not necessarily the optimal one. Comparisons to SOTA work besides the paper introducing ASP-P and MIP however, are hardly useful, due to differences in the model stemming from dynamic computation, (slightly) different definitions of demand/capacity measurement, objective functions, and time.

Statistical Significance: To evaluate the statistical significance of the algorithmic differences, we first performed a non-parametric Friedman test. The test indicated a statistically significant difference in the lexicographic mean ranks across the 12 variants (χ2F (11, N = 1889) = 15459.90, p < 0.001). Consequently, we conducted post-hoc pairwise Wilcoxon signed-rank tests, applying the Holm-Bonferroni correction to adjust for multiple comparisons. The results demonstrate that all pairwise differences are statistically significant (p < 0.001), establishing a strict performance hierarchy of ASPaeroFlowr,dp, ASPaeroFlowseq, ASPaeroFlowr,d, followed by the others. The final ordering of the variants, based on their mean ranks, is depicted in Figure 4.

Sequential vs. Simultaneous Optimization: We observe that simultaneous ASPaeroFlow is highly competitive to ASPaeroFlowseq. However, relying solely on aggregate statistical tests or scaling results across the entire benchmark yields inconclusive results: while all simultaneous variants together solve and win more than ASPaeroFlowseq, no single simultaneous variant beats ASPaeroFlowseq (Table 4). This occurs because sequential optimization possesses two inherent advantages: first, if an instance can be solved solely via DAC, sequential optimization achieves superior results since Kd = 0; second, the smaller search space per step permits more search steps compared to simultaneous optimization. Conversely, a major deficit exists: if pure DAC fails to eliminate overload, sequential optimization defaults to ATFMr,d, which performs worse than simultaneous optimization. We compare in more detail the variants ASPaeroFlowr,d and ASPaeroFlowseq: evaluating all instances (n = 1889) on the two methods, ASPaeroFlowr,d achieves #W: 864 and #S: 1717, while ASPaeroFlowseq achieves similar results (#W: 843, #S: 1734); with 182 draws. However, isolating the subset of instances where ASPaeroFlowseq fails to solve via DAC alone (n = 1318), ASPaeroFlowr,d demonstrates a clear advantage with #W: 864 (#S: 1154) compared to #W: 441 (#S: 1171) for ASPaeroFlowseq; with 13 draws. This divergence is reflected in the statistical analysis. Comparing only these two variants across the full dataset (n = 1889), the Wilcoxon signed-rank test yields mean ranks of 1.49 for ASPaeroFlowr,d and 1.51 for ASPaeroFlowseq (p = 0.61, not significant). Note that the loss of significance compared to Figure 4 stems exclusively from reducing the test space from k = 12 to k = 2; without the other variants skewing the global rank distribution, the high number of ties between these two highly competitive variants becomes statistically apparent. Interestingly, when applying the test to the dataset where ASPaeroFlowseq fails to solve via DAC alone (n = 1318), the mean ranks shift to 1.34 for ASPaeroFlowr,d and 1.66 for ASPaeroFlowseq, yielding a statistically significant difference (p < 0.001).

Ablation Study: Table 5 evaluates the impact of enabling rerouting (r), delaying (d), and restructuring (s). Each feature reduces overloads, however for r/¬r the results are strictly speaking inconclusive due to overlapping SEMs. Restructuring yields the largest reduction in both overload and arrival delay. While the heuristic optimizes locally, a sector split at t1 persists, providing global temporal benefits by resolving future overloads at t2 > t1. Conversely, rerouting and delay effects remain temporarily localized. For multi-leg flights, local delays may fail to resolve subsequent conflicts automatically and risk propagating downstream, inducing secondary overloads.

Conclusion

ASPaeroFlow demonstrates that bounded instance-space decomposition provides a computationally viable heuristic for joint ATFCM, scaling exact ASP to industry-sized instances. Our ablation study reveals that DAC is the primary driver for overload reduction because sector partitioning provides global temporal benefits, whereas flow measures risk downstream propagation of overloads. Furthermore, simultaneous optimization outperforms sequential approaches when DAC alone fails. Future work will address the open challenges of stochastic disruptions and the integration of Explainable AI (XAI) to extract rule-based justifications for automated scheduling decisions.

Improvements for AI systems

Improvements to AI Systems Based on This Paper:

Decomposition-Heuristic Hybrid Solver: Build an AI system that combines exact optimization (ASP) with instance-space decomposition to solve large-scale combinatorial problems. The system can partition a global problem into localized, tractable subproblems, solve each exactly, and iteratively refine until convergence—enabling scalability to industry-sized instances where pure exact methods fail.
Simultaneous Multi-Objective Optimizer: Implement an AI that jointly optimizes interdependent decision variables (e.g., flow management and airspace configuration) rather than sequentially. This system can exploit the enlarged search space to find better solutions when one dimension alone cannot resolve constraints, outperforming sequential pipelines in cases where the first-stage solution is insufficient.
Adaptive Parameter Tuning Engine: Create an AI with dynamic parameter adjustment (e.g., flight limits, delay windows, route counts, partition options) that expands search horizons when stalling and contracts when convergence is rapid. This ensures termination guarantees and balances solution quality with runtime, mimicking the algorithm’s “adjustParameters” logic.
Lexicographic Objective Prioritizer: Develop an AI that minimizes objectives in a strict priority order (e.g., overload magnitude → arrival delay → active sectors → reroutes → reconfigurations). This system can handle multi-criteria decision-making with clear, interpretable trade-offs, and can be applied to any domain requiring hierarchical constraint satisfaction.
Ablation-Aware Feature Selector: Build an AI that evaluates the marginal impact of each decision lever (e.g., rerouting, delaying, restructuring) via ablation studies. This system can identify which actions yield the highest global benefit (e.g., restructuring provides long-term temporal gains vs. localized flow measures), guiding resource allocation toward the most impactful interventions.
Global-Temporal Benefit Predictor: Implement an AI that distinguishes between locally optimal actions with short-term effects and those with persistent global benefits (e.g., sector splits resolving future overloads). This system can prioritize actions that prevent downstream propagation of issues, reducing secondary conflicts.
Statistical Robustness Evaluator: Create an AI that automatically performs non-parametric significance testing (Friedman test, Wilcoxon signed-rank with Holm-Bonferroni correction) to validate algorithmic improvements. This ensures that performance differences are statistically meaningful, not due to random variation, and can rank competing strategies reliably.
Instance-Aware Strategy Selector: Build an AI that analyzes problem characteristics (e.g., graph size, reconfiguration potential, traffic density) and selects the best optimization strategy (simultaneous vs. sequential, rerouting vs. delaying vs. restructuring). For instance, it can detect when DAC possibilities are limited and switch to flow-optimization-heavy approaches, or when DAC is rich, prioritize restructuring.
Explainable Scheduling Decision System: Leverage ASP’s rule-based modeling to generate human-interpretable justifications for each scheduling decision (e.g., why a flight was delayed, why a sector was split). This AI can provide transparent audit trails, improving trust and enabling regulatory compliance in safety-critical domains like air traffic management.
Scalable Real-Time Decision Support: Develop an AI that operates within strict time/memory limits (e.g., 1800s, 35GB) and can handle 10,000+ flights on real-world navpoint graphs. This system can be deployed in operational settings for daily planning, offering a middle ground between slow exact solvers and low-quality greedy heuristics (e.g., CASA).