Content area
Purpose
The small air transport (SAT) domain is gaining increasing interest over the past decade, based on its perspective relevance in enabling efficient travel over a regional range, by exploiting small airports and fixed wing aircraft with up to 19 seats (EASA CS-23 category). To support its wider adoption, it is needed to enable single pilot operations.
Design/methodology/approach
An integrated mission management system (IMMS) has been designed and implemented, able to automatically optimize the aircraft path by considering trajectory optimization needs. It takes into account both traffic scenario and weather actual and forecasted condition and is also able to select best destination airport, should pilot incapacitation occur during flight. As part of the IMMS, dedicated evolved tactical separation system (Evo-TSS) has been designed to provide elaboration of both surrounding and far located traffic and subsequent traffic clustering, to support the trajectory planning/re-planning by the IMMS.
Findings
The Clean Sky 2-funded project COAST (Cost Optimized Avionics SysTem) successfully designed and validated through flight demonstrations relevant technologies enabling affordable cockpit and avionics and supporting single pilot operations for SAT vehicles. These technologies include the TSS in its baseline and evolved versions, included in the IMMS.
Originality/value
This paper describes the TSS baseline version and the basic aspects of the Evo-TSS design. It is aimed to outline the implementation of the Evo-TSS dedicated software in Matlab/Simulink environment, the planned laboratory validation campaign and the results of the validation exercises in fast-time Matlab/Simulink environment, which were successfully concluded in 2023.
1. Introduction
The small air transport (SAT) aviation domain is gaining increasing interest over the past decade, based on its perspective relevance in enabling efficient travel over a regional range, in particular for commuters, by exploiting available small airports and fixed wing aircraft with up to 19 seats (EASA CS-23 category) (EPATS Consortium, 2007a, 2007b; Scarpellini Metz and Bowen, 2004; Dollyhigh, 2002; Clean Aviation, 2020). To support the further development of SAT aviation, Clean Sky 2 JU (European Commission, 2011), in accordance with the European Commission vision for aviation toward 2050 (Piwek and Wiśniowski, 2016; Lucky et al., 2024), awarded for funding the project COAST (Cost Optimized Avionics SysTem), which started in 2016, evolved according to the project plans and has been successfully concluded in 2023 (Di Vito et al., 2017a, 2017b).
In the COAST project, relevant technologies enabling affordable cockpit and avionics and supporting single-pilot operations for SAT vehicles have been designed (Di Vito et al., 2017a, 2017b; Vaispacher et al., 2022; Kanovsky et al., 2022; Zaykov et al., 2020; Wing and Cotton, 2011) and validated through flight demonstrations. Such technologies include single-pilot operations enablers for flight management, namely, as relevant enabler for single pilot operations in future traffic management scenarios (Di Vito et al., 2021a, 2021b, 2021c, 2021d), the tactical separation system (TSS) (Montesarchio et al., 2022); the advanced weather awareness system (AWAS) (Grzybowski and Szpakowska-Peas, 2020); and the flight reconfiguration system (FRS) (Di Vito et al., 2017a, 2017b). Among them, the dedicated decision-making support system designed to assist the pilot in the separation management, also in case of delegation of the separation responsibility to the pilot by the ATC, was the TSS (Di Vito et al., 2021a, 2021b, 2021c, 2021d).
The TSS baseline version was developed according to incremental approach, starting from conceptual design and passing, then, to algorithms design and implementation as software prototype, which was validated through fast-time as well as real-time validation campaigns (Di Vito et al., 2021a, 2021b, 2021c, 2021d; Di Vito et al., 2022a, 2022b, 2022c). Once successfully completed the software prototype validation, the final TSS software, including not only main software to be executed in the COAST avionics but also the dedicated HMI to be integrated in the pilot electronic portable device, was integrated in the COAST avionics and implemented onboard in the cockpit of the experimental aircraft EVEKTOR EV-55. The technology was successfully demonstrated in flight in the year 2021 over the Kunovice airport, using as intruder a real aircraft EVEKTOR VUT-100 (Di Vito et al., 2021a, 2021b, 2021c, 2021d).
After successful completion of the TSS baseline design and demonstration, in the COAST project, an integrated version of all the designed baseline single-pilot flight management technologies was conceived and designed, aimed to exploit at the highest level and enhance the individual technologies: the integrated mission management system (IMMS). The IMMS has been designed and implemented with the objective of allowing automatic optimization of the aircraft path taking into account multiple requirements and constraints, as listed below:
trajectory optimization needs (e.g. minimal length from starting position to selected destination);
traffic scenario;
weather conditions (actual and forecasted);
airspace requirements and constraints;
fixed obstacles; and
selection of the best destination airport, should pilot incapacitation occur during flight (Menichino et al., 2021; Di Vito et al., 2022a, 2022b, 2022c).
Based on that, the TSS baseline version has been properly evolved, leading to the evolved TSS (Evo-TSS) (Di Vito et al., 2022a, 2022b, 2022c), specifically finalized to be integrated into the IMMS thanks to inclusion of some specific functionalities, such as the consideration of not only surrounding traffic, over tactical time horizon, but also of far located traffic, relevant at strategic level. This allowed the subsequent provision of traffic clustering additional functionality, aimed to support the trajectory planning and re-planning by the IMMS.
This paper follows the previous ones, as indicated in the references (Di Vito et al., 2022a, 2022b, 2022c; Di Vito et al., 2023; Isufaj et al., 2021) and contextualized in the above-reported summary of the activities, and is aimed to outline the implementation of the Evo-TSS dedicated software in Matlab/Simulink environment (Section 2), the planned laboratory validation campaign (Section 3) and the results of the validation exercises in fast-time Matlab/Simulink environment (Section 4), which was successfully concluded in 2023.
2. Evolved tactical separation system: architecture and concept of operations
Based on the successful results achieved in the flight demonstration campaign carried out in 2021, the TSS baseline version development was completed, and the activities were then devoted to the evolution of such baseline version of the system towards integration into the COAST IMMS, able to optimize the ownship trajectory while taking into account all relevant potential hazards (traffic, weather, obstacles) and constraints (airspace requirements and restrictions). To this aim, the Evo-TSS version has been designed, aimed to support the emergency IMMS with not only tactical separation management, as in the baseline version, but also with processing of traffic far from the ownship (relevant at strategic level rather than at tactical one) and with provision of dedicated traffic clustering functionality. This latter functionality, in particular, is aimed to allow the trajectory optimization by the IMMS, while avoiding, if possible, high traffic density airspace volumes, identified by means of cylindrical areas properly identified and characterized by the Evo-TSS.
The Evo-TSS version implements the already existing TSS functionalities of Surveillance Processing, Coarse Filtering, Conflict Detection, Prioritization and Resolution, suitably managed by a dedicated TSS Logic, and provides the additional functionality of traffic clustering. The Evo-TSS architecture in Simulink environment is illustrated in Figure 1. The Evo-TSS receives in input ownship and surrounding tracks positions and velocities, respectively, by GNSS receiver and ADS-B receiver, and performs a first filtering of all the traffic beyond 150 NM, which is discarded because it is not relevant for the elaboration of the traffic picture over the tactical and strategic time horizons considered according to the cruise speed of ownship. Then, the surveillance processing function, in compliance with RTCA standard DO-317, consolidates the traffic picture and provides it to:
the Conflict Detection module, which predicts if the traffic vehicles trajectories, projected as straight line, and the ownship trajectory, also projected as straight line, are predicted to be in conflict over tactical time horizon, i.e. in other words, predicts if the ownship trajectory will potentially breach the separation volume set around each traffic vehicle over tactical time horizon; and
the Clustering module, which identifies and characterizes the traffic clusters, based on the criteria described in the previous paper (flightradar24, 2024) and proposed in (Isufaj et al., 2021).
The Conflict Detection module output is, then, processed by:
the Traffic Prioritization module, which prioritizes all the aircraft; and
the Conflict Resolution module, which is enabled by the TSS logic to provide suitable maneuver able to restore the separation minima.
Finally, the prioritized list of tracks and the suggested conflict resolution maneuver are provided to the multi-functional display (MFD), along with the traffic clusters information, to support the pilot decision-making and her/his situational awareness, whereas the traffic clustering info is also sent in input to the IMMS, to be considered by its trajectory optimization systems (the Evolved FRS, also referred to as the path change system) in performing its tasks.
Specifically, to support the IMMS in trajectory optimization, the following additional data were required to be provided in output by the Evo-TSS:
the position of center and radius of circles representing the horizontal section of the identified traffic clusters;
the minimum and maximum altitudes of the identified traffic clusters; and
a numerical value representing the severity level associated to each traffic cluster, which ranges from 0 (minimum hazard severity) to 1 (maximum hazard severity).
It is worth mentioning here that the association of a severity level to each cluster is needed to allow, in case of needed flight plan modification, the path change system integrated in the IMMS (Di Vito et al., 2023) to take into account traffic clusters scenario and to design a trajectory able to avoid, if possible, the most crowded volumes of the airspace. The clustering functionality with included severity assignment to each identified cluster, as added in the evolved version of the TSS, is based on proper application of general traffic clustering criteria indicated in (flightradar24, 2024). More in details, each traffic cluster is an assigned volume defined by:
a center;
a radius;
minimum and maximum altitude, including one or more traffic hazards, based on:
aircraft relative position vs ownship;
aircraft attitude vs ownship;
aircraft relative velocity vs ownship, identified by an evaluated hazard severity level, considering:
interdependency among cluster components;
strength of the cluster components; and
neighborhood of the cluster components.
The latter set of criteria, which is used to assign a proper severity to each cluster, is based on previous literature work (flightradar24, 2024), allowing to consider the indicated parameters as described in the following.
Interdependency – The interdependency between the aircraft refers to their relative reciprocal positions’ evolutions during time (i.e. approaching or diverging aircraft). More interdependency between the aircraft, more complex the cluster is. The closer these aircraft are, the bigger the effect they have on each other will be. If the two aircraft are in a conflict, which means they are closer than the standard safety distance (COAST Separation Volume is applied as: 3 NM horizontally and 1,000 ft. vertically), the effect they have on each other is maximum. From the implementation point of view, the interdependency between the aircraft is here defined as the number of approaching aircraft with respect to the number of aircraft couples inside the cluster. Given a cluster C, the Evo-TSS evaluates, inside C, all the couples of aircraft which are approaching each other and then compares this information with the total number of possible couples of aircraft inside C. The quantitative evaluation of the interdependency is performed as: (1) where n is the number of aircraft inside C, a is the number of aircraft, which are approaching each other. Strength – The strength associated to each aircraft depends on the centrality of the aircraft inside the cluster. As much stronger an aircraft is in the cluster, as much higher interdependency affects the aircraft and the others surrounding it. For instance, considering three aircraft in the cluster with AC1 and AC2 moving closer while AC1 and AC3 moving away from each other:
the strength of AC3 decreases through time; and
AC1 and AC2 strength score increases over time.
Overall result, with AC1 having an increasingly stronger interdependency with AC2, while its interdependency with AC3 becomes weaker over time, overall strength increases in time for the whole cluster. From the implementation point of view, the strength between the aircraft is here defined as the number of “strong” aircraft couples with respect to the number of aircraft couples inside the cluster. A couple is considered “strong” if the relative distance between the aircraft is lower than a defined threshold, which here corresponds to the TSS safety volume nominal dimensions plus 20%. This means that the aircraft that are too close each other give strength to the cluster. Given a cluster C, the Evo-TSS evaluates, inside C, all the couples of aircraft that are “strong” and then compares this information with the total number of possible couples of aircraft inside C. The quantitative evaluation of the strength is performed as: (2) where n is the number of aircraft inside C, s is the number of strong couples inside C.
Neighborhood – The neighborhood of each aircraft inside the cluster is a cluster complexity measure, so it directly affects its severity. More tight aircraft are, more complex the cluster is. From the implementation point of view, the neighborhood between the aircraft is here defined as an index of the closure between all the aircraft inside the cluster. As much closer are all the aircraft, as much higher becomes the severity level. Given a cluster C, the Evo-TSS evaluates, inside C, the mean distance D between all the aircraft and compares this information with a defined threshold T. The quantitative evaluation of the neighborhood is performed as: (3) where D is the mean distance between all the aircraft inside C and T is a defined threshold.
It is also worth mentioning here that in the reference literature work (flightradar24, 2024) also, a further parameter was proposed: the cluster coefficient, measuring the local cohesiveness of the aircraft inside the defined cluster, thus measuring the “stability” of the cluster. Nevertheless, such parameter was not considered in the evaluation of the clusters’ severity level performed by the Evo-TSS, because the system performs a real-time update at 1 Hz of the traffic picture and related clustering, which implies that the consideration of such additional parameter was not useful.
Therefore, all these concepts but the cluster coefficient have been included and properly combined to achieve the severity level indicator definition in the Evo-TSS design, with the aim of associating a score (severity) to each cluster. In particular, the severity level associated to each cluster by the Evo-TSS is here defined as the mean value of interdependency, strength and neighborhood indexes.
In Figure 2, an exemplary representation is reported of the Evo-TSS traffic clustering functionality elaborated output.
3. Prototype and laboratory validation campaign: simulation environment and exemplary test scenarios
The test campaign devoted to the Evo-TSS SW prototype validation has been carried out in a dedicated Matlab/Simulink simulation environment, to:
simulate fast-time traffic in input to Evo-TSS;
store the outputs of the simulation; and
perform the analysis of the obtained results to assess the clustering functionality performances.
The overall conceptual representation of the implemented validation procedure is reported in Figure 3, where it is possible to notice that:
“Ownship&TrafficModels” represents the software modules devoted to simulate the ownship and traffic behavior;
“HMI model” represents the software module devoted to simulate the pilot interaction with the HMI, specifically in terms of the input actions of freezing the proposed maneuver, in case of predicted conflict and provided suggested resolution maneuver (Di Vito et al., 2021a, 2021b, 2021c, 2021d);
dedicated script “Init_Evo_TSS.m” initializes all the simulation input parameters; and
dedicated script “Test_Evo_TSS.m” stores all the simulation output data, which are then examined to assess the Evo-TSS behavior.
To simulate and predict the Evo-TSS behavior during the flight demos to be carried out once again over the Kunovice airport (IKAO: LKKU), in 2023, a dedicated study of realistic aerial traffic around LKKU airport has been carried out. The traffic toward/from some key locations/waypoints, which correspond to the airports in proximity of Kunovice, was simulated and replicated in all directions around LKKU, so to generate traffic scenarios impacting on all the possible ownship trajectories starting from Kunovice. Finally, traffic data nearby the LKKU airport, during some typical days, have been collected, through Flightradar24 service [27], implementing the procedure here described: starting from snapshots of traffic flying over the Kunovice area, the list of aircraft involved with their flight data, when available, has been retrieved and the traffic evolution over time has been reconstructed, merging all the collected snapshots.
The aim of the tests carried out has been:
the verification of the maintained integrity of the TSS baseline functionalities, of course expected to not be altered by the implemented modifications to the system for its evolution; and
the assessment of the ability of the Evo-TSS in correctly identifying and managing the traffic in terms of clusters.
A huge set of fast-time traffic scenarios has been tested:
500 scenarios with very high random traffic level (100 traffic aircraft involved);
1,500 scenarios with traffic located near Kunovice and neighbor airports (from 40 to 60 traffic aircraft involved); and
and 100 scenarios with realistic traffic simulated (variable number of traffic aircraft).
An exemplary traffic scenario and the overlay of 50, over more than 2,000 scenarios, are shown respectively in Figure 4(a) and (b), where the local reference system is centered on the LKKU airport.
4. Prototype and laboratory validation campaign: exemplary test results
Several test scenarios have been simulated and successfully tested during the fast-time simulation campaign, as detailed in Section 3. The obtained results confirm the Evo-TSS effectiveness in identifying and clustering the surrounding traffic aircraft, while reassuring about the correct behavior and integrity of the TSS baseline functionalities. As an example, here the results of the set of 100 realistic test scenarios are detailed; nevertheless, all the considerations here reported are applicable also to the other test cases.
In compliance with the expected flight test campaign, the simulated realistic scenarios assumed the ownship flying from Kunovice airport to the Prague airport, with ownship speed of 90 m/s (324 km/h). A flight time of 1 h has been simulated. For what concerns the traffic aircraft, then, the speed and the altitude have been obtained by the data recorded by means of Flightradar24 service [27], as indicated in the previous Section 3.
In Figure 5(a), the number of simulated aircraft for each scenario is reported in black: it is variable and compliant with the realistic traffic days recorded. In addition, the number of aircraft:
filtered by the traffic filter (relative distance less than 150 NM) and, then, by the surveillance processing is depicted in green;
filtered by the coarse filter (relative distance less than 20 NM) is depicted in blue; and
predicted to be in conflict with the ownship by the conflict detection is depicted in red.
The tested scenarios covered a huge set of traffic conditions, to stress the Evo-TSS behavior: as expected, the traffic density is variable with homogeneous distribution of aircraft both in the proximity of ownship (circles in blue, relative distance less than 20 NM) and far away. This corresponds to the possibility of one or more conflicting aircraft to be identified by the TSS.
The number of clusters identified by the Evo-TSS for all 100 realistic scenarios is reported in Figure 5(b): it is never null, meaning that the clustering function is able to cluster the surrounding traffic, and it is often considerable, being the number of clusters quite high. The same consideration applies to the number of aircraft inside each cluster, represented in Figure 5(b) too.
The representation of a typical realistic scenario and of the clusters identified by the Evo-TSS is shown in Figure 6. Basing on the severity level associated to each cluster, the clusters are colored in green (low severity), yellow (medium severity) and red (maximum severity). All the surrounding traffic aircraft are reported:
the empty circles represent all the aircraft simulated that are discarded from the traffic filter, being too far from ownship and so being not relevant, neither for tactical nor for strategic traffic picture consolidation purposes;
the filled circles represent the aircraft processed and managed by the Evo-TSS; and
among them, the green filled ones represent the single aircraft clusters, which have a null severity (the aircraft is alone in the cluster).
As shown in Figure 6, the Evo-TSS correctly identifies cylindrical clusters with minimum and maximum altitude, being the simulated aircraft at very different altitudes, basing on realistic Flightradar24 data.
5. Conclusions
This paper presented the description of the fast-time validation campaign of the Evo-TSS software in the COAST project, reporting and commenting, then, the outcomes of the performed tests. The simulation campaigns that have been carried out demonstrated that the Evo-TSS software continued to assure the correct working of the TSS baseline functionalities and successfully included the additional functionality of traffic clustering, aimed to support the trajectory optimization functionality of the IMMS. Based on the positive outcomes of the described activities, the Evo-TSS main software and its evolved HMI have been integrated in the overall IMMS and have been successfully demonstrated in flight, in the dedicated live trials campaign carried out in 2023. The results of the flight demonstration will be the subject of future papers.
This work was carried out in the framework of the COAST (Cost Optimized Avionics SysTem) project. COAST project has received funding from the Clean Sky 2 Joint Undertaking (Clean Aviation), under the European Union’s Horizon 2020 research and innovation program (Grant Agreement No. 945535).
Figure 1Evolved TSS Simulink architecture
Figure 2Evo-TSS traffic clusters
Figure 3Fast-time simulation environment conceptual representation
Figure 4Exemplary fast-time simulation traffic scenarios with 50 traffic aircraft (a) and 2,000 traffic aircraft (b) over the considered regional area surrounding LKKU airport
Figure 5Number of simulated aircraft (a) and clusters and number of traffic aircraft exemplary scenarios (b)
Figure 6Evo-TSS traffic clustering output [exemplary scenario in 3D view (a) and vertical plane view (b)
© Emerald Publishing Limited.