# Air Traffic Simulation Framework for Testing Automated Air Traffic Control Solutions +
## 5 Time Management  
Temporality is a key consideration in both traffic estimation and control mode operations. The simulation operates in an event-driven manner, where synchronization plays a critical role in maintaining coherence between traffic management and the interacting agents. Key events--such as the completion of data processing, communication exchanges, or data refresh cycles--serve as triggers for subsequent actions within the simulation. This event-driven architecture ensures that all components remain aligned in time and behavior,  
Figure 8: Structure of command interface. Figure 9: Example communication through Interface 2 with transcript. supporting accurate and responsive system behavior. Figures 10-12 illustrate three separate but interrelated time axes:  
* API time: representing real time for real-time functionality (particularly relevant when using live ADS-B data);
* Simulation time: indicating the time of the modeled traffic situation, incorporating estimation timeframe;
* Running time: tracking the simulation's actual processing duration, reflecting how operations map to real time. This mapping is shown in the form of rectangles. Note that the axes are not drawn to scale but are presented to highlight the underlying logic behind temporality. The simulation begins at a defined start time \(t_{0}\). The first step involves retrieving data from the API, which may incur variable response times. This is denoted as \(t_{R}\). Following this, the simulation performs a data processing step, combined with the estimation process and represented together as \(t_{P}\). Subsequently, the traffic estimation stage commences, during which simulation time advances by a defined value \(t_{E}\). The time required for processing and estimation is considered negligible compared to \(t_{E}\), but is accounted for using the right sloping hatch area on Figure 10. To maintain temporal consistency in cyclic estimation, the timeframe for each subsequent estimation cycle is adjusted to compensate for elapsed real time by introducing \(t_{E2}\), which can be expressed as \(t_{E2}=t_{E}-(t_{R}+t_{P})\). This adjustment ensures that the simulation provides an updated traffic picture. This allows  
Figure 11: Control mode temporality. Figure 10: Adjusting the estimation timeframe. for refreshing the data in the outside area (according to Section 3.2) with a traffic demand based on real data. In control mode, additional time elements must be considered, as the simulation now includes controller actions. This mode extends the time logic by incorporating the following sequential steps:  
* Pilot request generation (by either the traffic simulation layer or the aircraft agent);
* Controller intention generation (by the controller agent);
* Traffic management (handled by the traffic simulation layer). The total runtime required for these operations is denoted as \(t_{C^{R}}\). As some components depend on agent responses, runtime is measured by observing elapsed time between interface communication. Furthermore, these control actions influence not only runtime but also advance simulation time by a defined timestep \(t_{C}\), representing the simulation's progression during controller interactions. As shown in Figure 11, a subsequent API request can only occur after a total of \(t_{R}+t_{P}+T_{C^{R}}\) from \(t_{0}\). To maintain synchronization with simulation time, the second estimation cycle must then use \(t_{E2}=t_{E}+t_{C}-(t_{R}+t_{P}+t_{C^{R}})\). This ensures that the simulation remains temporally consistent during complex control sequences. A more reliable approach, particularly suitable for offline analysis, involves using pre-recorded ADS-B data rather than relying on real-time feeds. This method eliminates uncertainties caused by API availability and response times. In this scenario, shown in Figure 12, archived data is sampled at intervals of \(t_{S}\).