1 Introduction

Most industry sectors experience a steady development towards heightened automation. Cost reduction, increased productivity and efficiency and improved safety are the most commonly referred arguments to account for this sustained investment. The implementation and use of automated systems has been debated for many decades, and yet substantial issues remain regarding its achievements in terms of improved safety and efficiency (Wiener and Curry 1980). The assessment of potential impacts (i.e. risk assessment) emerging from the introduction of automation features remains a key challenge. As operations increase in complexity, the transformations that are introduced tend to produce unforeseen impacts, often with serious safety consequences (Dekker et al. 2011). This motivates increasing concerns relating to the highly variable and uncertain nature of sociotechnical systems.

Despite the increased presence of technology, operations across all industry sectors retain their sociotechnical nature and inherently serve a human purpose. This means that operations remain (and in most cases become increasingly so) based on interactions between human and technological elements, where the human element is expected to generically oversee the performance of technology and intervein or override it whenever necessary (Bainbridge 1983). In the context of rail traffic control, Balfe et al. (2012) illustrated many of the issues identified by Bainbridge (1983) as the “ironies of automation”. How human operators are expected to maintain supervisory functions over automated systems’ performance, for which the requirements and implications are often poorly assessed, leading to profound impacts on overall operations.

The aviation industry has been in the past and continuous to be one of the most striving sectors in terms of automation. Aside from aircraft systems, traffic control is also undergoing a considerable transformation towards automation. Project AUTOPACEFootnote 1 addressed the need to better understand the potential impacts of future air traffic control (ATC) automation on the performance of air traffic controller (ATCo). This was mainly achieved through the development of a psychologic model and its analysis against a concept of operations (De Crescenzio et al. 2017) under foreseeable increased automation (Cañas et al. 2018).

Alongside this main line of project work, the functional resonance analysis method—FRAM (Hollnagel 2012a) was used to investigate the potential impacts of automation on ATC processes. The work carried out with FRAM provided input to various stages of AUTOPACE work, in particular to the development of hypotheses for further research. ATC complexity is the main driver of ATCo workload (Djokic et al. 2010) and, therefore, increased usage of air space is likely to lead to further increases in ATCo workload, despite the use of technology to manage the foreseen increased air space capacity. The issue explored by the FRAM analysis here presented is then to what extent increased traffic complexity will be effectively managed by automated systems and to what extent may it further impact on ATCo’s performance. A model was developed based on the concept of operations produced by the project and the shift of functions from the human ATCo to automated systems was simulated. This paper reports on the approach taken and discusses its achievements in light of current state of the art and the foreseeable transformations of ATC.

2 Project AUTOPACE

As discussed earlier, increased automation is expected to deliver higher capacity and efficiency whilst ensuring safety standards. The ATCo is expected to retain certain responsibilities and tasks throughout different technology levels that progressively lead to full ATC automation. Even under a foreseeable fully automated scenario, the system is expected to operate under human supervision. This means that ATCo requirements in terms of skills and competencies will be profoundly transformed and should, therefore, be managed, so as to keep pace with system and operational changes.

Project AUTOPACE addressed the training of ATCo and the changes in contents, approaches and requirements that will emerge from increased automation. Project methodology focused mainly on the human participation in what were considered typical ATC situations. These typical situations reflect sequences of actions that would be carried out in order to fulfil ATC operational needs. The following typical control situations were considered for the purpose of AUTOPACE research and as a basis for the work described in this paper:

  • Prepare inbound traffic: all actions required prior to the entrance of traffic into sector

  • Take a traffic into account: receiving control over traffic from lateral ATC

  • Prepare the outbound traffic: all actions required prior to traffic leaving sector (handing over to lateral ATC)

  • Perform traffic surveillance: monitor traffic situation

  • Contact with a traffic: all contacts to and from traffic

  • Evaluate and decide a solution: produce and assess traffic solutions

  • Modify, issue and communicate instructions/data: all actions required to implement a traffic solution

  • Coordinate with other controllers: communication and exchange of information with lateral ATC

  • Negotiate changes with local traffic manager (LTM): strategic planning of traffic control and de-complexing solutions

  • Negotiate changes with the pilot: receiving and processing requests from traffic that imply changes to traffic situation

  • Supervise System functioning: oversight of systems operation

Typical situations were identified based on current ATC operations and were then used to produce a concept of operations (ConOps). The ConOps essentially places the typical control situations in the foreseeable contexts of different degrees of automated ATC operations. Two distinct levels of automation were considered for the definition of ConOps:

  • An E2 scenario of “medium automation” foreseen for the year 2035, under which the ATCo retains a considerable degree of traffic monitoring and decision making responsibilities. The system will propose traffic solutions and prompt the ATCo for a decision on the most suitable one.

  • An E1 scenario of “full automation” for the year 2050, under which the ATCo is only expected to supervise system operation and intervene in case of system failure.

Based on the ConcOps and these two automation scenarios, project methodology followed five different steps (Fig. 1):

Fig. 1
figure 1

AUTOPACE methodology

Full size image

  • Understanding changes in ATC operations, emerging from increased automation, based on the analysis of the typical control situations and ConOps.

  • The potential impacts of such changes on ATCo performance, mainly in terms of workload by using a psychologic modelling approach.

  • Identifying changes in training requirements and proposing new contents and tools to address such requirements.

  • Hazard identification and risk assessment, aiming to investigate the extent to which the proposed training requirements and approaches address new risk factors potentially emerging from the introduced operational changes.

  • Definition of hypotheses for further research, relating to operational conditions under which ATCo psychologic overload or underload were found likely to occur. These hypotheses were mainly derived from the analysis of the dynamic relation between demanded and available resources, built around the application of the psychologic model to AUTOPACE ConOps for the future of ATC.

As illustrated in Fig. 1, these five methodology steps were iterated to support a validation of project outputs. On the one hand, the alignment of hazard identification and risk assessment with the proposed training requirements and approaches was pursued. On the other hand, feedback to the ConOps developed at earlier stages was produced, in order to ensure its accuracy and comprehensiveness. These activities were supported by the analysis of system failure circumstances, in order to investigate the suitability of the proposed project solutions. The following “typical” non-nominal situations were considered to investigate the impacts of failure modes under both E1 and E2 automation scenarios:

  • Situation 1: failure of conflict detection and resolution system.

  • Situation 2: failure of traffic complexity management System.

  • Situation 3: failure of system supported coordination (between ATCo).

The methodologic steps previously outlined won’t be addressed in the paper but will be referred to when relevant place the work carried out with FRAM in the context of AUTOPACE.

3 The functional resonance analysis method

The functional resonance analysis method—FRAM (Hollnagel 2012a) is essentially a modelling tool that focuses on system interdependencies, their dynamics and complexity. This tool is grounded on resilience engineering (Hollnagel et al. 2006) principles and within recent years, has shown to provide an innovative support to the understanding of complex operations and activities. FRAM is based on a description of real work (work as is) as functional elements of a sociotechnical system (what must be carried out to achieve a given goal), which then can be used to produce various operational scenarios as instantiations of the model. It is also an “abstraction” tool in the sense that it focuses on what must be carried out and what is needed (i.e. what resources) to achieve an operational goal. These characteristics of FRAM were considered useful for the pursuit of AUTOPACE objectives, as it provided a basis for comparison between the different scenarios and events under study.

A FRAM model is built based on the description of functions. A system function is something of either a human, technological or organisational nature, which transforms the state of the system towards fulfilling the operational purpose of this system. This introduces in the modelling a diversity of factors relating to system dynamics, which frequently are unobserved within models based on organisational structures or process flows, in particular aspects relating to the types and amplitudes of operational variability. FRAM takes into account the non-linear nature of performance in complex systems, as opposed to building cause–effect sequences of events in time.

The fundamental step in the use of this method is the identification and description of functions. Figure 2 illustrates the functional unit of a FRAM. Each function is defined by six descriptors (time, control, output, resource, precondition and input).

Fig. 2
figure 2

Functional unit of FRAM

Full size image

Potential sources of variability are then investigated, guided by the identification of context dependent human, technological and organisational aspects. This can then support the assessment of system capacities to cope with variability in view of both expected and unexpected variability emerging from system operation. Variability is mainly assessed according to two dimensions and based on the output of the functions:

  • Variability in time: the output is on time or within an acceptable timeframe, too early, too late…

  • Variability in quality: the output is up to expected standards, out of expected standards but adequate, unsuitable...

The graphical representation of functions as hexagons becomes useful for the remaining steps of FRAM. Using the six aspects of functions (time, control, output, resource, precondition and input), system interactions are studied, aiming to identify potential sources of resonance. For instance, the output of a function may be the input, a precondition or even enforce a control aspect of another function in the system. This process may also lead to the identification of possible dampening sources for undesired variability. As an example, if resources for a given function are rated as “more than necessary”, it could indicate the existence of a “spare capacity” that could operate as a damping barrier.

The process of investigating possible couplings between functions, for the identification of both potential undesired variability sources and barriers, is referred to as an instantiation of a FRAM model. These instantiations are essentially a given sequence of activation of all or some of the functions modelled. When functions are activated, it should be because their input became available as an output of another upstream functions. This means that a coupling between this latter upstream function and the former downstream function became effective.

Given its flexible and open nature, FRAM modelling may be used under many different analysis scopes and to respond to a wide diversity of needs. This renders the definition of modelling objectives particularly important, as the obtained model will be closely related to them. Objectives tend to be reflected in the level of detail attributed to certain operational areas of the system being modelled, namely by describing the functions in that area and their aspects in more depth. According to FRAM terminology, these areas are designated as the foreground of the model, whereas the background functions of the model are those for which no input was identified. Hence, the way in which modelling objectives are defined and made explicit, will bear weight on the definition of foreground areas.

FRAM is currently supported by the FRAM Model Visualizer (FMV). The FMV provides the means to build and work with FRAM models and supports the investigation of different types and sources of variability. A version of this tool is available at http://ww.functionalresonance.com.

4 FRAM in AUTOPACE

Despite its recent establishment, FRAM applications are relatively well documented in literature. In particular, within air traffic management (ATM), Yang et al. (2017) have illustrated the contribution of FRAM to improve the understanding of complex interactions in sociotechnical systems and of the non-linear phenomena that may emerge from them. Also, Edwards et al. (2012) discuss the need for a “multifactorial” approach to achieve safety improvements in ATC. The use of FRAM in AUTOPACE extends this multifactorial perspective beyond the restricted domain of human factors and aims to explore interactions between human, organisational and technological factors. FRAM introduces a joint cognitive systems perspective (Hollnagel and Woods 1983), based on which variability and interdependency issues may be thoroughly investigated.

As earlier stated, the analysis carried out aimed to explore the extent to which the foreseen ATC automation will impact on the expected supervisory role of the ATCo, and how this may in return, impact on overall ATC operation. The initial steps of FRAM modelling (the description of functions) enables an abstraction from processes and the multiple conditions under which they may be carried out (either in abidance to formal procedures and informal work methods, or in response to context-related factors). The focus is singly set on the definition of functions as something that must be carried out to achieve a given production purpose, and what under real work conditions, must be supplied (function aspects) to each of these functions so that their output is achieved. Only later with model instantiations are such context-related conditions introduced as potential sources of functional variability. This particular feature of FRAM was fundamental in the scope of this research, as it provided the means to establish a baseline for comparison. The future automation scenarios foreseen in AUTOPACE were investigated as instantiations of the model, initially developed based on current ATC operations. To this end, AUTOPACE ConOps and the two automation scenarios (E2 and E1) were used as primary inputs to the modelling process. The model was then used to instantiate the three different non-nominal situations that were also investigated by the project.

AUTOPACE scope was mainly built around the impacts of automation in terms of workload and the need for changes in training contents and approaches. Regarding workload, as outlined by Cañas et al. (2018), the potential impacts of both overload and underload were considered. From the perspective of FRAM instantiations, conditions of both cognitive underload and overload could be at the source of different forms (and most likely, amplitudes as well) of variability in the output of the functions that are carried out by the human operator. As one of the foundations of FRAM, functional variability was placed at the core of the work presented, but their potential sources, such as cognitive underload or overload were not discussed. The psychologic modelling (AUTOPACE 2017a) activities carried out by AUTOPACE supported the investigation of both cognitive overload and underload conditions, namely under the scope of the “Malleable attentional resources” theory (Young and Stanton 2002). The different conditions of cognitive underload and overload, as well as the operational impacts that were hypothesised by AUTOPACE, were not discussed within the scope of the work presented.

The first contribution of the FRAM based work to the project consisted on enhancing the description of actions described under the typical traffic situations by considering them beyond the single focus of human activities. FRAM analysis built on these typical situations to develop an integrated model of human, technical and organisational operational elements. Table 1 provides a description of the functions modelled through FRAM. The identified functions were then verified by AUTOPACE project team and subject matter experts, in order to ensure their validity in terms of real ATC operations.

Table 1 description of FRAM functions
Full size table

The model developed is illustrated in Fig. 3. The focus is set on functions that are carried out by the human operator under scenario E2. These are given in blue, and technological functions are shown in green. The reproduction in the paper of a readable illustration of the model was not possible. Despite this, Fig. 3 clearly underlines, on the one hand, the complexity of ATC operations, and on the other hand, the strong prevalence of human functions that can be expected still under the medium automation scenario E2.

Fig. 3
figure 3

FRAM model of ATC under scenario E2 (medium automation)

Full size image

The representation given shows all the potential couplings between functions, as given by the FMV. However, it should be kept in mind that these couplings only become effective when the model is instantiated. The analysis of instantiations and functional variability should be steered by the objectives based on which the modelling activity was initially considered necessary, or by the questions to which answers are expected to be achieved through the FRAM analysis approach being undertaken (Hollnagel 2012a). There are no real limitations to the number or type of instantiations that can be performed from a FRAM model. Applications of FRAM can range from the hindsight analysis of events and the pursuit of more in-depth understanding of complex causality relations, to the foresight investigation of systems and operations design requirements, among many others. For instance, AUTOPACE project gave particular emphasis to the investigation of conditions of cognitive overload and underload. These would likely produce meaningful variability of some function outputs but were deemed out of the scope of the present study, as the focus was set on the functional changes emerging from the increased presence of automation. Aiming to further enhance AUTOPACE project outputs, the instantiations performed and discussed in this paper focused on the investigation of changes in the relations between the human operator (the ATCo) and the changing technology, in particular how decision-making processes as a critical ATC feature may be impacted by the foreseeable transformations.

The two automation scenarios and the different non-nominal situations explored in AUTOPACE were investigated based on the instantiation of the FRAM model. In line with what is described by Hollnagel (2012a), operational variability should be investigated by considering the quality and timing of function outputs under the given instantiations. The instantiations lead to consider how function couplings and the operational conditions under which such couplings become effective, may generate changes in the type and amplitude of variability of function outputs. Using “normal” operations as a baseline for comparison and in line with AUTOPACE scope, two different sets of operational conditions were investigated as potential sources of changes in the variability of function outputs:

  • Changes in the nature of functions, such as the introduction of new ATC technologies where for instance, a given human or organisational function would become a technological function.

  • The failure of operational elements, namely ATC technology (non-nominal situations as described above), where some functions would have to be carried out by the human operator, rendering their output more variable or potentially unavailable.

The instantiations of the model were initiated by considering the “entrance of new traffic into the sector” as a starting point. This amounts to defining a given set of functions in the model as the foreground on which the analysis will be focusing. Other starting points were used for instantiation whenever initial findings indicated relevant issues to be explored by shifting the focus in the model to a different foreground.

4.1 Increased automation: from scenario E2 to scenario E1

Figure 4 illustrates the functional impacts of increased automation by comparing changes between scenarios E2 and E1. In addition to the green and blue colours previously used, the functions which are expected to be impacted by the enhanced automation to come into place as a result of the implementation of scenario E1 are shown in red colour. These are functions that will cease to be performed by the ATCo and are thereon performed by automated systems. The function “Negotiate solution” (shown in orange), is expected to remain as a human one but profoundly transformed, as solutions are no longer provided nor decided by the human ATCo. This is expected to rely on override capabilities that are granted to the human operator. From the list given in Table 1, the functions that are expected to become automated (in red) are:

Fig. 4
figure 4

FRAM model illustrating changes from medium to high automation scenario

Full size image

  • Modify data

  • Contact with traffic

  • Contact from traffic

  • Evaluate inbound traffic

  • Evaluate outbound traffic

  • Evaluate solution

  • Decide solution

  • Assume traffic control

  • Release traffic

  • Issue instructions

  • Coordinate with other controllers

Figure 4 illustrates the significant impacts of the enhanced automation foreseen under scenario E1. The participation of the human operator is withdrawn at 2 critical operational levels:

  • Traffic control decision making becomes fully automated, leaving only to the operator access to its outputs. In line with AUTOPACE ConOps and as shown in the FRAM model, the ATCo is only given access to the updated traffic information and conditions and has no knowledge regarding the decision processes or options that may be at the source of such updates. This may become particularly critical when having to monitor system performance and assess the automated solutions implemented, whilst having limited access to the structure and criteria that supports such decisions.

  • Direct communication with other controllers and with traffic becomes much more restricted. According to AUTOPACE ConOps, communication will take place via data link and, as illustrated by the FRAM model, no regular contact between traffic and ATCo is foreseen. Not only the need for such contacts is limited, but also, when needed, the information to support communication is also reduced. Communication with local traffic management (LTM) in the scope of de-complexing solutions still occurs, however solutions will be prepared, assessed and implemented through automated processes. Also, in this case, the ATCo is only provided with information on the changes to conditions resulting from the implementation of new or updated de-complexing solutions, rather than details on the solution itself.

When comparing Fig. 3 with Fig. 4, the potential couplings between functions are considerably shifted. In particular, when considering “traffic information”, while under scenario E2 this resource is obtained by the ATCo through the function “Perform traffic surveillance”, under scenario E1, because the process becomes automated, “traffic information” is considered as data integrated with the issuing or updating of traffic solutions (through function “Issue solution”). This means that the “traffic information obtained” by the ATCo as an output from “Perform traffic surveillance” is likely to differ from traffic data issued with the solution by the system, as between the two various ATC automated processes are developed and therefore, these function outputs may potentially be produced within considerably different timeframes and under different operational settings.

Figure 5 shows a FRAM instantiation using “Issue solution” as a starting point (shift of focus to a different foreground). This further elaborates on the changes in function couplings and supports the previous findings in terms of potential operational impacts. The numbers given in each function indicate the foreseeable sequence under which functions would be carried out. The numbering of functions indicates the sequence in which they are expected to be carried out.

Fig. 5
figure 5

Instantiation of FRAM model for solution issuing, evaluation and approval

Full size image

The red dashed lines in Fig. 5 indicate couplings that may become compromised, as information flows are profoundly transformed by the automation of a considerable number of functions. The ATCo only receives information from automated processes when traffic data and situation are updated. The timing and pace at which the ATCo may carry out the supervision of traffic and system functioning, is likely to be misaligned with the timings and pace at which the system produces, evaluates and implements solutions. Therefore, the conditions and evaluation criteria that is used by the ATCo may also differ from the ones based on which the system is issuing new solutions.

4.2 Non-nominal situations

As earlier described, three different non-nominal situations were under investigation within AUTOPACE:

  • Situation 1: Conflict detection and resolution fails

  • Situation 2: Complexity management system fails

  • Situation 3: System supported coordination fails

The analysis of non-nominal situations was based on both automation scenarios. However, keeping in mind that the three non-nominal situations under investigation are based on systems failure, emphasis was placed on scenario E1 (high automation). This option was further supported by the fact that risk analysis carried out within AUTOPACE has foreseen more significant impacts of non-nominal situations under fully automated ATC (Netjasov et al. 2017).

Instantiations of the FRAM model were produced in line with what was previously described for the analysis of increased automation (from scenario E2 to E1). The figures shown in the following sub-sections use the same colour coding as the one shown in Fig. 4.

4.2.1 Conflict detection and resolution failure

Conflict detection and resolution is at the core of ATCo activities and where task complexity primarily emerges (Boag et al. 2006). Figure 6 shows an instantiation of the FRAM model under conflict detection and resolution failure and focuses on the decision making process that produces solutions for conflict resolution. In addition to the colours used in Fig. 4, the yellow colour was here used to indicate functions that may be significantly impacted under this non-nominal situation. Because in this case solutions are no longer “issued” in the same way as it is defined in the FRAM model, function “Issue solution” was renamed in Fig. 6 as “Produce solution”. As in Fig. 5, the numbers given in each function indicate the sequence in which functions are expected to be operating.

Fig. 6
figure 6

Instantiation of FRAM model for conflict solution process under conflict detection and resolution failure

Full size image

Under nominal situation, traffic solutions are issued and merely its implementation has to be verified by the ATCo, in this failure case, traffic solutions have to be submitted to non-automated verifications and validations against critical safety and operation parameters. Functions “Prepare solution” and “Decide solution” will potentially be profoundly changed in terms of process (aside from other factors and performance conditions not under analysis here), as reaching a conflict resolution solution is likely to become a much more iterative process. The iterative nature that may emerge within the solution decision making process is illustrated in Fig. 6 by the red coloured numbering in the functions that will be carried out more than once within the same instantiation. These functions are:

  • Perform traffic surveillance (1, 6 and 9)

  • Evaluate traffic situation (2 and 7)

  • Decide solution (5 and 13)

  • Evaluate inbound traffic (8 and 10)

According to this instantiation, the traffic solution produced by the ATCo is iterated as parameters are checked or as traffic situation may change, while the decision making process to reach a suitable solution is ongoing. Functions “Perform traffic surveillance” and “Evaluate of traffic situation” are at the core of the multiple verifications needed to reach a solution for conflict resolution. The output of these functions act as fundamental controls and resources for the majority of the remaining functions. These outputs are highlighted in Fig. 6 with bold black continuous and dashed lines respectively.

On the one hand, the continuous “traffic surveillance” is needed to acquire updated traffic information. On the other hand, while needed under nominal situation to support system monitoring, under this non-nominal situation the “Evaluation of traffic situation” (or its re-evaluation) becomes critical to ensure process control throughout. This means that the ATCo must continuously acquire traffic information and assess its potential consequences for overall traffic situation, whilst pursuing anticipated (as much as possible in planning phase) conflict resolution. As complexity increases in traffic situation, a greater monitoring load is imposed on the ATCo and conflict decision making becomes more focused on expedient solutions, as opposed to efficient ones (Fothergill and Neal 2008). As expedient solutions become favoured, mismatches between traffic situation and the solutions being implemented may increase and lead to an increased need to iterate conflict resolution solutions. Therefore, this process is likely to become increasingly iterative, as traffic situation also becomes more complex, which in line with Bainbridge (1983), raises two fundamental issues:

  • The ability to acquire and process traffic information at the necessary pace, so as to produce timely traffic solution updates.

  • The ability to update traffic solutions in such a way that traffic information and situation remain coherent with parameters of proposed solution.

ATC is becoming increasingly strategic in conflict resolution, as opposed to tactical interventions. Automated systems are expected to more efficiently anticipate issues related to traffic complexity and variability, and accordingly adjust de-complexing solutions, which is then expected to reduce the need for tactical intervention from both the automated systems and the ATCo. Thus, assuming complexity management systems remain fully operational under conflict detection and resolution failure, automated systems may be expected to adjust de-complexing solutions within a timeframe that minimises the impacts of these issues previously mentioned.

4.2.2 Complexity management system failure

Complexity management is primarily a strategic process, under which preventive actions in terms of air space management and aircraft separation are taken (Prandini et al. 2011). As ATM complexity increases, the importance of this strategic and preventive process tends to increase, as such degrees of complexity cannot be effectively managed within the constraints and limitations of a tactical scenario (Prandini et al. 2011; AUTOPACE 2016). Hence, one of the key roles of automation is to effectively anticipate deconfliction needs at a strategic level and reduce to all possible extent the need for tactical solutions. Under current ATC arrangements, strategic and tactical solutions are kept separate under the responsibilities of different elements of the ATC team.

Figure 7 shows an instantiation of the FRAM model for the process of producing de-complexing solutions under complexity management system failure. Similar to the instantiation in Fig. 6, functions “Perform traffic surveillance” and “Evaluate of traffic situation” remain critical both as a resource and as a control. Thus, issues related to decision making processes within the scope of traffic situation assessment and supervision remain potentially relevant in this case. As earlier described, functions automated under scenario E2 are shown in red. The yellow colour is used to indicate the function that under this non-nominal situation would be failing (produce de-complexing solution).

Fig. 7
figure 7

Instantiation of FRAM model for the issuing of de-complexing solution under complexity management system failure

Full size image

De-complexing solutions would become “human-based”, which is expected to profoundly change operational processes and requirements. The thicker lines in Fig. 7 illustrate downstream automated functions that are coupled to the failing function “Produce de-complexing solution”. These couplings are likely to be considerably tight (with little tolerance for variability), as “evaluating” and “deciding” on solutions typically occur under considerable time pressure (Djokic et al. 2010). Given that the ATCo is required to take over the failed function (Produce de-complexing solution), the variability introduced may potentially exceed the capacities of downstream automated functions, namely “evaluate solution” and “decide solution”.

The specific process and context under which functions “coordinate with other controllers” and “negotiate solution” will be carried out remains particularly unspecified. These were also not in the scope of AUTOPACE focus and therefore, also not addressed in more depth in the scope of this work. Despite this, the following two observations support the assumption that these two functions may be more loosely coupled in this process, and therefore allow for increased flexibility and adaptability to changing ATC conditions:

  • If operational priorities change and the execution of these two functions must be deferred in time in favour of more critical ATC needs (Kontogiannis and Malakis 2013), the quality of their outputs are not necessarily compromised, nor does that imply immediate degradation of traffic situation.

  • As anticipated by AUTOPACE (2016), function “coordinate with other controllers” is likely to remain supported by a Local Traffic Manager (LTM), in which case, the execution of this function may rely on a broader and more adaptive range of available resources.

Hence, lower time pressure and constraints are likely to be experienced in the performance of functions “coordinate with other controllers” and “negotiate solution”. These potentially looser couplings are illustrated in Fig. 7 with dashed lines.

The red coloured lines in Fig. 7 highlight function couplings through which the process feeds back on itself. This amounts to what Leveson (2004) describes as a “multi-loop” control. This loop is initiated as frequently as de-complexing solution changes (function “Produce de-complexing solution” is activated). Under nominal operational conditions, this might be with relatively low frequency but when systems failures occur, reducing traffic complexity becomes imperative and various iterations of this loop are likely to occur until a de-complexing solution matches local conditions and needs.

Under the scenario here analysed, in which the failure directly affects the production of de-complexing solutions, this is particularly critical. The time window between the production and implementation of a de-complexing solutions at a strategic level, and the management of inbound traffic at a tactical level, may be significantly reduced, as a consequence of this failure. The need to revise de-complexing solutions may challenge the effectiveness of the management of inbound traffic. The support of additional ATC resources such as the LTM are likely to become critical in this scenario.

4.2.3 System supported coordination failure

Despite promising developments and successful testing of a sector-less concept (Rivière 2004), the envisaged future for automation of ATC remains grounded on a sector-based approach. The use of “data link” communications is however planned to progressively replace all other types of communications (European Commission 2009).

The failure of system supported coordination may potentially have widespread impacts on operations, as function “coordinate with other controllers” is coupled to many other functions in the model. It provides important inputs and resources to many other downstream functions and also receives input from other upstream functions, which critical to ensure coordination with other controllers. The function is more or less directly involved in many different ATC processes. Figure 8 highlights inputs and outputs of function “coordinate with other controllers”. Inputs from upstream functions are indicated with thicker full lines and outputs to downstream functions with dashed lines.

Fig. 8
figure 8

Instantiation of FRAM model for system supported coordination failure

Full size image

Two main types of processes can be identified as critical:

  1. 1.

    Ensuring adherence to de-complexing solution: the coordination with other controllers is required when changes are made to de-complexing solution or when a coordination warning is detected. In both cases, inputs from other upstream functions must be provided to function “Coordinate with other controllers”, so that processes may be carried out.

  2. 2.

    Verifying inbound/outbound traffic conditions: in both these cases outputs from function “Coordinate with other controllers” must be provided to other downstream functions, so that processes may be carried out.

The failure of a coordination system does not necessarily lead to the failure of the function itself. Although few details are yet known regarding the design and operation of these future systems, the need for redundancy features will most likely be taken into account. Even when planned automated and data link based systems are fully deployed, conventional communications are likely to remain available as backup systems, among other possibilities. This means that function “Coordinate with other controllers” may still operate under a degraded mode.

Ensuring the continuity of operations under this non-nominal situation will be closely related to the ability to manage these two types of critical processes and the couplings highlighted in Fig. 8. As earlier noted, reducing the complexity of traffic becomes critical when faced with a degrade mode of operation. Under system supported coordination failure, the ATCo is likely to be unable to manage the same volume of inbound and outbound traffic as the automated system would do under nominal conditions. The automated acceptance of inbound traffic and the handing over outbound traffic may remain operational but the coordination with other controllers that is needed to carry out these processes would rely on the ATCo. On the other hand, changes to de-complexing solution may be needed, which in addition to the failed system coordination support, also relies on other foreseeably automated functions, namely functions “evaluate solution” and “decide solution”. Two fundamental requirements can be drawn from this:

  • The automated functions that are not directly impacted by the failure of the system supported coordination are capable of operating independently.

  • These automated functions are designed with degrees of flexibility, so as to cope with the shift from an automated input from other automated functions, to operating with inputs provided directly by the ATCo.

Although not made explicit in Fig. 8, similarly to previous cases, the resources needed by the ATCo to perform adequate system and operation supervision may also be compromised. In case of system supported coordination failure, the ATCo monitoring capabilities would also be hindered by the absence of system-based coordination warnings (as an output of function “issue warning” shown in colour green in Fig. 8).

The possibility of function “coordinate with other controllers” being supported by the continuity of the role of LTM may also facilitate coping with system failure. However, it should be kept in mind that the failure of system supported coordination is likely to impact simultaneously on multiple ATC stations or posts, and that this in itself may be the source of other critical operational issues.

5 Discussion

Scenario E1 contrasts with scenario E2 in terms of the continuity of information flows. Traffic information is a critical resource for most functions. Under scenario E2, the ATC is required to actively supervise traffic and system functioning, in order to develop the decision making processes that support the issuing, evaluation and approval of new traffic solutions (Zeleny 1981). The ATCo is able to produce the feedback loops that are fundamental as a continuous control and adjustment mechanism of decision making processes (Leveson 2004). The prompting of the ATCo with different options for traffic solutions and requiring approval renders uncertainty associated with decision making processes more explicit. Because this process will be carried out at a strategic level, when having to confirm to automated system a choice for a traffic solution to be implemented, the ATCo is led to consider the uncertainty associated with each solution proposed in terms of its future implications for traffic situation. This interaction with automated systems may be related to the “speaking up” that Grote (2015) describes as an example for “promoting safety by increasing uncertainty”. Not only it supports a more thorough evaluation of solutions, but it may also support a more discretionary discussion amongst ATCos relating to solution parameters or traffic situation.

Under scenario E1, the ATCo is not expected to have direct access to the issuing of new solutions (it becomes an automated process). The supervisory responsibility that is attributed to the ATCo becomes an independent decision-making process that must be carried out in parallel to system operation. The ATCo must monitor system performance and assess the automated solutions implemented, whilst having limited understanding of the algorithms, rationale and criteria that support such decisions. Also, in this case, the ATCo may only be provided with information on the changes to traffic conditions resulting from the implementation of new or updated de-complexing solutions, rather than details on the solution itself.

As noted by AUTOPACE (2017b), the supervisory and take-over capabilities that are foreseen under scenario E1 can only be ensured if the ATCo maintains current competences and skills (regardless of additional ones that may be required). Supervising system operation supposes that the ATCo is capable of understanding the traffic solutions the system is implementing and match it to the interpretation of traffic situation. This was described in the scope of the AUTOPACE ATCo psychologic model (AUTOPACE 2017a), based on the general cognitive model proposed by Histon & Hansman (2008). AUTOPACE further hypothesises this as a potential source for the degradation of situation awareness and the emergence of the “out-of-the-loop” effect (Endsley 1995). Mismatches between demanded and available resources allocated to ATC tasks are also put forward as sources of either cognitive underload or overload conditions, which may act as additional contributing factors to the degradation of ATCo performance. Further research should then be devoted to investigating the extent to which, under “acceptable” conditions of cognitive load, may the ATCo be able to cope with the new demands that are generated by automated processing of traffic solutions. It should also be kept in mind that the assumption that cognitive workload conditions may be suitably monitored and controlled is yet to be acceptably demonstrated (Cinaz et al. 2013). Figure 5 only illustrates the process of issuing, evaluating and approving new solutions, as an example of situations where ATC automation may produce profound impacts. Similar ones are likely to occur at other operational levels.

The analysis of non-nominal situations underlines challenges that may emerge from increased variability and uncertainty in ATC. System failure is likely to lead to rapid and significant increases in traffic complexity. The highly interdependent and non-linear nature of ATC operations, that is illustrated by the FRAM model previously described, may lead to cascading effects that rapidly impact across many other functions beyond those affected by the failures and those directly involved in the ATC processes that characterise the non-nominal situations considered here.

The failure of automated features naturally poses increasingly challenging problems. Under current ATC scenarios, despite the already increasing presence of technology and automation features, the major role that the ATCo still plays facilitates the handling of degraded operational modes. As automation increases and the participation of the ATCo reduces, the notion of “graceful extensibility” (Woods 2015) becomes ever more critical. From the analysis carried out, the following aspects can be highlighted as key contributing factors towards embedding adaptive capacities (Woods 2015) into the design of future ATC systems and operations:

  • Despite the strong interdependency between functions, namely through the intensive sharing of resources (i.e. traffic information) and controls (i.e. evaluation of solutions), automated features must be autonomous to the extent that they may be independently kept operational under highly variable conditions. Automated systems must be capable of flexibly adjusting to inputs with significantly variable timings and perhaps even variable degrees of precision, namely those being provided by other automated features and those provided by the ATCo and under a wide variety of operational conditions, including non-nominal situations. Kontogiannis (2010) proposes adaptive planning principles that take into account the need to continuously re-plan and adjust functioning to highly dynamic working contexts. This can only be achieved if automated systems are flexible enough to effectively support the ATCo in implementing have adaptive strategies.

  • Human operators cope with local conditions by making proximate adjustments that at different levels, trade-off between factors contributing to operational efficiency against those contributing to safety in general. Hollnagel (2009) describes this as the efficiency-thoroughness trade-off (ETTO). Vanderhaegen and Jimenez (2018) address these trade-offs from the perspective of dissonances emerging from human, organisational or technical factors. In the context of decision making, Simon (1955) considered the inherent human cognitive limitations under the concept of bounded rationale. ETTOing becomes inevitable, as operational conditions are always underspecified and resources (i.e. time) are always limited (Hollnagel 2009). Under non-nominal situations, operational uncertainty tends to increase, which renders these local adjustments more likely to occur. This means that variability in the output from functions is also likely to increase and may be self-reinforced, as the variability of function outputs is consecutively amplified by the increasingly variable (and uncertain) input provided by upstream functions.

  • ATCos must be trained in such a way that they may, not only retain and build on current expertise, but also enhance it with knowledge and understanding regarding the operation of automated systems. As the primary focus of the project, AUTOPACE (2017b) establishes contents and approaches that aim to respond to both technical and non-technical requirements for future ATCo training programmes. In addition to technical and cognitive elements, this includes enhanced non-cognitive aspects that aim to foster increased capacity to cope with uncertainty and highly variable operating conditions (Corver and Grote 2016).

  • The ATCo’s participation in processes must follow a careful long-term plan for automation, so as to avoid at any stage of development and transformation of ATC operations, leaving the ATCo with some “arbitrary set of responsibilities” that do not provide a consistent participation in decision-making processes (Bainbridge 1983), both under nominal and non-nominal situations. As earlier observed, the envisaged roles of supervision and approval of solutions rely on feedback and control loops that must be ensured at all times and under multiple different scenarios of human–machine cooperation. In the scope of what Christoffersen and Woods (2002) define as observability and directability, automated systems must be designed in such a way that the ATCo is capable of perceiving and understanding every step of the automated processes, to anticipate the traffic situation that they are likely to produce in the future (observability), and act accordingly in the most seamless way possible (directability).

6 Conclusions

The approach discussed in this paper is bounded by its scope of application within project AUTOPACE. A wide range of issues are yet to be addressed in the pursuit of the envisaged ATC long-term goals. As more detailed information on systems and operations design becomes available, further in-depth analysis of factors is needed. Like project AUTOPACE itself, this work constitutes initial exploratory research that must be further detailed to support the clarification of problems and offer precise steering for design solutions. The findings outlined in this paper should be further supported by a more precise assessment of human, organisational and technical factors, namely through the use of other types of research methods. The “openness” of FRAM provides ample opportunities for the combination of FRAM analysis with multiple other types of tools and approaches (Patriarca et al. 2017a; Tian et al. 2016, among others), thus enabling the analysis of specific problems whilst maintaining an overall sociotechnical system perspective. The FRAM model developed can be reiterated and improved in terms of its granularity and provide further support on potential issues emerging from interdependency and complexity. AUTOPACE produced hypothesis on how the relation between available resources allocated to ATC tasks and the resource demands imposed by these tasks may change under different psychologic conditions. Future research may further investigate and validate these hypotheses, which can then be brought back to the FRAM model here presented, to investigate specific operational conditions, in view of different ATCo capacities and behaviours.

The work described assumes a qualitative and exploratory nature. As a tool targeted at improving the understanding of complex systems, FRAM aims to avoid the oversimplification and the quantification of ill-known variables, which could easily erode its founding principles. Patriarca et al. (2017b) have recently provided valuable contribution towards facilitating the interpretation of FRAM models and extended its potential with the production of statistical outputs based on the “myFFRAM” application (This may contribute to overcome the current difficulties in reading complex FRAM models that is made apparent in this paper). Quantified aspects such as risk and reliability assessment are fundamental within any suitable safety management approach but, as complexity increases operational scenarios tend to assume increasingly non-linear behaviours, which requires an understanding of such scenarios far more elaborate than the linear cause–effect relations that are frequently the single focus of risk management (Tian et al. 2016).

The analysis carried out demonstrated the usefulness of FRAM in building the level of operational understanding that is needed to then better steer risk management activities. Automated systems, ATCo and organisational features can be investigated in terms of their resource needs and conditions of operation, taking into account operational interdependency and variability. More importantly, beyond a purely graphical model of ATC, FRAM generates a learning process that can support change control processes, in anticipation of the technological transformations to be introduced into ATC operations. Understanding the impacts of automation throughout different operational sequences and contexts becomes critical to produce meaningful and precise guidance for the future of automation in ATC.

Recent technologies, namely those based on virtual reality, provide the means to produce powerful simulations of complex scenarios such as those of future ATC operations (Burdea and Coiffet 2017). However, not only such resources require substantial investments and development work, but more importantly they remain grounded on the formal assumptions of formal systems design and operation and of human performance. Research approaches are inevitably bounded by the characteristics and limitations of the tools applied.

FRAM is often referred to as a “model without a model”, as it takes on no pre-assumptions on what should be modelled, how it should be labelled and at what level of details and granularity (Dekker and Hollnagel 2004). This was particularly meaningful in the context of the research, as the purpose was to explore high impact and profound operational changes in ATC. The learning process that FRAM supports builds on the understanding of real work and focuses on the variability that emerges from highly interdependent operational elements that tend to be underestimated by many systems and operation design approaches. This is often the case as risk assessment activities that input such design approaches investigate risk items as isolated features that emerge from linear causality chains. In the continuity of AUTOPACE work, FRAM can provide a fundamental system framework on which the simulation activities carried out can be integrated and further expanded.

Increased automation seems to be the only viable path towards delivering the capacity growth that is envisaged for the aviation industry. It is, however, not without generating new challenges that emerge from the need to cope with complexity (Hollnagel 2012b; Flach 2012), many of which have long been described in different domains of literature, namely under the scope of joint cognitive systems (Hollnagel and Woods 1983). It is increasingly recognised that addressing such challenges requires tools that take into account high variability and uncertainty. Sociotechnical systems respond to human-based purposes, which far extend beyond the efficiency criteria that tend to prevail in the design and implementation of technology (Bainbridge 1983). Focus must shift from the streamlining of processes, towards recognising the inevitable need to cope with variability and uncertainty, as they are the means through which complex human endeavours can be achieved. No other element in a system copes better with variability and uncertainty than the human. Technology should, therefore, be addressed as additional resources to cope with increased system capacity, as opposed to a replacement of human resources.