4.1. Component-Structure
The structure of the digital interactive radar controller as designed in [11] and shown in Figure 2, requires some adaption to meet the requirements of the UDC. In contrast to the digital interactive radar controller, this controller is designed to independently guide traffic, rather than conducting planning actions and using as a support for an active controller. Moreover, an additional interface to coordinate with the UAM system is required. The resulting components structure is shown in Figure 4.
The data service component is replaced by multiple data interfaces to allow for UAM interaction (Figure 4 left side). The connection to the air situation display is eliminated (Figure 4 right side) and replaced by a clearance generator component. This generator translates a certain action into the commands for the different systems. For example, a takeoff clearance is translated into a takeoff message for the UAM system, a takeoff-status for the flight plan and an audio clearance for the airtaxi pilot.
4.2. Class Structure
The component structure is further detailed into a class structure with each class serving a functionality. To better visualize the classes within the paper, the class structure is visualized by the input part (data analysis and situation evaluation component) and the output part (activity plan, monitoring and clearance generator). Figure 5 shows the input part.
The input class diagram shows how the different data sources are merged. Audio (e.g. pilot requests), aircraft position and flightplan data are associated with the referenced flight. In this process, audio data requires special treatment as the audio stream must be translated into commands initially (cf. [15]). The multiple flight objects are then joined into a traffic situation object which is enhanced by a calculated UAM network plan. The slot algorithm (cf. [9]) is the basis of this calculation.
Based on the traffic situation class, the transfer into clearances (audio output) and system handling (e.g. route updates) are managed by the output part as shown in Figure 6.
Within the output part, the traffic situation is analysed by the task model and the monitoring class. The task model checks in which state each flight is and acts according to the operational concept (cf. ANNEX A). If for instance an airtaxi owns the status „departed“ and asks for landing clearance, the specified actions of checking the vertiport for traffic and then issuing the landing clearance are conducted. All activities are fed into an activity list which serves as a buffer for the execution. All non-nominal cases (e.g. traffic conflicts) are handled by the monitoring class. This class checks the traffic situation and if the execution is in conformance with the issued clearances.
4.3. Activities
The UDC consists of a large set of activities. As pointed out in chapter 4.2 the task model and the monitoring activity are the two activities which determine the general behaviour of the controller. The monitoring activity as show in Figure 7 is basically triggered whenever a rerouting is requested or a deviation from the calculated trajectory is detected. In consequence, a new trajectory is calculated, checked against conflicts and forwarded as three activities (direct-to-command on the VCS system, flightstrip update and UAM message).
The task model as shown in Figure 8 owns more tasks than the monitoring activity. It is either triggered whenever an airtaxi is in 2NM distance to the final approach fix (abbr. FAF) or a request of an airtaxi is received.
The activity is designed as a basic decision-tree-structure which can be summarized as the following cases:
- Enter control zone (airtaxi departing from inner-city vertiport): Check traffic load and vertiport clear of approaching / departing aircraft.
- Leave frequency (airtaxi landing on inner-city vertiport): Check airtaxis is short of vertiport
- Ready for departure (airtaxi departing from airport): Check traffic load and clear of traffic on final approach / departure
- Airtaxi 2NM from Final Approach Fix (airtaxi landing on airport): Check clear of traffic on final approach.
The design is concluded with the presented activities. The class diagram and the activities form the basis for the evaluation in the next section.
4.4. Evaluation
The evaluation took the 15 airtaxi flights from one human-in-the-loop simulation scenario (cf. [7]). Each flight was performed as a theoretical walkthrough. The simulation recorded takeoff- and landing times of the airtaxis and the conventional traffic. These times were used to initiated the walkthrough. Initially, the content of traffic situation object was generated by collecting all active aircraft five minutes prior to the landing / takeoff. These aircrafts were used as the content of the traffic situation object. Based on this object the task model activity and the monitoring activity were theoretically calculated step by step. The outcome was evaluated regarding safe and efficient air traffic. Figure 9 shows an example of a walkthrough for an airtaxi taking off at an inner-city vertiport.
In total, 15 airtaxis with 35 situations were examined in the evaluation. As a result, the following deficiencies in the model were detected:
- Data synchronisation: The current model assumes that data input and activities are sequential. In the operational system the data of the different sources will not be synchronized thus a component to buffer and collect the data is required.
- Hold Strategy: Currently the UDC commands an airtaxi to hold, but the point in time when the airtaxi is cleared to continue, especially in situations when multiple airtaxis are on hold. A sufficient strategy needs to be designed therefore.
- Output speed: In the current design, the UDC sends commands whenever the decision is made. Depending on the implementation this can generate a very fast sequence of commands or even synchronous commands upon using parallel computing. For humans interacting the UDC this can lead to misunderstandings (cf. [16]).
