Digital Twin Development for the Airspace of the Future

1. Introduction

The Urban Air Mobility (UAM) concept, combined with advancements in automation and energy storage technology, is propelling the urban aviation sector forward [1]. UAM includes a collection of regulations, techniques, and technologies that facilitate the movement of goods and people through air routes in urban settings [2,3]. UAM has the capacity to revolutionize economy of cities, generate employment opportunities, reduce emissions compared to conventional road vehicles and aircraft, and lower infrastructure costs. It heralds the beginning of a new era of multimodal transportation. While UAM has been considered a luxury mode of transport since the pandemic, AAM (Advanced Air Mobility) may play a crucial role in the efficient transport of time-sensitive cargo, including vital medical supplies, manufacturing equipment, and other packages where saving 30 minutes to an hour or more justifies the use of airborne vehicles [4]. The focus of the study was specifically on the application of UAM and air taxis within an urban setting [5]. The AoF project holds the potential to advance UAM initiatives by offering a detailed case study and a framework for cities to address the challenges associated with UAM implementation [6]. However, cities are ill-prepared for the integration of UAM into their existing transportation infrastructure, which presents a significant challenge [7].

The motivation of this research, referred to as the Airspace of Future (AoF), is to enable routine operational drone services in a safe coordinated environment on a regional and national basis in cognisance of realistic end user requirements; validated by robust business cases, simulation, stakeholder and public engagement; underpinned by an integrated transportation model with aviation at its core and an exploitation roadmap for the UK [8,9].

The Airspace of the Future research encompasses a wide range of interconnected domains, including the development and compliance of regulatory frameworks, enabling technologies and tool-sets such as digital twins and simulation. Additionally, it also addresses crucial societal concerns such as the validation of public acceptance of commercial drone operations. One of the key objective is to develop a virtual experimentation environment and digital twins to test new rules, processes, systems, technology and operating concepts rapidly at scale.

The aerospace industry has always been at the forefront of innovation, pushing the boundaries of human exploration and technological advancement. As we embark on the journey towards the future, a new concept known as "digital twins" is poised to revolutionize the aerospace landscape [10]. Digital twins, virtual replicas of physical assets, have the potential to transform how we design, build, and operate aerospace systems [11,12]. By integrating real-time data from sensors installed on physical assets, digital twins can monitor equipment health, predict maintenance needs, and proactively address potential issues [13,14]. This predictive maintenance approach minimizes downtime, improves safety, and maximizes the lifespan of aerospace systems. The digital twins trend is gaining momentum thanks to rapidly evolving simulation and modelling capabilities, better interoperability and IoT sensors, and more availability of tools and computing infrastructure. As a result, capabilities of digital twins are more accessible to organisations across industries [15,16].

This paper presents the development of the AoF digital twin of the National Beyond Visual Line of Sight (BVLOS) Experimentation Corridor (NBEC) [17]. The objective is to utilise the Simulation and Digital Twin as versatile tools that can facilitate both fully synthetic testing and Live Virtual Constructive (LVC) testing, especially when integrated with live elements. This would establish a secure and safe platform for testing drone infrastructure, as well as examining airspace structures and Unmanned Traffic Management (UTM) concepts [18].

To the best of authors knowledge, only the work in [19] has presented a digital twin model for designing and developing Urban Air Mobility (UAM)/UTM applications, such as vertiport location problems, airspace and air vehicle management. The paper discusses a digital twin of a case study for a 3D Urban Air Mobility Network. The presented research is preliminary, and further studies are needed to refine the model for use in other cities or scenarios. The authors noted that the data used for the model was limited and lacked validation, which could affect the accuracy and completeness of the model.

The paper highlights two main contributions. The first contribution is the design and implementation details of the Digital Twin of the airspace of the future project. This digital Twin is a virtual representation of the airspace, including terrain, buildings, and other relevant features. It allows to simulate drone flights in a realistic environment, which can help identifying potential issues and optimise flight plans.

The second contribution of the paper is the demonstration of the Airspace of the Future Digital Twin through simulated and hybrid flights with real drones. Several flight trials have been conducted using the Digital Twin. These trials demonstrated the effectiveness of the U-space services in managing drone flights in a safe and efficient manner. The results of these trials can be used to inform the development of UTM systems and policies, as well as to guide future research in this field.

In Section 2, the concept of the AoF Digital Twin is presented. Section 3 describes the Digital Twin Design design. In Section 4, the proposed Use Cases are summarised. Flight trials were performed for the Digital Twin, some of the results are presented in Section 5, and the results are analysed. Finally some conclusions are drawn.

2. Airspace of the Future Digital Twin

The Airspace of the Future Digital Twin creates an environment that closely resembles reality, providing a reliable platform to operate a diverse range of commercial drone and air mobility vehicles [20]. The objective is to develop simulation and testing tools that can serve both fully synthetic and LVC testing, effectively combining virtual and real-world elements.

The development of the digital twin has involved four steps (See Figure 1 ):

• Requirements definition: Requirements definition involves identifying key features, such as purpose, scope, data sources, accuracy, simulation, analysis capabilities, and performance metrics, that must be captured and replicated in the digital twin.
• Design and development: Design and development of the Digital Twin involves creating a virtual replica of the physical object. This process requires the integration of various technologies, sensors, and data analytics. The design phase focuses on identifying the key features to be replicated, and selecting appropriate technologies. During the development phase, the virtual model is created, and the necessary data sources are integrated.
• Use case simulation development: Use case development involves creating virtual scenarios that mimic real-world situations to evaluate systems or processes. These simulations are used to analyse performance, identify issues, and improve strategies. The process involves creating a model, identifying key variables and inputs, and running simulations to evaluate outcomes and measure performance.
• Verification and validation: Verification and validation are crucial steps in the development and implementation of a digital twin. Verification ensures that the digital twin accurately represents the physical system, while validation ensures that the digital twin can be used to make reliable predictions and decisions. The process involves comparing the output of the Digital Twin to real-world data and performance metrics to ensure that it operates correctly and produces accurate results. Verification and validation also help identify any errors or inaccuracies in the design of the digital twin, allowing for improvements to be made before it is put into use.

The focus of the Digital Twin is on the down-selected use cases. It creates an instance of the Enterprise Architecture and replicates interactions between users, such as Mission Planners, Operators, Remote Pilots, UTM Traffic Control Operators, and Air Traffic Controllers, and various systems that make up the drone operation ecosystem. When defining requirements for Airspace Management, it is essential to consider how RPAS integrate into the existing aviation system, future digital infrastructure, and rules of the air. These considerations are crucial to ensure the safety of manned aviation operations within UK airspace [21].

The design of the digital twin consists in the development and integration of the main components of the simulation environment and digital twin [22,23]. The AoF Digital Twin includes simulated models and interfaces with real systems covering the following:

• The enterprise architecture
• The various data threads
• System analysis tools
• Interface with ground infrastructure (holographic radar, communications, UTM, mission planning)
• Representative computer-generated models (e.g. drones, manned aviation traffic)
• Representative natural environment models (e.g. extended NBEC 3D model, weather model)
• Interface with UTM systems, in order to e.g. feed synthetic entities into UTM:
• Surveillance API
• Receive data and instructions from UTM (Strategic Conflict Resolution Service and Tactical Conflict Resolution Service )

In the following, is presented the design and development process of the Digital Twin.

3. Digital Twin Design and Development

The AoF Digital Twin represents the geographical Area of Interest displayed in Figure 2. This geographical area has been selected as it offers a varied and representative range of features. It includes the UK National BVLOS Experimentation Corridor (NBEC) and large urban areas, including Milton Keynes and Bedford, with key features such as hospitals and business parks. The NBEC is shown in Figure 1 within the bordered AoI in green and is active between $200\mathrm{ft}$. and $400\mathrm{ft}$. above ground level. The area also includes large rural areas with several villages, fields, woodlands and nature reserves. Key infrastructure such as motorways, A-roads, railways and power lines are also comprised in the selected region. This geographical area is big enough (approximately $1200\mathrm{km}2$ ) to accommodate testing of the representative use cases in the Synthetic Environment.

In addition, as it contains the NBEC, it was possible to perform Live Virtual Constructive testing by linking a real asset to the Digital Twin.

In the following is described the design of the Digital twin.

3.1. Architecture of the Digital Twin

The Digital Twin represents the Area of Interest (AoI), alongside features relevant to the studies and research elements of this research. There are several layers involved in creating a comprehensive Digital Twin Figure 3. These layers include the terrain, infrastructure, weather, airspace, and both unmanned and manned aviation. Each of these layers plays a crucial role in replicating the real-world environment and interactions that the digital twin is designed to simulate.

The digital twin concept of the on-board system consists of several subsystems, including communication, navigation, surveillance, DAA (Detect And Avoid), geofencing, and the autopilot [24]. The communication subsystem enables the transmission of data to and from the Unmanned Aircraft (UA), including direct communication with the Remote Pilot Station (RPS) and, in some cases, communication with the U-space service provider [25]. Navigation involves measuring or estimating the state vector of the aircraft and is integrated into the Flight Management System (FMS) within the Remotely Piloted Air Systems (RPAS) on-board system architecture [26]. The FMS also handles waypoint management, guidance priority, envelope protection, and emergency procedures. The surveillance subsystem enables the transmission of the identification and position of the UAV. Geo-fencing involves on-board management of constraints and utilizes DAA to ensure that the specified areas are not violated [27].

3.1.1. Functional Architecture

The Functional architecture diagram of the Digital Twin (Figure 4) highlights several essential components that are necessary to create a realistic representation of different environments and conditions. It is composed of the Synthetic Environment, the real world system and the Data thread.

The Synthetic Environment

The Synthetic Environment is a crucial tool for simulating and testing complex scenarios in the context of drone operations [28]. It is made up of various components that work together to provide a realistic representation of different environments and conditions.

The operation station is the central control centre of the Synthetic Environment, allowing users to manage and control the various components of the system.

The visualization system is another critical component that provides users with a graphical representation of the simulated environment, including terrain, objects, and weather.

The weather simulation and terrain data modules provide accurate and detailed information about different weather conditions and terrains, enabling users to test and validate the behaviour of drones under various environmental scenarios.

The communications simulation module is also essential, allowing users to test and validate the communication capabilities of drones and other objects in different scenarios.

The computer-generated models module enables users to create and customise drone models, which can be used for testing and validation purposes.

The UAV, also known as a remotely piloted aircraft (RPA), is an aircraft that is controlled by remote control equipment or equipped with an autonomous flight system. It serves as the core component of an unmanned aircraft system, which is an integrated system connecting the UAV to a ground station through a communication data link [29]. Additionally, the system utilizes other elements, such as related personnel and incorporates concepts like fusion airspace and isolation airspace theory, to assist in task execution and management [20].

The Real-world Systems

In addition to the Synthetic Environment, the Digital Twin also includes real-world systems and data. The real-world elements integrated into the Digital Twin include holographic radar, Automatic Dependent Surveillance-Broadcast ( ADS-B) [30], UTM, mission planning, real drones, and Air Traffic Management (ATM). These components allow users to test and validate the Synthetic Environment under real-world conditions, ensuring that it behaves as expected when interacting with real-world systems.

The holographic radar system provides users with a detailed representation of the environment, allowing them to detect and avoid potential obstacles and hazards.

The Data Thread

The data thread enable the collection, transmission, and storage of data from the real-world systems, which can then be used to inform and update the Synthetic Environment.

3.1.2. Logical Architecture

The Digital Twin system incorporates a set of nodes that are defined in the Airspace of the Future Architecture Figure 5. These nodes include UTM Service Providers, Drone Service Providers, Drones, Other Airspace Users, and the ATM. These nodes work together to provide a holistic view of the drone and UTM ecosystem. The UTM Service Providers node is responsible for managing and coordinating the various UTM services that are required to ensure safe and efficient drone operations. This includes services such as airspace management, flight planning, and traffic flow management. The Drone Service Providers node represents the various entities that provide drone-related services, including manufacturers, operators, and maintenance providers. The Drones node represents the drones themselves, including their hardware, software, and sensors. The Other Airspace Users node represents the other entities that may operate in the same airspace as drones, including piloted aircraft, helicopters, and other aerial vehicles.

The Airspace Traffic Manager node represents the human operators who are responsible for managing and controlling manned aviation traffic in the airspace. This node is essential for ensuring that drone operations do not interfere with manned aviation and that both types of traffic can coexist safely and efficiently.

3.1.3. The Simulation Framework

The Simulation of the Digital Twin system is a comprehensive platform that aims to provide an accurate and realistic representation of the drone and UTM ecosystem.

For the various components to be integrated and exchange and share data as efficiently as possible, the Digital Twin uses existing standards including the Distributed Interactive Simulation (DIS) [31] and High-Level Architecture (HLA) [32] standards to provide interoperability between the various components. The simulation components deployed on two different sites. The one running at Cranfield are integrated into one HLA federation. The components running on the Blue Bear [33] facilities run on a DIS infrastructure. The two distinct environments are connected together. Translation of objects and attributes between the two is performed by a HLA / DIS Adapter component. In addition to the HLA and DIS simulation environments, a Kafka network [34] is used to channel real-time data feeds into the Digital Twin. This open-source event streaming platform offers a reliable and persistent storage system for streams of events through its publish/subscribe event bus called the Kafka broker. The Digital Twin leverage the Kafka network to receive weather information streams, such as those provided by MetOffice [35] and StormGlass [36]. A visual specific interface using the Common Image Generator Interface (CIGI) [37] is also used to connect the 3D Visualisation component to the HLA Simulation Framework. The CIGI is an interface designed to promote a standard way for a host device to communicate with an image generator (IG) in the simulation industry. CIGI facilitates plug-and-play integration of image generator vendors who comply with the standard, resulting in cost savings during visual system upgrades.

3.1.4. The Geographical Area of Interest

The Area of Interest is represented in different components integrated in the Digital Twin. These include 3D Visualisation, 2D Visualisation. Some existing components reuse their current representation of the terrain, often in a map format. For these existing components, there is no requirement to correlate and align the data source. It is accepted that small discrepancies might exist between the different components. Figure 6 illustrates this.

UTM System

The UTM system is composed of GuardianUTM designed by Altitude Angel [38] and Thales Topsky [39]. The Digital Twin and its components support testing of operations including pre-flight, in-flight and post-flight operations. Under this research, GuardianUTM and Thales Topsky are not part of the Digital Twin but contributes to it. The Digital Twin provides data / consume data as such, it is treated as a normal user.

3.1.5. Digital Twin Systems

The Digital Twin systems include 3D Visualization, Infrastructure (Communication, Navigation, Surveillance), Weather and Atmosphere, Airborne Assets, Simulated Ground Control Station, User Interface, Control Station, and Operator Interface.

3D Visualization System

The 3D Visualisation component provides a 3D view of the environment and the entities, virtual and real, that operate in this environment (Figure 7 ). As a user interface, the 3D Visualisation component does not include any simulation capabilities and simply provides a view of activities within the Digital Twin. The 3D Visualisation component is based on the Unity game engine [40] and employs a database, including terrain, imagery and buildings.

Infrastructure

The infrastructure layer of the Digital Twin is concerned with the representation of the physical and digital infrastructure elements of the drone ecosystem. The necessary infrastructure falls into three main categories: communication, navigation and surveillance.

Communication Infrastructure The objective of the communication simulation is to accurately depict the various communication methods employed to establish connections between different systems and assets within the Digital Twin. The simulation encompasses several communication technologies such as 4G, 5G, SATCOM, Wide Area Network, and C2 Link. When simulating cellular communication, it is essential to not only represent potential obstacles but also incorporate the locations of mobile base stations to ensure a realistic simulation of the communication system. The NETSIM Software is utilized to simulate the communication system [41]. The masts data was sourced from Mastdata data base [42] and was implemented using NetSim GUI (Figure 8).

In the context of the communication simulation, 4G technology plays a vital role in representing one of the communication methods used within the Digital Twin. 4G networks provide high-speed data transmission, enabling efficient connectivity between different systems and assets. As part of the simulation, the characteristics and capabilities of 4G technology are modeled to accurately depict its performance within the Digital Twin. This includes simulating factors such as data transfer rates, signal strength, and network coverage. By incorporating 4G technology into the communication simulation, the Digital Twin can emulate real-world scenarios where 4G networks are utilized for seamless communication and data exchange between various components. This facilitates a comprehensive understanding of how the systems and assets interact and communicate with each other in a simulated environment. Through the utilization of the NETSIM Software, the communication simulation can effectively simulate the behavior and functionality of 4G technology, along with other communication technologies, to create a realistic representation of the communication infrastructure within the Digital Twin.

Navigation Infrastructure The Digital Twin incorporates a simulation of navigation systems including Global Navigation Satellite System (GNSS ). The Digital Twin navigation simulation is configurable and parametrically simulates the various technologies with critical configurable parameters including coverage, continuity, and accuracy. Non-nominal use cases might be investigated with the introduction of parameters such as interference, jamming or impact of weather. The Simulation Framework is considered as the ground truth for simulated entities i.e., their geographical positions, attitude and flight dynamics parameters in the Synthetic Environment simulate what they would be in real life. The utilisation of digital twin methodologies to replicate and model the progression and transformations of geographical environments is increasingly commonplace. The objective is to provide a thorough and measurable depiction of the physical world, enabling simulation and prediction of the consequences of various interventions [?].

Therefore, these parameters and position in particular need to be altered to generate realistic GNSS positions. For simulated UAS this conversion is done by a simple GNSS simulation component which translates the ground truth positions into GNSS positions. The GNSS simulation component introduces configurable positional error and latency for testing of various assumptions and technologies.

Surveillance Infrastructure The surveillance technologies include ground-based radars and electronic conspicuity.

Radar Surveillance

The Radar Surveillance simulation (Figure 9) generates a simple simulation of a network of ground-based radars. As for the GNSS simulation, the Radar Simulation component generates radar tracks from ground truth positions from the HLA Simulation Framework. The radar tracks are transmitted to the UTM platform(s) as sensor inputs. A simulated radar server translates the radar tracks into UTM API data.

Radar Server GNSS Surveillance

The GNSS data generated by the GNSS Simulation component is used to transmit 464 surveillance data to the UTM platform(s). The GNSS data is transmitted to the UTM platform(s) as sensor inputs and simulates the Remote ID and Tracking functions, as part of the electronic conspicuity systems.

Weather and Atmosphere

The weather layer in the Digital Twin focuses on modeling the atmosphere and weather and their effects on the various systems. The weather and atmosphere definitions are generated from live data and transported through the HLA simulation framework. They are then translated into a DIS PDU (Protocol Data Unit) and transmitted to the synthetic environment to affect the simulated systems.

Airborne Assets

The Digital Twin represents manned and unmanned airborne assets in the AoI. The 2D and 3D asset representations are of generic aircraft models matching the aircraft type of asset, irrespective of whether the asset is unmanned (generic quadcopter, fixed-wing UAV) or manned (light aircraft, commercial jet, microlight, helicopter) with associated symbology (Figure 11).

There are 2 categories of simulated assets: UAVs and manned aircraft:

• UAVs are used to perform the virtual operations as part of the virtual trials.
• Manned aircraft can also be generated to simulate manned traffic in more complicated scenarios.

Simulated Ground Control Station

A simulated Ground Control Station (GCS ) allows the user to play the roles of UAS Operator and UAS Pilot. The GCS consists of 2 main functions. First, it allows the user to define, modify and submit missions. This is the mission planning aspect of the GCS. The GCS interfaces with a UTM platform to submit the missions and obtain approval for flights. In addition, the GCS sends command and control messages to the simulated UAS. This is the control aspect of the GCS. The main interaction with the simulated is through a map centric user interface. The simulated GCS has been built to allow the user to role play several UAS Operators and Pilots. The user can generate scenarios made of multiple independent missions. Template missions can be generated and stored and reused in various scenarios at a later date.

User Interface

The user interface permits the operation of the synthetic environment. It allows the user to:

• Edit and create different scenarios based on real-time and synthetic data sets via a dashboard,
• Conduct scenario analysis during a mission and after a scenario has concluded, allowing investigations of asset and environment in real-time and after the fact.
• Switch between 2D and 3D views of the AoI, allowing the different perspectives of scenarios when conducting analysis.
• Input synthetic assets into a scenario. The 3D Visualisation component generates a 3D view of the Digital Twin Area of Interest (Figure 12). It is used as a situational awareness tool that provides the Digital User and observers with an up-to-date view of the state of the environment, including the real and virtual entities operating in the environment.

Control Station

The Control Station allows the Operator to control and manage some of the Synthetic Environment features (Figure 13. It is accessed via an Angular Front end and offers a 2D view of the Digital Twin.

Operator Interface

The Operator Interface is a User Interface that the Digital Twin user can use to simulate the actions of a UAS Operator (Figure 14). It is accessed via an Angular Frontend and allows the user to create, modify and submit flight plans to the UTM platform(s). There is one Operator Interface per UTM platform to simulate the separate UAS Operator groups using the different UTMs. The flight plans created on the Operator Interface are used by the simulated Ground Control Station to generate and control the virtual UAS flights.

3.2. Airspace

The Digital Twin visually represents both 2D and 3D airspace over the specified area, including classifications, geofencing and geocaging, and areas around key infrastructures. It covers both civil and military controlled spaces and other areas with specific restrictions. While the main focus is on airspace below 400 ft., layers above this are included for integration, but not the primary focus. Specific UAS airspace types, as per the CORUS U-Space Concept of Operations [43], are also represented, including type X for open airspace, type Y for areas needing UTM involvement, and type Z for strictly controlled spaces like airports and built-up areas.These types are represented in Figure 15.

The Digital Twin configure drone airspace type at the request of user. It employs the configured drone airspace types within the synthetic environment and any UTMs in advance of any scenarios being undertaken. The Digital Twin represents upto-date aviation charts with relevant Notice to Air Missions (NOTAM) information [45]. The Digital Twin has the capability to represent simulated permanent features and NOTAMs within the Synthetic Environment. Simulated features such as aerodromes/military bases have associated simulated airspace restrictions in place as if they were live features, which is represented in the UTMs and Synthetic Environment.

4. Use Cases Simulation

Several uses cases were identified and prioritised by the AoF. The Digital Twin supports the simulation of these use cases. This would enable scenario planning, execution and data gathering in a safe but realistic environment. The defined uses cases are summarised in Table 1.

It is shown that the uses cases cover different combinations of airspace characteristics, traffic volumes and UAS types. The scenario simulation environment supports the trials of these use cases. To enable this, the environment provides multiple U-Space services. Relevant data, such as weather, geospatial data can also be loaded into the scenario environments. Specific use cases were selected for the simulation scenarios, such as: agriculture, inspections, and light goods delivery. For each of the use cases, the Digital Twin allows the testing of the CORUS processes and services [44].

4.1. Scenario Mapping

The use cases needed to be mapped to actual locations and airspace types, see figure below. The Digital Twin supports the loading of real-world geospatial data for areas of interest to indicate the airspace types $X,Y,Z$. The geospatial data included: airspace restrictions relevant to UAS, Ordnance Survey data, and NBEC centreline data. The light goods scenario (Figure 16) considers delivery of goods with low weight from warehouses to customers. As shown in the figure above, for the light goods scenario in the AOI, the airspace was divided into X and Z type airspace. Each of these types of airspace had the required set of services associated with them. The Digital Twin and LVC environment provided the functionality to both specify the airspace types and to use the associated CORUS services for each airspace. Another scenario mapping is shown in (Figure 17), describing an agricultural (farm) inspection. For one of the scenarios, the whole mission was with X airspace (see top left of the figure). The Digital Twin supports the creation and execution of the mission plan for the scenario. Moreover, by using the implemented CORUS services, the mission can be visualised and recorded.

4.2. Implemented Simulation Services

To enable the simulation of scenarios, the Digital Twin implemented U-space services that have been defined in CORUS. These CORUS-based services are integral in the development and execution of flight scenarios in the Digital Twin. These services are summarised in Figure 18.

4.3. Scenario Simulation Process

The Digital Twin supports the end-to-end creation and execution of virtual flights. The process includes operation planning, UTM approval, and operation execution.

In the Digital Twin, Operations are planned using the simulated Mission Planning tool. The tool allows the user to act as UAS operators and create, modify and submit UAS operations to the UTM platforms. The same User Interface is also used to execute and monitor the simulated scenarios.

The Mission Planning tool is made of a frontend user interface and a backend server. The frontend interface allows the user to complete all tasks from creating, modifying, submitting and running the synthetic operations. All data is stored and managed in a local MongoDB database [46]. The backend server interfaces with the database, the synthetic environment through DIS, the simulated Ground Control Station and the UTM platforms (Altitude Angel GuardianUTM or Thales Topsky UAS UTM).

The operation planning process follows the following workflow:

• Creation of operation templates
• Creation of scenario templates
• Instantiation of scenario templates

5. Flight Trials

The trials focused on testing the system behaviour, AoF processes, agreed and available CORUS functionality and performance measures such as air traffic load, traffic proximity etc., when the volume of Drone Operations increased from one to the maximum concurrent flights in $X,Y,Z$ airspaces defined during High and Low Peak periods.

The following Trial Runs were conducted during flight trials

• Trial Run#1: The purpose of this trial run was to test single drone operations in $\mathrm{X}$ Airspace.
• Trial Run#2: The purpose of this trial was to test three concurrent flights in $\mathrm{X}$ and $\mathrm{X},\mathrm{Y},\mathrm{Z}$ airspace in synthetic environment only prior to loading the system with increased number of flight plans.
• Trial Run#3: The purpose of this trial was to test 10 concurrent flights in $\mathrm{X}$ and $\mathrm{X},\mathrm{Y},\mathrm{Z}$ airspace in synthetic environment at Low Peak volumes.
• Trial Run#4: The purpose of this trial was to test all concurrent flights in $\mathrm{X},\mathrm{Y},\mathrm{Z}$ airspace in synthetic environment at Low Peak volumes.
• Trial Run#5: The purpose of this trial was to test all concurrent flights in $\mathrm{X}$ and $\mathrm{X},\mathrm{Y},\mathrm{Z}$ airspace in synthetic environment at High Peak volumes.
• Trial Run#6: The purpose of this trial was to test all concurrent flights in $\mathrm{X}$ and $\mathrm{X},\mathrm{Y},\mathrm{Z}$ airspace in hybrid environment at High Peak volumes.

The analysis of the trials was conducted according to the defined performance requirements. These requirements include the total number of active flight plans, the total number of accepted flight plans, the total number of rejected flight plans, the total number of drone positions and tracks, the number of drones per airspace volume, traffic proximity, and message throughput. By examining these performance metrics, we can gain a comprehensive understanding of the system capabilities and identify any areas that require improvement.

5.1. Flight Trials Observations in Synthetic Environment

Observations made only for Digital Twin Simulation and Guardian UTM. The architecture processes developed for each phase of flight were conformant and as expected.

5.1.1. Air Traffic Load for an Airspace

The analysis included trial runs with both flights requiring strategic deconfliction and those in X airspace not needing it. Trial run #1, consisting of flights solely in X airspace, was included because it had multiple concurrent flights. As shown in Figure 19, the Digital Twin system managed flight plans, providing users with approval or rejection of their submitted plans without any details of conflicts.

Table 2 presents the number of accepted and rejected flight plans for each trial run. Flights in X airspace were considered accepted. Trial runs # 1 and #2 had acceptance rates of 100% because they did not require strategic deconfliction, and all intended flights were flown.

During trial run #3, 90% of ten flights were accepted, although it is possible that the airspace was not fully loaded. In contrast, trial run #1 had a 24% acceptance rate, indicating that current processes were at capacity. The current deconfliction approach blocks other drones from flying through any point on the reserved path, which has a significant impact on flights from delivery hubs. Both strategic and non-strategic deconfliction flights were conducted in all trial runs. As the number of submitted flights increased, the acceptance rate decreased, with a maximum of 18 accepted flights per hour. Trial run #4 had a 70% acceptance rate, which was lower than trial run #3, due to the randomisation of drone operations and route selection.

To understand the reason for the rejections in trial run #4, a plot of the operations plan was generated, which showed rejected plans in red and accepted plans in blue (Figure 20). The plot indicated that once a flight departs a given base, no other flight can depart or arrive at the base for the duration of that flight. For example, flights that planned to depart the hub during the duration of an accepted flight were rejected. The trial used a "light goods delivery" use case, where all flight plans started and ended at a single point, the supermarket.

The UTM rejected flight plans if conflicts were identified along the planned route. Trial run #4 had a lower acceptance rate due to conflicts at the start and end points. Alternative deconfliction methods and rule sets could address these issues. Optimised trial run #5 split flights into subsections and required approval for each subsection. Further optimization of airspace use is possible as even low-density runs had flight plan rejections. Next, safety and efficiency of airspace management will be explored.

5.1.2. Traffic Proximity/nearest approach

Airspace management aims to prevent drone collisions by analysing traffic proximity data. Results from post-trial analysis show how close drones come to each other, which is a safety and efficiency metric. Separation that is too great reduces the number of drones flown, potentially failing to meet user demand. Proximity data was obtained through a discrete and approximate method, resampling position data at $0.1$ second intervals to calculate the distance between concurrent drones. A conflict or incursion occurs if drones come within $60\mathrm{m},30\mathrm{m}$ or $10\mathrm{m}$ of each other. Results for each trial run can be seen in Table 3.

The majority of trial runs showed effective separation of drones with no conflicts within defined thresholds, demonstrating the efficacy of the airspace management processes. However, Trial Run #4 had a near miss and collision in the horizontal plane, corresponding to $1.6\%$ of operations. Vertical separation was $3.63\mathrm{m}$ and $10.36\mathrm{m}$ respectively, despite the drones flying at the same cruising altitude, due to altitude changes during takeoff and landing. The affected drones belonged to the same operator and were synthetic without detect-and-avoid. Lack of buffer time for landing in some operation plans likely caused the conflicts. Figure 21 shows a proximity violation, with drones 1 and 2 having blue and red tracks respectively, occurring at Base 1. Both drones were concurrent in flight time. Tactical de-confliction was not implemented in the trials.

Therefore, a drone from a previous operation may still be nearby in a location when another drone is about to take off. This issue was corrected in later trials by increasing the buffer time at the end of operations. This observation further stresses the need to put take extra care during take-off and landing procedures.

For most of the trial runs the separation between the drones is large, reaching up to $2256.37\mathrm{m}$ in Trial Run #5. This indicates there is room to optimise the airspace efficiency by exploring more ways to support more drones per unit time. This especially so if we consider that some flight plans were rejected even though the separation distance between any pair of the drones was large.

5.1.3. Number of drones per airspace volume

A crucial measure of the efficiency of the airspace management is the number of drones that can be safely flown per airspace volume. By analysing the timestamped position reports, this measure can be obtained for each trial run. That is, for each time interval (one minute in this case), the number of drones in operation in the airspace of interest were counted. The best-case scenario is to keep the number of drones per time close to the maximum capacity that can be supported by or the airspace. That way, the airspace is used more efficiently. Table 4 summarises the relevant results for each of the Phase 2 trial runs.

Trial Run #4 had the most drones, with a support of 7 drones per minute, but suffered from reduced separation and a collision between two drones. The highest number of drones with good separation was 5 drones per airspace in Trial Run #1, which had a large minimum separation of $2256.37\mathrm{m}$. Therefore, the optimal number of concurrent drones for good airspace use and sufficient separation lies between Trial Run #4 and Trial Run #5. To analyse the results further, a plot of the number of active drones over time for Trial Run #5 is shown Figure 22.

The plot reveals that, for most of the time, the number of active drones was lower than the peak capacity of 5 drones. Ideally, the number of concurrent drones should remain at the peak capacity of the airspace throughout the trial run. Therefore, increasing the number of drones in the airspace per unit time to the peak values for a larger fraction of the trial run would be beneficial. However, this observation is based on the assumption that there was good separation during the trial. To increase the number of concurrent drones, more sophisticated airspace management strategies could be employed. For instance, flight plans could be segmented and deconflicted, as demonstrated in the optimised Trial Run #5.

5.1.4. Total number of drone positions and tracks

For these trial runs, the number of drone tracks were equivalent to the number of flight plans submitted. This is because relatively ideal conditions were considered. This meant that most approved operations were flown and were not cancelled.

In addition, the drone positions were regularly submitted to the Altitude Angel Surveillance API. This meant that any stakeholder that has access to the API can be aware of drone traffic in their vicinity. This ensures safety and the drone position reporting service is a requirement of the CORUS-based systems used in this design.

Figure 23 shows a screenshot of the Guardian UTM dashboard displaying some tracks for planned drone operations during the trial Run #5. This type of information is useful to airspace users and stakeholders to inform adequate drone separations and drone awareness.

5.1.5. Message throughput

An important interface covered in this analysis was the interface between the GCS and strategic conflict resolution interface (GCS-SCR) through which de-confliction requests are submitted. The summary of the analysis for Phase 2 runs can be seen in Table 5. The table also shows the results for the interfaces between the GCS and Surveillance API (GCS-SURV) and that between the Remote ID and surveillance API (Remote ID-SURV).

The results for the GCS-SURV interface showed that the message traffic increased as the number of concurrent drones increased. This was expected because the interface handled position reports. This was because each drone transmitted its position regularly and these reports eventually got to the GCS-SURV interface. Note message data logging was not available during run #2. A similar result was obtained for the Remote ID-SURV interface because it also handled drone position reports.

Figure 24 shows an example plot of the variation of the message rate for the GCS-SURV interface (Trial Run #5). The figure could be compared with the respective plot for number of drones in the airspace to confirm the observation that message throughput varied with number of drones in the airspace.

In contrast, the results for the GCS-SCR interface showed a small number of messages. The messages correspond to the number of flight plans submitted to the strategic de-confliction API. Therefore, this interface handled messages mostly before operations and did not experience much loading, compared to the GCS-SURV interface. Because the messages handled by the GCS-SURV and Remote ID-SURV interfaces grew with the number of drones, the interfaces were more likely to be bottlenecks in the LVC (Live Virtual Constructive) environment. This is in comparison with the GCS-SCR interface that had low message load.

5.2. Flight Trials in Hybrid Environment

The conducted flight trials in a hybrid environment refer to the testing and evaluation of the system and processes in a combination of simulated and real-world operational conditions.

5.2.1. Air Traffic Load for an Airspace

During the hybrid operations at scale run, 75 target operations were conducted, some of which required submission to the strategic de-confliction service due to their flight paths passing through $\mathrm{Y}$ or $\mathrm{Z}$ airspace. Table 6 displays the traffic load results. In trial run #8, only 19 out of 75 operations were flown, resulting in an acceptance rate of 25.33%. This is similar to the acceptance rate of 24% obtained in synthetic run number #5, which also had 75 target flights. The slight difference in acceptance rate may be attributed to the variation in randomised routes between the two runs. For instance, trial run #8 included an operation at Cranfield Airport, which was not present in Trial run #5.

The UTM system used in the Airspace of the Future study offered a limited range of services and did not support tactical deconfliction, resulting in the work flow mechanism not accounting for the exact location of each participating drone. Thus, when flight plans were submitted, if the plans physically or time ’overlap’ the first flight plan would be accepted and all other conflicting flight plans will be rejected until the first flight plan has ’timed out’.

5.2.2. Traffic Proximity/nearest approach

This analysis aimed to determine the proximity of active drones to each other during the trial run. Three proximity thresholds were used for this analysis: $10\mathrm{m}$ for collisions, $30\mathrm{m}$ for near-misses, and $60\mathrm{m}$ for incursions. The results are presented in Table 7.

The table shows that all drones in the trial run remained within the defined proximity thresholds with no violations recorded. The minimum separation between drones was $1646.28\mathrm{m}$, indicating safe separation and a low probability of conflicts. This result is similar to that of run #7, which had the same number of drones and no proximity violations, but with a higher separation distance of $2256\mathrm{m}$. However, trial run #8 had a slightly higher number of accepted flights (19) compared to trial run #7 (18), indicating that it could support a higher number of flights without compromising safety.

Given the safe separation distances observed, there may be opportunities to optimise airspace utilisation by increasing the number of drones in the airspace. By doing so, airspace managers can enhance the efficiency of drone operations while maintaining safety.

5.2.3. Number of drones per airspace volume

Figure 25 shows the number of drones per airspace volume as a function of time. it can be observed that the maximum number of drones per minute recorded during this trial run was 5.

Throughout most of the run, the number of drones in the airspace was below its peak capacity of 5. Ideally, the airspace utilisation should be kept as close to its peak as possible to support more drones per unit time, thus increasing the number of services and operations available to airspace users. For example, if the number of concurrent drones were maintained at 5 per minute at all times, the drone traffic would increase to 300 drones per hour (5 multiplied by 60).

However, while large separation distances ensured safety during the run, they may have had a negative impact on airspace efficiency. This highlights the need for more CORUS services such as dynamic deconfliction and Detect and Avoid (DAA) to improve efficiency in the future.

5.2.4. Total number of drone positions and tracks

Like previous runs, the number of drone positions and tracks was equivalent to the number of flight plans, as discussed under the Air Traffic Load for an Airspace section above. This was because only the ideal ("sunny day") conditions were within the scope of these trials. Therefore, there were no cancellations and so on.

5.2.5. Message throughput

Table 8 summarises the message throughput analysis for important interfaces in the Digital Twin.

For the GCS-SCR interface, the throughput was low with just 38 messages sent per minute. This is because the interface was used to handle the few flight plans that needed strategic deconflictions. This process is usually done before operations. Thereafter, the interface was not needed. On the other hand, the GCS-SURV interface handled a larger number of messages throughout the trial run with a peak message rate of 48 messages per minute. The results indicate that the GCS-SURV interface was more likely to be a bottleneck compared with the GCS-SCR interface. The GCS-SURV interface would, therefore, require more resources and redundancy in operational deployments compared with the GCS-SCR interface. Figure 26 showed the plot of the message throughput variation with time. The message throughput for the GCS-SURV interface increased as the number of drones in the Digital Twin increased. This can be seen by comparing the figure with the number of drones in the airspace. The increase is because each drone transmits its position periodically and this data is then sent by the GCS to the SURV interface (surveillance API). Therefore, the message rate for a single drone is multiplied by the number of drones in the airspace to give the total throughput.

6. Conclusions

Digital twins are poised to revolutionize the aerospace industry by unlocking unprecedented levels of efficiency, safety, and optimization. From design and development to manufacturing, maintenance, and operations, digital twins offer a comprehensive approach to enhancing every aspect of aerospace systems. As we look towards the future, embracing this transformation technology will undoubtedly shape the next generation of aircraft and spacecraft, propelling us further into the realms of exploration and innovation. The digital twin showcased in this paper has demonstrated its potential as a valuable asset for testing airspace scenarios, facilitating the development and validation of new drone infrastructure and unmanned traffic management systems within a secure and controlled environment. By integrating synthetic testing and live virtual constructive testing, the digital twin creates a realistic and immersive simulation that accurately represents the actual airspace environment. This simulation incorporates real-time weather data and flight data, enabling thorough testing and validation of new drone infrastructure and unmanned traffic management systems while ensuring safety and security. Moreover, the adaptability of the digital twin allows for customization and application in diverse cities or scenarios, making it a versatile tool for testing and development across various contexts. Although the utilization of digital twins for airspace testing is a relatively recent concept, it is gaining traction due to its potential to enhance the safety and efficiency of drone operations. Further research is needed to explore the full range of capabilities offered by digital twins and how they can effectively address the challenges associated with airspace testing in the rapidly evolving drone industry.