2.1. Background and Motivations
In the last few decades, CIRA has gained relevant expertise in the design of DAA systems thanks to activities that have been carried out in both nationally-funded Italian projects and in internationally-funded European projects.
The integrated ADS-B-based automatic separation assurance collision avoidance system, whose real-time simulation campaign is the subject of this paper, is indeed the result of many years of incremental research on this topic. The main motivation that led the design of such a system was the capitalization and extension of previous experience related to single baseline systems for collision avoidance (radar-based) and self-separation in order to achieve the design of a unique, integrated system managing all functions at the same time according to properly designed overall system automation logic and the implementation of the above-mentioned functions in the most appropriate way while considering the requirements of compliance with the rules of the air [
15] and self-compatibility.
Here, the evolutionary approach that led to the ASACAS design is outlined. A baseline version of an autonomous collision avoidance radar-based system was developed in the framework of the nationally-funded Italian project TECVOL (Technologies for Autonomous Flight), reaching TRL (Technology Readiness Level) 6 as an individual technology [
16,
17,
18,
19]. The baseline version of an ADS-B-based separation assurance system was developed in the framework of the Italian project SEPARA (System for General Aviation Separation Support), reaching TRL 5 as an individual technology [
20,
21].
Starting from these baseline individual systems, in the nationally-funded Italian project MISE (Applications for Unmanned Aircraft Avionics), the first and baseline version of the ADS-B-based integrated ASACAS was developed. The first version of the ASACAS then evolved in the nationally-funded Italian project EATS (Efficient Air Transport System). The second (evolved) version of the system was then demonstrated, both in real-time and real live flight trials, in the SJU-funded project RAID, which was completed in 2016 and achieved TRL 6.
In more detail, ASACAS development was implemented through the incremental steps described as follows. The first version of the ASACAS (version 1p0) was designed in order to update the former autonomous collision avoidance (ACA) system developed in the framework of the project TECVOL. The rationale of this update was the need to adapt the collision avoidance functionality to the use of the ADS-B IN cooperative surveillance sensor as unique sensor for obstacle detection purposes, thus replacing the radar-based non-cooperative sensor suite used in the application developed in TECVOL. This represented the first step towards the development of a fully integrated automatic separation assurance and collision avoidance system (ASACAS version 2p0), including both separation assurance and collision avoidance functionalities based on the ADS-B IN surveillance sensor, as well as the integration of a dedicated situational awareness functionality and overall ASACAS logic. The ADS-B IN-provided surveillance data are used as input for conflict and collision detection algorithms in order to support the collision avoidance and the separation assurance functionalities.
In ASACAS 1p0, the collision detection system for collision avoidance was specifically modified with respect to the former TECVOL application [
16,
17,
18,
19] and designed in order to allow it to use ADS-B IN-provided data that are broadcast by all ADS-B OUT-equipped surrounding aircraft. The overall collision detection system architecture designed in ASACAS 1p0 aimed to manage the ADS-B data in order to provide the collision avoidance resolution algorithm (which has not been changed from the baseline version) with proper information about surrounding traffic [
22,
23]. In this phase, another dedicated surveillance processing application that is compliant with applicable RTCA (Radio Technical Commission for Aeronautics) standard DO-317 [
24] was designed and implemented.
ASACAS 2p0 improved the collision avoidance functionality that was already implemented in ASACAS version 1p0, and it designed and integrated the functionalities of separation assurance (modifying and evolving the baseline self-separation functionality from SEPARA [
20,
21]), TCAS compatibility check, and situational awareness. Moreover, ASACAS 2p0 included suitable automation logic that was specifically developed to properly manage the behavior of the whole integrated system.
The ASACAS therefore provides the RPAS with the following automatic capabilities:
Assistance to separation assurance to perform a separation maneuver when required to remain well clear of other traffic aircraft.
Collision avoidance.
Enhanced situational awareness, providing traffic information to allow the RPAS pilot to build their situational awareness related to the surrounding traffic as an enhancement of the remote pilot traffic supervision.
Provision of compatibility information between the ASACAS and the TCAS operations in the case of proximity between the ownship and a TCAS-equipped aircraft.
Provision of an automation logic that coordinates and sequences all the functionalities, based on the risk associated with the surrounding aircraft, and processes the possible remote pilot inputs received through the dedicated human–machine interface (HMI) implemented in the remote pilot station (RPS).
Further improvements of the ASACAS are still ongoing in the framework of the EATS project [
25,
26], benefitting from the additional experience and know-how gained by CIRA in several international projects both completed (e.g., the EDA-funded project MIDCAS: Mid-Air Collision Avoidance System [
27,
28]) and currently ongoing (e.g., the Clean Sky 2-funded project COAST [
4,
5,
7,
8]). Such improvements were focused on the improvement of the algorithms for detection and resolution and not on any change of the sensor for traffic detection, which remains the ADS-B IN to address cooperative traffic detection. Other works that make use of different sensors are available in literature, including papers vision-based intruder detection systems [
29], but the consideration of such systems is not foreseen as a future extension of ASACAS, at least for the time being and the near future.
2.2. Concept of Operations
Based on what is indicated above, three main capabilities are provided by ASACAS implementation: separation assurance (SA), collision avoidance (CA) and situational awareness (SitA). Here, we provide a description of the interactions between the system and the RPAS remote pilot in order to outline the ASACAS’s intended application and benefits.
The RPAS remote pilot is aware of traffic information by means of an HMI that allows them to build their situational awareness related to the surrounding traffic, including the indication of the consolidated traffic tactical picture around the remotely piloted aircraft (ownship) and the associated level of severity of each surrounding aircraft in terms of loss of separation and collision risk with respect to the ownship. To consolidate the traffic picture and evaluate the associated risks, the system uses ADS-B IN-provided inputs, as well as ownship navigation data provided by the onboard navigation sensor (GPS, Global Positioning System). The overall ASACAS concept of operations is represented in
Figure 1, where ATC indicates the air traffic control service provision facility, GCC is the RPAS ground control station where the remote piloted vehicle station is located, and FCC indicates the flight control computer hosting the on-board ASACAS software (as well as the additionally needed software for autopilot and low-level aircraft control).
From an operational point of view, the ASACAS continuously performs the monitoring of traffic in order to provide an enhanced situational awareness to the remote pilot and to identify a possible loss of separation and/or collision risks.
In the presence of a predicted loss of separation with respect to one or more traffic vehicles, the system is expected to provide information and automatically elaborate a separation recovery maneuver to the remote pilot. The remote pilot is then in charge of evaluating the feasibility of the maneuver with respect to the constraints affecting the flight and not considered by the ASACAS (it is worth noticing that the system performs the elaboration of the separation recovery maneuver without considering any constraint related to, for instance, existing no-fly zones, segregated areas, fixed obstacles, or flight plan constraints). If needed, based on the current tactical picture, the remote pilot can interact with the ATCo (air traffic controller) in order to ask for clearance for the implementation of the proposed maneuver or to negotiate it. Based on the outcomes of the remote pilot and/or ATCo evaluations, the maneuver can be accepted, and, in this case, the remote pilot can decide to delegate its automatic implementation to the aircraft autopilot or to implement the maneuver themself.
In the presence of a predicted risk of collision with respect to one or more surrounding traffic vehicles, the ASACAS is expected to provide information to the remote pilot and to automatically elaborate collision avoidance maneuver with respect to the most dangerous vehicle, according to the proper prioritization criterion. The collision avoidance maneuver, due to its emergency nature, is expected to be automatically implemented by the automatic guidance system. Nevertheless, the remote pilot is provided with the possibility of aborting the maneuver and taking the direct control of the vehicle at any moment.
The ASACAS is also continuously performing a TCAS compatibility check that is aimed to provide a prediction, based on the current trajectory of the ownship and traffic vehicles, of the resolution advisory activation in the surrounding traffic vehicles equipped with TCAS [
30]. Based on the outcome of this check, the expected behavior of the ASACAS with respect to the identified loss of separation and collision risks is accordingly modified in order to ensure that no maneuvers are generated by the ASACAS that could create nuisances to the TCAS-elaborated maneuver.
The ASACAS evaluates the situation in real time at a cycle frequency (ASACAS runs at 1 Hz), so it updates the maneuver suggested to the pilot continuously, which means that if the pilot waits too much and the suggested maneuver is no longer applicable, it is automatically substituted by the ASACAS with a new applicable maneuver.
The “latency” is referred to the overall time that is needed for the reception of traffic info by the ADS-B IN for processing by the ASACAS and the elaboration of the suggested maneuver, as well as the time needed for the maneuver evaluation by the remote pilot and implementation. In general, the latency contribution due to the ASACAS’s computation time is much lower (1 s usually when working at 1 Hz because in all the performed real-time simulations, the system was demonstrated to be able to provide a maneuver in 1 s) than the time needed by the pilot for evaluation and implementation. Considering that the human-related time is a variable not predictable, the ASACAS was designed to automatically perform continuous updates of maneuvers, as indicated above, so that the proposed maneuvers is immediately substituted with a new one when the old is no longer applicable, therefore overcoming the problem of a possible long evaluation time by the remote pilot. This concept is also applied after the clearance and implementation of the maneuver by the remote pilot because the current situation is always evaluated by the ASACAS at cycle frequency (1 Hz) during the flight—even during the maneuver execution—in order to be able to provide a new maneuver when needed.
2.3. Architecture
As outlined in the previous sections, the ASACAS includes the functionalities of SA and CA, and it provides an enhanced SitA to the remote pilot by classifying each surrounding vehicle based on the associated risk with respect to the ownship. The SA and CA functions are allocated to two different logical levels, since CA is considered an emergency function that is activated only when an emergency event is raised, whereas the SA function is in charge of guaranteeing safe separation among aircraft in tactical operations. The functional architecture of the ASACAS is reported in
Figure 2 [
14].
As indicated in
Figure 2, the system receives traffic position and velocity data about surrounding ADS-B OUT-equipped aircraft from the on-board ADS-B IN surveillance sensor in order to predict future conflicts (intended as a predicted loss of separation) and potential future collisions between the ownship and surrounding traffic. The DAA system is supported by a DO-317 [
24] surveillance processing application that is used to perform the processing of the raw data provided by the ADS-B IN surveillance system in order to allow for their use by the conflict/collision detection system. Furthermore, the functional architecture comprises the following functionalities, which are outlined in the following section:
Coarse filtering for both the collision avoidance and separation assurance functions.
Conflict detection for the separation assurance function.
Conflict resolution for the separation assurance function.
Collision detection for the collision avoidance function.
Collision prioritization for the collision avoidance function.
Collision resolution for the collision avoidance function.
TCAS compatibility check for the situational awareness function.
Severity assignment for the situational awareness function.
ASACAS logic.
The outputs of the system include the classification of the surrounding traffic in terms of conflicts (i.e., vehicles that constitute a potential loss of separation with respect to the ownship), threats (i.e., vehicles that constitute a collision risk with respect to the ownship), and traffic (i.e., vehicles that do not pose risks with respect to the ownship). Furthermore, the DAA system elaborates a suitable maneuver to restore the separation minima with respect to all the detected conflicts (if any) and a suitable maneuver to escape from the most dangerous collision vehicle detected (if any). The separation assurance maneuver is proposed to the remote pilot, who is in charge of providing his/her clearance and may also request the automatic implementation of the maneuver by the system. The collision avoidance maneuver is executed in an automatic way due to the emergency nature of such a maneuver and can be terminated by the remote pilot if needed.
2.4. Algorithms
A detailed description of the algorithms applied in the ASACAS and of the related implementation in the dedicated functionalities beyond the scope of this paper, which is focused on real-time test description. Nevertheless, in order to aid the comprehension of the system behavior, a conceptual description of each ASACAS function and, therefore, of the associated implemented algorithms is reported. Some details about the baseline versions of the collision avoidance individual algorithm and regarding the baseline version of the separation assurance individual algorithm can be found in the reference papers [
16,
17,
18,
19,
20,
21], respectively. As already described, these baseline versions have evolved the integration into the overall designed ASACAS, as outlined in
Section 2.1.
For the specific application in the real-time testing addressed in this paper, it is worth emphasizing here that the considered separation volume is a cylinder centered in the conflicting intruder, the planar radius of which is 0.5 Nm and the semi-height of which is 500 ft. The size of the cylinder is properly incremented in order to consider the uncertainties mainly affecting the position and velocity data of the intruder. The considered collision volume, then, is a sphere centered in the colliding intruder with a 500 ft radius. The radius of the sphere is properly incremented in order to consider the uncertainties mainly affecting the position and velocity data of the intruder.
2.4.1. SA and CA Coarse Filtering
In order to provide a pre-selection of the traffic, due to the ADS-B IN equipment’s capability of detecting traffic located very far away and therefore a priori not representing a risk for the ownship, a suitable coarse filtering function is needed to select the surrounding aircraft to be processed by the CA and SA functionalities, thus reducing the computational burden. The basic principle proposed for coarse filtering consists of excluding the aircraft whose distance from the ownship is greater than a specified threshold from the conflict/collision detection. The thresholds set for conflict and collision detection should be different due to the different natures of risk associated with SA and CA functionalities. Therefore, two different coarse filtering systems were implemented, one for each functionality.
2.4.2. SA Conflict Detection
After receiving traffic information about aircraft resulting from SA coarse filtering processing, the conflict detection function checks for a potential loss of separation between the ownship and each considered aircraft. The conflict detection is based on the calculation of possible breach of the cylindrical separation volume by the ownship with respect to all the surrounding traffic vehicles: a pair-wise check is implemented for each and all the surrounding traffic vehicles that have been provided by the dedicated SA coarse filtering functionality, and the cylindrical separation volume breach is considered only if occurring within the specified tactical time horizon considered for separation assurance by the ASACAS. The output of this functionality is a list of conflicting vehicles with associated conflict geometry data. For the separation assurance functionality, a suitable safety bubble, also referred as a “protected zone,” is defined. This represents a non-intrusion zone around a traffic aircraft where the ASACAS declares that action is needed to preclude the ownship from going into the volume associated with separation minima.
The ASACAS’s separation assurance functionality is implemented as the tactical capability of keeping the RPAS vehicle away from other airborne aircraft by at least the separation minima defined by Eurocontrol as follows [
31]: “Specification RPA11: Where an RPA pilot is responsible for separation, he should, except for aerodrome operations, maintain a minimum distance of 0.5 NM horizontally or 500 ft vertically between his RPA and other airspace users, regardless of how the conflicting traffic was detected and irrespective of whether or not he was prompted by a Sense and Avoid system”. Based on such approach, the separation assurance protected zone implemented by the ASACAS is a cylindrical volume of airspace centered on the aircraft, with a horizontal radius of 0.5 NM and a vertical height of 500 ft, as represented in
Figure 3.
In addition to such separation assurance volume nominal dimensions, suitable extra-sizes are considered due to the uncertainties affecting sensor measurements and aircraft maneuvering. These additional extra-sizes are obtained by means of an incremental sizing factor that increases separation volume dimensions according to the closure rate between the conflicting aircraft. Therefore, the protected airspace zone is obtained as the sum of the nominal (minimum) size and the closure rate-dependent calculated extra-size, resulting in a variable overall size due to the variable closure rate between the considered aircraft.
2.4.3. SA Conflict Resolution
The conflict resolution function is activated once one or more conflicting aircraft have been identified by the conflict detection function, and, therefore, a separation maneuver is automatically elaborated by this function, thus assuring the ownship separation from all the aircraft detected as conflicts. The function, therefore, calculates multi-conflict separation maneuver that aims to avoid cylindrical separation volume infringement for the considered conflict geometry while using separation and the proper prioritization of the channels (longitudinal, lateral, and speed) in which the maneuver is proposed in order to not generate excessive workload for the pilot in evaluating and implementing the maneuver.
In addition, in order to allow for the integration of the proposed system in regular conventional traffic and to inherently guarantee self-compatibility among aircraft equipped with the ASACAS SA functionality, the maneuver is elaborated in such a way as to comply with the rules of the air.
Furthermore, the maneuver is elaborated in such a way to be able to resolve all the conflict encounters detected by the conflict detection function while avoiding the insurgence of new conflicts as a consequence of the maneuver itself, thus ensuring the minimum deviation from the ownship nominal trajectory.
As anticipated above, the conflict resolution maneuver is elaborated according to three different possible strategies, with tuning priority as follows: horizontal resolution maneuver, vertical resolution maneuver, and velocity resolution maneuver. The horizontal resolution maneuver is a planar maneuver based on the modification of the current ownship’s track angle; the suggested track angle aimed to resolve the conflict situation is computed in order to avoid a breach of the separation volume while considering the airspace sector from which the conflicting intruder is coming and the applicable right of way. The vertical resolution maneuver is based on the modification of the current ownship’s height to avoid breaching the separation volume around the conflicting aircraft while maintaining the track angle. The speed resolution maneuver is calculated to avoid the separation volume breach by only changing the speed magnitude of the ownship. Finally, as a last resort, a full inertial speed vector variation maneuver, consisting of a whole inertial velocity vector modification, is computed if the previous individual ones cannot solve the conflict. The calculated separation maneuver is then suggested to the pilot on the HMI.
The separation assurance maneuver is considered to be completed when the condition of clear of conflict (CoC) is satisfied, as stated below:
AND
If the separation assurance maneuver was automatically executed (the remote pilot can command the automatic maneuver execution or can execute it manually as he/she prefers), once these conditions are met, the ownship automatically returns to the original course by implementing the automatic capture of the next applicable waypoint (WP) on the flight plan. Otherwise, if the maneuver was executed in manual or in semi-automatic modes, the responsibility of managing the vehicle once cleared of conflict is that of the remote pilot, who is made aware of the clear of conflict through the dedicated symbols on the interfaces.
2.4.4. CA Collision Detection
After receiving traffic information about aircraft of interest as resulting from the CA coarse filtering processing, the collision detection function checks for potential collision conditions between the ownship and each considered aircraft. The collision detection is based on the calculation of possible breach of spherical collision volume by the ownship with respect to all the surrounding traffic vehicles: a pair-wise check is implemented for each and all the surrounding traffic vehicles that are provided by the dedicated CA coarse filtering functionality, and the collision volume breach is considered only if occurring within the specified emergency time horizon (greater than the tactical time horizon of the SA functionality) that is considered the collision avoidance look ahead time by the ASACAS. The output of this functionality is a list of potentially colliding vehicles with associated collision geometry relevant data.
For the collision avoidance functionality, a suitable safety bubble that is smaller than the separation assurance volume is considered. Based on the near mid-air collision definition by the Federal Aviation Administration (FAA) [
32], which refers to the possibility of collision during an encounter in which the aircraft are within 500 ft of each other, the safety volume for the collision avoidance functionality implemented by the ASACAS is a spherical volume of airspace centered on the aircraft with a radius of 500 ft, as represented in
Figure 4, where the relation with the separation assurance volume is also indicated, even if not in scale.
In addition to such collision avoidance volume nominal dimensions, a suitable extra-size is applied due to the uncertainties affecting sensor measurements and aircraft maneuvering. This additional extra-size is obtained by means of an incremental sizing factor that increases collision volume dimensions according to the closure rate between the ownship and the involved threat. Therefore, the collision avoidance safety volume is obtained as a sum of the nominal (minimum) size and the closure rate-dependent calculated extra-size, resulting in a variable overall size due to the variable closure rate between the considered aircraft.
2.4.5. CA Collision Prioritization
Based on the check performed by the collision detection function, multiple collisions may be detected, i.e., more than one surrounding aircraft may pose a threat to the ownship. Therefore a dedicated prioritization criterion is proposed in order to individuate the most dangerous collision risk. To perform the prioritization, the most relevant collision geometry parameters are considered, and particular importance is given to the resulting time-to-go (i.e., the range over range rate ratio between the considered aircraft).
2.4.6. CA Collision Resolution
The collision resolution function shall elaborate a modification of RPAS vehicle trajectory that is aimed to avoid the predicted collision with respect to the only threat aircraft considered the highest priority by the prioritization logic. The function, therefore, elaborates a single-collision avoidance maneuver that is aimed to prevent the spherical collision volume infringement for the considered collision geometry. The maneuver does not implement any separation and prioritization of the channels (longitudinal, lateral, and speed), as it is inherently calculated as a 4D maneuver. Of course, based on the specific collision geometry, the elaborated maneuver may only affect one of the control channels (e.g., a purely collision avoidance maneuver can be elaborated), but this is not pre-determined or selected by specific design of the functionality and is purely determined by the collision geometry among the available 4D maneuvers. It is also worth noticing that, due to the emergency nature of the maneuver, it does not consider any requirement in terms of the rules of the air.
Due to the single-threat consideration approach, it is clear that, even when the collision detection has detected more threat aircraft, only one threat at a time is considered by the collision resolution. This is managed by the collision prioritization function that identifies the most dangerous threat aircraft as a priority. Once this collision threat is solved, a new one can be sequentially solved—but not simultaneously.
If the TCAS compatibility check identifies that the threat vehicle is equipped with TCAS and is triggering a resolution advisory (RA), a suitable logic is in charge of inhibiting the automatic execution of the ASACAS collision resolution maneuver in order to not interfere with the TCAS; this is a piece of industrially certified equipment that has priority over the ASACAS collision avoidance functionality. On the other hand, if the threat aircraft is detected as not equipped with TCAS or it is equipped but the TCAS is not expected to activate RAs, the ASACAS collision resolution maneuver is automatically implemented by the ownship. In this case, the remote pilot is only able to abort the automatic collision avoidance maneuver through dedicated command inputs available through the HMI if he/she wants.
The collision avoidance maneuver is considered as completed when the condition of clear of collision is satisfied, as described below:
AND
Once these conditions are met, the ownship can return to the original course by implementing the automatic capture of the next applicable waypoint on the flight plan.
2.4.7. TCAS Compatibility Check
In order to manage the compatibility of the ASACAS implemented in the ownship with the potential TCAS-equipped surrounding aircraft, the TCAS compatibility check function predicts when one or more of them will trigger a RA due to the ownship’s proximity. This information allows for the guarantee of the compatibility between the ASACAS and the TCAS, because based on the predicted RA-alerted aircraft, the expected behavior of the ASACAS with respect to the identified loss of separation and collision risks is accordingly modified in order to ensure that no nuisance maneuvers are generated by ASACAS that disturb the TCAS maneuver elaborated by the considered traffic vehicle.
2.4.8. Severity Assignment
The severity assignment function bases its elaboration on the data provided by the SA and CA functions in order to support the remote pilot by means of visual depiction on a dedicated cockpit display of traffic information (CDTI) system for the whole traffic scenario. Once all the aircraft have been processed by the CA and SA functions, all the detected surrounding aircraft are managed and classified based on:
The conflict status provided by the conflict detection function.
The collision status provided by the collision detection function and suitably prioritized by the collision prioritization one.
The RA alerted status provided by the TCAS compatibility check function.
For this aim, the severity assignment function identifies which is/are the surrounding aircraft with respect to whether a separation or collision avoidance maneuver is needed while also considering the RA-alerted aircraft. From a practical point of view, the severity assignment functionality-provided output is the data source for visualization on a dedicated display implemented on the HMI of all the relevant information related to the surrounding traffic, collected and elaborated by the CA and SA functions and suitably classified and prioritized according to the associated severity level of risk, in order to individuate and differentiate all the aircraft represented on the CDTI system.
2.4.9. ASACAS Logic
The assignment of a severity risk to each surrounding aircraft is processed by a suitable ASACAS logic in order to establish the ASACAS’s operational status. The ASACAS logic function processes the information about the aircraft detected as conflicts/collisions and those ones provided by the TCAS compatibility check in order to:
Coordinate and sequence the two functionalities of separation assurance and collision avoidance, based on the risk associated to the surrounding aircraft.
Process the remote pilot commands to the ASACAS (for instance, separation assurance or collision avoidance maneuver termination) issued through the HMI.