How ERASMUS Can Support an Increase in Capacity in 2020 Deirdre BONINI Egis Avia 195, rue Jean-Jacques Rousseau, 92138 Issy-les-Moulineaux, France deirdre.bonini@egis.fr and Carole DUPRÉ Intuilab Les Triades A, rue Galilée, BP 77242, 31672 Labége, France dupre@intuilab.com and Géraud GRANGER Steria 271 avenue de Grande-Bretagne, BP 3111, 31026 Toulouse, France geraud.granger@steria.com ABSTRACT With air traffic levels expected to increase, a future capacity problem needs to be addressed. The ERASMUS project proposes an innovative way to share the controller s workload with automation, in order to increase capacity. Focusing on a 2020 scenario, this article describes the core of this project, the algorithm and the services it can provide, and the gaming demonstration that was carried out to evaluate how effective ERASMUS would be in increasing capacity in the future. The main conclusions were that to increase capacity with ERASMUS it was necessary to make the algorithm s and the user s understanding of conflicts compatible. Furthermore, operational experts agreed that automation can replace human decision-maker only for certain tasks, whereas for other tasks automation was considered acceptable only as a support. Thoughts on the direction of future research close the paper. Keywords: air traffic control, conflict detection and resolution, genetic algorithms, user-centred design. 1. THE FUTURE CAPACITY PROBLEM Air traffic demand is expected to double by 2025 and behavioral analysts indicate that human air traffic controllers (hereafter referred to as controllers) will not be able to observe and vector many more aircraft than they do today [1]. In order to resolve the future capacity problem the Single European Sky ATM Research (SESAR) programme has been launched [9]. SESAR describes a roadmap to increase capacity through a number of changes, amongst which an increase in automation and a redefinition of the job of an air traffic controller, who is expected to be able to control more traffic with a higher degree of technological support. Considering the high level of automation and computing power that has been introduced into airborne systems in the last fifty years, an example being the Flight Management System (FMS), one may wonder why similar levels of automation have not been implemented in ground systems. Automation alone, however, can not provide the solution. Whilst the success of the future Air Traffic Management (ATM) system will depend on complex and sophisticated technology, the role of the human remains critical and important. The ultimate goal is thus find an optimal trade-off between automation and human tasks. The En Route ATM Soft Management Ultimate System (ERASMUS) project is an important milestone in the roadmap provided by SESAR, as it proposes a new and innovative way of sharing the controller s workload with automation. ERASMUS is based on an algorithm that uses information from both ground and airborne systems to reduce the number of conflicts between aircraft, and to provide more precise information, regarding the present and future positions of aircraft to operators. The expected result is the provision of a better service to airspace users. ERASMUS has been developed to be able to support an increase in capacity in present-day systems and in future systems. This paper focuses on the implementation of ERASMUS in a SESAR-compliant 2020 scenario. In particular, the objective of the work described was to identify the potential of the ERASMUS algorithm and the services it can provide to increase capacity in a future environment, which has yet to be fully specified. The approach chosen to evaluate the potential of ERASMUS in a 2002 environment, and ensure stakeholders and users needs are adequately addressed, was to run a gaming demonstration with operational experts. The conclusions drawn following this exercise are summarized in terms of lessons learned and of the necessary future work to improve ERASMUS.
2. THE ERASMUS SOLUTION The underlying idea of the solution provided by ERASMUS to the capacity problem is that to increase capacity it is necessary to reduce the workload of the controller [3]. The ERASMUS project studies the possibility of decreasing the attention load of the controller by developing automation that reduces the number of conflicts. It is assumed that by reducing the amount of attention a controller needs to give to each aircraft, the controller will have more time and resources to control a greater number of aircraft [4]. Furthermore, the ERASMUS algorithm is able to provide information based on both ground and airborne trajectory prediction, which is thus much more precise than that available to controllers today. This increase in precision of information means that the controllers will not only be able to rely more on the technology, but also benefit from additional services provided by a more reliable source of information about present and future traffic situation. The ERASMUS algorithm reduces the potential for conflicts between aircraft by changing the parameters of the flight (e.g. speed, flight level, or route). The algorithm can work in an autonomous fashion or in a non-autonomous manner, providing information to the controller supporting his/her decision-making. The services provided to the controller by the ERASMUS algorithm support the controller in detecting conflicts and in resolving conflicts. The following sections will describe the algorithm and the services that the algorithm is able to provide to actors in the ATM system, in particular to controllers. The ERASMUS algorithm The ERASMUS algorithm is the core of the ERASMUS project and is based on more than 10 years of work at the French DTI/DSNA (former CENA) 1. It is based on CATS (Complete Air Traffic Simulator) [5], which is a fast time air traffic simulator that has been used for study purposes since 1996. It is able to reproduce aircraft trajectories according to operational or fictitious flight plans, from departure airport to arrival, using standard or direct routes [6]. The ERASMUS algorithm is a genetic algorithm which works going through a numbers of steps: monitoring of the situation, detection of conflicts, resolution finding, and the application of the resolution. These four steps are briefly described in the following paragraphs. The monitoring step consists in getting all aircraft positions and trajectory predictions from the airside with constant uncertainty in time. The conflict detection is the second step. The algorithm uses these trajectory predictions to detect potential conflict situations. The conflict detection consists in measuring the predicted distances between aircraft and if the distance is under the defined minimum separation, then the aircraft pair is considered as a conflict. A transitive closure is applied on all pairs of conflicts. In other words, if A and B are in conflict and B and C are in conflict, then A, B and C are considered as being in conflict. This results in independent groups of conflicting aircraft, which will be referred to as clusters. The third step is the resolution process, which is carried out independently for each cluster. 1 The idea of ERASMUS is based on the work of Jacques Villiers, General engineer of the French Civil Aviation, now retired, whose work has been patented in France. Different kinds of resolutions are to be found. Initially, the ERASMUS algorithm tries to solve conflicts using small speed adjustments to the flight plans to the aircraft in each cluster. If this type of solution does not prove to be effective, the ERASMUS algorithm tries to change flight levels or find alternative routes to solve conflicts. All solutions found that are viable within the cluster and are then checked within the whole traffic to ensure that the given maneuvers do not generate new conflicts. If a new conflict is detected, a new resolution process is launched with a new cluster composed of the previous concerned clusters and another clusters or aircraft. This process is not infinite. In the worst case all aircraft will be considered in one cluster. In the fourth step, the resolution is applied. Choices have to be made regarding whether the resolutions are implemented automatically by the algorithm and/or who has to validate them. The solution envisaged in demonstration of ERASMUS in 2020 involved on the one hand an automatic sending of the resolution to the pilot, who had to acknowledge and accept this change to the flight plan, and on the other hand the use of information provided by the algorithm to the controller. These will be described in the third section. The settings used by the ERASMUS algorithm (e.g. the number of aircraft in a cluster, the minimum separation distance, the time between one complete cycle from detection to resolution, the aircraft which can and can not receive resolutions), can be parametered according to specific operational requirements. The services provided by ERASMUS The services that are provided by ERASMUS are based on the process described above. The algorithm can provide information regarding the conflicts detected, the resolution of these conflicts, and the monitoring of the effectiveness of these resolutions [7]. The first service is that of conflict detection. The information about conflicts is more precise than that offered by other conflict detection tools due to the fact that it is based on both ground and airborne trajectory prediction information. This type of information can be used to identify conflicts in advance (i.e. 20 minutes before the minimum separation distance). The second service is that of conflict resolution. The algorithm is able to find solutions to conflicts either through minor speed changes, new flight levels or trajectories. In the case of minor speed changes, the algorithm works in an autonomous fashion. In other words, the algorithm identifies the conflicts and solutions and sends the pilots proposals directly through the controller pilot data link communications (CPDLC) network, without the intervention of the controller. The controller may or may not be informed about this activity, as described later. The ERASMUS algorithm issues clearances that request the pilot to make minor adjustments to the horizontal or vertical speed of the aircraft (i.e. -6%, +3% of current speed). In the future it is expected that these clearances will be able to take into consideration fuel consumption and environmental constraints. From the point of view of who the decision maker is, ERASMUS can function in an autonomous fashion or be dependent on the controller s input. In terms of the information provided to the controller, ERASMUS can work in an opaque or transparent way.
In the case of autonomous conflict identification and resolution, with regard to the information that is provided to the controller, the algorithm can work in an opaque or transparent fashion. In the first case, although the controller will be aware that the algorithm is working in the background and sending clearances to the pilots to resolve conflicts through minor speed changes, the controller may not know which aircraft are concerned, nor what resolutions are being implemented. In the second case, the activity of the ERASMUS algorithm is transparent to the controller. Choices regarding which information and the way in which it should be provided, will have to be made when implementing ERASMUS. When the ERASMUS algorithm does not work in an autonomous manner, resolutions are sent to the controller for prior validation, and not directly to the pilot for acknowledgement and acceptance. In this case it is the controller who chooses to propose this resolution to the pilot, not the ERASMUS algorithm. Not all conflicts can be resolved through minor speed adjustments. A number of residual conflicts will have to be solved through an active intervention by the controllers. The way these conflicts are resolved by the controller is through the support of the algorithm. To summarize, a part of ERASMUS services can be provided in an autonomous way, in the sense that although the controller may be aware of the algorithm s activity or is aware of which aircraft the algorithm is deconflicting, this activity is not under the air traffic controller s direct control. These services can be provided in an opaque or transparent fashion in terms of how much or how little information is provided to the controller regarding the activity of the algorithm, as well as its results in the identification and resolution of conflicts. Another part of ERASMUS support is provided through tools that advise the controller on the existing conflicts and ways to resolve them. This type of support is not autonomous, on the contrary the ideal implementation is an optimal cooperation between the human and the automation, with the human in the loop taking decisions, and the automation providing accurate information to help the human in the best possible way identify and resolve problems. 3. PROVIDING SOLUTIONS IN A 2020 ENVIRONMENT A number of difficulties arose when trying to define a 2020 environment in which to carry out an evaluation of the potential of ERASMUS in terms of capacity. On the one hand, it was difficult to simulate an environment where many of the variables are yet unknown. It was thus necessary to imagine a context that was substantially different from that of today, in terms of airspace, traffic, roles, working methods and tools. On the other hand, if ERASMUS were to support the controller s decision-making, this would be done through tools. If tools that are either known or under development were used, it would have been difficult to clearly distinguish the impact of ERASMUS. The effects observed could have been due to the tools, and thus the way the information was provided, and not the information that was actually provided. This bias is particularly strong in an unfamiliar environment (i.e. 2020). The decision was thus taken to only use tools developed specifically for this demonstration, with the sole aim to illustrate the potential of ERASMUS. Furthermore, regarding the actual methodology chosen to measure capacity increase in a future scenario, consensus was reached that a new way to evaluate this had to be used [8], a gaming exercise, run like a demonstration. The results of fast-time simulations were used to support the running of demonstration where experts were shown how the future system would work, in terms of roles, working methods and tools. The aim was to collect participants feedback and their expert judgment. The demonstration followed a script, which was designed to illustrate all the services that ERASMUS could provide in a 2020 environment, and show how it was believed ERASMUS could support an increase in capacity. Although quantification was not possible, it is believed the results of such an approach to measure future capacity to be valid. In order to prepare the gaming demonstration a number of workshops with operational experts were run in order to define a SESAR-compatible 2020 scenario and to establish how ERASMUS services could be provided to a future controller through new tools, designed specifically for the demonstration. Visits to three European air traffic control centers (Rome, Stockholm and Maastricht) were carried out to identify features of today s roles, working methods, human machine interfaces (HMIs), and human computer interactions (HCIs) that would be relevant to a future scenario, characterized by an important increase in traffic level. The three sections below summarize the decisions made following these activities with regard to how the demonstration should be set-up, in terms of the future context, the services to be provided to controllers, their roles and working methods. The 2020 environment Due to the fact that it was not possible to carry out a user requirement analysis, the ERASMUS team collected information on the 2020 environment from the literature and operational experts. The starting point was SESAR documentation [9, 10, 11], where, although the 2020 context has not yet been completely specified, the guidelines provided were used to structure discussions with operational and SESAR experts. A number of features were chosento define a 2020 environment. Services provided by ERASMUS and the tools to illustrate these services The services provided by ERASMUS and identified as being relevant for a 2020 environment were of two types. The first were provided by ERASMUS in an autonomous fashion, in other words ERASMUS worked in parallel to the controller. The ERASMUS algorithm considers the traffic in an airspace, identifies the conflicts, and groups aircraft concerned by a conflict or with inter-related conflicts. Finally, the ERASMUS algorithm finds solutions in the form of small speed changes to be applied to concerned aircraft, which resolve the conflicts in a cluster without creating new conflicts with other aircraft. The ERASMUS algorithm sends a data-link message to the aircraft concerned by the speed change instruction. If the pilot accepts, the plot and label of the aircraft concerned by the speed changes color (i.e. became blue instead of white). This provides the controller with feedback concerning the status of the flight (i.e. not following an ERASMUS instruction versus following an ERASMUS instruction). According to the fast time simulations, 80% of the conflicts can be resolved through minor speed adjustments [12]. In the demonstration, a conflict was defined in terms of minimal separation distance. Thus if two aircraft were estimated as passing at less than 8 nautical miles distance, they were considered as being in conflict by the algorithm. The time lapse
between one calculation and the next of the ERASMUS algorithm was initially set at 3 minutes, to conform with the parameter used in fast-time simulations. Following tests, however, it was changed to 6 minutes to allow the controller to evaluate the traffic situation and make an informed decision on the effectiveness of the proposed change. In other words, the need to give the controller enough time to evaluate the problem and the solution was identified and 6 minutes was considered more reasonable than 3 minutes. In the autonomous ERASMUS, the controller was in the loop because it was transparent to him/her which aircraft are touched by speed changed by ERASMUS, although the controller was not the decision maker. The pilot, on the other hand, was in the loop as a decision maker as he/she could choose to accept or reject the ERASMUS proposed speed change. With regard to the services provided by ERASMUS as a support (i.e. not in an autonomous fashion), the controller had to resolve around 20% of residual conflicts through two tools that were developed specifically for the demonstration: the What-else (WE) tool and the What-if (WI) tool. The What-else (WE) tool showed solutions available from the algorithm to solve conflicts in a residual cluster. The operator could either select a criterion (i.e. flight level, route, time window) or leave the choice to the ERASMUS algorithm. The algorithm would consider all aircraft, with and without constraints, to provide the available solutions. The What-if (WI) tool provided a service that allowed the controller to understand the consequences of his/her actions on the traffic. To resolve a conflict between a pair of aircraft the operator could interrogate the algorithm on the effectiveness of using a certain resolution strategy. In other words, the WI tool provided information regarding whether implementing a solution would resolve a conflict, not create new ones. Human Machine Interfaces (HMI) were then developed to illustrate the ERASMUS services through these two applications to participants [13, 14, and 15]. Figure 1 illustrates the HMI that was imaged for the tactical controller, with information regarding the conflicts detected and the possible solutions found by the ERASMUS Solver. Figure 1: The tactical controller s Human Machine Interface. Roles and working methods It is generally accepted that the roles and actors in a 2020 SESAR-compliant environment will be quite different to those of today [16]. The main difficulty in defining these roles lies in the lack of detail we currently have concerning the future system, procedures and airspace. For the demonstration, the first choice was to have larger sectors as one of the ideas of SESAR is to have a new role, that of the meta-sector planner for a number of sectors, rather than a planner for each sector. The meta-sector planner (MSP) is responsible for a number of sectors and works at a strategic level, between 20 and 40 minutes ahead. Having a larger picture of the situation and working ahead in time the MSP should be able to solve problems with small changes, and without creating problems for other traffic in a large space. In one of the ATC centers visited it was observed that this type of role already existed, and thus inspired the definition used in the demonstration. Planning controllers worked for their sector but also coordinated with other sectors for the benefit of sectors other than their own. For example, the planning controller of sector N-3 called the adjacent centre to obtain an entry flight level from sector N, after which he/she informed all controllers concerned by this information. The MSP had to make sure that the tactical controllers of the sectors he or she is responsible for (i.e. in our demonstration, 2 sectors) were not overloaded in terms of traffic and level of complexity. In order to distinguish the aircraft under ERASMUS constraints from the others, they were blue and not white on the HMI. The tagging of aircraft was something that was observed in the centers visited, where controllers highlighted or marked aircraft visually on their HMI. The fact of controlling mixed traffic was also observed. It was thus considered acceptable for controllers to see aircraft represented differently on their HMI to help them manage a diverse traffic. With regard to the working methods associated with this role, when the MSP decided to resolve a cluster, he/she chose amongst the resolutions provided by the WE tool and then sent it to the concerned tactical controller (TC). The concerned TC was the controller who currently had the aircraft under control. If the resolution was considered acceptable, the TC sent it to the pilot/s concerned. Feedback was provided on the controller s position if the pilot accepted the clearance. With regard to the tactical controller, the TC had two kinds of activities related to conflict resolution. The first was strategic, and thus different to that of today, because he/she took decisions that benefited the next sector. In other words, the TC sent ERASMUS resolutions to aircraft under his/her control so that conflicts further along the line were resolved. The second activity was closest to the separation assurance done today by TCs, ensuring that the minimum separation standards are respected. The TC had 3 tools to support him/her in his/her work. The first was the 6 minute What-else. Every 6 minutes (i.e. at every new sweep of the algorithm s process), the ERASMUS algorithm provided the controller with resolutions, in the form of flight level or new trajectory proposal. The controller could choose amongst a number of resolutions and was assured that the resolution would not create a new one, at least within a 20- minute look ahead envelope of time. The controller tried to choose solutions that were RBT compliant and thus to follow its planned route. The second tool was the 2-minute WE. It worked in the same way as the 6-minute WE, but with a smaller look-ahead time (i.e. 2 minutes). This tool is tactical in terms of time frame. ERASMUS does not find solutions for all conflicts, mainly because aircraft have received too many constraints or have special status. With the 2 minute WE all the constraints in a cluster are removed and thus the ERASMUS algorithm is able to find resolutions.
The third tool was the WI tool, which was designed to help the controller understand the effect of an action taken on an aircraft on the rest of the traffic. This was particularly powerful as the consequence is seen for the next 15 to 20 minutes. The definition of the HCI with this tool came from the visits to operational centers, where controllers were observed using a projection tool to evaluate the position of an aircraft 10 or 15 minutes in time. This tool helped the controller decide whether a conflict would occur or not, and to monitor the evolution of the situation. 4. THE ERASMUS DEMONSTRATION The gaming demonstration was carried out over 3 days with both stakeholders and operational experts (i.e. ground and airborne) participating. The ERASMUS algorithm and services were presented to the audience, following which the demonstration proper illustrated the services through the HMIs specifically developed for the event. The storyboard of the gaming demonstration included three types of events: the autonomous ERASMUS, the ERASMUS working as a support for the MSP and the ERASMUS working as a support for the TC. A question and answer session took place after each demonstration, which was an opportunity to collect impressions, opinions, and discuss with experts the strengths and weaknesses of the services provided. With regard to the autonomous services provided by ERASMUS, participants expressed positive and negative opinions regarding the tagging of aircraft under ERASMUS speed constraints (i.e. in the gaming demonstration these were colored blue). The positive aspects involved the sharing of information, feeling that the controller would thus be able to collaborate with the automation. However, questions were raised regarding exactly what information should be shared, e.g. minimal separation distance, couple in conflict, concerned cluster, and so on. Furthermore, issues were raised regarding when the aircraft should be tagged: before the speed constraint is implemented, during or after. Further research is needed to optimize the collaboration between the autonomous ERASMUS and the human in the loop to ensure that ultimately workload is not increased, but capacity is. In fact, the negative opinions expressed concerning the tagging of information were that once aircraft are tagged, the controller has less freedom in conflict resolutions. It is expected that in the future the controller will have to understand a much more complex context than today s traffic, where there is not a mixed traffic situation, with blue, purple and white traffic (i.e. speed constrained, WE aircraft and conflict-free traffic). Finally, the issue of who monitors the correct functioning of the autonomous ERASMUS was highlighted, in relation not only to liability but also in terms of emergency versus non-nominal situations. In other words, who should monitor the ERASMUS algorithm, what happens if the ERASMUS algorithm fails or if the human makes a mistake. Monitoring is a time- and resource-consuming activity, which needs to be carefully designed in working methods. For the demonstration, the calculation cycle was set to 6 minutes. This value is a parameter that can be adjusted in ERASMUS. In fast-time simulations, the choice of the cycle resolution depends only on the technology (i.e. the power of the computers used). In the gaming demonstration the complex relationship between the cycle resolution and the controller s decision-making processes was highlighted. Indeed, for each new resolution process, if the resolution is unsuccessful, the ERASMUS algorithm will assess the situation once again, and find a different solution. Seeing that the logic used by the algorithm evolves, it is thus necessary to give the controller time to manage new proposals in terms of imagining the consequence of change on the traffic situation. Extending the resolution cycle from 3 to 6 minutes resulted in a reduction of the efficiency of the algorithm, but underlined the need to make the algorithm s view compatible with the controller s mental picture. Further work on the coordination of the system and user s image is certainly necessary. It is necessary to find a reasonable number of maneuvers sent to the aircraft by the ERASMUS algorithm or solutions provided by the algorithm to the controller. This balance will be found in terms of a trade-off between the uncertainty of the information used (trajectory prediction) and a measure of the overall system efficiency. Many questions remain open regarding the parameters for the ERASMUS algorithm. For example, the time-lapse setting, how many constraints an aircraft can receive during its flight, the consideration of rates of climb and descent in trajectory prediction, environmental considerations, fuel consumption. Concerning the HMIs that were designed for the demonstration, participants found them very intuitive and attractive. The controllers commented on the fact that although the interfaces had not been designed to control but to demonstrate, they illustrated the concepts effectively and allowed them to easily imagine the future operational setting. In terms of ERASMUS providing support via tools, with regard to working methods, issues were raised concerning cross-boundaries (i.e. the functioning of the algorithm from one sector to another, and from one centre or ERASMUS algorithm to another). A number of issues have to be addressed around who sends ERASMUS clearances to pilots (e.g. planning controller, MSP, tactical controller), whether different controllers can work on the same cluster, what visualization information is provided on the ground and on the flight-deck. In general, air traffic control experts wondered whether ERASMUS was to go as far as supporting controllers in conflict resolution. It was suggested that ERASMUS should only support the detection of conflicts, leaving their resolution to the human expert. The concern here was that the automation was seen as a substitute for the human in resolving conflicts. The idea of support tools was well accepted, but not an idea of an automation deciding and driving the activity. Operational experts considered that to efficiently resolve a problem it was necessary to have first properly detected and analyzed it. Moreover, once an expert identifies a problem usually the solution is found as well. In the same way as to monitor a solution it is better to have elaborated it, so as to understand if the expectations are effectively fulfilled. Participants considered that having to monitor the automation could result in an increase in workload, and thus a reduction of capacity. 5. CONCLUSIONS AND FUTURE WORK The conclusion of the gaming demonstration was that, according to the participating stakeholders and experts, ERASMUS has a great potential in terms of increase of capacity, and its main underlying ideas seemed to be accepted by operational experts as a viable and exciting solution to help tackle the capacity problem. Controllers were positive about ERASMUS working in an autonomous way, although they wanted to know what the algorithm was doing (i.e. autonomous was acceptable, opaque was not acceptable). This feeling may be related to issues
around liability and responsibility. For acceptability to be ensured it will of course be necessary to carry out studies of the HCIs between operators and ERASMUS in non-nominal situations (e.g. storms, technical break-downs) as well as the transition and recovery phases from nominal to non-nominal situations. Controllers were more interested in the support of ERASMUS in detecting conflicts, and less in helping them resolve them. Flight deck experts could see the potential of ERASMUS support to pilots as well. The selection of the algorithm s parameters needs to be considered in terms of the effects on controller s mental picture of the traffic, to ensure operators can easily maintain situational awareness. To conclude, although the first findings are positive, the questions that the gaming demonstration raised underline the need for a stepped approach in investigating how to ensure that an optimal collaboration between ground controllers, pilots, and ERASMUS results in an increase in overall ATM system capacity. [12] ERASMUS, Fast-time simulation results 2020 scenario, 2008 [Deliverable D1.3.2]. [13] ERASMUS Design Graphique version 2 de l environnement de démonstration ERASMUS 2020 / Graphic design version 3 of the ERASMUS 2020 demonstration s environment, 2008 [DSNA reference: DTI/R&D/NT08-624]. [14] ERASMUS, Design Graphique version 3 de l environnement de démonstration ERASMUS 2020 / Graphic design version 3 of the ERASMUS 2020 demonstration s environment, 2008. [DSNA reference: DTI/R&D/NT08-625]. [15] ERASMUS, Manuel d utilisation IHM / HCI User Manual, 2008. [DSNA reference: DTI/R&D/NT08-626]. 6. ACKNOWLEDGMENT The work described in this paper was funded by DTI/DSNA. The authors are extremely grateful to Rinaldo Malé, Alfredo Corradini, Kris Vermeiren, and Christopher Vozmediano. We wish to thank the controllers for their time and generosity, as well as our colleagues in the ERASMUS project, whose work we referred to in this paper. Thank you also to Intactile Design for the design of the HMIs developed for the demonstration, and to Christopher Misiak and Caroline Chabrol for their constructive comments on the paper. 7. REFERENCES [1] T.B. Sheridan, Next Generation Air Transportation Systems: Human-Automation Interaction and Organizational Risks, Proceedings of the 2nd Symposium on Resilience Engineering, Juan-les-Pins, France, November 8th-10th 2006 [2] http://www.sesar-consortium.aero/ [3] ERASMUS 2, Concept of operations, 2008 [DSNA reference: DTI/R-D/0807296/MTC]. [4] ERASMUS, Experimental plan environment baseline 2007, 2008 [Deliverable D4.2.1]. [5] J.M. Alliot, J.F. Bosc, N. Durant, L. Maugis, CATS : a complete air traffic simulator, Proceedings of the 16th Digital Avionics Systems Conference, 1997. [6] N. Durant, G. Granger, A traffic complexity approach through cluster analysis. Proceedings of ATM2003, 2003. [7] ERASMUS, Note de cadrage / Framework memorandum, 2008 [DSNA reference: DTIR-D0806446MTC]. [8] ERASMUS, Experiment 5 experimental plan: The 2020 scenario ERASMUS demonstration, 2008 [Deliverable D4.2.2.]. [9] SESAR Consortium, The ATM Target Concept, 2007 [DLM-0612-001-02-00a]. [10] SESAR Consortium, Baseline Operational Description for the Mid-term, Task 2.2.4, 2007 [DLT-0612-224-00-07]. [11] SESAR Consortium, Concept of Operations, Task 2.2.2, 2007 [DLT-0612-222-02-00]. 2 Unless DSNA references are provided, ERASMUS deliverables are available at www.atm-erasmus.com