# Toward a Human Systems Integration approach to the design and operation of a remote and virtual air traffic control center

Alexandre Disdier, Dimitri Masson, Thomas Brethomé, Marija Jankovic, Guy-André Boy

► To cite this version:

Alexandre Disdier, Dimitri Masson, Thomas Brethomé, Marija Jankovic, Guy-André Boy. Toward a Human Systems Integration approach to the design and operation of a remote and virtual air traffic control center. 24th International Conference on Engineering Design (ICED23), The Design Society, Jul 2023, Bordeaux, France. pp.3561-3570, 10.1017/pds.2023.357. hal-04064881

HAL Id: hal-04064881

https://hal.science/hal-04064881

Submitted on 11 Apr 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Toward a Human Systems Integration approach
to the design and operation of a remote and
virtual air traffic control center

Alexandre Disdier¹,²,³, Dimitri Masson⁴, Thomas Brethomé³,
Marija Jankovic¹, and Guy-André Boy¹,²

¹Paris Saclay University, CentraleSupélec, LGI, 9 rue Joliot Curie,
91190 Gif-sur-Yvette, France

²ESTIA Institute of Technology, 90 allée Fauste d'Elhuyar,
F-64210 Bidart, France

³CS Group, 22 Avenue Galilée, 92350 Le Plessis-Robinson, France

⁴Bordeaux University, ESTIA Institute of Technology, 90 allée Fauste d'Elhuyar, F-64210 Bidart, France

Abstract

Remote and virtual centers have been studied for the past twenty
years as an alternative to the traditional air traffic control tower environ-
ment. Designing such complex sociotechnical systems requires a systems
engineering approach that appropriately integrates the human element as
well as the technological and organizational components. In this paper,
we identify the challenges of implementing this human-systems integration
in the design of complex systems. We present the feedback we obtained
from a series of semi-structured interviews with people involved in the
development of military air traffic solutions. The participants' responses
helped us establish methodological guidelines for designing and building
a disruptive remote and virtual air traffic control center. We discuss how
virtualized human-in-the-loop simulations in particular should help de-
signers analyze user activity and be more flexible in system acquisition.

***Keywords***— Human Systems Integration, User centred design, Remote tower operations, Simulation, Participatory design
# 1 Introduction

The increasing complexity of sociotechnical systems demands new approaches to Systems Engineering (SE) that no longer focus solely on technology but also consider people as a central element. Human Systems Integration (HSI) is one of these approaches. HSI is an interdisciplinary field that seeks to integrate technology, organizations and people throughout the entire system life cycle in order to achieve better overall system performance and minimize costs. The consequences of an improper integration of human and organizational elements into the design, development, deployment and operation of a complex system are twofold. On the one hand, it generates operational issues such as poor system performance, lack of trust from operators in the system and more generally system failure to meet its primary goals. On the other hand, it also affects designers and developers themselves since it may lead to improper design decisions, which in turn may cause tedious and costly redesigns of the system.

Air Traffic Control (ATC) towers, from which controllers must inspect the tracks and their surroundings to give a comprehensive picture of the airspace situation, are complex sociotechnical systems. The successive European SESAR partnerships (Bolic and Ravenhill, 2021) seek to develop alternative control paradigms to reduce tower life cycle costs, ease traffic flow, and mitigate the environmental impacts of air traffic management. Remote and virtual air traffic control towers, which allow for air surveillance from a distant center located outside the airfield, are being studied today as a viable cost-reducing air traffic control model. Such systems are heavily human-oriented by nature. Consequently, their design, development and operation may benefit from an HSI approach which considers and integrates every stakeholder's concern. However, HSI methods and tools are still in heavy development, and there is a need to understand better how current SE processes can be adapted to integrate the human element into system design.

In this paper, we derive a series of critical HSI research issues that should be addressed to help create and sustain complex sociotechnical systems. We conducted a series of semi-structured interviews with employees of an industrial company specialized in the design, integration and operation of critical systems primarily aimed at the defense and cybersecurity domains. Most interviewed participants are involved in developing air traffic control solutions in partnership with the French Airforce. We asked them a series of general questions about how they implement SE within the company and the amount of care given to human and organizational elements in the SE processes currently in place. We leverage the research issues that we drew from their answers to understand how we may define a more human-centered approach to creating and operating a virtual air traffic control system.

The remainder of the paper is structured as follows. Section 2 gives a quick overview of the field of HSI and states the general problem of remote air traffic control. Section 3 describes the method we applied to identify the key characteristics of today's implementation of SE within the target industrial company. Section 4 presents the results we obtained and draws from them a list of key identified SE concepts that give room to a better human-centered approach. Section 5 presents the research gaps stemming from the derived concepts and discusses how we could apply an HSI approach to the design of a virtual air traffic control system. Section 6 concludes the paper.
### 2.1 Human Systems Integration (HSI)

HSI is an effort that strives to provide a set of methods, tools and processes as part of a wider SE approach to ensure that humans, organizations and technology are integrated in a cohesive manner into all stages of a system life cycle (Boy, 2021). In HSI, the human element is considered as being another component of a system along with traditional software and hardware components. The term "human" in HSI refers to all personnel involved with a given system, including not only end-users, but also owners, designers, test personnel, operators, maintenance personnel, support personnel, logistics suppliers and training personnel.

Adopting an HSI approach involves defining the critical human-related areas that need to be correctly interrelated and integrated to achieve better system and operator performance. These areas, referred to as HSI domains, are project-specific and must be carefully defined at the very beginning of each project. For instance, NASA (2021) specifies six HSI domains: Human Factors Engineering (HFE), Operations, Maintainability and Supportability, Habitability and Environment, Safety, and Training. Other institutions, such as the Department of Defense and the US Air Force (US Air Force, 2009), may define slightly different HSI domains according to the purpose of their projects (e.g. Manpower, Hazard Management or Environment). Nevertheless, some common HSI domains such as Human Factors remain at the heart of the quality execution of an HSI effort. The key to implementing HSI is properly defining and analyzing the trade-offs between these domains at the beginning and during system development.

HSI results from the combination of Human-Centered Design (HCD) and SE. It is particularly suited to the design and operation of complex systems, including systems of systems. Complexity in this case stems from the many interactions between the interconnected parts of a system, resulting in unanticipated emergent properties (Booher, 2003). This concept of emergence is key to understanding the intricate nature of human activity at operation time.

HSI literature tends to promote Human-in-the-loop simulations (HiTLS) (Rothrock and Narayanan, 2011) as a means to better understand this complexity of human behavior. Indeed, HiTLS may help identify early patterns and behaviors that were not anticipated at design time, capture emergent properties early in the system life cycle and adapt the design accordingly. When adopting a HiTLS approach, the system of interest should be designed as a virtual prototype with which end-users can interact. User activity is then observed and analyzed. The analysis results help the designers refine both requirements and prototype design. Working on a fully or partially virtual prototype makes this refinement phase more flexible and design modifications less costly. After several iterations and once the virtual prototype has been validated, a tangibilization phase should turn the virtual system components into physical components.

There is still a lack of standard tools and frameworks to support such virtual HiTLS. We think there is a need to explore the use of non-conventional ways of doing Modeling and Simulation (M&S) (Loper, 2015) of complex sociotechnical systems. In fact, research regarding M&S has recently expanded to the use of products that were not initially intended for SE. Software like commercial game engines has already been assessed by actors such as the Department of Defense, NATO, Audi, and the maritime sector (Hjelseth et al., 2015). This use of entertainment technology has started to be studied as a support to SE processes under the name of gamification and serious games (Uskov and Sekar, 2014). Madni (2015) states that game engine environments enable the creation of virtual worlds which
aim to improve comprehensibility and transparency between system stakeholders.
This is especially relevant to the goals of any HSI endeavor.

Finally, it should be noted that there are commonalities between the HiTLS
approach described above and research on Digital Twins (DTs) design (VanDer-
Horn and Mahadevan, 2021). Camara Dit Pinto et al. (2021) defines a DT as "a
dynamic representation of a physical system using interconnected data, models,
and processes to enable access to knowledge of past, present, and future states
to manage action on that system.". In fact, the virtual prototype being incremen-
tally improved during HiTLS sessions is also a representation of its final physical
complex system counterpart.

In the remainder of this section, we introduce remote and virtual air traffic control
towers as one example of complex sociotechnical systems that may benefit from
virtual HiTLS.

2.2 Remote and Virtual Towers

A widely adopted air traffic control model today relies on a cab placed on top of a tower, from which a team of operators can visually scan an airfield and its tracks. These operators, referred to as Air Traffic Controllers (ATCos), establish a comprehensive air situation around the tower and interact with other controllers whose roles may differ. The role of a controller mainly determines their missions and the geographical area under their responsibility (Ground ATCos, Departing ATCos, Approach ATCos, Radar ATCos, En-route ATCos).

Since the late 1990s, researchers and industrials have been working on conceptu-
alising alternative air traffic control paradigms (Fürstenau, 2014). The first studies
primarily sought to augment the ATCo's view with optronic devices. For instance,
Fürstenau et al. (2004) tried to superimpose the radar display with the out-of-
window view in order to reduce the amount of time that the controllers' attention
was not focused outside the tower. Research projects after that worked on a more
disruptive air traffic control paradigm. Schaik et al. (2016) tried to remove the
physical tower and replace it with a remote center, potentially located hundreds
of kilometers away, in which a screen wall had been substituted for out-the-
view windows. The screens displayed a video signal from cameras near the target
airfield.

Separating the controlling center from the controlled airfield presents at least two
advantages. First, the absence of a physical tower reduces construction and main-
tenance costs. Second, air traffic service providers may pool their human and
technical resources from several airfields with little traffic into one remote center.
The center is then referred to as a multiple remote center (Papenfuss and Friedrich,
2016). Some air traffic control providers such as HungaroControl, Avinor and
ENAC have already demonstrated the feasibility of remote tower operations in
place of conventional towers (Kearney and Li, 2018).

However, the camera-based remote control model introduces two significant con-
cerns. On the one hand, technological constraints and costs limit its applicability,
as transmitting a video signal from the airfield to the remote center requires high-
bandwidth communication facilities. Furthermore, such heavy equipment may
make the deployment of a remote center lengthy and tedious. On the other hand,
most camera-based remote tower prototypes today only shift the routine air traf-
fic control issues to a remote location. These solutions do not reconsider the role
of the human element within the system. Issues regarding the ATCos’ trust in the
system, focus, situation awareness, fatigue and comfort are not directly addressed.
In particular, the workload is not improved since ATCos still need to continu-
ously inspect the track and its surroundings. Even worse, stress may be increased
because the sole restitution of the air situation around the airfield onto screens
has proven insufficient, as a controller is also sensitive to non-visual cues such as sounds and vibrations (Reynal et al., 2019).

An air traffic control solution is not only a matter of technology and should take into account concerns from a broad spectrum of people. When the system is in operation, these people are primarily ATCos, technicians, maintenance personnel, ground support personnel (both on the remote center and on the airfield), and pilots. Should we now consider the entire system life cycle, the people involved extend to designers, developers, testers, engineers, managers, project supervisors, trainers, manufacturers, suppliers, qualifiers and regulators. External stakeholders may also be implicated, including weather forecast services, fire brigades and rescue teams. All the participants, whether humans, organizations or machines, must cooperate and coordinate efficiently to achieve the two main objectives of air traffic control as stated by the ICAO: prevent collisions and maintain an orderly flow of air traffic.

Therefore, we consider air traffic control systems as complex, life-critical sociotechnical systems of systems. They are life-critical because an unanticipated or poorly managed event may result in severe injury or death. However, anticipating every potential event that may occur before a system is deployed is a difficult task. Since controllers are human, their behavior during operation is also highly unpredictable. As such, an air traffic control system, whether *in situ* or remote, is likely to show emergent properties that may not have been expected during design time. These concerns call for measures to add flexibility. This may refer to flexibility during operations, meaning that the whole system should be able to restructure itself to cope with incidents or unusual events. Nonetheless, this paper focuses on flexibility during system design, meaning that we want to detect these emergent properties as soon as possible, especially before any substantial financial commitment has been made. The subsequent sections provide guidelines for establishing an SE strategy that enables this design flexibility. It does so through the case study of the engineering team that develops the French Airforce's air traffic control systems.

## 3 Research method

We conducted semi-structured interviews with a convenient sample of seven employees from an industrial company that develops and manufactures cyber-protected critical systems in multiple fields (Figure 1).

<table><caption>Figure 1. Profile of the interviewed participants</caption><thead><tr><td>Position</td><td>Field</td><td>Experience within the company</td></tr></thead><tbody><tr><td>Validation Expert</td><td>Air Traffic Control</td><td>10 years</td></tr><tr><td>Developer</td><td>Air Traffic Control</td><td>6 years</td></tr><tr><td>Safety Assurance Expert</td><td>Air Traffic Control</td><td>22 years</td></tr><tr><td>System Architect</td><td>Industrial Engineering</td><td>3 months</td></tr><tr><td>Former Controller and Operational Expert</td><td>Air Traffic Control</td><td>7 years</td></tr><tr><td>Technical Manager</td><td>Air Traffic Control</td><td>1 year</td></tr><tr><td>System Architect</td><td>Space Industry</td><td>1 year</td></tr></tbody></table>

We asked the participants open questions about the nature of their work, the processes, methods and tools that are engaged in each phase of the system life cycle, the types of exchanges they have with the different stakeholders involved in the project, and the opportunities and limitations they see in the way that SE is currently being carried out within the company. We sought to understand through these questions the three broader interrogations that follow:

* Which SE processes, methods and tools, or variants, are currently used within the company to achieve program and project objectives?
* Who are the stakeholders participating in these processes, and what are their relationships?

* Is the human element integrated for each stage of a system life cycle, including concept, specification, design, development, deployment, operation, training, maintenance, support, and disposal?

We taped the interview sessions and manually transcribed the audio records. We then applied a two-cycle coding analysis on the transcriptions, following a grounded theory-inspired approach. (Strauss and Corbin, 1990). First, we extracted verbatim excerpts from the transcripts that we deemed relevant for understanding one of the three interrogations listed above. Each excerpt could be words, groups of words or even entire paragraphs. For each excerpt, we assigned a code, phrased as a claim capturing either a feeling (e.g. "System specification documentation often contains too many details") or a fact (e.g. "Users never interact with the successive system prototypes"). Each of the collected feelings and claims expresses one aspect of how SE is done within the company, whether positive or negative. Multiple excerpts could be assigned the same code. At the end of this step, we obtained 113 codes for a total of 236 verbatim excerpts. A second pass occurred to gather related codes into several clusters. We found that these clusters of code were interrelated: we therefore grouped them into tighter and smaller categories. Two clusters were aggregated into the same category when they shared a common HSI goal or when one had assuredly some influence on the other. We discuss in detail this clustering process as well as the resulting categories in the next section.

## 4 Interview analysis

We identified 35 clusters of codes from the second pass analysis. Each cluster is composed of up to 8 first-level codes. The clusters correspond to categories that help clarify the aspects of current SE processes that may be addressed in order to improve the integration of the human element. We then tried to understand the relationships between these 35 second-level clusters by tagging each of them according to four criteria:

1. **Its relevance to HSI.** Some clusters reflect issues that do not directly relate to a lack of human consideration. Some are a consequence of the poor application of traditional SE standards and processes. Some are not human-related *per se*, but a quality implementation of HSI practices can strongly influence the issues they convey. The remaining clusters are critically human-related as they underscore issues that directly involve users, clients, or the developing team.

2. **Its nature.** We have found that every cluster is a high-level objective, an enabler for achieving a high-level objective, or a challenge for it.

3. **The system life cycle stage it refers to.** We talk here about stages as defined by the ISO 15288 SE Process Model, namely: Concept, Development, Production, Utilization, Support, Retirement (ISO and IEC, 2015).

4. **The HSI domains it relates to.** HSI domains are those defined by the literature, namely: Human Factors Engineering, Operations, Maintainability and Supportability, Training, Safety and Occupational Health, Manpower and Personnel, Sustainability, Habitability, Usability, Comfort, and Survivability (Booher, 2003; US Air Force, 2009; NASA, 2021).

This tagging process enabled us to group and factor the 30 critically or strongly human-related clusters into four categories that we deem relevant to improve the consideration of the people involved in both the utilization and the acquisition phase (Figure 2). The remainder of this section describes each of these categories.
<table><caption>Figure 2. The four categories of absolutely or strongly human-related identified clusters</caption><thead><tr><th>Increase flexibility in the design stage</th><th>Consider post-deployment early</th><th>Engage the right stakeholders</th></tr></thead><tbody><tr><td><strong>High-level objectives</strong><br>Circumvent rigidity of traditional SE models</td><td><strong>High-level objectives</strong><br>Consider maintenance early</td><td><strong>High-level objectives</strong><br>Involve operators</td></tr><tr><td><strong>Enablers</strong><br>Consider several alternative designs</td><td>Consider training early</td><td><strong>Enablers</strong><br>Be transparent for customers</td></tr><tr><td>Develop supporting digital tools</td><td>Ensure steady operational readiness</td><td>Ensure users are projected into the system</td></tr><tr><td>Know when to reconsider decisions</td><td>Ensure system performance in real conditions</td><td>Ensure users trust system data</td></tr><tr><td>Prioritize most needed features</td><td><strong>Enablers</strong><br>Keep documentation focused and short</td><td>Highlight scenario-based design</td></tr><tr><td>Raise frequency of exchanges</td><td>Motivate stakeholders to use documentation</td><td>Keep subject matter expert engaged</td></tr><tr><td><strong>Challenges</strong><br>Late commitments from clients</td><td><strong>Grow an organization-wide culture</strong><br><strong>High-level objectives</strong><br>Sensitize internal teams to SE challenges</td><td><strong>Challenges</strong><br>Out-of-scope client expectations</td></tr><tr><td>Long-term requirement variability</td><td><strong>Enablers</strong><br>Make internal units cooperate</td><td>Subject matter expert varying availability</td></tr><tr><td>Imposed SE constraints and standards</td><td><strong>Challenges</strong><br>Lack of trust on agility from collaborators</td><td>Intermediary stakeholder interference</td></tr><tr><td>Ambiguity on V&amp;V baseline</td><td></td><td>Conflicting views</td></tr></tbody></table>

## 4.1 Increase flexibility in the design stage

Most participants pointed out a substantial rigidity in the system acquisition stage. Participants particularly questioned the V cycle model, which does not encompass the high variability of customer and user needs. One difficulty lies in the fact that the V cycle constrains the engineering team to specify the system deeply before the actual development can start. Since development is delayed, communication with external stakeholders (i.e. customers, qualifiers and end users) is reduced to basic requirement elicitation methods through working groups and e-mail exchanges. Even once some system component has been produced, external stakeholders usually experience passive interaction with it in the sense that they only get a grasp of its features through static PowerPoint presentations and non-interactive mock-ups. We see two downsides to this approach. The first one has to do with active stakeholder engagement, as discussed in section 4.2. The second one is that static communication between stakeholders does not enable the engineering team to analyze user activity in order to refine the elicited requirements and to detect the emerging properties of the system.

As noted in section 2, these emerging properties are inherent to complex sociotechnical systems. They may lead to disastrous impacts on the system, the people around it or its environment. In addition, most interviewed participants vented the frustration they feel when they strive to integrate a particular feature into the system, which eventually gets rejected by the clients even though this feature had been articulated as a requirement from the start. One participant gave the example of a former ATC program requirement that expressed the need for the digitalization of stripping procedures used by ATCos to track the flights under their control area. After 18 months of development, the clients declined the two proposed interfaces as they did not see how those would fit their operational needs. A more flexible approach to design should have enabled the team to detect and circumvent this change of requirement earlier.

## 4.2 Engage the right stakeholders

According to participants' comments, one reported challenge is that clients and system qualifiers impose standards and regulatory procedures on the engineering team. This is particularly true for life-critical systems like ATC solutions which can be operated only once all regulatory assessments have been conducted and the system has received approval for deployment. Several participants considered this issue as problematic: the engineering team activities are tied up to the program or project external stakeholders' will. In our case study, this gets especially concerning when the system qualifier does not contractually commit to early baselines. In other words, only when the system has been fully developed do external stakeholders formally evaluate and approve it. This has caused trouble for interviewed engineers who had to do late redesigns as the system architecture has not been
endorsed yet by the clients. One of the interviewed participants, a former military air traffic controller, also explained that experts like him were encouraged not to work upstream tightly with system developers, since not committing too early on system proposals enabled them to contradict more easily design decisions later on.

The other issue with external stakeholders is their interference to communications with end users. By end users, we mean not only controllers, but technicians, maintainers, pilots, and any person related to system operation. Participants bring this topic as one of the most troublesome issues. Their comments helped us identify and validate the most significant interactions between the high-level stakeholders involved in the Airforce's air traffic control program. Figure 3 shows this organizational model: end users of the air traffic control program are part of the Air Traffic Control Squadron from the Airforce Command. However, the engineering team that works for the company in charge of the implementation deals mainly with the Product Owner, which also funds and qualifies the Air Traffic Control System. The Product Owner does not have expertise in ATC, so they are assisted by the Airforce's Air Warfare Center, comprised of former controllers and air traffic management experts. Therefore, the engineering team does not interact directly with end users, but with their representatives. While his organization is understandable given the vast number of end-users involved, three difficulties emerge: first, the Air Warfare Center controllers no longer exercise, and their requirements may be outdated and out of scope. Secondly, the Air Warfare Center has teams that rotate, so people that expressed the need at the beginning of the system life cycle are rarely the ones who will participate in the validation process. One participant stressed that in this regard, working with institutions with no intermediary validation team has proven much more efficient as engineers worked directly with permanent personnel who still use the system. Thirdly, since the qualifier has the final word on system approval, it may be perceived as a burden to system development as it may contradict end users' real concerns.

<figure><img src="image_2.png" /><figcaption>Figure 3. Stakeholder organizational chart of the French Airforce ATC tower program</figcaption></figure>

As we have just seen, actual system users are not always directly involved during acquisition. Furthermore, when they are, they may have trouble propelling themselves in the future since the system has yet to be developed and integrated, resulting in a lack of understanding between stakeholders. This last point raises the issue of user engagement. As noted earlier, interactions with user representatives are heavily passive. In addition to the lack of feedback on user activity, static exchanges do not allow users to project themselves into the future and adequately
get a mental model of the system, its operational context and its environment. We
discuss in section 5 how HiTLS can also improve stakeholder engagement.

4.3 Consider post-deployment early

The engineering team should consider how the system will be supported, man-
aged, and eventually dismantled from the early stages of the system life cycle.
In this regard, interviewed participants have mainly expressed concerns about
maintenance and documentation. Documentation content too often lack relevant
information or, on the contrary, is cluttered with unnecessary details. They think
that it would be beneficial, particularly for the maintenance personnel, to have
smaller documentation that goes straight to the point without losing the reader's
focus and attention. They claim that maintenance personnel has no interest in
general terms or trade-off analyses, even though such information can represent
a large amount of the document. Finally, they advocate for a finer decomposition
of documentation, each part being related to one topic only (interfaces, trade-offs,
signatory list, architecture...). All the produced records should then be digitally
centralized not to accumulate too many documents.

4.4 Grow an organization-wide culture

The HiTLS-based methodology we mentioned earlier is highly iterative and builds
upon agile principles. However, some participants expressed their reservations
about agile methods as they are traditionally applied and sometimes even imposed
by customers. They deem agile methods like SCRUM too theoretical as they actu-
ally are intensive for developers and too punitive as the team feels like work is
never finished between two successive sprints, making motivation decline. They
also reported to us that some projects mix highly detailed initial requirements with
agile system acquisition processes, which makes it hard to be clear about which
baseline ultimately serves as the reference for system verification and valida-
tion. Finally, participants were concerned about which hierarchical management
model was best suited to agile development, and how agile methods could apply
to non software-intensive systems containing hardware components that are hard
to redesign or rethink in an iterative manner.

Therefore, there is a need to inspire an HSI mindset among the collaborators and
to reassure them that alternative SE strategies are not only possible but almost
surely needed. Some participants’ answers have also highlighted more high-level
views of what appears to them as the most critical challenges for future systems
SE research. Among the outlined perspectives, one questions the in-house edu-
cation opportunities regarding SE and HSI training of internal teams, including
engineers and developers, but also management personnel, executives and pre-
sales teams. This helps confirm that promoting HSI is a long-term effort that
should emphasize dialogue and cooperation between all stakeholders, including
non-technical ones.

5 Discussion and future research

Some of the outlined challenges mentioned above do not depend solely on the
engineering team: they may stem from organizational complexity, regulatory con-
straints, and even the nature of relationships between stakeholders that may be
tainted by conflicts of interest for financial and political reasons. Nonetheless,
our results provide scope for further development towards a more human-related
SE effort, especially regarding gaining better system knowledge during the acqui-
sition phase. We believe that a framework that combines scenario-based design
(Rosson and Carroll, 2002) with software-intensive HiTLS can improve the
understanding of the human characteristics of the people involved. The follow-
ing example gives some guidelines as to how such a framework could support the
design of a virtual air traffic control center.

The traditional ATC tower cab is typically defined by one or more ATCos with
different roles (ground, approach, apron...), each in front of an operator station
equipped with at least a radiocommunication system, a stripping management
system and possibly a radar display depending on the role. All operators can see
the airfield and its surroundings through the panoramic window. An HSI-driven
virtualization effort should start with a comprehensive task analysis of today's
procedures, methods and challenges of the controller's jobs given different oper-
ational contexts. Let us suppose that we decide to virtualize the landing gear state
verification procedure. When an aircraft is about to land on the track, military
ATCos must double-check that the gear is down. First, the pilot sends a radio or
audible signal to the controller, which the aircraft radiocommunication system
can physically send only if the gear is actually down. One of the ATCos must
then visually confirm through their binoculars that the gear is down. It should be
noted that this procedure was initially designed to be at the pilot's initiative, hence
reducing its stress level by not imposing more pressures and time constraints.

This simple process illustrates a specific allocation of functions. Some are under
the responsibility of humans (e.g. the controller visually checks the gear through
the window). Some have been transferred to machines (e.g. the aircraft sends
the signal if and only if the gear is down and the pilot decides so). In a remote
environment, the out-the-view window is no longer here, so the "visual check of
the gear through the window" function becomes deprecated. We could imagine a
number of alternative allocations, but system users would only be able to project
themselves into this context of operations and give an opinion once the system
has been physically developed, built and integrated. Moreover, designers could
not tell which solution to adopt, nor could they analyze user activity when users
get confronted with the adopted solution.

An HiTLS-based framework can circumvent the limitations described above. At this stage, designers must decide on an allocation compatible with remote center conditions. They need an early tool which users can interact with. HiTLS are not new in the field of remote ATC centers (Schier, 2016), but they are often carried out within heavy camera-based simulation environments and with costly physical devices. This is where a more software-based simulation environment supported by tools like game engines could be a significant asset to a more flexible acquisition of system knowledge.

In our landing gear check example, we could quite rapidly set up a remote envi-
ronment in which visual verification of the landing gear state is carried out by a
camera well positioned on the airfield. It may be hard to determine whether the
state of the gear should eventually be determined by the ATCo seeing the video
signal sent by the camera, or by an image processing algorithm that determines
this state automatically. Maybe the ATCo wants to have the freedom to set the
automation level at run-time by themselves. If the system carries out the check,
how does it deliver the signal to the ATCo? Should the ATCo get a video signal
in any case? What happens if the landing gear is still up? And who is in charge of
warning the pilot?

These questions should be carefully discussed with domain experts. Then, the
established scenarios should feed the simulation software to enable designers to
assess human and system performance through HiTLS. There are many bene-
fits to using an entirely game-based virtual simulation framework. First, virtual
worlds enable flexibility in scenario creation, as the simulated environment can
provide a common unambiguous language to users, designers and even non expert
stakeholders. They can exploit visual cues given by the simulated environment to
communicate more efficiently and agree on scenario staging and conduct charac-
teristics. The simulation configuration can also be easily changed after the HiTLS
has been carried out. Since all simulation assets are virtual, no commitment to any
particular device is necessary. As such, if the simulation shows that the camera-
based landing gear check is unsuitable to user needs, the camera can be ditched
immediately. Stakeholders can therefore explore and define many scenarios in
one session. Game-based simulations are easy to set up, as off-the-shelf game
engines tend to have many layers of abstraction, including graphical scripting
languages that enhance their access to non-developers. They significantly fos-
ter creativity as virtual worlds may comprise any imaginable asset, making the
designed proposals highly disruptive compared to already existing solutions. In
addition, game engines do not only handle visual information but can manage
anything from sound to realistic real-time rendering, head-up displays, artificially
intelligent agents, physics-based motion, virtual reality, haptic controllers, and
many innovative interaction paradigms.

Most of all, going virtual enables designers to simulate aspects that are irrelevant to the experiment. For instance, our landing gear scenarios should only focus on user activity regarding awareness of the gear state from the ATCo. Any technical aspects that do not serve to analyze this issue (e.g. data fusion of radar tracks, system interfaces with tactical data links, stripping system, flight plan management module...) do not have to be implemented to conduct the experiment. The assets that matter are simulated as well: the landing gear simulation designer has to give the plane a pre-determined path, but there is no need to model the intricate details about the plane cockpit or its fuel reserves, unless we decide to implement an off-nominal scenario with an out-of-fuel emergency landing. This kind of simulation that voluntarily omits irrelevant subsystems is sometimes referred to as part-task simulation (Loper, 2015).

6 Conclusion

The objective of this research was to identify the challenges of current SE prac-
tices in the industry regarding the integration of the human element in the design
of complex systems. We analyzed the processes and the difficulties of engineers,
designers and experts from a defense company and have identified four categories
of critical issues that we may address to better integrate the human element during
system acquisition.

These categories directly relate to the concerns raised by HSI practitioners. For
our virtual air traffic control center project, we think that a strong emphasis should
be put on modeling and simulation, especially game-based virtual HiTLS to help
conceptualize, design and develop such a disruptive system with many intricate
relations between human and machine elements. We believe that a computer-
based simulation environment, properly built around collaboratively defined user
scenarios, can be a real communicating tool that brings stakeholders together
and provide a common framework for the flexible creation of safe, effective and
efficient complex sociotechnical systems.

REFERENCES

Bolic, T. and Ravenhill, P. (2021), “SESAR: The past, present, and future of european ATM research”, *Engineering*, Vol. 7, http://doi.org/10.1016/j.eng.2020.08.023.

Booher, H.R. (2003), *Handbook of human systems integration*, John Wiley & Sons, http://doi.org/10.1002/0471721174.
Boy, G.A. (2021), "Human systems integration and design", in: G. Salvendy and W. Karwowski (Editors), *Handbook of Human Factors and Ergonomics*, chapter 2, John Wiley & Sons, Ltd.

Camara Dit Pinto, S., Masson, D., Villeneuve, E., Boy, G. and Urfels, L. (2021), "From requirements to prototyping, application of HSI methodology in DT design", *Proceedings of the International Conference on Engineering Design (ICED21)*, Vol. 1, pp. 1617–1626, http://doi.org/10.1017/pds.2021.423.

Fürstenau, N., Rudolph, M., Schmidt, M., Lorenz, B. and Albrecht, T. (2004), "On the use of transparent rear projection screens to reduce head-down time in the air-traffic control tower", in: *HPSAA, Vol. 1, Psychology Press, Daytona Beach, pp. 195–200.

Fürstenau, N. (2014), "Virtual and remote control tower - research, design, development and validation", http://doi.org/10.1007/978-3-319-28719-5.

Hjelseth, S., Morrison, A. and Nordby, K. (2015), "Design and computer simulated user scenarios: Exploring real-time 3d game engines and simulation in the maritime sector", *International Journal of Design*, Vol. 9, pp. 63–75.

ISO and IEC (2015), "ISO/IEC/IEEE International Standard", *ISO/IEC/IEEE 15288 First edition* 2015-05-15, http://doi.org/10.1109/IEEESTD.2015.7106435.

Kearney, P. and Li, W.C. (2018), "Multiple remote tower for single european sky: The evolution from initial operational concept to regulatory approved implementation", *Transportation Research Part A: Policy and Practice*, Vol. 116, pp. 15–30, http://doi.org/10.1016/j.tra.2018.06.005.

Loper, M. (2015), *Modeling and Simulation in the Systems Engineering Life Cycle: Core Concepts and Accompanying Lectures*, Springer, http://doi.org/10.1007/978-1-4471-5634-5.

Madni, A.M. (2015), "Expanding stakeholder participation in upfront system engineering through storytelling in virtual worlds", *Systems Engineering*, Vol. 18 No. 1, pp. 16–27, http://doi.org/10.1002/sys.21284.

NASA (2021), *Human Systems Integration Handbook*, NASA.

Papenfuss, A. and Friedrich, M. (2016), "Head up only — a design concept to enable multiple remote tower operations", in: *35th Digital Avionics Systems Conference (DASC)*, pp. 1–10, http://doi.org/10.1109/DASC.2016.7777948.

Reynal, M., Imbert, J.P., Aricò, P., Toupillier, J., Borghini, G. and Hurter, C. (2019), "Audio focus: Interactive spatial sound coupled with hazards to improve sound source location in poor visibility", *International Journal of Human-Computer Studies*, Vol. 129 No. C, p. 116–128, http://doi.org/10.1016/j.ijhcs.2019.04.001.

Rosson, M.B. and Carroll, J.M. (2002), "Scenario-based design", in: J. Jacko and A. Sears (Editors), *The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications*, L. Erlbaum Associates Inc., p. 1032–1050.

Rothrock, L. and Narayanan, S. (2011), *Human-in-the-loop simulations*, Springer.

Schaik, F.J., Roessingh, J.J.M., Lindqvist, G. and Fält, K. (2016), *Detection and Recognition for Remote Tower Operations*, in: Fürstenau (2014), pp. 53–65, http://doi.org/10.1007/978-3-319-28719-5_3.

Schier, S. (2016), *Remote Tower Simulation Environment*, in: Fürstenau (2014), pp. 69–85, http://doi.org/10.1007/978-3-319-28719-5.

Strauss, A. and Corbin, J. (1990), *Basics of qualitative research*, Sage publications.

US Air Force (2009), *Air Force Human Systems Integration Handbook*, US Air Force.

Uskov, A. and Sekar, B. (2014), "Serious games, gamification and game engines to support framework activities in engineering: Case studies,
analysis, classifications and outcomes”, in: *IEEE EIT*, pp. 618–623,
http://doi.org/10.1109/EIT.2014.6871836.

VanDerHorn, E. and Mahadevan, S. (2021), “Digital twin: Generalization, characterization and implementation”, *Decision Support Systems*, Vol. 145, p. 113524, http://doi.org/10.1016/j.dss.2021.113524.