UAV Operations and Vertiport Capacity Evaluation with a Mixed-Reality Digital Twin for Future Urban Air Mobility Viability

Abstract

This study presents a high-fidelity digital twin (DT) framework designed to evaluate and improve vertiport operations for Advanced Air Mobility (AAM). By integrating Unreal Engine, AirSim, and Cesium, the framework enables real-time simulation of Unmanned Aerial Vehicles (UAVs), including unmanned electric vertical take-off and landing (eVTOL) operations under nominal and disrupted conditions, such as adverse weather and engine failures. The DT supports interactive visualisation and risk-free analysis of decision-making protocols, vertiport layouts, and UAV handling strategies across multi-scenarios. To validate system realism, mixed-reality experiments involving physical UAVs, acting as surrogates for eVTOL platforms, demonstrate consistency between simulations and real-world flight behaviours. These UAV-based tests confirm the applicability of the DT environment to AAM. Intelligent algorithms detect Final Approach and Take-Off (FATO) areas and adjust flight paths for seamless take-off and landing. Live environmental data are incorporated for dynamic risk assessment and operational adjustment. A structured capacity evaluation method is proposed, modelling constraints including turnaround time, infrastructure limits, charging requirements, and emergency delays. Mitigation strategies, such as ultra-fast charging and reconfiguring the layout, are introduced to restore throughput. This DT provides a scalable, drone-integrated, and data-driven foundation for vertiport optimisation and regulatory planning, supporting safe and resilient integration into the AAM ecosystem.

1. Introduction

With the continued growth of the global population and accelerating urbanisation, both air and ground transportation systems are experiencing unprecedented pressure. Advanced Air Mobility (AAM) has emerged as a transformative concept that integrates electric vertical take-off and landing (eVTOL) aircraft into low-altitude airspace, offering the potential to reshape urban transportation [1]. The purposes of the AAM are to reduce travel times, improve intermodal connectivity, alleviate surface congestion, and support decarbonisation goals. Given that the aviation sector accounts for approximately 2.5% of global carbon dioxide emissions, AAM holds considerable promise for addressing environmental concerns while simultaneously creating new economic opportunities and supporting industrial transition [2].

However, the deployment of AAM depends not only on autonomous flight technologies, but also on the development of robust, scalable vertiports, capable of managing high-frequency operations safely under dynamic and uncertain conditions [3]. These facilities must be capable of safely and reliably managing high-frequency eVTOL operations under a wide range of operating conditions. A major operational challenge lies in understanding and optimising vertiport capacity under realistic scenarios, including adverse weather and in-flight emergencies. Existing analytical approaches often rely on simplified assumptions or static design standards, which fail to capture the complexity and dynamic interactions present in real-world vertiport environments. Critically, there remains a lack of validated frameworks to systematically quantify capacity degradation, delay propagation, or performance deterioration under disrupted conditions.

To address this gap, this study proposes a high-fidelity digital twin (DT) platform integrating Unreal Engine, AirSim, and Cesium geospatial tools to simulate a realistic 3D vertiport located at Cranfield Airport. The system is further enhanced by real-time meteorological data acquisition, mixed-reality testing with a physical Unmanned Aerial Vehicle (UAV), and automated algorithms targeting critical operational zones such as the Final Approach and Take-Off (FATO) area. Within this virtual environment, the extent to which intelligent scheduling and layout reconfiguration strategies mitigate the impact of adverse conditions on throughput and safety is investigated. The proposed DT contributes to the development of a robust evaluation framework for vertiport resilience and performance, offering critical insights for future deployment strategies within the autonomous AAM ecosystem.

Although prior studies have established robust frameworks for vertiport design and operations [4,5,6,7], physically validated testbeds that quantify operational effects under off-nominal events at vertiports are still lacking. This gap signals a clear opportunity for dedicated high-fidelity platforms. This research purposes to extend the capabilities of Microsoft AirSim by developing a high-fidelity vertiport model, which will be utilised to test various eVTOL operations and ultimately realise vertiport functionality. The vertiport has been designed following the design specifications provided by the EASA. The contributions of this paper are as follows:

• A high-fidelity DT of a vertiport was created using Unreal Engine V4.27, AirSim V1.8, and Cesium for Unreal 2.0, incorporating real-time data through Python 3.17 interfaces. The environment accurately represents key infrastructure components for simulation and analysis.
• Adverse weather scenarios were simulated to study the wind effects on eVTOL take-off and landing. Wind deflection data enabled assessment of safety margins and operational limits.
• An emergency response flow was designed for engine failure events and implemented in the DT. The model quantified delays and supported contingency planning through realistic scenario testing.
• Vertiport layouts were developed based on the EASA specifications, with stand capacity evaluated analytically. A custom simulation framework assessed delay impacts and guided layout and scheduling improvements.

The remainder of this paper is structured as follows. Section 2 introduces the related work of DTs, simulation tools, and the development of vertiports. Section 3 presents the methodology, including vertiport design, DT construction, and contingency scenario modelling. Section 4 details the development of the enhanced DT platform and its functional integration with eVTOL operations and obstacle environments. Section 5 describes the implementation and validation of contingency scenarios, intelligent detection algorithms, and operational flowcharts within the DT, including delay and deflection analysis. Section 6 introduces the mixed-reality testing framework, covering integration strategies, hardware setup, synchronisation processes, and algorithm validation. Section 7 evaluates vertiport capacity under realistic operational and contingency conditions. Section 8 summarises the conclusion, key findings, analysis results, and limitations and outlines directions for future research.

2. Literature Review

2.1. Digital Twin

The DT technology has emerged as a transformative tool in AAM, offering real-time, data-driven digital replicas of physical systems that go far beyond traditional simulation methods. By integrating sensor data, the DT enables dynamic scenario testing, predictive maintenance, and operational optimisation without relying on physical prototypes. This not only accelerates research and development and reduces costs, but also enhances safety, efficiency, and public trust. As AAM evolves, DTs are expected to play a central role in addressing its technical and regulatory challenges, reinforcing their significance in ongoing research and development efforts.

Recent developments in DT technologies have greatly advanced testing, validation, and planning capabilities for AAM. To support safe AAM operations, a DT-based approach combining real-time simulation and artificial intelligence has been introduced to enhance situational awareness and airspace coordination [8]. A multi-layered DT framework has also been designed for remote testing and certification of eVTOL vehicles, offering modularity and scalability in urban contexts [9]. In urban airspace management, DT-augmented language models have been employed to interpret Remote ID data and forecast drone speed, contributing to proactive conflict mitigation through predictive analysis [10]. Flexible replication of real-world airspace has been achieved through modular DT architectures built on Unreal Engine, AirSim, and Python, supporting the evaluation of multi-agent behaviours and early UTM service concepts [11]. Improvements in UAV dynamics modelling and sensor integration have been demonstrated using a co-simulation framework that combines MATLAB R2023 and AirSim V1.6 to validate autonomy algorithms under AAM scenarios [12].

For route and vertiport planning, DT models utilising detailed 3D city representations have proven effective in capturing spatial constraints and operational feasibility [13]. In addition, optimisation of electric aviation networks has been explored through the DT framework designed to simulate large-scale air mobility management systems [14], while real-time eVTOL teleoperation has been demonstrated using immersive DT–VR systems tailored for remote piloting tasks [15]. Enhanced realism in airspace simulation has also been achieved via co-simulation frameworks that combine BlueSky and AirSim to evaluate autonomous UAS and emerging AAM concepts [16]. Furthermore, deep learning has been integrated into the DT workflow through obstacle detection algorithms such as YOLOTransfer-DT, improving perception in dynamic UAM environments [17]. On the policy and planning side, government-led DT platforms incorporating 3D modelling and economic analysis have been applied to support strategic AAM deployment [18]. In addition, geospatial DT frameworks unifying airspace structures, vertiport siting, and trajectory datasets have been developed to ensure safe and efficient urban operations [19].

2.2. Digital Twin Simulation Tools

The most DT development adopts a modular software stack that integrates a 3D visualisation engine, robotics middleware, flight dynamics solvers, and model-based design tools to create a closed-loop sensing, decision, and actuation environment. The stack supports model-in-the-loop (MIL), software-in-the-loop (SIL), and hardware-in-the-loop (HIL) testing, data-driven controllers, and scenario-based evaluation at multiple scales. Representative simulators and their typical roles are summarised in

Table 1. Simulation and DT development tools survey.

Simulator	Ref.	Core Use/Positioning	Key Strengths	Main Limitations
AirSim	[20]	End-to-end UAS/autonomy simulation (DT-friendly)	Open-source, active community, easy CV/ML integration	Requires coding and system integration skills
Quantum3D Fixed-wing UAV Simulator	[21]	Fixed-wing with sensor/camera co-simulation	Portable; standalone or networked runs	Limited test capacity and scalability
MIT Media Lab UAV Pilot Simulator	[22]	Web-based, photo-realistic visualisation	Low hardware barrier; rapid design iteration	Limited DT and large-scale capability
CoppeliaSim, formerly V-REP	[23]	General robotics simulation	Multi-entity control; multi-language support	High resource use; slow sim speed; scalability limits
Gazebo	[24]	Robotics/ROS ecosystem	Feature-rich; broad language/platform support; big community	Steep learning curve; hardware-hungry
Hexagon Flight Simulator	[25]	Professional flight simulation	Dynamic mission tuning; rich control interfaces	Not aimed at multi-UAS; limited flexibility/customisation
MATLAB/Simulink	[26]	Modelling and control; SIL/HIL	Mature toolchain; great docs; UAS toolboxes	High-fidelity DT weaker; resource-heavy; slower sims
Simulator and Testbed for MAV Swarm Experiments (Simbeeotic)	[27]	Swarm UAS and comms	Models sensing–actuation–comms loops; distributed multi-agent	Weaker for complex infrastructure/airport scenarios
Flight Gear	[28]	Open-source flight sim (fixed-wing focus)	Many aircraft; customisable weather/scenes	Not targeted at multi-UAS; weaker fit for DT use-case
DroneSim Pro	[29]	Training/entry-level drone simulation	Easy to use; broad model coverage; low cost	Not suitable for large-scale UAS/AAM or novel airframes
X-Plane	[30]	Commercial simulator with realistic flight dynamics	Accurate model; vast add-on ecosystem; robust modelling tools	UAV features not default; some add-ons are paid
JSBSim	[31]	Open-source flight-dynamics engine embeddable in many simulators	Physics-based, highly customisable; suitable for UAV control design	Initial setup/configuration can be complex
Unreal Engine (with Cesium)	[32]	Visual DT backbone; city scale GIS; sensor and MR	Streams photorealistic 3D tiles; controllable timestep	Coding and integration effort; high hardware demand; requires external FDM

.

In practice, components are combined as required, spanning vehicle dynamics, autonomy, communications, and operator interfaces, enabling experiments from single UAS control to AAM-level operations. This composability enables closed-loop testing with rapid substitution of models, sensors, and actors, keeping the twin aligned with the evolving physical system and its operating context.

Recent work on vertiport DT tools spans planning, GIS-driven siting, and immersive validation. The Vertiport Design Tool links layout and pad assignment with battery logistics to simulate capacity, delay, safety, and noise across multifunction, hybrid, and linear configurations [33]. A GIS workflow in ArcGIS Pro automates candidate site screening and 3D airspace clearance checks from building and terrain shapefiles to produce compliant layout options and coverage analytics [34]. In addition, an immersive toolchain built in Unreal Engine with Cesium for Unreal and Google Photorealistic 3D Tiles, with city assets in SketchUp 2022 and Blender, JSBSim for flight dynamics, and Microsoft HoloLens 2 for mixed-reality HUD testing, demonstrates end-to-end procedure validation [35].

2.3. Vertiport Design and Capacity

With the expected rise of eVTOL operations in AAM, vertiport capacity and efficiency have become key constraints to scalable and reliable service. Understanding how layout, scheduling, and infrastructure design affect throughput is essential for building resilient ground systems. Recent studies have addressed this challenge through both analytical models and simulations, examining the impact of various operational and structural factors on vertiport performance. Vertiport capacity has been extensively examined from layout, operational, and modelling perspectives, reflecting its critical importance in enabling scalable AAM operations. The spatial configuration of vertiports has been identified as a key determinant of urban throughput efficiency, with systematic reviews emphasising how layout directly influences operational performance [36]. In terms of physical design optimisation, capacity sizing methods based on passenger throughput per unit area have demonstrated that the adoption of smaller eVTOL types can significantly enhance spatial efficiency [37].

Building upon these spatial considerations, queuing-based analytical models have been developed to link vertiport location with operational processes, aiming to minimise delays arising from waiting and loitering times [38]. The influence of infrastructure design parameters—such as gate-to-pad ratios and separation buffers—has also been captured through methods that define vertiport capacity envelopes, providing valuable benchmarks for strategic planning [39]. A vertiport DT toolchain integrates GIS screening, obstacle mapping and urban wind simulation with flight-dynamics models, then validates procedures in simulators [40].

Agent-based simulation has played a central role in evaluating how demand peaks, layout asymmetries, and stand configurations affect delay propagation and overall capacity [41,42]. An AnyLogic agent-based platform models vertiports, micro weather, eVTOL fleets, and passenger flows to support AAM decision-making and improve vertiport management [43]. A performance-driven framework, known as the Vertidrome Airside Level of Service, has been introduced to quantify airside flow efficiency based on operational metrics and stakeholder-specific performance criteria [44]. Further simulation studies have shown how layout design and repositioning strategies directly impact throughput, while simplified scheduling models have been used to assess how surface times and parking constraints influence pad utilisation under first-come, first-served conditions [45,46]. Operational adaptability under human supervision has also emerged as a key factor. A human-in-the-loop vertiport management framework has demonstrated that real-time decision-making by managers can substantially affect vertiport throughput, particularly under time urgency [47]. A nonlinear estimator-based controller with high-order sliding mode disturbance estimation achieves robust quadrotor position and yaw tracking under wind and parameter changes, validated by Simulink and Simcenter Amesim co-simulation [48]. Integrating adaptive Dubins planning with L1 guidance and LADRC roll control yields a drift-angle landing strategy that stabilises crosswind approaches and improves touchdown accuracy [49]. These findings collectively highlight the multifaceted nature of vertiport capacity and the need for integrated modelling approaches.

3. Methodology

3.1. Methodology Overview

This project developed a digital twin system to evaluate AI methods for UAS operations, as shown in Figure 1. A 3D operational environment of vertiport was constructed in Unreal Engine, with AirSim integrated as the vehicle simulator via its Unreal plugin. The workflow comprises three interconnected stages: acquisition and pre-processing of multi-source data to synthesise the virtual environment; compilation and deployment of AirSim within the Unreal project to enable runtime interaction; and algorithm development and assessment for normal operation, adverse weather, and engine failure, in which simulated vehicles are accessed through the AirSim APIs to generate training data, train the models, and conduct controlled evaluations. The platform-independent interfaces of AirSim provide consistent data access and vehicle control, supporting reproducible experiments across a range of autonomous algorithms.

3.2. Vertiport Design

3.2.1. Vertiport Location

Vertiport design was conducted following the Prototype Technical Design Specifications for Vertiports issued by the EASA [50]. The design process involves an in-depth analysis of several key factors. The proposed site must be assessed for its geographical suitability, including the evaluation of terrain and its proximity to existing transport infrastructure. Such an assessment ensures the integration of the vertiport into the wider transport network while minimising potential environmental impacts.

Furthermore, the layout planning phase is critical for optimising vertiport operations and passenger flow. This requires careful consideration of the spatial arrangement of landing pads, passenger terminals, and support facilities to ensure efficient, safe, and environmentally sustainable operations. This phase also includes the strategic placement of vertiport components to accommodate future expansion and the anticipated evolution of eVTOL technologies.

The vertiport location was selected to be in the parking area (rex box) adjacent to the Digital Aviation Research and Technology Centre (DARTeC), as illustrated in Figure 2. Situating the vertiport next to an established airport such as Cranfield facilitates seamless integration with existing aviation services, including maintenance facilities, air traffic control, and emergency response units.

Leveraging these existing resources can substantially reduce the operational costs and complexities that would otherwise arise from establishing such services independently for the vertiport. Furthermore, integrating the vertiport with an existing airport is likely to streamline regulatory approval processes. As Cranfield Airport already complies with a range of safety, noise, and environmental regulations, extending these certifications to encompass vertiport operations may be more straightforward.

3.2.2. Vertiport Layout

The vertiport layout was selected from existing configurations currently adopted by the industry, rather than designing a new layout from the beginning. This decision aligns with developing a DT for vertiport operations that can be readily adopted by the industry. The chosen layout was selected from the twelve options illustrated in Figure 3.

The small and parallel layout was selected for the following reasons:

• Cranfield is expected to experience low demand; therefore, medium and large layout categories were excluded.
• A parallel configuration was chosen as it provides redundancy and resilience by offering multiple FATO areas for take-off and landing, ensuring continued service during disruptions or emergencies.

The small and parallel arrangement of the vertiport infrastructure not only optimises spatial utilisation but also enables simultaneous take-off and landing operations across multiple FATO pads. This parallelism significantly reduces ground time and turnaround intervals, thereby increasing overall throughput. By coordinating aircraft flow within a compact and well-structured layout, the system supports high-frequency operations with minimal interference or congestion. This integrated approach enhances operational efficiency by streamlining traffic management, minimising scheduling delays, and enabling more predictable resource allocation. Collectively, these improvements contribute to a substantial increase in vertiport capacity, ensuring that the infrastructure can meet growing demand in urban air mobility environments.

3.2.3. Vertiport Parking Gate

The number of required Parking Positions (PPs) at the vertiport was calculated using the following formula [52]:

$$S=\sum _{i=1}^n\left({\displaystyle \frac{T_i}{60}}·N_i\right)+\alpha$$

(1)

In this expression, $S$ denotes the number of stands (or gate parking positions), $n$ denotes the number of aircraft types, $T_i$ denotes the gate occupancy time in minutes for each specific group of aircraft $i$, $T_i/60$ indicates that the time $T_i$ is being converted from minutes to hours, and $N_i$ represents the number of arriving aircraft per group during peak hours. The reserve factor α indicates the number of additional stands maintained as a buffer.

For this analysis, it is assumed that $i=1$, as the vertiport serves a homogeneous fleet of identical eVTOL aircraft. The gate occupancy time $T_i$ is set to 10 min, and $N_i$ is defined as 24 aircraft per hour, reflecting the estimated peak demand in the Cranfield area. The reserve factor $\alpha$ is set to zero, assuming no additional stands are connected to the terminal.

As a result, the calculation determines that four gate PPs are required for the proposed vertiport design.

3.2.4. Vertiport Characteristics

The characterisation of the vertiport size was carried out using the EASA guidelines for vertiport infrastructure design [50], thereby ensuring compliance with safety and regulatory requirements. Before commencing the dimensioning process, a reference aircraft was identified. This reference aircraft must be the largest expected to use the vertiport, thereby ensuring the facility can accommodate operations by all potential vehicle types. The eVTOL aircraft considered for operations and multiple scenarios testing at the Cranfield University Vertiport, as shown in

Table 2. Dimensions of 4~6 seater eVTOLs.

Aircraft	Passengers Number	Length (m)	Wingspan (m)
Joby S4	4	7.3	10.7
Vertical VX-4	4	13.1	15.0
Lilium Jet	4~6	8.5	13.9

.

The Vertical Aerospace VX-4 eVTOL aircraft has the largest dimensions among the candidate aircraft. Therefore, it has been selected as the reference aircraft for the design and will define the dimensional constraints for the FATO area as well as the remaining elements of the vertiport. The principal dimensions adopted for the vertiport design is shown in

Table 3. Vertiport dimensions [50].

Element	Dimensions (m)
FATO centre diameter	12
FATO outer diameter	22.5
FATO safety zone diameter	30
Taxi width	15
Curbs inner radius	5
Curbs centre radius	12.5
Curbs outer radius	20
PP dimensions	18 × 18
Terminal area	36 × 18

.

All of these dimensions have been derived following the EASA manual on standard characteristics and safety requirements for vertiports [50]. Figure 4 presents a top-down 2D view of the vertiport, illustrating all of the previously defined dimensions within the layout.

3.3. Enhanced Digital Twin Development

To evaluate the safety, efficiency, and resilience of AAM operations under complex real-world scenarios, a DT-driven methodology was adopted. In our prior study [6], the DT achieves decimetre-level fidelity, with mean absolute errors of 0.89 m (horizontal), 0.42 m (vertical), and 0.98 m (overall). A DT is a high-fidelity digital replica of a physical system, enabling real-time data integration, scenario simulation, and system behaviour prediction as shown in Figure 5. In this project, the DT was developed to model eVTOL–vertiport interactions, with particular focus on contingency scenarios such as adverse weather and engine failure.

The DT architecture was implemented using Unreal Engine for 3D visualisation and Microsoft AirSim for flight dynamics and sensor simulation. CAD models of the vertiport were imported and geo-referenced using Cesium, enabling high-resolution spatial context. The simulation environment was enriched with real-time weather data via the OpenWeatherMap API, providing live inputs for wind deflection modelling and visualisation. The physical–virtual interface was further extended through mixed-reality testing, integrating a DJI Tello drone with the AirSim simulation via a Python client and ArUco marker-based FATO detection [32,53,54].

This DT framework enabled multiple capabilities essential for AAM safety assessment:

• Real-time operation visualisation and scenario execution under high-fidelity simulation;
• Predictive maintenance and resource optimisation, by modelling vertiport asset use and failure points;
• Emergency procedure validation, including algorithmic responses to engine failure and wind deviation thresholds;
• AI algorithm testing, with precision landing implemented through intelligent control routines validated in both virtual and physical environments.

By facilitating risk-free testing of eVTOL operations, the DT offered an effective methodology for evaluating vertiport layout efficiency, assessing contingency readiness, and optimising traffic throughput. The platform provides a reproducible, extensible, and data-driven foundation for simulating urban air mobility infrastructures, aligning with industry trends toward autonomous and intelligent AAM systems.

3.4. Contingency Scenario Modelling

3.4.1. Adverse Weather Modelling and Operation

Operating eVTOL in adverse weather, particularly under high wind conditions, presents distinct challenges. Wind gusts and variable wind speeds can hinder the ability of the aircraft to take off, land, or maintain a stable hover, thereby directly affecting operational safety and efficiency. To mitigate these risks, eVTOL operators should implement robust real-time weather monitoring systems, including wind gust alerts, to enable proactive adjustments to flight operations. In addition, the establishment of contingency plans with alternate vertiports ensures preparedness for sudden weather changes. A focused approach to managing wind-related impacts allows operators to adapt dynamically to evolving weather conditions.

Within the DT framework for eVTOL and vertiport operations, the analysis of wind deflection has been prioritised as a critical weather factor due to its measurable impact on both hardware and software systems. Simulating sensors within DTs under rain or fog conditions is highly complex and frequently results in operational delays until visibility improves. By contrast, the variability of wind speed spans a broad spectrum, ranging from normal operating conditions to extreme events requiring temporary shutdowns. This variability enables a more practical and extensive classification of operational scenarios, thereby supporting targeted research. As a result, focusing on wind offers an optimal balance of feasibility, observable effects, and research applicability.

3.4.2. Engine Failure Workflow

For this use case, the primary objective is to study and evaluate the contingency scenario of an aircraft experiencing engine failure and to assess how this affects the standard operations of the vertiport.

The definition of engine failure must be established. It is understood as the malfunction of any engine-related system that necessitates the removal of the engine from service. As a result, standard vertiport operations cannot proceed, and specific contingency measures must be implemented. As illustrated in Figure 6, an engine failure can occur at any stage of the standard operational sequence. Therefore, the response will vary depending on the phase in which the failure occurs.

This use case focuses on the actions required from the vertiport side, outlining the necessary procedures to be followed. These procedures will subsequently be visualised using the DT. In addition, to assess the operational impact of engine failure, the delays generated by such a scenario will be evaluated. A pre-planned daily schedule will be used as a reference to quantify the delay caused by a single engine failure event. The outcomes of this use case will include the following:

• A flowchart serves as a reference protocol in the event of engine failure.
• Digital data generated within the DT environment.
• A delay analysis was conducted using an external computational tool.
• These results inform mitigation strategies aimed at reducing delays and restoring standard vertiport operations as efficiently as possible.

3.5. Capacity Analysis for Vertiport Operations

This section outlines the methodology adopted to evaluate the operational capacity of a vertiport under representative AAM mission cycles. The objective is to develop a structured capacity assessment framework that can be integrated within a DT environment to support scalable, conflict-aware vertiport design and scheduling.

3.5.1. Definition of Operational Cycle

Vertiport capacity evaluation begins with defining a complete eVTOL operational cycle. This includes ground taxiing from the PP to the FATO, vertical take-off, cruise phase (excluded from vertiport modelling), landing, and return taxi to the parking stand. By formalising this sequence, the model ensures consistency in temporal and spatial resource usage simulation across multiple vehicle operations.

3.5.2. Process Segmentation and Throughput Modelling

The operational cycle is segmented into discrete, measurable phases (e.g., taxiing, take-off, landing, turnaround), enabling the modelling of each process individually. For each segment, estimated durations, conflict points, and resource dependencies are identified. These segmented processes are then mapped onto critical vertiport infrastructure components, such as FATO pads and parking stands, allowing identification of system bottlenecks and constraints on parallelism.

3.5.3. Constraint Layering and Bottleneck Identification

The modelling approach accounts for physical and procedural constraints that limit vertiport throughput. These include the following:

• Infrastructure constraints (e.g., number of FATOs, availability of taxiways and gates).
• Operational constraints (e.g., required separation buffers between movements on the same FATO).
• Turnaround constraints (e.g., time required for passenger or cargo handling).
• Charging constraints (e.g., duration of battery recharge and availability of power infrastructure).

By simulating these constraints both individually and in combination, the methodology supports the derivation of realistic upper and lower bounds for vertiport capacity under varying assumptions.

3.5.4. Disruption Propagation and Recovery Modelling

To account for irregular operations, such as engine failure events, the methodology incorporates contingency scenario analysis. These scenarios are defined in terms of disruption type, duration, and affected infrastructure elements. The DT framework is used to simulate resulting propagation delays and queuing effects. This enables the evaluation of system resilience, identification of failure-induced capacity reductions, and development of mitigation strategies (e.g., buffer allocation, rescue procedures).

3.5.5. Digital Twin Integration

All methodological steps are embedded within a DT platform, enabling high-fidelity replication of vertiport layouts, aircraft trajectories, and operational schedules. This digital environment enables the iterative testing of scheduling policies, capacity enhancement strategies, and disruption responses without requiring physical deployment. The simulation outputs provide decision support for both vertiport designers and airspace regulators.

4. Enhanced Digital Twin Vertiport Development

4.1. Digital Twin Development Roadmap

The DT development of the Vertiport Test Platform (VTP) and related infrastructure adopted a staged modelling approach, combining 2D drafting, 3D modelling, and simulation to achieve spatial accuracy and operational relevance. A list of the surrounding obstacles of the VTP is shown in

Table 4. List of VTP surrounding obstacles.

Obstacle ID/ Designation	Obstacle Type	Obstacle Position	Elevation/Height		Obstruction Lightning Type/Colour	Remarks
(VP/EGTC2353)	BUILDING (AIRC320)	52°04′12.9″ N 03°738.8″ W	460 FT	100 FT	Yes/Red	White Roof
(VP/EGTC2354)	BUILDING (DARTeC105)	52°04′03.4″ N 03°73′9.8″ W	425 FT	65 FT	No	Light Grey Roof
(VP/EGTC2355)	BUILDING (B50)	52°04′12.9″ N 03°74′2.53″ W	415 FT	55 FT	No	White Roof
(VP/EGTC2356)	BUILDING (121)	52°04′11.6″ N 03°74′2.6″ W	392 FT	32 FT	No	Red Building
(VP/EGTC2357)	BUILDING (321)	52°04′10.1″ N 03°74′4.5″ W	382 FT	22 FT	No	Glass Structure

. Two-dimensional plans were created in AutoCAD 2023, scaled using precise dimensions, and geospatially aligned with Google Maps overlays. These were then imported into Solid Edge to generate 3D models, incorporating surface textures for aprons and taxiways to improve visual realism.

The completed models were integrated into Unreal Engine 4, serving as the DT platform and enabling interactive visualisation of vertiport operations. As shown in Figure 7, the layout was based on regulatory and spatial criteria, including two FATOs, four parking stands, and a 60-metre separation between FATOs, reflecting site-specific constraints.

As shown in Figure 8, the terminal was modelled with enhanced finishes and lighting to achieve a realistic representation in Unreal Engine. The fidelity of the DT was further refined through the application of detailed textures, material properties, and environmental effects, closely replicating real-world conditions.

4.2. Functional Integration of eVTOL and Obstacle Environment

The eVTOL model, as outlined in a previous chapter, was provided by academic partners and was seamlessly integrated into the Unreal Engine environment without requiring modification. This enabled immediate deployment in simulation and testing scenarios. Furthermore, a catalogue of obstacles was developed, replicating the structure of the list presented in the Aeronautical Information Publication (AIP) for Cranfield Airport in the UK [55]. This inventory adheres to the same organisational framework as its counterpart in the AIP UK.

When an eVTOL enters a FATO, the associated trigger volume changes the display status from “Available” to “Unavailable.” This function provides a clear visual indicator of the operational state of the FATO, helping to manage traffic in the DT environment in a way that reflects real-world air traffic control procedures.

As shown in Figure 9, the development of the DT environment demonstrates academic precision, from accurate 2D designs to detailed 3D models, intending to create a reliable and scientifically valid virtual testing space. The use of high-resolution mapping data and realistic materials strengthens the role of DTs in supporting AAM infrastructure planning. This reflects the need for interdisciplinary input from urban planning, aeronautical engineering, and computer science.

In Unreal Engine, FATOs are represented by coded trigger volumes that function as built-in sensors. These volumes are programmed using the visual scripting system of the engine, known as Blueprints, to display dynamic messages indicating the availability status of each FATO.

4.3. Cranfield Vertiport Layout and Operational Scenarios

The final Cranfield Vertiport model, developed using DT technology with Unreal Engine integrated with AirSim, is illustrated in Figure 10.

The design adopts a compact parallel layout comprising one terminal and two FATOs. The vertiport includes a terminal building, parking pad, taxiways, and FATOs. The terminal is positioned on one side of the vertiport, with a public access gate for passenger entry and exit, and two boarding gates facing the pad for embarkation and disembarkation. The layout features four parking bays, each oriented to face the terminal when eVTOLs are parked. Aircraft are towed along the taxiway using hooks aligned with the centreline, initially towards the departure FATO and then to the designated holding position. The vertiport taxiway network includes a route linking the terminal and FATO, as well as an auxiliary taxiway connecting the FATO to the parking pad, enabling eVTOL repositioning, FATO reassignment, or transfer to the maintenance facility.

5. Contingency Scenario Modelling and Validation

5.1. Adverse Weather

This use case focuses on the simulation of vertiport operations under adverse weather conditions through a DT framework. It outlines the procedural adaptations necessary to maintain operational continuity in challenging meteorological scenarios, providing a structured representation of vertiport response mechanisms. The virtual environment replicates real-time weather conditions captured externally, thereby enabling realistic scenario modelling within the digital platform. In addition to supporting situational analysis, the DT also generates synthetic datasets that facilitate model training and operational evaluation. Furthermore, it has been employed to simulate take-off and landing sequences during adverse weather events, contributing to the assessment of contingency protocols and system resilience.

To enable dynamic weather simulation, real-time environmental data were integrated into the virtual platform using the OpenWeather API. This involved issuing HTTP requests to retrieve live weather parameters, such as temperature, humidity, wind speed, direction, and visibility, in JSON format. The data were subsequently imported into Unreal Engine, where the ‘JsonUtilities’ class was used to parse the JSON string into structured variables suitable for simulation.

A visual scripting system called Blueprint was used in Unreal Engine to extract and present weather indicators. These values were assigned to variables and displayed on the DT interface in real time. Once data was received and processed, weather conditions within the DT were synchronised using Python embedded in the AirSim environment.

Using synthetic data from the DT, a wind speed threshold is established to determine safe take-off conditions at the vertiport. Simulations under varying wind conditions are conducted to evaluate eVTOL lateral deflection during take-off and landing. In the context of eVTOL vertiport operations, wind deflection is defined as the radius of a notional circle, representing the maximum lateral displacement of an eVTOL from its intended position, without specifying a directional path. This deflection results from variable lateral wind forces during critical flight phases. Figure 11 shows the concept illustration of deflection.

The safety procedure, presented in Figure 12a, comprises steps for assessing weather, verifying clearance, and maintaining communication. Its iterative structure supports repeated take-offs and contingency planning. As the eVTOL approaches the FATO, meteorological alerts trigger a re-evaluation. If conditions are deemed safe, take-off proceeds. If wind speeds exceed the 20 m/s threshold, the delay is logged via the Common Information Service Provider (CISP), and obstructions at the FATO are cleared. Passengers are informed of delays, and an alternate route may be confirmed. Once validated, take-off continues along the revised path with updated passenger communication.

Landing follows a structured assessment as shown in Figure 12b, including descent management, alternate routing, and weather monitoring. The flowchart contains a decision node evaluating whether wind speeds remain below the 20 m/s threshold. If landing is safe, the aircraft proceeds to the FATO. If unsafe, it holds position pending weather improvement. If no improvement is forecast, the aircraft diverts to the nearest vertiport, or a distant airport if necessary, considering battery constraints. Updates are issued via the CISP. Passenger communication remains essential throughout to maintain situational awareness. The process is designed for repeat use, ensuring continued operational safety and coordination.

5.2. Engine Failure

When an engine failure notification is received from an aircraft operating at the vertiport, following precise contingency procedures is critical to avoid cascading issues across vertiport subsystems.

Figure 13 illustrates the contingency flowchart. Green boxes indicate potential starting points, corresponding to specific scenarios as follows.

• Take-off or landing: If engine failure occurs during these phases, the aircraft must land promptly, passengers must disembark, and the severity of the engine failure is assessed. Depending on whether the aircraft can be quickly removed from the FATO, subsequent operations either proceed or are rescheduled.
• Emergency landing: An aircraft experiencing engine failure during flight is prioritised to land at an available FATO. If none are immediately available, aircraft occupying the FATO or taxiways are redirected to parking areas, allowing the emergency aircraft to land. Post-landing, standard operation resumes or layouts are adjusted as needed.
• Taxiing: For engine failures detected during taxiing, if systems allow, the aircraft is redirected to a hangar instead of occupying a FATO. This resolution ensures that standard operation quickly resumes.

Figure 13. Engine-failure workflow for vertiport operations in DT.

Figure 13. Engine-failure workflow for vertiport operations in DT.

All scenarios share the objective of swiftly resolving contingencies, returning to normal operations, ensuring safety compliance, and reporting incidents clearly.

Calculating operational delays requires the use of a standard schedule, which enables comparisons between expected and actual operation times when failures occur. Given that the expected operational demand at the Cranfield Vertiport is approximately 4 operations per hour, this figure is doubled during contingency analysis (8 ops/h) in order to reflect delays and support realistic planning for future activities. Daily operational scheduling, as presented in

Table 5. Daily operations schedule.

Flight ID	Origin	DEST	DEP Date	DEP Time	ARR Date	ARR Time	FATO	PP	Oper	Expt Time
CFV038	Cranfield	Edinburgh	3 December 2024	8:00:00	3 December 2024	8:30:00	1	1	DEP	8:00:00
CFV035	Edinburgh	Cranfield	3 December 2024	7:37:30	3 December 2024	8:07:30	2	4	ARR	8:07:30
CFV040	Cranfield	B‘ham	3 December 2024	8:15:00	3 December 2024	8:45:00	1	2	DEP	8:15:00
CFV037	Manchester	Cranfield	3 December 2024	7:52:30	3 December 2024	8:22:30	2	1	ARR	8:22:30
CFV042	Cranfield	London	3 December 2024	8:30:00	3 December 2024	9:00:00	1	3	DEP	8:30:00
CFV039	Bristol	Cranfield	3 December 2024	8:07:30	3 December 2024	8:37:30	2	2	ARR	8:37:30
CFV044	Cranfield	B‘ham	3 December 2024	8:45:00	3 December 2024	9:15:00	1	4	DEP	8:45:00
CFV041	B‘ham	Cranfield	3 December 2024	8:22:30	3 December 2024	8:52:30	2	3	ARR	8:52:30
CFV046	Cranfield	London	3 December 2024	9:00:00	3 December 2024	9:30:00	1	1	DEP	9:00:00
CFV043	Manchester	Cranfield	3 December 2024	8:37:30	3 December 2024	9:07:30	2	4	ARR	9:07:30
CFV048	Cranfield	Manchester	3 December 2024	9:15:00	3 December 2024	9:45:00	1	2	DEP	9:15:00
CFV045	B‘ham	Cranfield	3 December 2024	8:52:30	3 December 2024	9:22:30	2	1	ARR	9:22:30
CFV050	Cranfield	B‘ham	3 December 2024	9:30:00	3 December 2024	10:00:00	1	3	DEP	9:30:00
CFV047	London	Cranfield	3 December 2024	9:07:30	3 December 2024	9:37:30	2	2	ARR	9:37:30
CFV054	Cranfield	B‘ham	3 December 2024	9:42:30	3 December 2024	10:07:30	1	4	DEP	9:42:30
CFV049	London	Cranfield	3 December 2024	9:22:30	3 December 2024	9:52:30	2	3	ARR	9:52:30

, provides a structured basis for delay analysis.

5.2.1. Utility of the DT

The primary role of the DT in this use case is generating digital data to simulate and visualise multiple contingency scenarios, assisting decision-making without physical testing. Unreal Engine provides animated scenarios controlled through blueprints linked to specific operational animations.

The DT captures and exports eVTOL trajectories within the vertiport. Coordinates generated within Unreal Engine are exported to Excel for external integration, linking simulated and actual operations. The blueprint of this part is shown in Figure 14. Additionally, Unreal Engine indicates the real-time availability of FATOs via visual labels triggered by predefined conditions, as illustrated in Figure 15.

5.2.2. Code Explanation

The engine failure scenario analysis aims to proactively manage and minimise operational delays. Due to limitations in the visual-based dynamic representation of Unreal Engine, C++ coding is used to simulate operations, calculate delays, and enhance flexibility. The C++ approach allows adaptive layout management and facilitates detailed delay calculations and operational insights.

Delays typically result from blocked critical areas (e.g., taxiways or FATO). For instance, engines are activated only on FATOs; therefore, failures during taxi or parking involve moving eVTOLs to hangars, incurring minimal delays (~5 min). Conversely, extended FATO occupation (over 20 min) prompts layout changes or cancellations to minimise disruption. Optimal daily scheduling remains essential for effective delay mitigation.

Object-oriented programming in C++ manages eVTOL and layout interactions efficiently. Layouts defined from Unreal Engine coordinates identify specific vertiport sections, facilitating operational planning and delay handling. Attributes, including vehicle availability, trajectories, and malfunctions, guide operational flow.

The central algorithm oversees daily operational sequencing, checking operational readiness, rearranging schedules during disruptions, and adjusting for prolonged delays by reallocating operations to available FATOs. Figure 16 depicts algorithmic workflow logic, highlighting decision-making processes during operational adjustments.

5.3. Intelligent Algorithm for FATO Detection

To enhance the functionality of the vertiport DT, intelligent algorithms have been tested to detect and analyse critical elements within the virtual environment. One such element is the FATO area, essential for the safe operation of eVTOL aircraft. The methodology focuses on the application of intelligent algorithms, particularly through the implementation of the Hough Circle Transform using the OpenCV, for FATO detection within the DT.

The Hough Circle Transform serves as a feature extraction method for detecting circular forms in images, particularly in noisy conditions or when circles are only partially visible. It transforms points from the original image into a parameter space where circles are represented explicitly, which simplifies their detection.

For identifying circles, three parameters are used: the centre coordinates ($x_{centre}$, $y_{centre}$) and the radius ($r$). Points from the original image that form a circle converge at a single location in parameter space, indicating both the centre and the radius of the detected circle.

In OpenCV, the HoughCircles function implements the Hough Circle Transform. This requires preliminary edge detection. Gaussian blur is first applied to smooth the image, followed by the Canny edge detector to extract edges, and then circle detection is performed. To support efficient FATO detection, OpenCV-based image pre-processing is conducted, including noise filtering, edge extraction, and greyscale conversion to reduce processing complexity. Using the HoughCircles function, circular patterns are then detected from the processed images. Detection parameters, such as radius limits, accumulator resolution, and threshold values, are tuned to match the expected geometry of the FATO area.

After circle detection, further analysis is conducted to ensure the correct identification of the FATO. Detected circles are filtered by size and location using robust edge clarity metrics to retain only those consistent with the actual layout of the FATO. Once the FATO area is correctly identified, its coordinates are transmitted to the eVTOL navigation system. This allows for real-time adjustment of the approach and departure trajectories of the eVTOL, ensuring alignment with the designated landing area and supporting safe and continuous operations.

5.4. Test Validation Result

5.4.1. Operational Flowchart Implementation and Testing

The development of a DT provides a dynamic platform for simulating and evaluating advanced vertiport operations. Operational flowcharts serve as functional blueprints within the DT, translating complex sequences into structured animations that encompass pre-flight and tactical procedures.

The pre-flight flowchart, as shown in Figure 17, outlines key stages such as registration, preparation and verification, and boarding, which cover credential checks, checklist completion, and passenger transfer from the terminal. The tactical operations flowchart, as shown in Figure 18, illustrates the sequence from taxi clearance to the FATO, take-off under UTM or ATC authorisation, and subsequent landing, where the eVTOL reduces altitude, re-establishes contact, and taxis to a parking stand with ground support. The process concludes with passenger disembarkation, with immigration procedures undertaken if required. These flowcharts are converted into three-dimensional animations within the DT to simulate real-time operations and analyse system-wide interactions. A representative scenario, engine failure, is used to evaluate system resilience under stress. Through flowchart-based simulation, each process step is scrutinised, enabling the quantification of delays and operational disruptions. The results form an empirical basis for assessing emergency protocols and refining strategies to minimise response time and enhance safety.

5.4.2. DT Delays Evaluation

This section evaluates delays caused by engine failure and FATO unavailability, particularly given that eVTOL charging takes approximately 30 min and operations rely on a single push/pull mechanism, permitting one action at a time. The analysis quantifies delayed operations, total delay duration, and optimal rearrangement strategies to reduce disruption, with emphasis on redirecting operations to the available FATO during defined periods, as shown in

Table 6. Delays results for a single engine failure.

Engine Failure Duration (min)	Max Delay (min)	Mean Delay (min)	Number of Operations with Delay	Total Delay (min)	Total Operation Impact
5	0	0	0	0	0
10	0	0	0	0	0
15	5	3.96	8	31	22
20	10	3.35	13	43	19
30	20	11.23	9	101	13
45	35	18.21	14	254	16
60	55.22	23.20	31	719	59

.

When an engine failure occurs, the eVTOL is moved from the FATO to the hangar, rendering it temporarily unusable and halting concurrent operations. The duration of evacuation directly affects subsequent schedules.

Delays under 15 min tend to have limited impact due to alternating departure and arrival cycles being spaced 5–10 min apart, though push/pull procedures and human factors introduce additional time. Significant delays arise once a specific FATO becomes a dependency, leading to bottlenecks and potential parking congestion. For instance, a 15 min delay affects 8 operations, whereas a 20 min delay impacts 13. Interestingly, after 20 min, the number of delayed operations follows a nonlinear trend: 14 are impacted at 45 min, although fewer (9 operations) are impacted at 30 min, with a longer cumulative delay of 1 h and 41 min.

These variations in the number of delayed operations and total delay are visualised in Figure 19 and Figure 20.

This suggests 30 min may minimise the number of affected operations, but for delay duration, the 20 min threshold is more efficient: maximum delay is 10 min and average 3.34 min, compared to 15 and 11.22 min under 30 min conditions. Hence, a 20 min rearrangement strategy slightly increases delayed operations but significantly reduces total delay, preserving flow without major disruption.

To eliminate delay, a FATO reassignment strategy applied at the onset of a 20 min disruption window reroutes operations to the functioning FATO. This proactive switch introduces no delay, even if one FATO remains unavailable throughout the day. The flight plan adopts a one-at-a-time operational rule, and the push/pull configuration enables smooth sequencing, thereby maintaining throughput at high volumes. The maximum tolerable delay under this layout should be adjusted according to vertiport congestion levels.

A further evaluation was conducted under a complete disruption scenario, where both FATOs become unavailable due to sequential engine failures, 60 min for FATO 2 and 30 min for FATO 1. Four layout strategies were tested. The results indicate that layout changes made only after both failures cannot recover the delay, while early redistribution during the first failure substantially reduces it. The initial adjustment alone proved sufficient to mitigate operational disruption, as shown in

Table 7. Final results for two engine failures.

Change of Layout	Max Delay (min)	Mean Delay (min)	Number of Operations with Delay	Total Delay (min)	Total Operation Impact
No Change FATO 2; No Change FATO 1	55.22	23.20	31	719	59
No Change FATO 2; Change FATO 1	55.22	23.20	31	719	59
Change FATO 2; No Change FATO 1	28.37	14.83	14	207	18
Change FATO 2; Change FATO 1	28.37	14.83	14	207	18

.

5.4.3. Timestamp Validation Results

As shown in

Table 8. Timestamp validation results.

Timestamps	DT Calculation	Mission Planner Simulation
PP1-FATO1	53	55
FATO2-PP1	67	71
PP2-FATO1	63	65
FATO2-PP2	57	61
PP3-FATO1	73	79
FATO2-PP3	47	49
PP4-FATO1	80	86
FATO2-PP4	39	41
Take-off	50	60
Landing	50	60

, there is a minimal difference in the duration calculated for ground movement routes between the Mission Planner (MP) simulation outcomes and the theoretical results from the vertiport DT. In the theoretical approach, travel distance is measured with the CAD model in Unreal Engine. A limitation of this method is its assumption of fixed speed, which does not reflect conditions where object velocity varies continuously.

The conversion of DT layout to waypoints (WPs) in MP is shown in Figure 21. The MP simulation addresses this limitation by incorporating dynamic speed variations, enhancing the reliability of the sensor-based software under realistic operational conditions. The process of time measurement within MP is illustrated in Figure 22, which supports the delay analysis under the engine failure scenario. However, synchronising the vertiport layout between the DT and the MP environment can introduce inconsistencies due to potential misalignment in coordinates.

Despite these limitations, the table confirms strong agreement between the two approaches. Therefore, the analysis conducted for visualising the impact of delays on standard operations under the engine failure scenario is considered consistent with real-world expectations and operational accuracy.

5.5. Adverse Weather Results and Analysis

5.5.1. Wind Deflection Results

In the adverse-weather use case, in-depth analysis is conducted to assess the impact of wind on eVTOL operations within the vertiport environment. The effects of wind are simulated in the DT using data obtained from the OpenWeather API. The evaluation is based on linear modelling techniques. As a result, a comprehensive operational procedure for wind classification is developed based on the analysed data.

The deflection distance caused by wind is measured within the DT. The dataset containing deflection values and corresponding wind speeds is summarised in

Table 9. Wind speed vs. distance from origin.

Wind Speed (m/s)	Distance from Origin (m)
1.0	0.003847
3.0	0.036407
5.0	0.099275
7.0	0.192068
9.0	0.314795
10.0	0.380739
11.0	0.459461
13.0	0.647580
15.0	0.857458
17.0	1.093058
19.0	1.354887
20.0	1.481998
21.0	1.626389
23.0	1.943993
25.0	3.062898
27.0	3.142529
29.0	4.157102
30.0	4.265534

. The deflection increases with wind speed, indicating a linear relationship between the two variables. Linear models are applied to identify this pattern. Based on the analysis, an estimation model is developed to predict deflection values for different wind speeds.

5.5.2. Linear Estimation Models

Linear interpolation and regression are foundational data modelling techniques with distinct purposes. Interpolation estimates unknown values within a known range, assuming linear change between points. It infers intermediate values from this relationship. Regression models the relationship between a dependent variable and one or more independent variables by fitting a linear equation to the observed data [56], aiming to minimise the discrepancy between the predicted and actual values.

The graphs highlight the importance of selecting a suitable model for predicting deflection distances from wind speeds. The regression model, as shown in Figure 23a, suggests a proportional relationship but incorrectly predicts negative values below 5 m/s, which is physically unrealistic.

In contrast, the interpolation model, as shown in Figure 23b, better reflects the nonlinear trend, adapting to data curvature and ensuring non-negative predictions. This aligns with physical constraints and is therefore more suitable, particularly for DT applications in eVTOL operations. It provides a more realistic representation of how deflection responds to varying wind speeds, as confirmed by the evaluation metrics in

Table 10. Evaluation metrics.

Metric	Linear Regression	Linear Interpolation
MAE	0.143702	0.020284
MSE	0.025515	0.000565
RMSE	0.159734	0.023780

.

5.5.3. Wind Deflection Polynomial Interpolation Equation

As the linear interpolation model is deemed more suitable for estimating deflection values, this section presents the equation used to compute these values based on the principle of interpolation. The calculations result are shown in Figure 24 and Table 11. The deflection $a$ corresponding to the wind speed $x$ (5.3 m/s in this case) is given by

$$a=(x-x_1)\times {\displaystyle \frac{(y_2-y_1)}{(x_2-x_1)}}$$

(2)

where

• $x=5.3$ (the wind speed you want to find the deflection for);
• $x_1=5$ and $x_2=5$ (the lower and upper bounds of the wind speed range);
• $y_1=0.036$ and $y_2=0.099$ (the known deflection values at $x_1$ and $x_2$, respectively).

The data for wind speeds of 5 m/s and 7 m/s in Table 9.

Figure 24. Sample polynomial calculations.

Figure 24. Sample polynomial calculations.

Table 11. Sample polynomial calculations.

Wind Speed (m/s)	Interpolated Deflection Distance (m)
5.3	0.113194
6.1	0.150312
7.2	0.204341
9.2	0.328984

Table 11. Sample polynomial calculations.

Wind Speed (m/s)	Interpolated Deflection Distance (m)
5.3	0.113194
6.1	0.150312
7.2	0.204341
9.2	0.328984

5.5.4. Wind Deflection User Interface

The result of the adverse-weather scenario is a user interface (UI) that operates alongside the DT.

Table 12. Weather data visualisation.

Names	Values
Temperature	12.35 °C
Wind speed	2.24 m/s
Latitude	52.07
Longitude	−0.623
Description	Overcast clouds

and Figure 25 shows the weather data that was collected via the API. This supplementary UI serves data visualisation and analysis purposes. It supports the DT by retaining the obtained data and enabling further evaluation using numerical methods such as machine learning models (e.g., linear models).

The UI also displays a wind threshold warning in the lower-left corner, based on the wind classification operational levels defined in

Table 13. Wind speed operational categories.

Wind Speed/Gust Speed (m/s)	Wind Categories	Description
W/G < 8.75	Nominal Wind-Operational (WO)	Perform standard operations with increased vigilance. Adjust timings based on wind intensity.
8.76 < W/G < 10.29	Wind Advisory (WA)	Implement advisory procedures. Increase intervals and response times proportional to wind speed.
10.30 < W/G < 20	Wind Warning (WW)	Enforce warning protocols. Significantly increase intervals and response times. Consider operational limits.
W/G > 20	Wind Shutdown (WS)	Cease operations if the wind speed surpasses safe operational thresholds. Resume only when conditions improve.

. This classification process uses deflection outcomes alongside findings from the literature [52].

Overall, the output supports dynamic threshold setting for vertiport operations, as clearly outlined in the operational flowchart. The UI is implemented using the AirSim Python client.

6. UAV-Based Mixed-Reality Testing

6.1. Categories of Mixed-Reality Testing

Mixed-reality testing refers to the process of evaluating the integration, performance, and user experience of mixed-reality applications or systems. Mixed reality combines real-world and virtual elements, enabling interactions that bridge the physical and digital domains. This form of testing is essential to ensure that mixed-reality applications operate as intended, offering users a seamless, intuitive, and engaging experience. As mixed reality becomes increasingly embedded in AAM platforms, including simulation environments and DT architectures, the need for rigorous testing methodologies has become more pronounced. Effective testing contributes to system robustness, operational reliability, and end-user trust in the fidelity and responsiveness of the virtual–physical interface.

The concept of mixed-reality testing encompasses the systematic evaluation of integration, performance, and user experience across applications that combine physical and virtual environments. This process is critical to ensure that mixed-reality systems deliver a consistent, immersive, and functionally coherent experience. Various testing categories address different aspects of system functionality, environment interaction, and user engagement. The principal categories of mixed-reality testing include the following:

• Integration testing;
• Performance testing;
• User experience testing;
• Environment testing;
• Safety and compliance testing;
• Interoperability testing.

6.2. Achieved Testing Types

6.2.1. Integration Testing

Integration testing in mixed reality focuses on ensuring seamless cooperation among heterogeneous system components, including hardware such as sensors and cameras, software modules comprising application logic and interfaces, and user-facing devices such as displays and control panels. Within mixed-reality environments, the synchronisation of physical and digital subsystems is critical. For example, in medical applications, real-time physiological data may be projected onto a three-dimensional organ model to support intraoperative decision-making. Any deviation in timing or data alignment may introduce perceptual inconsistencies, degrade system credibility, or compromise mission outcomes.

The integration testing process generally begins with the isolated validation of the functionality of each component. Once verified, components are combined into subsystems to examine interoperability and joint behaviour under nominal conditions. Particular emphasis is placed on verifying data exchange across system boundaries, ensuring that updates occur continuously and in real time, without introducing perceptual delays or loss of coherence across the mixed environment.

6.2.2. Performance Testing

Performance testing examines how reliably a mixed-reality system maintains operational integrity under diverse computational loads. This is essential for applications that demand sustained high performance, particularly those incorporating complex graphics rendering, low-latency sensor input processing, or multi-threaded simulation logic. In domains such as aviation or urban air mobility simulation, performance degradation may lead to perceptual mismatches, disorientation, or delayed feedback, all of which significantly impair training efficacy or mission realism.

The assessment of performance typically involves simulating a range of usage conditions, from baseline operational loads to extreme stress scenarios. Key metrics include responsiveness to input, system throughput, memory and GPU consumption, and visual frame consistency. Evaluators also monitor the ability of the system to maintain real-time execution without perceptible interruptions or functional errors, which is fundamental to preserving user immersion and interaction fidelity.

6.2.3. Environment Testing

Environment testing evaluates how reliably a mixed-reality system operates under various physical conditions, including changes in lighting, spatial configurations, ambient noise, and temperature. Such factors are critical, particularly for outdoor or dynamic operational scenarios. For instance, systems deployed in construction or vertiport environments must perform consistently under direct sunlight, fluctuating weather, and variable terrain.

Key assessments include testing the system in diverse locations to observe performance variation, evaluating adaptability to environmental shifts such as lighting and obstructions, and validating sensor accuracy in capturing and reflecting real-world data within the virtual system.

Within this project, environment testing was conducted to ensure that the DT model of the vertiport could replicate real-world behaviour with high fidelity. Special attention was given to testing intelligent algorithms, such as automated landing, across both simulated and actual settings, confirming their robustness and reliability. Additionally, the synchronisation between physical actions and digital reflections was examined to ensure seamless integration, supporting operational readiness and system reliability in practical applications.

6.2.4. Hardware Requirements

The experimental mixed-reality framework required a set of hardware components to support physical operations, digital simulation, and system synchronisation. These elements enabled the integration of physical drone dynamics with their virtual counterparts in a controlled environment.

A DJI Tello drone was employed as the primary physical platform to simulate movement and behaviours replicated by the DT within the virtual simulation. AirSim, running on Unreal Engine, served as the core simulation environment, accurately modelling eVTOL dynamics and physical interactions in real time [57].

Two laptops were utilised in the testing setup. One was dedicated to executing DT simulations, managing data processing, and visualising the virtual counterpart of the drone. The second laptop was responsible for generating and managing virtual elements, enhancing the complexity and fidelity of the simulated environment.

An ArUco marker (6 × 6, 250 bit) was used to support high-precision tracking and positioning within the test arena. This was essential for accurate spatial alignment between virtual objects and the physical environment. The marker used in the experiment is shown in Figure 26a: 6 × 6 250 ArUco Marker; the mixed-reality test environment is shown in Figure 26b.

A Logitech webcam (720p resolution) was placed in the flight zone to observe and record drone movements, enabling real-time feedback and subsequent data analysis. An external camera was additionally deployed to enhance the integration of virtual elements and support a more immersive simulation experience.

Supplementary tools included the measuring tape and duct tape. The measuring tape ensured accurate alignment of virtual and physical domains by precisely quantifying distances and displacements during testing. Duct tape was used to mark reference points such as take-off and landing positions, essential for reproducible test conditions.

6.2.5. Testing Execution and Evaluation

The testing environment was adapted from the main operational layout and simplified to focus exclusively on critical regions, such as the landing pad and the FATO area. This selective configuration enabled more controlled assessment of specific functions and interactions within the mixed-reality setup. The mixed-reality calibration and visualisation pipeline for UAV testing is shown in Figure 27.

Based on measurements between the test map and the actual scale, a scaling factor of 78.334 was determined, indicating that the DJI Tello drone and its test setting were 78.334 times smaller than the simulated environment. A synchronised command framework was implemented using Python to establish a WiFi bridge between the Tello drone and the AirSim simulation. This mirroring technique ensured both drones received identical command sequences and executed them in parallel. Such synchronisation was essential for verifying the reliability and consistency of command execution across the physical drone and its virtual counterpart in AirSim.

A key feature of this setup involved overlaying the AirSim drone camera feed onto the operational video stream from the Tello drone. This process combined the simulated visual output from AirSim with the live video captured by the Tello drone camera. The resulting blended feed enabled operators or automated systems to view the virtual environment through the perspective of the real-world drone. This technique was critical for assessing the accuracy and integration of navigation behaviour within the mixed-reality space, ensuring that interactions with virtual elements remained seamless and spatially aligned.

6.2.6. Calibration and Projection

To ensure the precision of overlays and the alignment between virtual and real-world elements, the cameras used during testing were calibrated with a checkerboard pattern. This calibration process corrected distortions and lens misalignments, allowing for accurate visual projections. Following calibration, a three-dimensional model of the landing pad was projected onto an ArUco marker, which functioned as a reference for position and orientation detection. A Logitech camera, positioned to observe this configuration, captured the ArUco marker with the overlaid virtual landing pad. This provided visual confirmation of how digital elements were spatially represented within the physical testing environment.

6.2.7. Algorithm Execution and Mixed-Reality Evaluation

The core methodology involves executing the designated algorithm via a Python client that interfaces directly with the DT setup. The algorithm, which may include procedures such as landing sequences, navigation control, or other critical operational functions, is applied to the DT and executed in real time. This process enables the evaluation of algorithm efficiency, accuracy, and reliability within both simulated and physical environments simultaneously.

This approach provides a comprehensive assessment of the capability of the mixed-reality system to replicate and respond to DT elements under realistic conditions. It highlights the potential of mixed reality to enhance the functionality of drones and other autonomous systems when deployed in complex, real-world operational contexts.

6.3. Mixed-Reality Evaluation

6.3.1. Algorithm Accuracy Assessment

The evaluation of algorithm performance focused on measuring its accuracy and consistency across both digital and physical environments. This assessment was essential to determine whether the DT could reliably replicate real-world behaviours without significant discrepancies under operational conditions.

To assess positional accuracy, the project measured the distance between the AirSim eVTOL and the centre of the FATO area after landing. This was compared against the landing position of the DJI Tello drone on a physical ArUco marker. The results are shown in Figure 28. The comparison enabled the identification of deviations in landing performance, which were attributed to limitations in sensor precision or the influence of environmental disturbances.

In addition to positional deviation, the evaluation also examined consistency across repeated trials. The DT, operating within the AirSim environment, demonstrated stable landing performance with minimal variation. In contrast, the physical drone showed noticeable fluctuations in landing accuracy, primarily caused by the Inertial Measurement Unit drift during flight. These drifts were critical in understanding how external factors can cause the physical drone to deviate from its planned trajectory, emphasising the importance of such mixed-reality validations.

6.3.2. Connection Latency Evaluation

The connection evaluation focused on assessing latency and synchronisation between the digital and physical components of the mixed-reality system. This aspect was crucial for real-time applications, where delays between command input and system response can significantly affect overall operational performance.

During testing, it was observed that a latency of approximately 3 to 7 s occurred between the execution of identical actions by the AirSim drone and the DJI Tello drone. This delay was attributed to limitations in the processing capabilities of the DJI Tello platform and the high computational demands of the Unreal Engine environment supporting AirSim. Identifying and addressing this latency is critical for enhancing real-time responsiveness and ensuring reliability in time-sensitive operational scenarios.

7. Vertiport Capacity Evaluation

7.1. Operational Movement Analysis

Vertiport capacity analysis is integrated into a real-time DT framework supporting simulated eVTOL flight, human-in-the-loop piloting, manned urban operations, and tactical conflict resolution. This system-wide environment allows for proactive deconfliction, throughput analysis, and emergency scenario testing under realistic airspace conditions.

The operational capacity assessment commenced with defining a representative movement sequence for eVTOL aircraft at the vertiport. Based on the 3D layout provided, a typical operational cycle involves the movement of the aircraft from Parking Position 3 (PP3), proceeding via designated taxiways (Taxi_3 to Taxi_2) to the assigned FATO pad (FATO2), followed by vertical take-off. After completing the airborne segment, which is beyond the scope of vertiport operations, the aircraft returns to FATO2, performs a vertical landing, and taxis back to its original parking stand (PP3).

The duration of each operational segment was derived from DT simulations, resulting in the following detailed timing per phase:

• Taxi from PP3 to FATO2: 47 s.
• Take-off from FATO2: 50 s.
• Landing at FATO2: 50 s.
• Taxi from FATO2 back to PP3: 47 s.

Consequently, a complete operational cycle takes approximately 194 s (3.23 min). The analysis identifies the FATO pads as critical bottlenecks, limiting operational parallelism due to the constraint of accommodating only one aircraft at a time per FATO pad. With two FATO pads available, the maximum theoretical throughput under ideal, back-to-back scheduling conditions was calculated at approximately 37 aircraft operations per hour. The eVTOL landing and take-off operation is shown in Figure 29.

However, realistic operational scenarios necessitate introducing safety separation buffers between sequential operations and accounting for turnaround times at PPs. Incorporating a 30 s safety buffer reduces the effective capacity to approximately 32 operations per hour. Including a practical turnaround time of 5 min per PP further constrains the system to around 29 operations per hour.

This comprehensive operational movement analysis thus establishes a robust baseline for evaluating and optimising vertiport throughput under practical operational constraints.

7.2. Throughput and Bottleneck Identification

Throughput evaluation involved an in-depth examination of operational constraints and their effects on vertiport capacity. The critical bottleneck was identified as the FATO pads, which can only process one aircraft at a time, significantly restricting simultaneous operations. With two available FATO pads, each capable of handling one aircraft every 194 s, an ideal, conflict-free, back-to-back operational schedule can support roughly 37 aircraft per hour.

However, the throughput assessment highlighted two principal practical limitations: safety separation buffers and turnaround operations at PPs. Introducing a 30 s buffer between operations on the same FATO pad reduces throughput capacity to approximately 32 operations per hour. Additionally, turnaround processes, such as passenger boarding, cargo loading, and readiness checks, typically require around 5 min per aircraft at each PP, further reducing throughput to approximately 29 operations per hour.

These identified bottlenecks underscore the importance of optimising both FATO utilisation and ground turnaround processes. Effective management of these constraints is crucial to achieving enhanced operational efficiency and higher practical throughput at the vertiport.

7.3. Impact of eVTOL Charging

Charging requirements for eVTOL aircraft significantly impact vertiport throughput by introducing additional operational constraints. Typical fast-charging times are shown in

Table 14. Typical fast-charging times.

Charging Power	0~80% Recharge Time
200 kW	~30–40 min
350 kW	~20–30 min
600 kW (Ultra-fast)	~10–15 min

. Charging duration depends primarily on the battery size, charging power, depth of discharge, and desired recharge level. Based on realistic projections for 2025, typical charging times are estimated between 20 and 30 min per aircraft using 200–350 kW chargers.

Given that each PP is equipped with only one charging station and aircraft must remain stationary during the charging process, this constraint becomes a critical throughput bottleneck. Assuming an average charging duration of 25 min per aircraft with no overlapping charging sessions at any single charger, each PP can handle approximately two aircraft per hour, limiting the total practical throughput significantly to around eight operations per hour across four PPs.

To mitigate charging-related capacity limitations, several strategies can be implemented, including increasing the number of PPs and chargers, adopting battery-swapping technologies, or utilising ultra-fast chargers (600 kW or higher), which could reduce charging times to approximately 10–15 min. Incorporating such enhancements can notably increase throughput to approximately 20–25 operations per hour, thereby alleviating one of the critical bottlenecks in vertiport capacity. The summary of charging-constrained capacity is shown in

Table 15. Summary of charging-constrained capacity.

Scenario	Approx. Max Capacity (ops/h)
Without charging bottleneck	29 ops/h
With 25 min charging at 4 PP	~8 ops/h
With battery swapping or 600 kW	20–25 ops/h

.

7.4. Capacity Under Contingency Scenarios

The capacity analysis further examined vertiport operations under contingency scenarios, specifically focusing on engine failure events and their associated impacts on operational throughput. Disruptions were categorised based on their duration and severity, influencing both immediate and cascading delays within the system.

Short-duration failures (less than 15 min) typically impose minimal capacity reduction, with throughput decreasing by less than 10%. Moderate-duration events (15–30 min) introduce more substantial disruptions, reducing throughput capacity by approximately 15–20%. Significant disruptions (45–60 min) cause severe operational congestion, considerably limiting throughput, potentially dropping to as low as 10–15 operations per hour under the worst conditions.

Table 16. Example calculations.

Failure Duration	Ops Impacted	Percent of Hourly Operations	Capacity Reduction	Adjusted Capacity
15 min	22	76%	~10%	~26 ops/h
30 min	13	45%	~15%	~25 ops/h
45 min	16	55%	~20%	~23 ops/h
60 min	59	>200% (overlap likely)	Critical	~10–15 ops/h (severely danger)

illustrates these effects through example calculations for each failure duration category.

To counteract these impacts, incorporating contingency buffers within operational schedules, deploying efficient towing and rescue protocols, enhancing predictive maintenance, and implementing robust real-time operational management are recommended. These strategies collectively enhance the resilience of vertiport operations, ensuring that throughput remains optimised even during unforeseen disruptions.

7.5. Discussion and Recommendations

The analysis presented highlights several critical factors influencing vertiport operational capacity, including infrastructural bottlenecks, charging limitations, and contingency scenarios. These combined constraints significantly affect practical throughput and operational resilience.

To enhance vertiport operational efficiency and throughput, the following recommendations are proposed:

• Increase infrastructure capacity by adding additional FATO pads and PPs.
• Employ advanced operational management strategies such as predictive maintenance and dynamic scheduling to mitigate disruptions.
• Optimise charging infrastructure through ultra-fast charging stations or battery-swapping technology to reduce turnaround times.
• Develop robust contingency response protocols, including additional buffer slots and rapid towing or rescue capabilities.

By systematically addressing these areas, vertiport operators can significantly improve overall capacity, reduce operational delays, and enhance resilience against disruptions, thereby supporting sustainable and efficient AAM operations.

To provide a concise operational reference,

Table 17. Summary of vertiport capacity.

Scenario	Estimated Capacity
No failure	29 ops/h
One 15–30 min failure	23–26 ops/h
One 45–60 min failure	10–23 ops/h
Multiple failures	≤15 ops/h

summarises the adjusted hourly capacity of the Cranfield Vertiport under varying failure scenarios, ranging from normal operations to severe multi-failure conditions. These estimations are derived from the delay simulations and throughput evaluations presented in Section 7.4 and offer practical benchmarks for resilient scheduling and layout planning under uncertainty.

8. Conclusion and Future Work

This work develops a DT framework that couples high-fidelity 3D simulation in Unreal Engine, AirSim, and Cesium with operational logic to examine vertiport performance under realistic AAM scenarios. Across adverse-weather and engine-failure cases, the framework shows that wind conditions are a dominant driver of lateral deviation. Using DT-generated datasets, interpolation-based estimators captured the deflection and wind relationship with markedly lower error than linear regression and avoided non-physical negative predictions at low wind speeds, enabling actionable thresholds for operations and a live UI to provide surface warnings and support decision-making.

Delay modelling of contingency handling indicates that a 20 min layout rearrangement reduces total delay compared with longer holding strategies, and pre-emptive reassignment to the functioning FATO at the onset of a 20 min outage can eliminate delay under the one-at-a-time push/pull operating rule; with sequential failures on both FATOs, early redistribution during the first failure substantially reduces disruption relative to deferred changes. In addition, mixed-reality tests with a scaled UAV confirmed spatial alignment through camera/marker calibration and video-feed overlay with AirSim, with stable simulated landings and larger dispersion on the physical platform attributable to IMU drift—evidence that the DT can translate to physical behaviour while also revealing sensor-driven variability to be managed.

Overall, the strengths of the framework are its integrated toolchain that links high-resolution geospatial context, flight dynamics, live weather, and operational rules; its reproducible scenario-based evaluation that quantifies deflection, delay, and capacity impacts; and its mixed-reality pathway that grounds virtual findings in physical tests. Together, these elements yield capacity envelopes and recommendations that inform scheduling and layout planning under uncertainty.

For the research limitations, the present implementation emphasises steady wind components and coarse variability rather than full gust/turbulence spectra; engine failure is simplified as discrete events; charging and turnaround are approximated with idealised parameters; capacity analysis focuses on a single site and limited demand patterns; mixed-reality validation uses a small UAV surrogate that requires explicit scaling; and city-scale computation performance and statistical uncertainty are only partially quantified.

This paper demonstrates a running demo of the vertiport DT, illustrating end-to-end operation from scenario configuration to real-time visualisation and contingency handling. The next phase will strengthen scalability, fidelity, and validation and conduct more detailed research on vertiport capacity, including pilot/operator-in-the-loop experiments being integrated via fixed-base or VR interfaces to quantify workload, response times, and decision quality under disruptions while iterating the user interface for situational awareness and procedure compliance. Environment modelling will be enriched with gust and turbulence spectra, urban flow fields, precipitation and icing, and short-horizon nowcasts to assess impacts on deviation, minima, and controllability. Sensing and data fusion will integrate Remote ID/ADS-B, radar, and vision-based FATO detection with fault detection, isolation, and reconfiguration, enabling autonomy-assisted contingency handling. Validation and verification will also extend to targeted flight tests and structured safety cases. The scope will expand from a single site to networked multi-vertiport scheduling with shared charging resources and recovery strategies. A minimal reproducible package with scenario libraries will be released to facilitate third-party benchmarking and uptake.