ELSA Agent Based Model
The agent-based model developed by the ELSA project aims at simulating the European air traffic. It is a versatile model which can be used as a library to develop other types of models easily by making use of different parts independently.
This model is based on interacting agents (mainly flights and controllers) and is composed of several fairly independent modules:
- A network generator, including navpoints and sectors.
- A trajectory generator, used to test different traffic situations.
- A tool to “rectify” trajectories in case of simulation of the SESAR scenario,
- A conflict resolution engine, simulating a tunable, imperfect controller.
The model uses a description of the airspace in terms of navigation points (which form a network on which the flights are traveling) and sectors. The latter define in which area the controller can actually interact with the flight. The core engine of the model is the resolution of conflicts, given an airspace and some flights traveling through the sector. The controller can have different strategies (horizontal deviation, vertical deviations, give a direct) depending on the environment and its own limited – and tunable – look-ahead time. The controller is perfect in the sense that he avoids all conflicts but sometimes makes suboptimal decisions due to its limited forecast capacities. ”Shocks” can be used to perturb the trajectories. Indeed, some parts of the airspace can be randomly shut down for a given time, simulating weather events or military exercises. The spatial and temporal distributions of shocks can be fully controlled. The model also includes a possibility of building some airspace, ranging from full manual definitions of navpoints and sectors to automatic generation of airspace. Real airspaces can also be used easily, possibly integrating deviations from reality controlled by the user (e.g. number of navpoints). The airspace can be composed of several sectors and is in three dimensions. The model gives the possibility of generating flight trajectories in a controlled way. In particular, there exists the possibility of slowly tending to business trajectories – i.e. straighter and straighter trajectories, thus testing the possibility of continuous integration of the SESAR scenario on real airspace. The integration can be heterogeneous, with some sectors keeping a fixed grid of navpoints whereas others have already moved to business trajectories.
The resolution engine itself is written in C, with an interface with Python. The code is organized in a modular way, making it possible to use only the resolution engine and feeding it with some user defined airspace, or use only the trajectory generator, etc. Moreover, some default post-processing manipulations are included for simple metrics about the networks, on the trajectories and on the actions of the controller.
The network generator module is very versatile and allows:
- To draw the spatial distribution of navigation points or use external data,
- To compute the navigation points network edges with a triangulation1 or use external data,
- To draw sectors at random, using a Voronoi tessellation for the boundaries or use external data.
- To compute time of travels between edges of navigation points or use external data.
Hence user can fully specify the network and the sectors or use the module in a semi-automated way. It is also possible to build a network based on traffic data. This module is written in Python.
The trajectories generator can be used to generate synthetic traffic on a given network of navigation points + sectors. It allows to create traffic in a set of sectors given some airports and/or entry/exit points in a realistic way, making sure no sector is overloaded. The user can specify:
- a total number of flights,
- a distribution of flights per pair of entry/exit points,
- some capacities for the sectors.
This module is written in Python.
With this module, one can study the trajectory-based operations in the SESAR scenario. In the SESAR Concept of Operation is in fact foreseen the implementation of Business Trajectories where requested trajectories from airlines will be progressively made straighter and straighter across sectors and FIRs. With these trajectories, the flights are not bound to travel on the navpoint network anymore, but can rather use straighter trajectories. This rectification happens for trajectories at random, moving one navpoint chosen at random on the trajectory to make it straighter. Different probabilities can be associated to different sets of navpoints, hence allowing heterogeneous transition to business trajectories, for instance for different sectors. The navpoints are rectified until a certain value of the “efficiency” is reached. The efficiency is the average ratio over all flights of the length of the direct trajectory (from entry point to exit point) with the current trajectory. This efficiency is directly related to the Key Performance Indicator defined by the Performance Review Commission as “flight efficiency”. This module is written in Python.
Conflict resolution engine
This engine is used to deconflict a set of flights on an airspace. A “super-controller” is trying to avoid conflicts by changing the trajectories of flights using the three dimensions. Some features included in the engine are:
- The controller is actually deconflicting all the flights: no conflict ever occurs,
- However, the controller is not perfect because she has a limited lookahead time.
- Hence, she takes actions which could trigger other conflicts in the future.
- Some noise can be applied on the speed of the aircraft, possibly destroying the forecast of the controller.
- The user can trigger some “shocked areas”, volume of the airspace forbidden to any flight. This is simulating closed airspace for military reasons or local weather events.
This generator also includes a (tactically) pre-deconflicting module (right now, a brute force algorithm shifting flights in time). This can be used to study the case where only the noise on velocity (i.e., predictability) impacts the conflict resolutions. Note that in the current scenario, the planned trajectories are NOT conflict-free. Thus, the pre-deconflicting module aims at simulating the improved coordination, information sharing and trajectory prediction that is foreseen in the SESAR scenario. This module is written in C with an interface with Python.
Coordinator: Deep Blue