Systems and methods for scheduling aerial vehicles in urban environments using data ecosystem integration

Abstract

A computer-implemented method for scheduling and managing aerial vehicle operations is disclosed. The computer-implemented method may include: generating one or more proposed flight operations for at least one vehicle using a first component associated with the system; submitting the one or more proposed flight operations for validation by a second component associated with the system and a third component associated with the system; receiving validation results at the first component from the second component and the third component; determining whether one or more modifications to the one or more proposed flight operations need to be made based on the validation results; finalizing, responsive to determining that no modifications need to be made to the one or more proposed flight operations based on the validation results, the one or more proposed flight operations; and initiating execution or simulation of the one or more finalized proposed flight operations.

Description

SYSTEMS AND METHODS FOR SCHEDULING AERIAL VEHICLES IN URBAN ENVIRONMENTS USING DATA ECOSYSTEM INTEGRATIONCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63 / 653,008, filed May 29, 2024, which is incorporated by reference herein in its entirety.TECHNICAL FIELD

[0002] Various aspects of the present disclosure relate generally to urban air mobility (UAM), and more particularly, to systems and methods for scheduling and managing UAM aerial vehicles using data-driven ecosystem integration.INTRODUCTION

[0003] UAM systems promise to transform urban transportation through aerial vehicles such as air taxis. Effective UAM operations require coordination with ground infrastructure, air traffic control, and environmental factors. Traditionally, dispatch functions under Federal Aviation Regulations (FARs) Parts 121 and 135 have ensured flight safety and efficiency. Similar dispatcher-like functionality should be adapted for UAM. However, UAM presents a variety of unique challenges, and present systems lack a comprehensive fleet scheduling and operational platform that integrates UAM-specific data and stakeholder services.

[0004] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in thisapplication and are not admitted to be prior art, or suggestions of the prior art, by inclusion in this section.SUMMARY OF THE DISCLOSURE

[0005] In one embodiment, the present disclosure is drawn to a computer- implemented method for scheduling and managing aerial vehicle operations, including: generating, using one or more processors associated with a system, one or more proposed flight operations for at least one vehicle using a first component associated with the system; submitting, using the one or more processors, the one or more proposed flight operations for validation by a second component associated with the system and a third component associated with the system; receiving, using the one or more processors, validation results at the first component from the second component and the third component; determining, using the one or more processors, whether one or more modifications to the one or more proposed flight operations need to be made based on the validation results; finalizing, using the one or more processors and responsive to determining that no modifications need to be made to the one or more proposed flight operations based on the validation results, the one or more proposed flight operations; and initiating, using the one or more processors, execution or simulation of the one or more finalized proposed flight operations.

[0006] Various aspects of the present disclosure may also include: wherein the generating comprises: receiving, at the first component, at least one operational data metric including: flight demand data, infrastructure availability data, vehicle performance data, route constraint data, historical demand pattern data, or environmental factor data; and generating the one or more proposed flight operations based on the at least one operational data metric; further including:wherein the generating the one or more proposed flight operations comprises determining a four-dimensional (4D) flight trajectory; further including: wherein the second component is configured to evaluate whether one or more types of infrastructure are available to support the vehicle during the one or more proposed flight operations; and wherein the third component is configured to evaluate whether a four-dimensional (4D) flight trajectory intersects with a restricted zone or creates a conflict with a previously scheduled flight operation; further including: wherein each of the validation results comprises supplemental information including an approval condition or a reason code explaining a basis for a rejection; further including: modifying, using the one or more processors and responsive to determining that at least one modification needs to be made to the one or more proposed flight operations based on the received validation results, the one or more proposed flight operations at the first component; further including: wherein initiating the execution of the one or more finalized proposed flight operations comprises dispatching the at least one vehicle to execute the one or more finalized proposed flight operations; further including: wherein initiating the simulation of the one or more finalized proposed flight operations comprises simulating the one or more finalized proposed flight operations using a simulation engine configured to model vehicle performance, energy usage, and time-based conformance; and further including: collecting telemetry data during the execution or simulation of the one or more finalized proposed flight operations; transmitting the telemetry data to a resource tracking system; and storing the telemetry data in a source tracking database associated with the resource tracking system.

[0007] In another embodiment, the present disclosure is drawn to a system for scheduling and managing aerial vehicle operations, including: a memory includinginstructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: generating one or more proposed flight operations for at least one vehicle using a first component associated with the system; submitting the one or more proposed flight operations for validation by a second component associated with the system and a third component associated with the system; receiving validation results at the first component from the second component and the third component; determining whether one or more modifications to the one or more proposed flight operations need to be made the validation results; finalizing, responsive to determining that no modifications need to be made to the one or more proposed flight operations based on the validation results, the one or more proposed flight operations; and initiating execution or simulation of the one or more finalized proposed flight operations.

[0008] Various aspects of the present disclosure may also include: wherein the instructions executable by the at least one processor for generating the one or more proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: receiving, at the first component, at least one operational data metric including: flight demand data, infrastructure availability data, vehicle performance data, route constraint data, historical demand pattern data, and environmental factor data; and generating the one or more proposed flight operations based on the at least one operational data metric; further including: wherein the instructions executable by the at least one processor for generating the one or more proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: determining a four-dimensional (4D) flight trajectory; further including: wherein the second component is configured to evaluate whether one ormore types of infrastructure are available to support the vehicle during the one or more proposed flight operations; and wherein the third component is configured to evaluate whether a four-dimensional (4D) flight trajectory intersects with a restricted zone or creates a conflict with a previously scheduled flight operation; further including: wherein the instructions are further executable by the at least one processor to perform operations comprising: modifying, responsive to determining that at least one modification needs to be made to the one or more proposed flight operations based on the received validation results, the one or more proposed flight operations at the first component; further including: wherein the instructions executable by the at least one processor for initiating the execution of the one or more finalized proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: dispatching the at least one vehicle to execute the one or more finalized proposed flight operations; and further including: wherein the instructions executable by the at least one processor for initiating the execution of the one or more finalized proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: simulating the one or more finalized proposed flight operations using a simulation engine configured to model vehicle performance, energy usage, and time-based conformance.

[0009] In another embodiment, the present disclosure is drawn to a method for validating a route schedule, including: providing a resource information of a first vertiport, a second vertiport, and passenger demand to a fleet scheduler; receiving, from the fleet scheduler performing a route schedule simulation, a candidate route schedule; and providing the candidate route schedule to a vertiport managementsystem for validation, wherein the vertiport management system determines resource information of at least the first vertiport and the second vertiport.

[0010] Various aspects of the present disclosure may also include: in response to receiving an approval of the candidate route schedule from the vertiport management system, providing a flight plan, corresponding to the candidate route schedule, to a provider of services for urban air mobility (PSD); further including: in response to receiving a denial of the candidate route schedule from the vertiport management system, providing the candidate route schedule to the fleet scheduler, performing a second route schedule simulation, to determine a second candidate route schedule; and further including: in response to receiving an approval of the flight plan from the PSU, providing the flight plan to a simulator, the simulator determining telemetry data based on the flight plan; and continuously streaming telemetry data to the PSU for flight monitoring.

[0011] Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

[0012] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and together with the description, serve to explain the principles of the disclosed embodiments.

[0014] FIG. 1 depicts an exemplary block diagram illustrating subsystems of a computer system interacting to enable efficient scheduling, validation, and execution of aerial vehicle operations, according to one or more aspects of the present disclosure.

[0015] FIG. 2 depicts an exemplary block diagram illustrating a workflow of an operational process of the computer system of FIG. 1 , according to one or more aspects of the present disclosure.

[0016] FIG. 3 depicts an exemplary block diagram of an information flow sequence for operation of the computer system in FIG. 1 , according to one or more aspects of the present disclosure.

[0017] FIG. 4 depicts an exemplary flow chart illustrating a workflow for scheduling and managing aerial vehicle operations in a UAM system, according to one or more aspects of the present disclosure.

[0018] FIG. 5 depicts an example computing system, according to one or more aspects of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[0019] Both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the features, as claimed. As used herein, the terms “comprises,” “comprising,” “has,” “having,” “includes,” “including," or other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus thatcomprises a list of elements does not include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. In this disclosure, unless stated otherwise, relative terms, such as, for example, “about,” “substantially,” and “approximately” are used to indicate a possible variation of ±10% in the stated value. In this disclosure, unless stated otherwise, any numeric value may include a possible variation of ±10% in the stated value.

[0020] The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

[0021] The rise of urban air mobility (DAM) presents a transformative shift in how people and goods may be transported within congested urban environments. These aerial vehicles - such as electric vertical takeoff and landing (eVTOL) aircraft - offer the promise of reducing ground traffic, decreasing travel time, and enabling on-demand, point-to-point transportation. However, integrating these new aerial systems safely and efficiently into urban airspace may pose a host of operational challenges that remain unsolved by conventional aviation practices.

[0022] In traditional commercial aviation, governed under FAR Parts 121 and 135, the role of the dispatcher is well established. Dispatchers are responsible for tasks like weather assessment, flight planning, monitoring in-flight progress, and coordinating with air traffic controllers. While these functions ensure operational safety and reliability for commercial airlines, they are not directly transferrable to UAM. This is due, for instance, to significant difference in scale, automation, aircrafttype, airspace usage, and infrastructure availability. Furthermore, traditional systems assume predictable, long-haul, high-capacity routes - conditions that contrast sharply with the short, frequent, and high-density operations envisioned for UAM.

[0023] Initial attempts to adapt existing aviation scheduling and traffic management systems to UAM have encountered limitations. For instance, these systems lack the granularity, flexibility, and interoperability required for UAM’s distributed and decentralized nature. Many such systems rely on static scheduling or manual coordination, which cannot scale to the anticipated volume of future flights. Other systems fail to integrate critical components such as vertiport availability, airspace capacity, and battery constraints of the eVTOLs, resulting in inefficiencies, unapproved flight plans, and / or unmet passenger demand. Moreover, there is often a disconnect between flight scheduling tools and regulatory airspace service providers, leading to delays, routing conflicts, and underutilization of vertiport and vehicle resources.

[0024] To overcome these challenges, the present disclosure provides a novel Fleet Operation Management System (FMS) that acts as an intelligent control and coordination hub for UAM operations. The FMS may integrate real-time data from multiple ecosystem participants - including fleet schedulers, vertiport management systems (VMS), and providers of services for UAM (PSU) - into a dynamic scheduling framework. The system may generate pre-departure flight schedules that optimize energy usage, match passenger demand, and minimize airspace and vertiport congestion. In an aspect, the FMS may include iterative feedback loops. Forexample, if a flight plan is rejected by the VMS or PSU, the system may adjust and re-simulate the schedule until an optimized, conflict-free plan is approved.

[0025] This integrated, data-driven approach addresses the shortcomings of conventional solutions by providing real-time visibility across the operational landscape and enabling automated, scalable decision-making. By linking scheduling directly to airspace and infrastructure availability, the FMS may ensure higher rates of plan approval, better resource utilization, and more reliable service delivery. Additionally, the system’s modular architecture may support adaptation to regional regulatory frameworks and future expansion, making it a practical solution for enabling safe, efficient, and scalable urban air mobility.

[0026] The concepts described herein represent a significant improvement to computer technology and the technical field of UAM by introducing an integrated, data-driven system that automates and optimizes the complex scheduling, validation, and monitoring of aerial vehicle operations in urban environments. Unlike traditional scheduling systems that operate in silos and rely on manual inputs or isolated decision-making, the FMS described herein leverages real-time data integration across heterogenous systems through defined digital interfaces. This integration enables dynamic, automated generation and continuous refinement of flight plans based on aircraft specifications, passenger forecasts, airspace availability, and / or resource constraints at vertiports. In an aspect, the system’s ability to iteratively adjust and validate mission intents through simulation and telemetry feedback not only enhances the operational reliability and efficiency of UAM services but alsoreduces the cognitive load on human operators, minimizes conflicts in shared airspace, and improves response time to unforeseen changes.

[0027] The subject matter of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments. An embodiment or implementation described herein as "exemplary” is not to be construed as preferred or advantageous, for example, over other embodiments or implementations; rather, it is intended to reflect or indicate that the embodiment(s) is / are “example” embodiment(s). Subject matter may be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any exemplary embodiments set forth herein; exemplary embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof. The following detailed description is, therefore, not intended to be taken in a limiting sense.

[0028] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter include combinations of exemplary embodiments in whole or in part.

[0029] The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

[0030] FIG. 1 depicts an exemplary block diagram of a computer system 100 (“system”) that illustrates how different subsystems interact to enable efficient scheduling, validation, and execution of aerial vehicle operations. System 100 may include a central processor (e.g., the FMS) 105, a fleet scheduler 110, a vertiport management system (VMS) 115, a provider of services for (JAM (PSU) 120, and a simulation module 125.

[0031] In an aspect, the fleet scheduler 110 functions as the central planning engine within the system 100. The fleet scheduler 110 may be configured to generate a pre-departure flight schedule in response to operational requests that define passenger demand between a set of vertiports within a defined geographic region and time window. In an aspect, the fleet scheduler 110 may receive as input one or more of the following: passenger demand forecasts, available fleet size, aircraft and battery performance characteristics, vertiport layout and resource availability, route definitions, or regulatory airspace constraints. These inputs may be provided in real time or near-real time, or retrieved from static databases. In some aspects, the fleet scheduler 110 may also receive weather data, maintenanceschedules, or infrastructure availability from third-party services or internal subsystems.

[0032] Based on the collected data, the fleet scheduler 110 may compute a set of mission intents, each representing a proposed flight operation. A mission intent may include a four-dimensional (4D) flight trajectory, anticipated departure and arrival times, gate and pad usage windows at origin and destination vertiports, or an estimate of energy consumption or battery state of charge (SOC) impact. The fleet scheduler 110 may apply optimization algorithms to minimize energy use, maximize resource utilization, or reduce passenger wait times, depending on user-defined criteria or system policies. The generated mission intents may then be submitted to the VMS 115 for evaluation of ground resource availability.

[0033] Following validation by the VMS 115, the fleet scheduler 110 may package the confirmed mission intents into one or more flight plan proposals, which are then submitted to the Airspace Management (PSU) system 120 for airspace approval, as further described herein. In response to a rejection from either the VMS 115 or the PSU 120, the fleet scheduler 110 may reprocess the affected mission intents, such as by adjusting time slots, re-routing trajectories, or selecting alternative aircraft or vertiports. This iterative feedback mechanism allows the fleet scheduler 110 to continuously refine the schedule until a fully approved flight plan is achieved. Approved flight plans may be transmitted to the simulation module 125 or onboard systems of the eVTOL for execution and monitoring.

[0034] In an aspect, the VMS 115 may be responsible for evaluating and allocating ground-based infrastructure resources at one or more urban vertiports in connection with a proposed UAM flight schedule. In various aspects, the VMS 115 may be implemented as a standalone software module or integrated within a broaderairport or vertiport operations platform. The VMS 115 may receive proposed mission intents or flight plans from the fleet scheduler 110, each including arrival and departure times, anticipated pad and gate usage, aircraft type, and potential service needs for the eVTOL (e.g., battery charging). The VMS 115 may also have access to a vertiport configuration database, which may contain static information such as vertiport layout, number and dimensions of touch-down and lift-off (TLOF) pads, passenger staging areas, charging stations, and safety buffers, for the vertiport. Additionally, the VMS 115 may receive or store dynamic operational data, including real-time pad occupancy, scheduled maintenance, emergency availability, and hours of operation, for the vertiport.

[0035] Upon receiving a flight plan or mission intent, the VMS 115 may perform a resource validation process, determining whether sufficient capacity exists at the origin and destination vertiports to support the proposed operation. This may include verifying whether a TLOF pad, gate, and / or charging station is available at the scheduled time, whether the aircraft meets vertiport weight or dimensional limits, and / or whether any conflicting operations are already scheduled during the same window. The output of the VMS 115 may include a confirmation or rejection of each flight plan. If the flight plan is approved, the VMS 115 may assign specific time slots and pad allocations. If the flight plan is rejected, the VMS 115 may provide one or more reason codes — such as "pad unavailable," "weight limit exceeded," or "operation outside allowed hours" — which may be returned to the fleet scheduler 110 for reprocessing. This validation loop may occur multiple times until a feasible and conflict-free plan is accepted or approved.

[0036] In some aspects, the VMS 115 may also support resource reservation and time-based slot holding, enabling the system 100 to tentativelyreserve infrastructure (e.g., vertiport landing pads, etc.) for pending approval by the PSU 120 or further scheduling refinements. The VMS 115 may update a resource tracking database to log all confirmed schedules and track usage metrics in support of performance monitoring or regulatory compliance. Through its validation and coordination functions, the VMS 115 may ensure that ground infrastructure at urban vertiports is utilized safely, efficiently, and in alignment with the high-throughput requirements of UAM networks.

[0037] In an aspect, the system 100 may include the PSU 120, which may be configured to receive flight plans from the system 100 and evaluate their viability within the operational airspace. In an aspect, the PSU 120 may be implemented by or in coordination with one or more Air Navigation Service Providers (ANSPs) and may operate in accordance with local or national aviation authority standards. In an aspect, the PSU 120 may receive, as input, a flight plan based at least in part on an arrival and departure schedule generated by the fleet scheduler 110 and validated by the VMS 115. The flight plan may include 4D trajectory, aircraft identification, expected departure and arrival times, route segments or corridors, and / or flight performance characteristics. The PSU 120 may also access dynamic airspace data, including, but not limited to, current traffic flows, temporary flight restrictions, weather data, and known route constraints.

[0038] Upon receipt of the flight plan, the PSU 120 may perform strategic deconfliction, verifying that the proposed trajectory does not conflict with other active or scheduled UAM flights, conventional aircraft operations, or restricted airspace. This verification may be based on trajectory-based operations (TBO) principles, and may include time-based separation analysis, altitude stratification, and lateral separation criteria. In some aspects, the PSU 120 may utilize predictive algorithms toforecast traffic densities and determine whether additional load can be safely accommodated within the proposed time slot and corridor. In an aspect, the PSU 120 may generate an output comprising either (i) an approval of the flight plan, optionally including confirmation of a time slot and airspace segment allocation, or (ii) a rejection of the flight plan accompanied by one or more reason codes indicating the cause for denial. Reason codes may include, for example, airspace congestion, weather constraints, route conflicts, or violation of minimum separation thresholds. The rejection data may be returned to the fleet scheduler 110 to allow for rerouting and rescheduling. In some aspects, this process may occur iteratively until the flight plan satisfies airspace constraints and is approved.

[0039] Once a flight plan is approved, the PSU 120 may further perform flight activation, which includes registering the flight as an authorized operation and enabling live monitoring. During flight execution or simulation, telemetry data corresponding to the actual flight path, timing, speed, and other metrics may be received by the PSU 120 from one or more data sources, including a simulation tool or onboard avionics systems. The PSU 120 may compare the received telemetry against the approved flight plan to assess execution conformance. If a deviation is detected — such as route divergence or timing mismatch — the PSU 120 may trigger alerts, send conformance violations to the system 100, or initiate corrective actions according to predetermined protocols. In this manner, the PSU 120 ensures that only strategically deconflicted and operationally feasible flight plans are cleared for execution, and that active UAM flights maintain adherence to their approved routes.

[0040] In an aspect, the simulation module 125 may be configured to emulate the execution of approved flight plans, and to generate corresponding telemetry data for monitoring and analysis. The simulation module 125 may be implemented as astandalone software tool or as an integrated module within the system 100. It may utilize third-party simulation engines, proprietary modeling frameworks, or cloudbased computation resources depending on system architecture. In an aspect, the simulation module 125 may be invoked either pre-operationally, for validation and testing, or in a parallel environment that mirrors live operations.

[0041] In an aspect, the simulation module 125 may receive, as input, an approved flight plan that has passed validation by both the VMS 115 and the PSU 120. The flight plan may include a 4D trajectory, including specific altitudes, waypoints, time slots, and speeds, as well as additional metadata such as aircraft type, energy consumption estimates by the eVTOL, and scheduled vertiport interactions. Based on the flight plan, the simulation module 125 may perform a high- fidelity emulation of the aerial vehicle's operation, modeling various flight phases including takeoff, climb, cruise, descent, approach, and landing. In some aspects, the simulation may also incorporate physical performance models of specific aircraft types, including propulsion behavior, battery discharge profiles, aerodynamic efficiency, and response to environmental factors such as wind, temperature, or precipitation. During execution, the simulation module 125 may generate telemetry data representative of real-time flight metrics. These metrics may include but are not limited to: geospatial position (latitude, longitude, altitude), velocity, heading, estimated time of arrival, state of charge (SOC) of the battery, or conformance to the approved trajectory. The telemetry data may be produced at a configurable update rate and may be formatted in accordance with aviation industry data standards.

[0042] In an aspect, the output telemetry may be transmitted to one or more components of the system 100. For example, the PSU 120 may receive the telemetry stream to assess route conformance and ensure the simulated flightadheres to the approved airspace plan. Any deviations from the assigned trajectory may trigger alerts or initiate revalidation procedures. Additionally, telemetry data may be returned to a Resource Tracking Database within the system 100 for archival, statistical analysis, and system performance evaluation. In some aspects, the simulation module 125 may support what-if analysis and scenario testing. For instance, simulated flights may be run under varying demand levels, airspace congestion conditions, or vertiport resource constraints to assess system resilience and identify operational bottlenecks. This functionality may also be used to optimize schedule planning and to develop improved routing or fleet allocation strategies.

[0043] Turning now to FIG. 2, an exemplary workflow 200 is depicted that illustrates the operational process of the system 100. One or more components of the system 100 in FIG. 1 may be leveraged in one or more steps of workflow 200.

[0044] At step 205, various types of data inputs necessary to generate a feasible and optimized flight schedule may be collected and analyzed. This data may include, but is not limited to, forecasted passenger demand between origin and destination vertiports, real-time and historical vertiport capacity information (e.g., including available charging pads, TLOF pads, passenger staging areas, etc.), predefined UAM route structures such as corridors or procedural routes, aircraft performance parameters, battery limitations, and turnaround requirements, and environmental or regulatory constraints affecting vertiport operations or airspace access. This data may be acquired from internal databases, third-party service providers, real-time sensors, or historical usage trends and may be provided to thefleet scheduler 110 so that it may have a contextual understanding of the operational environmental.

[0045] At step 210, upon receiving the relevant data, the fleet scheduler 110 may generate a set of mission intents forming a pre-departure flight schedule. Each mission intent may represent a proposed aerial operation between a pair of vertiports and may include a 4D flight plan including spatial coordinates and associated timing data. Additionally, the mission intent may include various other parameters such as estimated gate occupancy times, intended usage of infrastructure, energy consumption estimates based on aircraft model and route profile, and aircraft tail number or other types of aircraft identifiers. In an aspect, the fleet scheduler 110 may utilize optimization algorithms to generate flight schedules that maximize resource utilization, reduce energy consumption, and meet passenger demand while minimizing conflicts with other operations. The result of this process is an initial flight schedule that is ready for infrastructure and airspace validation.

[0046] At step 215, the flight schedule generated at step 210 may undergo a dual validation process. First, the flight schedule may be submitted to the VMS 115, which verifies whether sufficient resources are available to support each mission intent. This may include checking one or more of: TLOF pad availability, gate and passenger staging occupancy, charging station readiness, and weight and aircraft dimensional compliance. Upon receiving acceptance or rejection feedback from the VMS 115, the mission intent is updated accordingly. For all approved intents, the updated schedule may be submitted to the PSU 120 for airspace validation. The PSU 120 may evaluate whether each flight plan can be safely accommodated in the context of other active or planned UAM operations. This process may involve strategic deconfliction, which includes trajectory analysis, separationassessment, and compliance with airspace constraints. If any flight plan is rejected at either validation stage, the fleet scheduler 110 may revise the mission intent using the received feedback and reinitiate validation, enabling an iterative refinement loop.

[0047] At step 220, following the integration of feedback and necessary schedule adjustments, the mission intents may be revalidated by both the VMS 115 and PSU 120. Upon receiving final approval from both components, the flight schedule may be deemed executable. The approved schedule may then be transmitted for implementation within operational systems, including simulation module 125, onboard vehicle systems, simulation modules, or fleet monitoring platforms. In an aspect, the system 100 may also facilitate real-time monitoring and adjustment of the approved schedule. This may include continuous tracking of actual flight progress, telemetry ingestion, and dynamic reallocation of resources in response to disruptions, delays, or changes in passenger demand. Any updates, including deviations from planned routes or changes in battery state of charge (SOC), may be logged in a persistent resource tracking database.

[0048] FIG. 3 depicts diagram 300 that illustrates an exemplary information flow sequence for the operation of system 100. The information flow sequence depicted in diagram 300 depicts a vertiport database 305, a route database 310, aircraft database 315, fleet scheduler 320 (equivalent to fleet scheduler 110 in FIG. 1), simulation module 325 (e.g., equivalent to simulation module 125 in FIG. 1), FMS 330 (e.g., equivalent to system 100 in FIG. 1), PSU 335 (e.g., equivalent to PSU 120 in FIG. 1), VMS Vertiport A 340 (e.g., equivalent to VMS 115 in FIG. 1),VMS Vertiport B 345 (e.g., equivalent to VMS 115 in FIG. 1), and resource tracking database 350.

[0049] As shown in diagram 300, at step 0.1 , a vertiport database 305 may provide vertiport identification, location, layout, and / or resource capacity data to the FMS 330. The FMS 330 may correspond to system 100 and may act to integrate the fleet scheduler 320, vertiports, and one or more Air Navigation Service Providers. Alternatively, the FMS 330 may have pre-stored data regarding vertiport identification, location, layout, and / or resource capacity. At step 0.2 the FMS 330 may provide the identification, location, layout, and / or resource capacity configuration to one or more vertiports, labeled in FIG. 3 as a first vertiport (e.g., Vertiport A) 340 and a second vertiport (e.g., Vertiport B) 345.

[0050] At step 1.1 , a request may be provided to the first vertiport 340, which may correspond to VMS 115, by the FMS 330. A response may be received from the first vertiport 340, at the FMS 330, containing resource information such as capacity for additional aircraft, hours of operation, acceptable weight range, size of vacant spots, scheduled inbound flights, in addition to any other vertiport information discussed elsewhere herein. Requests may be provided to any additional number of vertiports / VMSs, for example to the second vertiport 345 at step 1.2. A response may be received from the second vertiport 345, which may contain resource information such as capacity for additional aircraft, size of open spots, flights scheduled, or acceptable weight range of incoming aircraft, in addition to any other vertiport information discussed elsewhere herein. By consulting the first and secondvertiports 340, 345 directly, the FMS 330 may be able to have the most recent vertiport data.

[0051] At step 2.0, vertiport location(s) and / or operational time(s) may be forwarded to the fleet scheduler 320. At step 3.0, the fleet scheduler 320 may generate a pre-departure flight schedule, by incorporating the routes database 310 and aircraft database 315 and generate data such as optimized route(s) departure and arrival times, and / or resource allocations (e.g., charging slots). The fleet scheduler 320 may utilize aircraft characteristics when determining a candidate route schedule, which may be received from an aircraft characteristics database 315. The fleet scheduler 320 may further utilize route information received from a route database 310 defining different route possibilities, which may be defined based on aircraft types and / or characteristics. Further, the fleet scheduler 320 may utilize vertiport information received from the vertiport database 305, which may contain both static and dynamic vertiport characteristics discussed elsewhere herein.

[0052] At step 4.0 the candidate route schedule may be provided to the FMS 330, which at step 5.0 may perform post-processing. The post-processing may comprise generating one or more flight plan requests in a predetermined format based on the candidate route schedule, which may request approval of the flight plan from the start and destination vertiports at steps 6.1 and 6.2 (e.g., first vertiport 340 and second vertiport 345, respectively). The process may be iterated for multiple pairs of vertiports and multiple flight plans. At steps 6.1 and 6.2 the flight plan request response may be received from the start and destination vertiports (e.g., first vertiport 340 and second vertiport 345, respectively). If the flight plan is rejected by any vertiport, a request for a second candidate route schedule may be provided to the fleet scheduler 320, which at step 6.3 may run another simulation. If any reasonfor the rejection is provided by the vertiport, it may be forwarded to the fleet scheduler 320. The fleet scheduler 320 may consider the reason provided for the rejection of the candidate route schedule, and may generate a second candidate route schedule based on the rejection information. The fleet scheduler 320 may then provide the second candidate route schedule to the FMS 330. The second candidate route schedule may be used to generate an updated flight plan request, which may be forwarded to the start and destination vertiports (e.g., first vertiport 340 and second vertiport 345, respectively). This process may be iterated as many times as needed.

[0053] At step 7.1 the FMS 330 may additionally receive route and aircraft information from one or more of route database 310 or one or more of aircraft database 315, as desired. The flight plan may be generated, based on the approved candidate route schedule, the route and / or aircraft information, and at step 7.2 may be submitted to one or more Air Navigation Service Providers, including any Providers of Service for (JAM (PSU) 335. The PSU 335 may respond by approving or denying the flight plan. In case of a rejection, the rejection may be forwarded to the fleet scheduler 320, which may perform a re-simulation, e.g., using simulation module 325, at step 7.3, based on the rejection. With the re-simulation, steps 6.1 , 6.2, and / or 7.2 may be performed again. The re-simulation process may be iteratively performed until approval is received from the PSU 335. At step 8.0, approved flight plan data may be activated and provided to a simulation tool 325, which may simulate the flight, based on the flight plan data, to determine telemetry data. The telemetry data may be provided to the FMS 330 at step 9.0. At step 10.0, the FMS 330 may stream telemetry data back to PSU 335 for in-time route conformance and monitoring. If any nonconformance occurs, the PSU 335 mayinform the FMS 330. As shown as step 11.0, the FMS 330, at any time, may update and maintain a resources tracking database 350 with flight data such as the flight plan, the state of charge of the battery, etc.

[0054] Referring now to FIG. 4, an exemplary workflow 400 is described for scheduling and managing aerial vehicle operations in a UAM system. Aspects of the exemplary workflow 400 may be performed in accordance with some or all components described in FIG. 1 and / or FIG. 3.

[0055] At step 405, a scheduling system (e.g., fleet scheduler 110) may be configured to generate one or more proposed flight operations for aerial vehicles operating within a UAM network. The scheduling system may be implemented as a centralized software module, a distributed set of cloud-based services, or any other computing architecture capable of ingesting operational data and producing output schedules in an automated or semi-automated manner. In an aspect, the scheduling system may receive and process a variety of operational data, which may include, but is not limited to: (i) flight demand data, such as passenger booking patterns, origin-destination forecasts, or aggregated traffic models; and (ii) infrastructure availability data, such as vertiport capacity, resource allocation windows, and charging station readiness. In some aspects, additional data may be used, including vehicle performance characteristics (e.g., battery range, turnaround time), route constraints, historical demand patterns, or environmental factors.

[0056] Based on the operational data, the scheduling system may be configured to generate one or more proposed flight operations. Each proposed flight operation may define a point-to-point aerial mission between two or more vertiports and may include associated metadata, such as a tentative departure time, expected arrival time, candidate flight path or route corridor, and anticipated infrastructurerequirements at each involved location. In some implementations, the scheduling system may apply optimization algorithms to account for energy efficiency, travel time minimization, infrastructure load balancing, or adherence to regulatory constraints. In an aspect, the generation process may be conducted iteratively, dynamically adjusting proposed operations in response to changing operational inputs or external feedback. The proposed flight operations may be stored in memory, transmitted to other subsystems for further validation, or presented to operators for manual review.

[0057] At step 410, following the generation of one or more proposed flight operations by the scheduling system, the proposed flight operations may be submitted to one or more infrastructure or airspace management systems for validation. The infrastructure management systems may include, but are not limited to a vertiport management system (e.g., VMS 115) configured to manage ground- based resources such as TLOF pads, passenger staging areas, and charging stations. The airspace management systems may include, but are not limited to, a providers of services for (JAM (e.g., the PSD 120) or other authorized entities responsible for deconflicting aerial trajectories and managing low-altitude urban airspace capacity.

[0058] The validation process may involve assessing whether sufficient infrastructure is available at proposed departure and arrival locations during the specified time windows, and whether the proposed flight paths conflict with other known or scheduled operations. The scheduling system may transmit relevant flight data, including proposed time slots, route segments, and vehicle characteristics, to the VMS 115 and / or the PSU 120 using defined communication protocols. Thesesystems may return approval or rejection responses based on real-time or forecasted system status, operational limits, or policy-based constraints.

[0059] The VMS 115, in response to receiving the proposed flight operation data, may evaluate the availability of necessary vertiport infrastructure during the requested operational window. For example, the VMS 115 may determine whether a charging pad is available at the destination vertiport at the estimated arrival time, whether the requested TLOF pad is unoccupied during the specified landing window, and whether the aircraft’s physical attributes (e.g., weight, wingspan, etc.) comply with operational limitations specific to that vertiport. The VMS 115 may also consider time-based capacity constraints and pad turnover rates. If any of the proposed infrastructure allocations exceed the current or forecasted capacity of the vertiport, the VMS 115 may reject the request and optionally provide a reason code or suggested alternative time slot. Simultaneously or subsequently, the PSU 120 may evaluate the same or an equivalent set of proposed flight operations for airspace feasibility and strategic deconfliction. The PSU 120 may assess whether the proposed 4D flight trajectory intersects with or violates any restricted zones, creates a conflict with previously scheduled flights, or causes a breach of minimum separation standards required under UAM flight protocols. The PSU 120 may perform conflict detection and resolution (CD&R) analysis, apply airspace usage policies, and reference near-real-time flight traffic models. Additionally, the PSU 120 may consider dynamic airspace factors, such as temporary flight restrictions (TFRs), weather-induced route adjustments, and contingency buffer zones. If the proposed operation cannot be safely accommodated, the PSU 120 may reject the request and provide specific guidance or rejection codes to facilitate re-planning

[0060] At step 415, subsequent to submitting the proposed flight operations to the relevant management systems, the scheduling system may receive validation results indicating either approval or rejection of each proposed operation. In an aspect, each result may be received via defined communication protocols, including secure web-based APIs, aviation-grade communication systems, or dedicated service buses, depending on system architecture. In an aspect, each result may be accompanied by supplemental information, such as approval conditions or reason codes explaining the basis for a rejection. Examples of rejection reasons may include unavailability of vertiport resources, route congestion, insufficient separation, or violations of local regulatory or operational thresholds. The scheduling system may store these validation results and associate them with the corresponding flight operations in a persistent or temporary data structure. This information may then be used to inform subsequent adjustments to flight scheduling, ensuring that operational constraints are accounted for prior to implementation.

[0061] At step 420, the system may determine whether any modifications need to be made to the one or more flight operations based on the validation results. More particularly, responsive to determining, at step 420, that the one or more proposed flight operations have been approved, the system may, at step 425, proceed to finalize the one or more approved flight operations. In an aspect, finalization may include confirming time slots, reserving required infrastructure resources, updating central flight tracking databases, and notifying relevant subsystems or stakeholders. In some aspects, finalization may also involve packaging the approved flight operation into a format suitable for downstream execution by onboard systems, autonomous flight control software, or operational command interfaces.

[0062] Conversely, at step 420, in response to receiving validation results indicating that one or more proposed flight operations have been rejected or flagged, the scheduling system may modify, at step 430, the proposed flight operations. In an aspect, the modifications may be based at least in part on the validation feedback, which may suggest alternate time slots, vertiport locations, or route configurations. The scheduling system may dynamically adjust one or more parameters of the affected flight operation — such as adjusting the departure time, shifting pad reservations, rerouting the trajectory, or reassigning the flight to a different vehicle. This iterative process may be automated, semi-automated, or manually supervised depending on the implementation. Once modified, the updated flight operations may be resubmitted for validation (e.g., at step 410), or queued for inclusion in the finalized operational schedule (e.g., at step 425). This responsive adjustment process ensures that only feasible and approved operations are eventually executed

[0063] At step 435, following finalization, the system may proceed to initiate execution or simulation of the approved flight operations. In operational environments, this may include dispatching aerial vehicles to execute the flight plan, with corresponding monitoring of conformance and performance. In pre-operational or planning environments, a simulation engine (e.g., the simulation module 125) may emulate the flight trajectory, generating telemetry such as location data, velocity, heading, energy consumption, and time-based metrics. The simulation or execution process may be monitored in real time by one or more oversight systems, including the PSU 120 or a centralized system (e.g., the FMS 105). The results of the execution or simulation may be stored in a resource tracking system (e.g., the resource tracking database 350), enabling real-time visibility into system-wide status and facilitating historical analysis, operational optimization, and compliance auditing.

[0064] Provided below is a non-limiting, exemplary scenario that illustrates the practical implementation of the concepts described herein.

[0065] In an urban setting such as Los Angeles, California, which is a major U.S. city exploring UAM solutions, the system described herein may be deployed to coordinate and optimize a fleet of eVTOL air taxis servicing routes between multiple strategically located vertiports. The system may be initialized with a digital map of vertiport infrastructure — each site detailed with data on layout, TLOF pads, passenger staging areas, charging stations, and available operating hours. Throughout the day, the system may receive continuous input from demand forecasting modules that monitor ride requests across the city using passenger booking data, traffic conditions, and time-of-day patterns. Upon receiving a forecast indicating a spike in demand between downtown Los Angeles and Santa Monica during rush hour, a fleet scheduler component of the system may automatically generate candidate 4D flight plans optimized for minimal battery consumption and airspace interaction. These plans consider aircraft state of charge (SOC), charging needs, and vertiport gate availability. Each mission intent may include precise departure and arrival times, proposed pad reservations, and projected flight telemetry. These flight plans may first be validated by the VMS at both origin and destination ensuring that the necessary ground resources are available at the requested time. Upon VMS approval, the plans may be forwarded to the PSU for airspace deconfliction — ensuring that multiple UAM flights do not conflict in busy air corridors. Once approved by both the VMS and PSU, the mission plans may be activated in a simulation engine, which models the flight in near real-time to confirm battery efficiency and route feasibility. As the flight progresses, the PSU may receive a live telemetry feed from the aircraft simulator for route adherence monitoring. Ifdeviations or anomalies (e.g., adverse micro-weather conditions or technical faults) are detected, the system can reroute or reschedule missions in real-time, leveraging updated forecasts and network-wide data.

[0066] In general, any process discussed in this disclosure that is understood to be computer-implementable, such as the processes illustrated in FIGS. 2-4, may be performed by one or more processors of a computer system, such as computer system 100 described above. A process or process step performed by one or more processors may also be referred to as an operation. The one or more processors may be configured to perform such processes by having access to instructions (e.g., software or computer-readable code) that, when executed by the one or more processors, cause the one or more processors to perform the processes. The instructions may be stored in a memory of the computer server. A processor may be a central processing unit (CPU), a graphics processing unit (GPU), or any suitable types of processing unit.

[0067] A computer system, such as the computer system 100, may include one or more computing devices. If the one or more processors of the computer systems are implemented as a plurality of processors, the plurality of processors may be included in a single computing device or distributed among a plurality of computing devices. If the computer system 100 comprises a plurality of computing devices, the memory of the computer system 100 may include the respective memory of each computing device of the plurality of computing devices.

[0068] FIG. 5 is a simplified functional block diagram of a computer system500 that may be configured as a computing device for executing the process illustrated in FIGS. 2-4, according to exemplary embodiments of the present disclosure. FIG. 5 is a simplified functional block diagram of a computer that may beconfigured as the computer system 100 according to exemplary embodiments of the present disclosure. In various embodiments, any of the systems herein may be an assembly of hardware including, for example, a data communication interface 520 for packet data communication. The platform also may include a central processing unit (“CPU”) or processor 502, in the form of one or more processors, for executing program instructions. The platform may include an internal communication bus 508, and a drive unit 506 (such as ROM, HDD, SDD, etc.) that may store data on a computer readable medium 522, although the system 500 may receive programming and data via network communications via electronic network 525 (e.g., voice, video, audio, images, or any other data over the electronic network 525). The system 500 may also have a memory 504 (such as RAM) storing instructions 524 for executing techniques presented herein, although the instructions 524 may be stored temporarily or permanently within other modules of system 500 (e.g., processor 502 and / or computer readable medium 522). The system 500 also may include input and output devices 512 and / or a display 510 to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. The various system functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the systems may be implemented by appropriate programming of one computer hardware platform.

[0069] Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and / or associated data that is carried on or embodied in a type of machine-readable medium. “Storage” type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may providenon-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the mobile communication network into the computer platform of a server and / or from a server to the mobile device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.

[0070] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

[0071] In general, any process discussed in this disclosure that is understood to be performable by a computer may be performed by one or more processors. Such processes include, but are not limited to the processes shown in FIGS. 2-4, and the associated language of the specification. The one or more processors may be configured to perform such processes by having access to instructions (computer-readable code) that, when executed by the one or moreprocessors, cause the one or more processors to perform the processes. The one or more processors may be part of a computer system (e.g., one of the computer systems discussed above) that further includes a memory storing the instructions. The instructions also may be stored on a non-transitory computer-readable medium. The non-transitory computer-readable medium may be separate from any processor. Examples of non-transitory computer-readable media include solid-state memories, optical media, and magnetic media.

[0072] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention needs more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

[0073] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0074] Thus, while certain embodiments have been described, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

[0075] The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other implementations, which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description. While various implementations of the disclosure have been described, it will be apparent to those of ordinary skill in the art that many more implementations are possible within the scope of the disclosure. Accordingly, the disclosure is not to be restricted except in light of the attached claims and their equivalents.

Claims

What is claimed is:

1. A computer-implemented method for scheduling and managing aerial vehicle operations, the computer-implemented method comprising: generating, using one or more processors associated with a system, one or more proposed flight operations for at least one vehicle using a first component associated with the system; submitting, using the one or more processors, the one or more proposed flight operations for validation by a second component associated with the system and a third component associated with the system; receiving, using the one or more processors, validation results at the first component from the second component and the third component; determining, using the one or more processors, whether one or more modifications to the one or more proposed flight operations need to be made based on the validation results; finalizing, using the one or more processors and responsive to determining that no modifications need to be made to the one or more proposed flight operations based on the validation results, the one or more proposed flight operations; and initiating, using the one or more processors, execution or simulation of the one or more finalized proposed flight operations.

2. The computer-implemented method of claim 1 , wherein the generating comprises:receiving, at the first component, at least one operational data metric including: flight demand data, infrastructure availability data, vehicle performance data, route constraint data, historical demand pattern data, or environmental factor data; and generating the one or more proposed flight operations based on the at least one operational data metric.

3. The computer-implemented method of claim 1 , wherein the generating the one or more proposed flight operations comprises determining a four-dimensional (4D) flight trajectory.

4. The computer-implemented method of claim 1 , wherein the second component is configured to evaluate whether one or more types of infrastructure are available to support the vehicle during the one or more proposed flight operations; and wherein the third component is configured to evaluate whether a fourdimensional (4D) flight trajectory intersects with a restricted zone or creates a conflict with a previously scheduled flight operation.

5. The computer-implemented method of claim 1 , wherein each of the validation results comprises supplemental information including an approval condition or a reason code explaining a basis for a rejection.

6. The computer-implemented method of claim 1 , further comprising:modifying, using the one or more processors and responsive to determining that at least one modification needs to be made to the one or more proposed flight operations based on the received validation results, the one or more proposed flight operations at the first component.

7. The computer-implemented method of claim 1 , wherein initiating the execution of the one or more finalized proposed flight operations comprises dispatching the at least one vehicle to execute the one or more finalized proposed flight operations.

8. The computer-implemented method of claim 1 , wherein initiating the simulation of the one or more finalized proposed flight operations comprises simulating the one or more finalized proposed flight operations using a simulation engine configured to model vehicle performance, energy usage, and time-based conformance.

9. The computer-implemented method of claim 1 , further comprising: collecting telemetry data during the execution or simulation of the one or more finalized proposed flight operations; transmitting the telemetry data to a resource tracking system; and storing the telemetry data in a source tracking database associated with the resource tracking system.

10. A system for scheduling and managing aerial vehicle operations, comprising:a memory including instructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: generating one or more proposed flight operations for at least one vehicle using a first component associated with the system; submitting the one or more proposed flight operations for validation by a second component associated with the system and a third component associated with the system; receiving validation results at the first component from the second component and the third component; determining whether one or more modifications to the one or more proposed flight operations need to be made the validation results; finalizing, responsive to determining that no modifications need to be made to the one or more proposed flight operations based on the validation results, the one or more proposed flight operations; and initiating execution or simulation of the one or more finalized proposed flight operations.

11. The system of claim 10, wherein the instructions executable by the at least one processor for generating the one or more proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: receiving, at the first component, at least one operational data metric including: flight demand data, infrastructure availability data, vehicle performancedata, route constraint data, historical demand pattern data, and environmental factor data; and generating the one or more proposed flight operations based on the at least one operational data metric.

12. The system of claim 10, wherein the instructions executable by the at least one processor for generating the one or more proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: determining a four-dimensional (4D) flight trajectory.

13. The system of claim 10, wherein the second component is configured to evaluate whether one or more types of infrastructure are available to support the vehicle during the one or more proposed flight operations; and wherein the third component is configured to evaluate whether a fourdimensional (4D) flight trajectory intersects with a restricted zone or creates a conflict with a previously scheduled flight operation.

14. The system of claim 10, wherein the instructions are further executable by the at least one processor to perform operations comprising: modifying, responsive to determining that at least one modification needs to be made to the one or more proposed flight operations based on the received validation results, the one or more proposed flight operations at the first component.

15. The system of claim 10, wherein the instructions executable by the at least one processor for initiating the execution of the one or more finalized proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: dispatching the at least one vehicle to execute the one or more finalized proposed flight operations.

16. The system of claim 10, wherein the instructions executable by the at least one processor for initiating the execution of the one or more finalized proposed flight operations comprise instructions executable by the at least one processor for performing operations further comprising: simulating the one or more finalized proposed flight operations using a simulation engine configured to model vehicle performance, energy usage, and timebased conformance.

17. A method for validating a route schedule, comprising: providing a resource information of a first vertiport, a second vertiport, and passenger demand to a fleet scheduler; receiving, from the fleet scheduler performing a route schedule simulation, a candidate route schedule; and providing the candidate route schedule to a vertiport management system for validation, wherein the vertiport management system determines resource information of at least the first vertiport and the second vertiport.

18. The method of claim 17, further comprising:in response to receiving an approval of the candidate route schedule from the vertiport management system, providing a flight plan, corresponding to the candidate route schedule, to a provider of services for urban air mobility (PSD).

19. The method of claim 18, further comprising: in response to receiving a denial of the candidate route schedule from the vertiport management system, providing the candidate route schedule to the fleet scheduler, performing a second route schedule simulation, to determine a second candidate route schedule.

20. The method of claim 18, further comprising: in response to receiving an approval of the flight plan from the PSU, providing the flight plan to a simulator, the simulator determining telemetry data based on the flight plan; and continuously streaming telemetry data to the PSU for flight monitoring.

Images