Routing based on vehicle characteristics

Abstract

Air vehicles are assigned routes within the transportation network based on the air vehicle's state of charge, power state, and / or health. Such aspects may be modeled based on one or more statistical and / or machine learning models, among other examples. As another example, an energy budget may be used to ensure that the air vehicle's state of charge, power state, and / or health state during and / or after traversing the route remains within the energy budget. A load is assigned to the route and associated air vehicle, thereby generating a journey. In examples, the journey is verified by the air vehicle to ensure that the air vehicle can travel the route with the load. In examples where the air vehicle rejects the journey, the journey is assigned to another air vehicle, and a new journey is identified for the air vehicle.

Description

[Technical Field]

[0001] The present invention relates to routing based on vehicle characteristics. [Background technology]

[0002] A transportation service entity may use a fleet of air vehicles with various vehicle characteristics to transport cargo within a transportation network. As a result of the differences in vehicle characteristics, one air vehicle may be better suited than another to travel a given route and / or transport a given cargo. However, optimizing the use of air vehicles and the routing of cargo within a transportation network while taking such considerations into account is difficult. Summary of the Invention [Means for solving the problem]

[0003] Routes are generated within the transportation network to meet anticipated demand within the network. Each route includes a departure vertiport and a destination vertiport. Air vehicles are routed based at least in part on an analysis of the air vehicle's state of charge, power state, and / or health. In examples, such aspects are modeled based on one or more statistical and / or machine learning models, among other examples. An air vehicle may be routed multiple times if the air vehicle's expected state of charge, power state, and / or health after traveling one route is sufficient to travel a subsequent route (e.g., with or without charging or refueling between routes). In other examples, an air vehicle is routed without associated cargo, thereby placing the air vehicle at a different departure vertiport for the subsequent route. As another example, an energy budget is used, and air vehicles are routed against the energy budget to ensure the air vehicle's state of charge, power state, and / or health stays within the energy budget.

[0004] A load is assigned to a route and associated air vehicle, thereby generating an itinerary. In some instances, the itinerary is verified by the air vehicle (e.g., automatically based at least in part on manual instructions by a pilot, flight attendant, or other provider) to ensure that the air vehicle can travel the route with the assigned load. In some instances, the air vehicle rejects the itinerary, and the itinerary is assigned to another air vehicle, and a new itinerary is identified. In other instances, where the actual state of charge, power state, and / or health of the air vehicle during or after the route travel differs from the air vehicle's expected characteristics, one or more subsequent routes associated with the air vehicle are reassigned within the transportation network. As another example, the air vehicle is rerouted to a different destination vertiport, and a new or updated itinerary is generated as needed for the load. The present invention provides, for example, the following. (Item 1) 1. A method for determining an air vehicle and route for transporting a load within a transportation network, comprising: generating a set of available routes within the transportation network based on historical demand information, each route including a departure vertiport and an arrival vertiport; accessing, for a set of air vehicles in the transportation network, a set of vehicle characteristics for each air vehicle in the set of air vehicles, the set of vehicle characteristics comprising: the energy type of the air vehicle; the state of charge of the air vehicle; the power state of the air vehicle; or The health of said air vehicle accessing the data, the data including at least one of: accessing capability information for each vertiport of a path in said set of available paths; assigning an air vehicle from the set of air vehicles to the route based on the set of vehicle characteristics and the capability information; A method comprising: (Item 2) generating at least one predicted vehicle characteristic of the set of vehicle characteristics for the specified air vehicle type using a model for the specified air vehicle type; Item 1, the method further comprising: (Item 3) 3. The method of claim 2, wherein the at least one predicted vehicle characteristic is one of a predicted state of charge, a predicted power state, or a predicted state of health at the arrival vertiport. (Item 4) the predicted vehicle characteristic is a predicted state of charge; receiving an indication of a state of charge that differs from the predicted state of charge from the designated air vehicle; identifying a subsequent route assigned to the designated air vehicle; designating a new air vehicle in place of the designated air vehicle for the subsequent route based on the received indication of state of charge; Item 3. The method according to item 2, further comprising: (Item 5) the route is a first route of a set of routes for the specified air vehicle; determining a second route for the air vehicle that includes an arrival vertiport that is the same as a departure vertiport of the first route; assigning the second route to the air vehicle; reordering the set of routes for the designated air vehicle so that the second route is traversed before the first route; Item 1, the method further comprising: (Item 6) the pathway is a first pathway, receiving a journey request associated with a load including load characteristics; determining, based on the cargo characteristics, that a new route should be generated instead of transporting the cargo using the first route; generating the new route including a new departure vertiport and a new arrival vertiport based on the cargo characteristics; determining a new air vehicle for the new route based on the cargo characteristics, vehicle characteristics of the new air vehicle, and capability information associated with the new arrival vertiport; generating a journey in response to the journey request, the journey including information related to the new route and the new air vehicle; Item 1, the method further comprising: (Item 7) receiving a journey request associated with a load including load characteristics; evaluating the cargo characteristics, the route, and the designated air vehicle to determine that the route should be used to transport the cargo; generating an itinerary including information related to the route and the specified air vehicle; Item 1, the method further comprising: (Item 8) 2. The method of claim 1, wherein assigning the air vehicle to the route further comprises evaluating a predicted time for the assigned air vehicle to reach a predetermined state of charge at the arrival vertiport. (Item 9) 1. A method for validating an itinerary for transporting a load using an air vehicle within a transportation network, comprising: receiving an itinerary from a transportation system, the itinerary including a start vertiport, a destination vertiport, and cargo instructions; the energy type of the air vehicle; the state of charge of the air vehicle; the power state of the air vehicle; or The health of said air vehicle accessing a set of vehicle characteristics for the air vehicle, the set including at least one of: evaluating the set of vehicle characteristics based at least in part on the origin vertiport, the destination vertiport, and the cargo to verify whether the air vehicle is capable of carrying out the journey; providing an instruction to the transportation system to accept the journey or to reject the journey based on verifying whether the air vehicle is capable of performing the journey; A method comprising: (Item 10) an instruction to reject the journey is given to the transportation system; receiving a second journey from the transportation system; evaluating the set of vehicle characteristics to verify the second journey; Item 10. The method according to item 9, further comprising: (Item 11) evaluating the set of vehicle characteristics to verify whether the air vehicle is capable of performing the journey; generating a display including a vehicle condition indicator based on evaluating the set of vehicle characteristics; receiving input via said display to accept or reject said journey; Item 10. The method according to item 9, further comprising: (Item 12) 10. The method of claim 9, wherein the set of vehicle characteristics is accessed at least in part from a vehicle state monitor of the air vehicle. (Item 13) at least one processor; operatively connected to the at least one processor and, when executed by the at least one processor, generating a set of available routes within the transportation network based on historical demand information, each route including a departure vertiport and an arrival vertiport; For a set of air vehicles in the transportation network, accessing a set of vehicle characteristics for each air vehicle in the set of air vehicles, the set of vehicle characteristics comprising: the energy type of the air vehicle; the state of charge of the air vehicle; the power state of the air vehicle; or The health of said air vehicle accessing, including at least one of: accessing capability information for each vertiport of a path in said set of available paths; and assigning an air vehicle from the set of air vehicles to the route based on the set of vehicle characteristics and the capability information; a memory for storing instructions for causing the system to perform a set of operations including Including, the system. (Item 14) The set of processes generating a predicted vehicle characteristic of at least one of the set of vehicle characteristics using a model for the specified air vehicle type; Item 14. The system of item 13, further comprising: (Item 15) Item 15. The system of item 14, wherein the at least one predicted vehicle characteristic is one of a predicted state of charge, a predicted power state, or a predicted state of health at the arrival vertiport. (Item 16) the predicted vehicle characteristic is a predicted state of charge, and the set of processes is receiving an indication of a state of charge that differs from the predicted state of charge from the designated air vehicle; Identifying a subsequent route assigned to said air vehicle; and designating a new air vehicle for the subsequent route in place of the designated air vehicle based on the received indication of charge status. Item 15. The system of item 14, further comprising: (Item 17) The route is a first route of a set of routes for the specified air vehicle, and the set of processes determining a second route for the air vehicle that includes an arrival vertiport that is the same as a departure vertiport of the first route; assigning the second route to the air vehicle; and reordering the set of routes for the designated air vehicle so that the second route is traversed before the first route; Item 14. The system of item 13, further comprising: (Item 18) The set of processes receiving a journey request associated with the load including load characteristics; determining, based on the cargo characteristics, that a new route should be generated instead of transporting the cargo using the first route; generating the new route including a new departure vertiport and a new arrival vertiport based on the cargo characteristics; determining a new air vehicle for the new route based on the cargo characteristics, vehicle characteristics of the new air vehicle, and capability information associated with the new arrival vertiport; and generating a journey in response to the journey request, the journey including information relating to the new route and the new air vehicle; Item 14. The system of item 13, further comprising: (Item 19) The set of processes receiving a journey request associated with the load including load characteristics; evaluating the cargo characteristics, the route, and the designated air vehicle to determine that the route should be used to transport the cargo; and generating an itinerary including information related to said route and said specified air vehicle; Item 14. The system of item 13, further comprising: (Item 20) Item 14. The system of item 13, wherein assigning the air vehicle to the route further comprises evaluating a predicted time for the assigned air vehicle to reach a predetermined state of charge at the arrival vertiport. [Brief explanation of the drawings]

[0005] [Figure 1] 1 illustrates an example of a multimodal transportation system in which cargo is routed according to aspects described herein. [Figure 2] 1 illustrates an example system for routing cargo using air vehicles of a transportation services entity. [Figure 3A] An example method for generating routes for air vehicles within a transportation network and determining itineraries in response to itinerary requests is presented. [Figure 3B] 1 illustrates an example method for specifying an itinerary for an air vehicle. [Figure 3C] 1 illustrates an example method for verifying a route in an air vehicle. [Figure 4A] An example method for generating a set of routes in a transportation network based on historical demand information is presented. [Figure 4B] 1 illustrates an example method for assigning an air vehicle to a route based on vehicle characteristics. [Figure 5] 1 illustrates an example of a computing device in which aspects of the present disclosure can be practiced. DETAILED DESCRIPTION OF THE INVENTION

[0006] A transportation service entity may use a fleet of air vehicles having a variety of vehicle characteristics to transport cargo within its transportation network. For example, the air vehicles may use any of a variety of energy types (e.g., hydrocarbon fuels, electric power, hybrid technology, etc.). In addition, there may be a variety between different energy types, including, but not limited to, diesel fuel versus ethanol fuel, or lithium-ion batteries versus lithium-polymer batteries, among other examples. It will be understood that other vehicle characteristics may vary among the air vehicles in its fleet, including, but not limited to, air vehicle hardware (e.g., number of engines / electric motors, number of seats or cargo capacity, wingspan, etc.), air vehicle capabilities (e.g., vertical takeoff, vertical landing, etc.), and vehicle weight / lifting capacity.

[0007] In an example, characteristics of an air vehicle are obtained from a manufacturer and stored in a vehicle information data store. For example, the vehicle information data store includes general characteristics related to an air vehicle model (e.g., vehicle manufacturer, vehicle model, fuel / charge capacity at time of manufacture, maximum payload capacity, etc.). In another example, the vehicle information data store includes vehicle-specific characteristics (e.g., current fuel / charge capacity, when the vehicle was last maintained, when maintenance is scheduled, etc.). For example, particular air vehicles of the same vehicle type may have different characteristics, or characteristics may change over the life of the vehicle.

[0008] An air vehicle having a particular energy type may have or be associated with a state of charge. As used herein, the "state of charge" of an air vehicle refers to the energy currently available to the air vehicle. Given that an air vehicle has various characteristics, determining the state of charge of the air vehicle may depend on such characteristics. For example, the state of charge refers to the amount of energy available to the air vehicle (e.g., watt-hours, voltage, etc.). Depending on the air vehicle's energy type, the state of charge may be determined based on the charge of one or more rechargeable batteries, the amount of fuel remaining in the fuel tank, or a combination thereof. The state of charge affects the distance the air vehicle can travel. The state of charge also affects the maximum payload the air vehicle can carry relative to distance.

[0009] Air vehicles may also have or be associated with a health state. The "health" of an air vehicle refers to the air vehicle's ability to store or use energy to complete a route. For example, the battery capacity of an electric or hybrid air vehicle's rechargeable batteries may decrease over time, resulting in a reduced air vehicle's range and ability to carry heavy loads. It will be appreciated that hydrocarbon-based air vehicles may also experience declining health over time as a result of mechanical degradation of the air vehicle's engines and other components. Another example of declining health is the gradual increase in the weight of the air vehicle over its lifespan. Thus, it will be appreciated that the aspects of the air vehicle used to determine the air vehicle's health will vary based on the characteristics of the air vehicle, including, but not limited to, the type of energy, the air vehicle's hardware, and the vehicle's weight, among other examples.

[0010] An air vehicle may also have or be associated with a power state. The "power state" of an air vehicle represents airlift capacity and thereby indicates the maximum amount of payload the air vehicle can carry (e.g., during takeoff, while climbing to a target altitude, etc.). The power state therefore represents the peak energy available (e.g., the current, horsepower, and / or torque output available from one or more battery cells, etc.). Examples of factors for determining the power state include, but are not limited to, the open-circuit voltage and / or internal resistance of one or more battery cells, the duration that peak power is available (e.g., before current begins to drop, a temperature threshold is reached, etc.), the state of health, the state of charge, and / or temperature (e.g., ambient temperature, the operating temperature of the air vehicle, etc.). It will be appreciated that different algorithms can be used to determine the power state of different types of air vehicles. For example, an all-electric air vehicle may use a different algorithm than a hybrid vehicle or a strictly hydrocarbon-powered vehicle.

[0011] As a result of these differences in vehicle characteristics, it may be beneficial to evaluate the vehicle characteristics when determining which air vehicle to use (e.g., to transport passengers). This evaluation may be useful when generating a route for the determined air vehicle to travel (e.g., to transport a user from one location to another). For example, a hydrocarbon-powered or hybrid air vehicle may exhibit a longer range and therefore be a better candidate for traveling a longer route. As another example, an electric air vehicle exhibiting reduced health may be a better candidate for a series of short trips compared to an electric air vehicle with relatively better health. As a result of reduced health, it may take longer to recharge a depleted battery after a long trip compared to an electric air vehicle with better health. As a result, the vehicle may be grounded for an extended period of time. Given that the power state of an electric air vehicle decreases proportionally to the decrease in health, an electric air vehicle with high health may be used to transport a heavy load compared to an electric air vehicle with low health. Rather, an electric air vehicle with low health may not have enough power to maneuver adequately with a heavy payload.

[0012] The air vehicle's state of health, state of charge, and power status are communicated by the air vehicle to the transportation system. In one example, the air vehicle includes a vehicle status monitor that collects information from various sensors and controllers on the air vehicle. For example, fuel and / or charge sensors are used to determine the vehicle's state of charge. As another example, a health controller monitors engine oil life, estimated or measured air vehicle weight, and scheduled required maintenance, among other examples. A power status controller may monitor peak airborne capacity, maximum current obtainable from one or more batteries, and / or engine efficiency, among other examples. The vehicle status monitor may communicate the state of health, state of charge, and power status periodically, upon request from the transportation system, and / or upon the occurrence of certain events (e.g., upon departing from or arriving at a vertiport, upon reaching a certain state of charge, or upon determining that estimated vehicle performance has deviated from actual vehicle performance by more than a predetermined threshold).

[0013] Air vehicles travel between vertiports. As used herein, a vertiport is a location where an air vehicle arrives, departs, refuels / charges, and / or is maintained, among other examples. A vertiport can be located at ground level, above ground level, or below ground level. A vertiport may have a variety of associated functions, including, but not limited to, the ability to charge electric or hybrid air vehicles, the ability to refuel hydrocarbon-based or hybrid air vehicles, and the ability to perform various types of vehicle maintenance. Thus, given the diversity of vertiports in a transportation network, it may also be beneficial to evaluate the functionality of such vertiports when determining air vehicles and generating routes for air vehicles. In some examples, vertiport functionality is evaluated in combination with vehicle characteristics.

[0014] The vertiport functions of vertiports in a transportation network can be stored using a vertiport information data store. For example, the vertiport information data store includes functions related to types of vertiports (e.g., vertiports co-located with commercial airports, refueling vertiports, charging vertiports, etc.) and / or vertiport-specific information. In some examples, the vertiport information data store also includes historical demand information, which can be used to predict future demand at a given vertiport and between pairs of vertiports.

[0015] It will be understood that cargo transported by an air vehicle in accordance with embodiments described herein may include one or more passengers, luggage, cargo, food, or any combination thereof, among other examples. Characteristics of the cargo include, but are not limited to, cargo weight, cargo volume, number of passengers in the cargo, pickup location, delivery location, and / or travel distance. In some examples, demand information for a vertiport or pair of vertiports is further categorized based on cargo type. To transport cargo, an air vehicle may travel between a pair of vertiports in a transportation network. In some examples, cargo is transported to or from a vertiport (e.g., before or after transport by the air vehicle) by another mode of transportation, including, but not limited to, an automobile, a scooter, or a bicycle, among other examples. In other examples, cargo may be transported between a series of nodes in a transportation network, with the cargo being transported accordingly using the same air vehicle or multiple air vehicles.

[0016] In some examples, the transportation system provides an application programming interface (API). The API is used to register air vehicles with the transportation system. The API can be used to indicate when an air vehicle is active in the transportation network and available to transport cargo. For example, an air vehicle may use the API to indicate its availability to transport cargo (e.g., when it is powered on, when it leaves a predetermined location, etc.). As another example, a computing device (e.g., which may be used by an air vehicle owner, an air vehicle operator, etc.) may use the API to indicate that the air vehicle is available to transport cargo. In some examples, the API is used to provide air vehicle information to the transportation system, including, but not limited to, the air vehicle's energy type, health status, charge status, power status, current cargo weight, and / or available cargo capacity. The air vehicle information can be provided by the vehicle manufacturer, the air vehicle owner / operator, and / or the air vehicle itself, among other examples. In some examples, the transportation system stores the vehicle information obtained using the API in the vehicle information data store described above.

[0017] Accordingly, this disclosure describes systems and methods for selecting and routing air vehicles to generate itineraries for transporting cargo between vertiports in a transportation network. In an example, available origin and destination vertiports are evaluated, alone or in combination with vehicle characteristics. Demand information (which may be stored, for example, by a vehicle information data store) is processed to generate routes through the transportation network, thereby meeting predicted demand (which may be modeled, for example, according to past observations and / or upcoming events, among other examples) for transporting cargo between vertiports in the transportation network. A route includes a departure vertiport and a destination vertiport, which may be referred to as a vertiport pair. A route may be time-related, determined based on the demand information. In an example, a route further includes information regarding past and / or predicted demand for one or more expected cargo categories (e.g., passengers, baggage, cargo, food, etc.). Air vehicles for transporting cargo between the generated routes are then determined as described herein. In another example, an air vehicle may travel a route without transporting cargo (e.g., "empty sailing"). In examples, such routes are used to position air vehicles at destination vertiports in anticipation of forecasted demand, to perform vehicle maintenance, to refuel / charge air vehicles according to specific vehicle characteristics, etc.

[0018] In an example, an air vehicle is associated with a set of generated routes. The set of routes is determined based on evaluating the air vehicle using one or more models (e.g., statistical models, machine learning models, etc.) against available routes (which may be generated, for example, according to the aspects described above). For example, models related to the air vehicle's energy type, state of charge, state of health, and / or power state, among other vehicle characteristics, may be evaluated to generate the predicted vehicle characteristics. In an example, the statistical model is specific to the air vehicle type, and processes data for a set of air vehicles of a given type to generate the type-specific model. Vehicle information used for such evaluation may be accessed from the vehicle information data store described above.

[0019] The evaluation further includes evaluating route distance, vertiport capabilities, and cargo demand information based on the modeled vehicle characteristics to select an air vehicle capable of traveling the route carrying the predicted load. The set of routes may include one or more additional routes for placing the air vehicle at a given vertiport after the air vehicle completes the set of routes. For example, a given vertiport may be a vertiport where the air vehicle can charge / refuel, or may be a vertiport where the air vehicle is expected to begin a new set of generated routes.

[0020] In some examples, the state of charge and / or power state of the air vehicle are evaluated to maintain an energy budget. For example, the energy budget may include a state of charge threshold such that the state of charge of the air vehicle is maintained above the threshold. As another example, the energy budget may include a power state threshold such that the power state of the vehicle does not fall below the power state threshold. Thus, a route may be selected to keep the air vehicle at a predetermined state of charge and / or power state upon arrival at the destination vertiport. The threshold may be determined based on a subsequent route assigned to the air vehicle (e.g., to ensure that the air vehicle has sufficient energy to complete the subsequent route) and / or based on a minimum energy requirement to ensure that the air vehicle can be refueled at a given vertiport, among other examples.

[0021] Among other examples, air vehicle routing may change as a result of vehicle characteristics deviating from modeled characteristics while traveling a route or as a result of unforeseen demand. For example, an air vehicle may be assigned a first route followed by a second route. However, adverse weather conditions may adversely affect the vehicle's state of charge, resulting in the vehicle no longer having sufficient energy to travel the second route. The second route may then be reassigned to a different air vehicle, and the first air vehicle may be reassigned a different route within the transportation network over which it can travel in light of its updated vehicle characteristics. In another example, an air vehicle is routed to a new vertiport after completing the first route. For example, a reduced state of charge may result in the absence of any suitable route. The new vertiport may allow the air vehicle to recharge / refuel, take on cargo more suited to the air vehicle's current state of charge, or travel a route more suited to the air vehicle. Thus, an air vehicle is assigned to one or more routes to optimize or improve one or more criteria, including, but not limited to, travel time, travel distance, charging / refueling time, energy constraints, state of charge constraints, power state constraints, and / or air vehicle downtime.

[0022] A route is generated for transporting cargo within a transportation network. The route includes one or more routes and associated air vehicles. In an example, an existing route for transporting cargo is determined based on cargo characteristics, route distance, route duration, and projected or actual demand for the route. Given that the route exists, an air vehicle may already be associated with the route, so the determination further includes evaluating cargo characteristics based on vehicle characteristics. For example, the evaluation may include evaluating the weight of the cargo compared to the air vehicle's state of charge, state of health, and / or power state. In some examples, the route is generated in response to a received route request. The route request may be received from a computing device and may include at least a start location and a destination location for the cargo. It will be appreciated that the start location and destination location need not each be a vertiport, and that in some examples, multiple transportation modes are used, as described above.

[0023] In other examples, a new route for the load is generated instead of using an existing route. For example, an existing route may not have capacity for the load (e.g., due to volume limitations, weight limitations, etc.), or there may be no existing route for transporting the load to the destination. In such examples, a route can be generated based on predicted or actual demand information and the load's pickup / delivery locations. For example, if additional load shares a similar pickup / delivery location, a new route is generated to accommodate that load. As explained above, generating a route includes selecting departure and arrival vertiports for the load accordingly. An air vehicle is determined and associated with the route, and the air vehicle is selected based on an evaluation of the load characteristics and vehicle characteristics. Returning to the above example with multiple loads, the evaluation may further include evaluating the characteristics of each additional load against the vehicle characteristics. It will be understood that air vehicles may be fully utilized, while in other examples there may be excess capacity depending on the current demand for the air vehicle or the planned future routes, among other examples.

[0024] FIG. 1 illustrates an example of a multimodal transportation system 100 in which cargo is routed according to aspects described herein. The multimodal transportation system 100 is shown to include passengers 110, luggage 120, vertiports 140, air vehicles 150, and ground vehicles 130, 160, and 170. The air vehicles 150 and ground vehicles 130, 160, and 170 are shown as examples of transportation modes used to transport one or more loads (e.g., passengers 110 and luggage 120) within the multimodal transportation network. It will be understood that any of a variety of additional or alternative transportation modes can be used without departing from this disclosure. Similarly, the multimodal transportation system 100 is shown to include passengers 110 and luggage 120 as examples of cargo. Additional or alternative loads, including, but not limited to, cargo or food, may be used according to other aspects of the disclosure.

[0025] In the example, the payloads 110 and 120 are at a starting location for transport to a destination location. In some examples, the starting location may be a vertiport 140 where the air vehicle 150 is located, such that the payloads 110 and 120 are transported to the destination location at least in part using the air vehicle 150. In other examples, the starting location is not a vertiport 140. In such examples, another transportation mode is used to transport the payloads 110 and 120 to the vertiport 140 in order to route the payloads 110 and 120 to the destination location using the air vehicle 150. For example, one or more of the ground vehicles 130, 160, and / or 170 may be used. Similarly, the destination vertiport where the air vehicle 150 lands may be the destination location for the payloads 110 and 120. However, in other examples where the destination vertiport is not the destination location, one or more other transportation modes may be used to transport the payloads 110 and 120 from the destination vertiport to the destination location.

[0026] Furthermore, while the multimodal transportation system 100 is described with respect to a single air vehicle 150 traveling from the starting vertiport 140 to the destination vertiport, it will be understood that in other examples, additional vertiports and / or air vehicles are used to transport the cargo accordingly. For example, intermediate vertiports may be used to refuel / charge the air vehicle 150, or as another example, the cargo 110 and 120 may leave the air vehicle 150 and travel to the destination location on another air vehicle. As another example, the cargo 110 and 120 may leave the air vehicle 150 at a first intermediate vertiport, travel using one or more different transportation modes to a second intermediate vertiport, and travel to the destination location on another air vehicle at the second intermediate vertiport. Thus, cargo need not travel solely from the starting vertiport to the destination vertiport within the transportation network, but instead may be routed from the starting location to the destination location using any of a variety of transportation modes, intermediate stops, and vehicles.

[0027] Passenger 110 uses a client device to specify a start location and a destination location. As shown, passenger 110 uses a tablet computing device, although it will be understood that any of a variety of other computing devices may be used. In an example, an automobile 130 is specified to transport passenger 110 and luggage 120 from the start location to vertiport 140. In another example, passenger 110 uses a client device to identify a nearby vehicle, such as one of vehicles 160 and 170. Passenger 110 can then "unlock" vehicle 160 or 170 and use that vehicle accordingly. In some examples, passenger 110 may travel to vertiport 140 using one mode of transportation (e.g., vehicle 160 or 170), while luggage 120 may be transported to vertiport 140 using another mode of transportation (e.g., automobile 130).

[0028] A vertiport 140 is a location where an air vehicle (e.g., air vehicle 150) arrives, departs, refuels / charges, and / or is maintained, among other examples. As such, a vertiport 140 may have any of a variety of associated functions, including, but not limited to, the ability to charge and / or refuel the air vehicle 150 and perform various types of vehicle maintenance. A vertiport 140 may be located at ground level, above ground level, or below ground level. While multi-modal transportation system 100 is shown as including one air vehicle 150, it will be understood that any number of air vehicles may use the functions associated with a vertiport 140. Returning to the example above, cargo 110 and 120 may originate from vertiport 140 or may arrive at vertiport 140 for transport by air vehicle 150 (e.g., after transport by another air vehicle, after transport by ground vehicles 130, 160, and / or 170, etc.).

[0029] Air vehicle 150 may be an electric air vehicle, a hybrid air vehicle, or a hydrocarbon-based air vehicle, among other examples. According to aspects described herein, air vehicle 150 has various associated vehicle characteristics, including, but not limited to, vehicle manufacturer, vehicle model, fuel / charge capacity at time of manufacture, current fuel / charge capacity, maximum payload capacity, when the air vehicle was last maintained, and / or when maintenance is scheduled. Such characteristics may be stored in a vehicle information data store associated with multimodal transportation system 100 and may be used to route cargo using air vehicle 150 according to cargo characteristics associated with the cargo.

[0030] In examples, the air vehicle 150 further includes a vehicle status monitor that determines the state of health, state of charge, and / or power status of the air vehicle 150. Such information is communicated to the multimodal transportation system 100 and used to route cargo in accordance with aspects described herein. For example, the vehicle status monitor may communicate the state of health, state of charge, and power status of the air vehicle 150 periodically, upon request from the multimodal transportation system 100, and / or upon the occurrence of certain events (e.g., upon departure from or arrival at the vertiport 140, upon reaching a certain state of charge, upon determining that estimated vehicle performance has deviated from actual vehicle performance by more than a predetermined threshold, etc.).

[0031] 2 illustrates an example of a system 200 for routing cargo using air vehicles of a transportation service entity. In the example, aspects of system 200 are used to route cargo within a multi-modal transportation network, such as multi-modal transportation system 100 discussed above with respect to FIG. 1. As shown, system 200 includes client devices 205, 210, and 215, a transportation system 220, and air vehicles 225 and 230. In one example, each of client devices 205, 210, and 215 is any of a variety of computing devices, including, but not limited to, a mobile computing device, a laptop computing device, a tablet computing device, or a desktop computing device.

[0032] For example, client device 205 may include a passenger application through which a passenger identifies and / or unlocks a vehicle (e.g., vehicle 160 or 170 in FIG. 1 ), requests a ride from a provider (e.g., operating a motor vehicle such as automobile 130), and / or schedules a trip by air vehicle (e.g., air vehicle 150). Accordingly, the passenger application on client device 205 communicates (e.g., using an API) with transportation system 220 to provide a journey request and thereby obtain a journey for transporting cargo (e.g., including passengers, baggage, and / or cargo, etc.) from a start location to a destination location.

[0033] As another example, client device 210 includes a provider application used by a provider operating a fleet of vehicles to, among other actions, indicate its capacity to meet demand within the transportation network and to accept requests to transport one or more loads. In another example, client device 215 includes a provider application used by a provider operating an air vehicle (e.g., pilots, flight attendants, etc.). The provider application may allow the provider to input information including, but not limited to, unladen vehicle payload capacity, remaining vehicle payload capacity, and / or one or more served geographic areas. In another example, the provider application automatically collects information such as the client device's location or client device's altitude, among other examples. Similar to the passenger application, the provider application can communicate with transportation system 220 using an API. While example functionality has been described with respect to separate passenger applications and separate provider applications, in other examples, such functionality may be combined into a single application or distributed across any number of other applications.

[0034] Air vehicle 225 includes vehicle state monitor 250, energy source 255, and processor 260. Energy source 255 can be any of a variety of energy sources according to aspects described herein, including, but not limited to, hydrocarbon fuel, one or more battery cells, or other power sources, or any combination thereof. In an example, vehicle state monitor 250 collects information from various sensors and controllers of air vehicle 225. For example, vehicle state monitor 250 determines the state of charge of energy source 255 (e.g., using a fuel sensor and / or a charge sensor). As another example, vehicle state monitor 250 monitors engine oil life, estimated or measured air vehicle weight, and scheduled required maintenance, among other examples. Vehicle state monitor 250 can monitor aspects related to the power state of air vehicle 225 (e.g., peak airlift capacity, maximum current available from one or more batteries, and / or engine efficiency).

[0035] Processor 260 communicates information collected by vehicle status monitor 250 to transportation system 220. For example, processor 260 communicates the health, charge, and / or power status of air vehicle 225 periodically, upon request from transportation system 220, and / or upon the occurrence of certain events (e.g., upon departure from or arrival at a vertiport, upon reaching a certain state of charge, upon determining that estimated vehicle performance has deviated from actual vehicle performance by more than a predetermined threshold, etc.).

[0036] In an example, processor 260 obtains a journey from transportation system 220. As explained above, the journey may include a route from a start vertiport to a destination vertiport, as well as instructions for the cargo to be transported between the two vertiports. Processor 260 then processes the received journey to verify that air vehicle 225 is capable of performing the journey. As an example, processor 260 evaluates the power and / or energy requirements associated with the journey compared to the state of charge and / or power state of air vehicle 225, respectively.

[0037] In some examples, processor 260 generates one or more vehicle status indicators (e.g., state of charge, power status, health status, etc.) related to air vehicle 225 that are provided to a provider operating air vehicle 225. Such vehicle status indicators may be provided by a display within air vehicle 225 and / or by a provider application, among other examples. For example, the vehicle status indicator may be a recommendation to accept the journey, a recommendation to reject the journey, a set of vehicle characteristics, or any combination thereof, among other examples. The provider may use the vehicle status indicators to determine whether air vehicle 225 is suitable to perform the journey, after which the provider provides instructions to processor 260 to accept or reject the journey.

[0038] Thus, it will be understood that in some instances the verification process is performed automatically, while in other instances human interaction is received as at least part of the verification process. Based on the verification process, processor 260 provides instructions to transportation system 220 regarding whether to accept or reject the itinerary. In instances where the itinerary is rejected, another itinerary may be received from transportation system 220 to be verified according to aspects described herein. In other instances, in addition to or in lieu of the verification techniques performed by processor 260, transportation system 220 may verify the itinerary for air vehicle 225 to accept or reject the itinerary on behalf of air vehicle 225. Thus, it will be understood that verification need not be performed exclusively by the air vehicle.

[0039] Air vehicle 230 includes vehicle state monitor 265, energy source 270, and processor 275, aspects of which are similar to vehicle state monitor 250, energy source 255, and processor 260 of air vehicle 225 and therefore will not be described again in detail below. In examples, a route is assigned to air vehicle 225 by transportation system 220, as verified by processor 260 in accordance with aspects described herein (e.g., based on the state of charge, power state, and / or health state determined by vehicle state monitor 250). In some examples, processor 260 determines that air vehicle 225 is not suitable to perform the route (e.g., based on the payload exceeding the weight that can be supported by the power state, the route distance exceeding the state of charge of air vehicle 225, etc.).

[0040] In such an example, processor 260 provides a reject instruction to transportation system 220, after which the rejected itinerary is reassigned. For example, the rejected itinerary may be reassigned to air vehicle 230. Similar to air vehicle 225, processor 275 of air vehicle 230 evaluates the itinerary as described above to verify that air vehicle 230 is capable of performing the assigned itinerary. Thus, if processor 275 successfully verifies the itinerary, processor 275 provides an accept instruction to transportation system 220. However, if the itinerary is not verified, a reject instruction is provided to transportation system 220 instead.

[0041] Transportation system 220 is shown as including vehicle information data store 235, vertiport information data store 240, and itinerary generation engine 245. Vehicle information data store 235 stores any of a variety of vehicle information (e.g., related to air vehicles 225 and 230), including, but not limited to, general characteristics related to the air vehicle model (e.g., vehicle manufacturer, vehicle model, fuel / charge capacity at time of manufacture, maximum payload capacity, etc.). In other examples, vehicle information data store 235 includes vehicle-specific characteristics related to air vehicle 225 and / or air vehicle 230 (e.g., current fuel / charge capacity, when the vehicle was last maintained, when maintenance is scheduled, etc.).

[0042] It will be appreciated, therefore, that the vehicle information stored by vehicle information data store 235 may originate from any of a variety of sources. As one example, general characteristics related to a model of air vehicle may be provided by or accessed from one or more manufacturers associated with the model of air vehicle, while vehicle-specific characteristics may be collected or received from the air vehicle in accordance with aspects described herein (e.g., from processor 260 and vehicle state monitor 250 of air vehicle 225 and / or from processor 275 and vehicle state monitor 265 of air vehicle 230). As another piece of information, transportation system 220 may generate the vehicle information stored by vehicle information data store 235. For example, vehicle information data store 235 may store metrics related to the percentage of accepted / rejected journeys for a given air vehicle, as well as the accuracy of predicted vehicle characteristics compared to actual vehicle characteristics (e.g., modeled state of charge compared to reported state of charge, modeled power state compared to reported power state, modeled health state compared to reported health state, etc.).

[0043] Transportation system 220 is further shown as including a vertiport information data store 240 that stores information related to vertiports in the transportation network (e.g., vertiports 140 in FIG. 1). For example, vertiport information data store 240 includes features related to vertiport types (e.g., vertiports co-located with commercial airports, refueling vertiports, charging vertiports, etc.) and / or vertiport-specific information (e.g., whether a vertiport is located at ground level, above ground level, or below ground level, the number of air vehicles that may be at the vertiport at a given time, etc.). In some examples, vertiport information data store 240 also includes historical demand information, which can be used to predict future demand at a given vertiport and between pairs of vertiports.

[0044] The itinerary generation engine 245 of the transportation system 220 generates routes, assigns air vehicles to the generated routes, and generates itineraries for transporting cargo using the routes and associated air vehicles according to aspects described herein. As an example, the itinerary generation engine 245 can access demand information in the vertiport information data store 240 and process the demand information to generate routes between vertiports in the transportation network. For example, to meet predicted demand for transporting cargo between vertiports in the transportation network, demand can be modeled according to past observations and / or upcoming events (e.g., which may be stored by the vertiport information data store 240), among other examples. The routes generated by the itinerary generation engine 245 include a departure vertiport and an arrival vertiport, which may be referred to as a vertiport pair. The generated routes can be associated with a time determined based on the demand information. In an example, the routes further include information regarding past and / or predicted demand for one or more expected cargo categories (e.g., passengers, baggage, cargo, food, etc.).

[0045] Thus, itinerary generation engine 245 associates an air vehicle (e.g., air vehicle 225 or air vehicle 230) with a set of generated routes. The set of routes is determined based on evaluating a given air vehicle using one or more models (e.g., statistical models, machine learning models, etc.) against available routes. For example, models related to the air vehicle's energy type, state of charge, state of health, and / or power state, among other vehicle characteristics, may be evaluated to generate the predicted vehicle characteristics. In an example, the statistical model is specific to the air vehicle type and processes data for a set of air vehicles of a given type to generate the type-specific model.

[0046] In some examples, the itinerary generation engine 245 evaluates the air vehicle's state of charge and / or power state to maintain an energy budget for the air vehicle. For example, the energy budget may include a state of charge threshold such that the air vehicle's state of charge is maintained above the threshold. As another example, the energy budget may include a power state threshold such that the vehicle's power state does not fall below the power state threshold. Thus, the itinerary generation engine 245 may select a route to maintain the air vehicle at a predetermined state of charge and / or power state upon arrival at the destination vertiport. For example, the threshold may be determined based on a subsequent route specified for the air vehicle (e.g., to ensure that the air vehicle has sufficient energy to complete the subsequent route) and / or based on a minimum energy requirement to ensure that the air vehicle can be refueled at a given vertiport, among other examples. Vehicle information for a given air vehicle used in such evaluation is accessed from the vehicle information data store 235.

[0047] In some examples, the evaluation performed by the itinerary generation engine 245 further includes evaluating route distance, vertiport capabilities, and cargo demand information based on modeled vehicle characteristics to select air vehicles capable of traveling the route carrying the predicted cargo. Such information may be accessed from the vertiport information data store 240. As explained above, a set of routes may include one or more additional routes for placing the air vehicle at a predetermined vertiport after it has completed a set of routes. For example, a predetermined vertiport may be a vertiport where the air vehicle can charge / refuel, or a vertiport where the air vehicle is expected to begin a new set of generated routes. In another example, the itinerary generation engine 245 routes the air vehicle without a corresponding cargo (e.g., "empty flight"). In examples, such routes are used to place the air vehicle at a destination vertiport in anticipation of predicted demand, for performing vehicle maintenance, for refueling / charging the air vehicle according to specific vehicle characteristics, etc.

[0048] Itinerary generation engine 245 may also generate itineraries for transporting cargo within the transportation network. In an example, such itineraries are generated in response to a itinerary request, which may be received from a client device, such as client device 205, 210, or 215. According to aspects described herein, the itinerary request may include at least a start location and a destination location for the cargo. It will be appreciated that the start location and destination location need not each be a vertiport, and that in some instances, multiple modes of transportation are used, as described above. An example of such an aspect is described with respect to multimodal transportation system 100 of FIG. 1. As another example, itinerary generation engine 245 generates itineraries based on instructions received from an air vehicle (e.g., processor 260 or processor 275 of air vehicle 225 or 230, respectively). Such aspects are described in more detail below.

[0049] As described above, a journey includes one or more routes and associated air vehicles. In examples, an existing route generated by the journey generation engine 245 is selected based on cargo characteristics, route distance, route duration, and expected or actual demand for the route. In examples, at least some of such information is included in the journey request. In examples where an existing route is used, an air vehicle (and in some examples, one or more cargoes) may already be associated with the route, so the journey generation engine 245 evaluates cargo characteristics based on vehicle characteristics of the associated air vehicle. For example, the evaluation may include evaluating the weight of the cargo compared to the state of charge, state of health, and / or power status of the air vehicle associated with the route. In other examples, the journey generation engine 245 generates a new route for the cargo (e.g., based on the received journey request) instead of using an existing route. For example, an existing route may not have capacity for the cargo (e.g., due to volume restrictions, weight restrictions, etc.), or there may be no existing route for transporting the cargo to the destination.

[0050] In some examples, a route may be changed as a result of actual vehicle characteristics deviating from modeled characteristics (e.g., while traveling a route) or as a result of unforeseen demands, among other examples. For example, vehicle characteristics received from processor 260 of air vehicle 225 or processor 275 of air vehicle 230 may indicate that the modeled vehicle information differs from the air vehicle's actual state of charge, power state, and / or health. Accordingly, itinerary generation engine 245 may reassign the route to a different air vehicle, thereby generating an updated itinerary. As another example, the air vehicle may reject the assigned itinerary, thereby causing the itinerary to be reassigned and / or a new itinerary to be generated for the air vehicle.

[0051] In another example, itinerary generation engine 245 may decide to route the air vehicle to a different vertiport after completion of a designated route. For example, as a result of a low state of charge, there may not be any suitable route for the air vehicle, so a new vertiport may allow the air vehicle to charge / refuel, take on cargo that is more suitable for the air vehicle's current state of charge, or travel a more suitable route from that vertiport. Thus, itinerary generation engine 245 assigns the air vehicle to one or more routes to optimize or improve one or more criteria, including, but not limited to, travel time, travel distance, charging / refueling time, energy constraints, state of charge constraints, power state constraints, and / or air vehicle downtime.

[0052] 3A illustrates an example method 300 for generating routes for air vehicles within a transportation network and determining a journey in response to an itinerary request. In an example, aspects of method 300 are performed by a transportation system for routing cargo within a transportation network, such as transportation system 220 of FIG. 2 and multi-modal transportation system 100 of FIG. 1. In some examples, aspects of method 300 are performed periodically and / or upon the occurrence of certain events (e.g., in response to an air vehicle accepting or rejecting a journey in response to an itinerary request, etc.).

[0053] Method 300 begins with operation 305, where vertiport demand information is accessed. In an example, vertiport demand information is accessed from a vertiport information data store, such as vertiport information data store 240 of Figure 2. Examples of vertiport demand information include, but are not limited to, historical demand information for a given vertiport and / or vertiport pair, as well as predicted future demand (e.g., according to one or more models, based on one or more forecasted events, etc.).

[0054] Flow continues to operation 310, where a route is generated according to the accessed demand information. As discussed above, the route includes a departure vertiport and an arrival vertiport, which may be referred to as a vertiport pair. The route may be time-related, as determined based on the demand information. In an example, the route further includes information regarding historical and / or forecasted demand for one or more expected cargo categories (e.g., passengers, baggage, cargo, food, etc.), which may be determined according to the demand method accessed in operation 305.

[0055] As one example, pairs of vertiports between which several loads have been transported are identified according to historical data. In some examples, only pairs of vertiports with demand above a predetermined threshold are identified. For example, the predetermined threshold may evaluate the number of loads transported between the pair of vertiports per day, per hour, or any of various other time periods. As another example, demand information for a set of vertiports associated with a region is aggregated, thereby generating routes based on the assumption that the vertiports within the set are interchangeable and can each be used to serve demand from the more global region. Thus, cargo can be routed to any of the vertiports in the set according to the multimodal transportation network disclosed herein. While example route generation techniques have been described, it will be understood that any of a variety of techniques may be used in addition to or instead of the techniques described herein.

[0056] In operation 315, air vehicles are assigned to the generated routes according to vehicle characteristics. In one example, the air vehicles are evaluated using one or more models (e.g., statistical models, machine learning models, etc.) against the available routes (e.g., generated in operation 310). For example, models related to the air vehicle's energy type, state of charge, state of health, and / or power state, among other vehicle characteristics, may be evaluated to generate the predicted vehicle characteristics. In an example, the statistical model is specific to the air vehicle type and processes data for a set of air vehicles of a given type to generate the type-specific model. Vehicle information used in such evaluation may be accessed from a vehicle information data store, such as vehicle information data store 235 of FIG. 2, discussed above.

[0057] In some examples, process 315 further includes evaluating route distance, vertiport capabilities, and predicted cargo demand information based on the modeled vehicle characteristics to select air vehicles capable of traveling the route carrying the predicted cargo. In examples, one or more additional routes are assigned to the air vehicle to position the air vehicle at a predetermined vertiport after the air vehicle completes a set of designated routes. For example, the predetermined vertiport may be a vertiport where the air vehicle can charge / refuel, or may be a vertiport where the air vehicle is expected to begin a set of new generated routes.

[0058] Process 315 may further include evaluating the state of charge and / or power state of the air vehicle to maintain an energy budget. For example, the energy budget may include a state of charge threshold such that the state of charge of the air vehicle is maintained above the threshold. As another example, the energy budget may include a power state threshold such that the vehicle's power state does not fall below the power state threshold. Thus, an air vehicle may be assigned to a given route based on determining that the air vehicle will have a predetermined state of charge and / or power state upon arrival at a destination vertiport for the route. The threshold may be determined based on other (e.g., subsequent) routes assigned to the air vehicle (e.g., to ensure that the air vehicle has sufficient energy to complete the subsequent route) and / or based on a minimum energy requirement to ensure that the air vehicle can be refueled at a given vertiport, among other examples.

[0059] Flow continues to operation 320, where a journey request is received. For example, the journey request may be received from a client device, such as client device 205, 210, or 215 of FIG. 2. As discussed above, the journey request may include at least a start location and a destination location for the cargo. It will be appreciated that the start and destination locations need not each be vertiports, and that in some instances, multiple modes of transportation are used, as discussed above. The journey request may further include one or more cargo characteristics, including, but not limited to, cargo type, cargo weight, cargo volume, number of passengers in the cargo, pickup location, delivery location, and / or travel distance.

[0060] The process proceeds to operation 325, identifying a set of routes based on the received journey requests. As one example, the routes generated in operation 310 are determined based on cargo characteristics, route distance, route duration, and / or expected or actual demand for the route. The determination may further include evaluating cargo characteristics based on vehicle characteristics of the air vehicle assigned to the route in operation 315. For example, the evaluation may include evaluating the weight of the cargo compared to the state of charge, state of health, and / or power status of the air vehicle. The evaluation may further include evaluating characteristics of additional cargo assigned to the route against the vehicle characteristics. It will be appreciated that an air vehicle may be fully operational, while in other instances there may be excess capacity depending on the current demand for the air vehicle or planned future routes, among other examples.

[0061] Similar techniques can be used to add additional routes to the set of routes, such that multiple routes are connected for transporting a load. Additionally, although process 325 is described as using an existing route, it will be understood that other examples may include generating a new route for the load (e.g., as described above with respect to processes 305-315), among other examples.

[0062] At operation 330, an itinerary is generated that includes a set of routes and associated air vehicles. In one example, instructions for the generated itinerary are provided (e.g., to a client device) in response to the itinerary request received at operation 320. As another example, instructions for the generated itinerary are provided to an air vehicle, such as air vehicles 150, 225, and / or 230 of Figures 1 and 2. The flow ends at operation 330.

[0063] 3B illustrates an example method 340 for assigning an itinerary to an air vehicle. In the example, aspects of method 340 are performed by a transportation system for routing cargo within a transportation network, such as transportation system 220 of FIG. 2 and multi-modal transportation system 100 of FIG. 1. Method 340 begins with operation 345, which generates an itinerary for the air vehicle. In some examples, operation 345 includes performing aspects of method 300 discussed above with respect to FIG. 3A.

[0064] Flow continues to operation 350, where route instructions are provided to the air vehicle for which the route is being generated. In an example, the instructions include information about the route (e.g., vertiport pairs, distance, vertiport characteristics, etc.) and information about one or more associated cargoes. The instructions may be provided to a processor of the air vehicle, such as processor 260 of air vehicle 225 or processor 275 of air vehicle 230 in FIG. 2. In another example, the instructions may be provided to a provider application on a client device. While example instructions are described herein, it will be understood that alternative, additional, or less information may be provided as part of the instructions. For example, vertiport characteristics may be omitted, so that the air vehicle instead accesses such information from a vertiport information data store, such as vertiport information data store 240 in FIG. 2.

[0065] In operation 355, an indication is received from the air vehicle indicating that the air vehicle accepts or rejects the journey. In some examples, the indication includes additional information regarding why the air vehicle decided to accept or reject the journey. For example, the indication may include an estimated state of charge, power state, or health state of the air vehicle after completing the journey. As another example, the indication may include an indication of an energy / power surplus or deficiency that may be used by the transportation system to revise one or more models or when generating subsequent journeys, among other examples.

[0066] Therefore, if the itinerary is indicated as not acceptable to the air vehicle, flow branches "NO" to operation 365, where the itinerary is reassigned. In an example, reassigning the itinerary involves performing steps similar to those discussed above with respect to method 300 of FIG. 3A to identify an air vehicle other than the air vehicle identified in operation 345. The itinerary is therefore reassigned to the new air vehicle, and flow returns to operation 345 to generate a new itinerary for the air vehicle accordingly. As noted above, the indication obtained in operation 355 may include information regarding the reason for rejection of the itinerary that can be used when generating the new itinerary. Flow proceeds through operations 345, 340, 355, and 360 as described above.

[0067] However, if the itinerary is instead indicated as being accepted by the air vehicle, flow branches "yes" to operation 370, where the itinerary is stored associated with the air vehicle. In examples, the itinerary is stored by a transportation system, such as transportation system 220 of FIG. 2. In some examples, operation 370 further includes providing instructions to a client device (e.g., one or more of client devices 205, 210, or 215 of FIG. 2). Method 340 ends with operation 370.

[0068] Although method 340 and other aspects disclosed herein are described in examples in which an air vehicle verifies a journey to accept or reject it, in other examples, the transportation system may follow similar techniques to verify the journey instead of or in addition to verification by the air vehicle. As an example, to determine whether a journey is accepted or rejected on behalf of the air vehicle, the transportation system may evaluate the state of charge, power state, and / or health state to verify the journey. If the journey is determined to be rejected, the journey may be redesignated (e.g., as described with respect to process 365) and a new journey may be created (e.g., as described with respect to process 345). In examples in which the journey is determined to be accepted, the journey may be associated with the air vehicle (e.g., as described with respect to process 370).

[0069] 3C illustrates an example method 380 for validating a journey in an air vehicle. In the example, aspects of method 380 are performed by an air vehicle, such as processor 260 of air vehicle 225 or processor 275 of air vehicle 230 in FIG. 2. Method 380 begins with operation 382, ​​which receives journey instructions. In the example, the instructions are received from a transportation system, such as transportation system 220 in FIG. 2. The instructions may be received from the transportation system performing operation 350 of method 340, discussed above with respect to FIG. 3B.

[0070] Flow continues to operation 384, where the journey is evaluated based on the air vehicle's state of charge. In examples, the state of charge is determined based at least in part on a vehicle state monitor, such as vehicle state monitor 250 or 265 of FIG. 2 . In some examples, the air vehicle's state of charge is estimated according to one or more statistical and / or machine learning models, among other examples. Thus, to verify that the air vehicle is capable of executing the journey, the energy requirements of the journey (which may be determined based on, for example, route distance, cargo weight, current and / or forecasted weather conditions, etc.) are evaluated according to the air vehicle's current and / or estimated state of charge. This evaluation may further include evaluating the air vehicle's estimated state of charge after the journey is performed against a predetermined threshold to ensure that the air vehicle maintains a certain energy budget (e.g., a minimum energy budget, a budget required to execute the subsequent journey, etc.).

[0071] In operation 386, the journey is evaluated based on the power state of the air vehicle. In examples, the power state is determined based at least in part on a vehicle state monitor, such as vehicle state monitor 250 or 265 in FIG. 2 . In some examples, the state of charge of the air vehicle is estimated according to one or more statistical and / or machine learning models, among other examples. Thus, to verify that the air vehicle is capable of executing the journey, the power requirements of the journey (which may be determined based on, for example, route distance, payload weight, current and / or forecasted weather conditions, etc.) are evaluated according to the air vehicle's current and / or estimated power state. This evaluation may further include evaluating the estimated power state of the air vehicle after executing the journey compared to a predetermined threshold to verify that the air vehicle maintains a certain power budget (e.g., a minimum power budget, a budget required to execute the subsequent journey, etc.).

[0072] The process proceeds to operation 388, evaluating the journey based on the health of the air vehicle. In examples, the health is determined based at least in part on a vehicle health monitor, such as vehicle health monitor 250 or 265 of FIG. 2. In some examples, the evaluation includes estimating the health of the air vehicle according to one or more statistical and / or machine learning models, among other examples. The health of the air vehicle may be estimated according to the journey, for example, to estimate the vehicle health during the journey or after completion of the journey.

[0073] Flow continues to operation 390, where a decision is made to accept or reject the journey. In an example, the evaluations performed in operations 384, 386, and 388 are used as part of this decision. For example, each evaluation can generate a score, and each of the scores can be combined according to a weighting so that a composite score is compared against a predetermined threshold. As another example, each evaluation can return a Boolean value (e.g., "yes" / "no," "true" / "false," etc.), whereby the decision in operation 390 decides to accept the journey only if each of the three evaluations returns a "yes" or "true" value. In some examples, operation 390 includes identifying one or more reasons why the journey is accepted or rejected. It will be appreciated that other techniques may be used to determine whether to accept a journey based on the evaluations.

[0074] In operation 392, a decision instruction is provided to a transportation system (e.g., transportation system 220 of FIG. 2). In some examples, the instruction includes additional information relevant to the decision to accept or reject the journey. For example, the instruction may include an estimated state of charge, power state, or health state of the air vehicle after completing the journey. As another example, the instruction may include an indication of energy / power surplus or deficiency, or an indication of which assessment caused the journey to be accepted or rejected. Flow ends at operation 392.

[0075] FIG. 4A illustrates an example method 400 for generating a set of routes within a transportation network based on historical demand information. In an example, aspects of method 400 are performed by a transportation system for routing cargo within a transportation network, such as transportation system 220 of FIG. 2 and multimodal transportation system 100 of FIG. 1. In some examples, aspects of method 400 are performed periodically and / or upon the occurrence of certain events (e.g., based on an air vehicle accepting or rejecting a journey in response to a journey request, etc.). As another example, aspects of method 400 may be performed as part of process 310 discussed above with respect to method 300 of FIG. 3A.

[0076] Method 400 begins with operation 405, where vertiport demand information is evaluated for a first vertiport. In examples, vertiport demand information is accessed from a vertiport information data store, such as vertiport information data store 240 of FIG. 2. In some examples, the first vertiport is selected based on proximity to a given location, historical demand, and / or predicted demand, among other information. In other examples, vertiports are processed iteratively according to method 400, with each vertiport in the set of vertiports being evaluated according to aspects described herein. Evaluating the demand information for the first vertiport may include identifying one or more peak travel times, estimating vertiport traffic according to time of day and / or day of week, or evaluating one or more cargo characteristics associated with the demand information, among other examples.

[0077] In process 410, a second vertiport is determined based on the demand information. In an example, the vertiport is determined based on identifying a set of vertiports that are close to one or more of the destination locations in the demand information. As an example, the identified peak travel time, vertiport traffic volume, and / or cargo characteristics associated with the first vertiport in process 405 can be used to identify the second vertiport. For example, the second vertiport is a destination vertiport that can transport one or more cargo from the first vertiport. In some examples, the set of vertiports is ranked according to, among other factors, proximity to the destination location, ability to service past or expected cargo volume, type, or other cargo characteristics indicated by the demand information. Process 410 can include evaluating characteristics of the second vertiport and / or vertiports associated with the first vertiport. In an example, such characteristics can be accessed from a vertiport information data store, such as vertiport information data store 240.

[0078] Flow continues to operation 415, where operation 415 generates a route including a first vertiport and a second vertiport. As described herein, the generated route includes a departure vertiport (e.g., the first vertiport in operation 405) and an arrival vertiport (e.g., the second vertiport in operation 410). The route may be related to time and / or historical or forecasted demand for one or more cargo categories, which may have been determined in operation 405 and / or 410 based on demand information.

[0079] While aspects of method 400 have been described with respect to generating routes to meet historical and / or projected demand, it will be appreciated that such techniques need not be used solely to generate routes to transport cargo. Rather, as explained above, routes can be generated for air vehicles without transporting associated cargo (e.g., "empty voyages"), thereby positioning the air vehicles at destination vertiports to meet demand and / or receive maintenance, among other examples.

[0080] At decision 420, it is determined whether there is additional demand to address. This determination includes evaluating the demand information against the set of generated routes to determine whether additional routes should be generated. For example, a predetermined threshold may be used such that routes are generated if the remaining demand against the set of routes exceeds the predetermined threshold. As another example, the set of routes is evaluated to determine whether additional routes need to be generated to reposition air vehicles to better meet demand at different vertiports. While example considerations have been described, it will be understood that any of a variety of other considerations may be used in addition to or instead of such example considerations.

[0081] If it is determined that there is more demand to serve, the flow branches "yes" and again executes operations 405-420 as described above to generate more routes. However, if it is determined that there is no more demand to serve, the flow instead branches "no" to operation 425, where the routes generated according to operations 405-420 are stored. The set of routes can be stored by a transportation system (e.g., transportation system 220 of FIG. 2) and / or assigned to an air vehicle and used to serve demand in the transportation network according to aspects described herein. The flow ends at operation 425.

[0082] FIG. 4B illustrates an example method 450 for assigning an air vehicle to a route based on vehicle characteristics. In an example, aspects of method 450 are performed by a transportation system for assigning an air vehicle to a set of routes in a transportation network, such as transportation system 220 of FIG. 2 and multimodal transportation system 100 of FIG. 1. In some examples, aspects of method 450 are performed periodically and / or upon the occurrence of certain events (e.g., in response to a journey request, based on an air vehicle accepting or rejecting a journey, based on a determination that additional air vehicles are needed to service a given route, etc.). As another example, aspects of method 450 may be performed when assigning an air vehicle to a route, as discussed above with respect to operation 315 of method 300 of FIG. 3A.

[0083] Method 450 begins with operation 455, where a generated route is accessed. As explained above, a generated route includes vertiport pairs having a start vertiport and a destination vertiport between which one or more loads may be transported. In some examples, the route may relate to a time determined based on demand information (which may have been generated, for example, according to method 400 of FIG. 4A). The route may further include information regarding historical and / or forecasted demand for one or more expected load categories, among other load characteristics.

[0084] Operation 460 accesses air vehicle information. In an example, the air vehicle information is accessed from a vehicle information data store, such as vehicle information data store 235 of FIG. 2. As discussed above, the vehicle information may be provided by the manufacturer of the air vehicle and / or by the air vehicle itself, among other examples. The vehicle information includes, but is not limited to, general characteristics related to the model of the air vehicle. In another example, vehicle information data store 235 includes vehicle-specific characteristics related to the air vehicle (e.g., air vehicle 225 and / or air vehicle 230 described above with respect to FIG. 2).

[0085] In some examples, aspects of method 450 are performed iteratively, with vehicle information for particular vehicles being selected and evaluated according to aspects described below. Air vehicles may be selected based on the route accessed in operation 455, for example, based on route distance, past and / or projected demand, and / or one or more cargo categories with demand. In other examples, aspects of method 450 are performed for a set of air vehicles, such that the evaluation described below is performed for each air vehicle in the set. The air vehicles may then be ranked accordingly (e.g., based on a combined score of weighted factors, based on a single score, based on one or more logical rules, etc.) so that the highest ranked air vehicles may be selected and assigned to the route. It will be appreciated that various other techniques may be used to select and evaluate air vehicles according to aspects described herein.

[0086] Flow continues to operation 465, where the route is evaluated according to the air vehicle's state of charge. Thus, to determine whether the air vehicle can traverse the route, the energy requirements associated with the generated route are evaluated according to the vehicle information accessed in operation 460 (which may be determined based on, for example, the route's distance, past and / or expected payload weight, current and / or forecasted weather conditions, etc.). In some examples, the air vehicle's power state is estimated according to one or more statistical and / or machine learning models, among other examples. This evaluation may further include evaluating the air vehicle's estimated state of charge after the route traverse compared to a predetermined threshold to ensure the air vehicle maintains a consistent energy budget.

[0087] In operation 470, the route is evaluated according to the power state of the air vehicle. In an example, the vehicle information accessed in operation 460 includes a power state determined at least in part by a vehicle state monitor, such as vehicle state monitor 250 or 265 of FIG. 2. In some examples, the power state of the air vehicle is estimated according to one or more statistical and / or machine learning models, among other examples. Thus, to verify that the air vehicle can traverse the route, the power requirements of the route are evaluated according to the current and / or estimated power state of the air vehicle. This evaluation may further include evaluating the estimated power state of the air vehicle after the route traverse compared to a predetermined threshold to verify that the air vehicle maintains a certain power budget (e.g., a minimum power budget, a budget required to execute the subsequent journey, etc.).

[0088] The process proceeds to operation 475, where the route is evaluated based on the health of the air vehicle. As one example, the health may be part of the vehicle information accessed in operation 460 and may have been determined based at least in part on a vehicle health monitor, such as vehicle health monitor 250 or 265 of FIG. 2. In some examples, the evaluation includes estimating the health of the air vehicle according to one or more statistical and / or machine learning models, among other examples. The health of the air vehicle may be estimated along the route, for example, to estimate the vehicle health during or after the route has been traveled.

[0089] Decision 480 determines whether to assign a further route to the air vehicle. In an example, this determination includes evaluating a predicted state of charge, a predicted power state, and / or a predicted health state associated with the air vehicle compared to one or more predetermined thresholds (e.g., energy budget, power budget, etc.) to determine whether the air vehicle is available to travel a further route after the accessed route. Such techniques can be applied to a set of routes, with each route in the set being evaluated to determine whether any route is a candidate route for the air vehicle. As another example, predicted and / or historical demand information based on other air vehicles in the transportation network can be evaluated to determine whether the air vehicle is underutilized relative to other air vehicles. For example, target or threshold utilization rates (e.g., percentage of time spent in operation versus time spent out of operation, designated cargo weight and / or volume versus available unladen cargo capacity, etc.) can be used to more evenly distribute routes across the air vehicles in the transportation network. In another example, decision 480 includes determining that no other air vehicles are available for subsequent routing.

[0090] If decision 480 determines that an additional route should be assigned to the air vehicle, flow branches "yes" to operations 455-475, where an alternative route is accessed, evaluated, and assigned to the air vehicle as described above. In one example, a route is accessed based on determining that the route's starting vertiport is the destination vertiport of a previously assigned route. In another example, a route is accessed based on determining that the new route's arrival vertiport is the same as the departure vertiport of a previously assigned route. This can reorder the routes, thereby generating a set of routes in which the new route is traveled by the air vehicle before the previously assigned route. In another example, a route can be evaluated that has a starting vertiport that is different from the destination vertiport of a previously assigned route, so that the air vehicle can travel empty to the subsequent starting vertiport.

[0091] However, if it is determined that no further routes are to be assigned, the flow instead branches "NO" to operation 485, where a set of routes is assigned to the air vehicle. In an example, assigning a set of routes includes creating an association between the air vehicle and each route in the set. The association may indicate one or more dates and times at which the air vehicle is assigned the route, or may more broadly associate the air vehicle with the route such that the air vehicle is assigned to all instances of the route regardless of the exact date and time. The flow ends at operation 485.

[0092] Figure 5 illustrates an example of a computing device 500 capable of implementing aspects of the present disclosure. Computing device 500 may be integrated with or associated with an air vehicle, such as air vehicle 150 and / or air vehicles 225 and 230, described above with respect to Figures 1 and 2, respectively. Additionally, computing device 500 may be integrated with or associated with various systems shown and described with respect to Figures 1 and 2. As shown in Figure 5, computing physical components (e.g., hardware) are illustrated that may be used to implement various aspects of the present disclosure.

[0093] The computing device 500 may include at least one processing unit 510 and a system memory 520 or memory resource. The system memory 520 or memory resource may include, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memory. The system memory 520 may also include an operating system 530 and one or more program modules 540 that control the operation of the computing device 500. The program modules 540 may be responsible for collecting, receiving, and / or determining vertiport / vehicle information 550 and / or generating the routes and / or itineraries described above. The system memory 520 may store or provide access to this information. Several different program modules and data files may be stored within the system memory 520. While executing on the processing unit 510, the program modules 540 may perform the various processes described above.

[0094] Computing device 500 may also have additional features or functionality. For example, computing device 500 may include additional data storage devices (e.g., removable and / or non-removable storage) such as, for example, magnetic disks, optical disks, or tape. These additional storage devices are labeled removable storage 560 and non-removable storage 570.

[0095] Furthermore, examples of the present disclosure may be practiced by electrical circuits including discrete electronic elements, packaged or integrated electronic chips including logic gates, circuits utilizing a microprocessor, or on a single chip including electronic elements or a microprocessor. For example, examples of the present disclosure may be practiced by a system-on-chip (SOC) in which each or many of the components shown in Figure 5 may be integrated onto a single integrated circuit. Such an SOC device may include one or more processing units, graphics units, communications units, system virtualization units, and various application functions, all of which are integrated (or "baked") onto the chip substrate as a single integrated circuit.

[0096] When operated by a SOC, the functions described herein may be operated by application specific logic integrated with other components of the computing device 500 on a single integrated circuit (chip). The present disclosure may also be practiced using other technologies capable of performing logical operations such as AND, OR, and NOT, including, for example, but not limited to, mechanical, optical, fluidic, and quantum technologies. Additionally, examples of the present disclosure may be practiced using computing devices associated with or integrated with electric vehicles and / or by any other circuit or system.

[0097] Computing device 500 may include one or more communication systems 580 that enable communication with and / or between client devices, air vehicles, transportation systems, other computing devices 595, network services, etc. Examples of communication systems 580 include, but are not limited to, radio frequency (RF) transmitter, receiver, and / or transceiver circuitry, a controller area network (CAN) bus, a universal serial bus (USB), parallel and / or serial ports.

[0098] Computing device 500 may also have one or more input devices and / or one or more output devices, shown as input / output devices 585. These input / output devices 585 may include a keyboard, sound or voice input devices, haptic devices, touch, force, and / or swipe input devices, displays, speakers, etc. The above-mentioned devices are examples and others may be used.

[0099] Computing device 500 may also include one or more sensors 590. The sensors may be used to detect or provide information regarding the operating status of the light electric vehicle, the rechargeable battery, and / or the rechargeable battery kiosk. In other examples, sensors 590 may provide information regarding the light electric vehicle with which computing device 500 is associated. For example, sensors 590 may include a heat sensor, a charge sensor, or other such rechargeable battery sensor.

[0100] As used herein, the term computer-readable media may include computer storage media, which may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, or program modules.

[0101] System memory 520, removable storage 560, and non-removable storage 570 are all examples of computer storage media (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article that can be used to store information and that can be accessed by computing device 500. Any such computer storage media may be part of computing device 500. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0102] Communication media such as a carrier wave or other transport mechanism may be embodied by computer-readable instructions, data structures, program modules, or other data in a modulated data signal and includes any information delivery media. The term "modulated data signal" may refer to a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0103] As can be appreciated from the above disclosure, one aspect of the present technology relates to a method for determining air vehicles and routes for transporting cargo within a transportation network, the method including: generating a set of available routes within the transportation network based on historical demand information, each route including a departure vertiport and an arrival vertiport; accessing, for a set of air vehicles in the transportation network, a set of vehicle characteristics for each air vehicle of the set of air vehicles, the set of vehicle characteristics including at least one of an energy type of the air vehicle, a state of charge of the air vehicle, a power state of the air vehicle, or a health state of the air vehicle; accessing capability information for each vertiport of a route within the set of available routes; and assigning an air vehicle from the set of air vehicles to the route based on the set of vehicle characteristics and the capability information. In an example, the method further includes using a model for the type of the assigned air vehicle to generate a predicted vehicle characteristic for at least one of the set of vehicle characteristics for the assigned air vehicle. In a further example, the at least one predicted vehicle characteristic is one of a predicted state of charge, a predicted power state, or a predicted state of health at the arrival vertiport. In yet another example, the predicted vehicle characteristic is a predicted state of charge, and the method further includes receiving from the designated air vehicle an indication of a state of charge that differs from the predicted state of charge, identifying a subsequent route designated for the designated air vehicle, and designating a new air vehicle in place of the designated air vehicle for the subsequent route based on the received indication of state of charge. In yet another example, the route is a first route of a set of routes for the designated air vehicle, and the method further includes determining a second route for the air vehicle that includes an arrival vertiport that is the same as a departure vertiport of the first route, designating the second route for the air vehicle, and reordering the set of routes for the designated air vehicle so that the air vehicle traverses the second route before traversing the first route.In an example, the route is a first route, and the method further includes receiving a journey request related to cargo including cargo characteristics, determining based on the cargo characteristics that a new route should be generated instead of transporting the cargo using the first route, generating the new route including a new departure vertiport and a new arrival vertiport based on the cargo characteristics, determining a new air vehicle for the new route based on the cargo characteristics, vehicle characteristics of the new air vehicle, and capability information related to the new arrival vertiport, and generating an itinerary including information related to the new route and the new air vehicle in response to the itinerary request. In another example, the method further includes receiving a journey request related to cargo including cargo characteristics, evaluating the cargo characteristics, the route, and the specified air vehicle to determine that the route should be used to transport the cargo, and generating an itinerary including information related to the route and the specified air vehicle. In a further example, assigning the air vehicle to the route further includes evaluating a predicted time for the assigned air vehicle to reach a predetermined state of charge at the arrival vertiport.

[0104] In another aspect, a technique relates to a method for validating an itinerary for transporting cargo using an air vehicle within a transportation network, the method including the steps of receiving an itinerary from a transportation system including instructions for a start vertiport, a destination vertiport, and a load, accessing a set of vehicle characteristics of the air vehicle including at least one of an energy type of the air vehicle, a state of charge of the air vehicle, a power state of the air vehicle, or a health state of the air vehicle, evaluating the set of vehicle characteristics based at least in part on the start vertiport, the destination vertiport, and the load to verify whether the air vehicle is capable of performing the itinerary, and providing an instruction to the transportation system to accept the itinerary or to reject the itinerary based on verifying whether the air vehicle is capable of performing the itinerary. In an example, an instruction to reject the itinerary is provided to the transportation system, and the method further includes the steps of receiving a second itinerary from the transportation system and evaluating the set of vehicle characteristics to verify the second itinerary. In another example, evaluating the set of vehicle characteristics to verify whether the air vehicle is capable of completing the journey further includes generating a display including a vehicle health indicator based on evaluating the set of vehicle characteristics and receiving input by the display to accept or reject the journey. In a further example, the set of vehicle characteristics is accessed at least in part from a vehicle health monitor of the air vehicle.

[0105] In a further aspect, a technique relates to a system including at least one processor and a memory operatively connected to the at least one processor that stores instructions that, when executed by the at least one processor, cause the system to perform a set of operations, the set of operations including: generating a set of available routes through a transportation network based on historical demand information, each route including a departure vertiport and an arrival vertiport; for a set of air vehicles in the transportation network, accessing a set of vehicle characteristics for each air vehicle of the set of air vehicles, the set of vehicle characteristics including at least one of an energy type of the air vehicle, a state of charge of the air vehicle, a power state of the air vehicle, or a health state of the air vehicle; accessing capability information for each vertiport of routes within the set of available routes; and assigning an air vehicle from the set of air vehicles to the route based on the set of vehicle characteristics and the capability information. In an example, the set of processes further includes generating at least one predicted vehicle characteristic of the set of vehicle characteristics using a model for the type of the designated air vehicle. In another example, the at least one predicted vehicle characteristic is one of a predicted state of charge, a predicted power state, or a predicted state of health at the arrival vertiport. In a further example, the predicted vehicle characteristic is a predicted state of charge, and the set of processes further includes receiving an indication of a state of charge from the designated air vehicle that differs from the predicted state of charge, identifying a subsequent route assigned to the air vehicle, and assigning a new air vehicle in place of the designated air vehicle for the subsequent route based on the received indication of state of charge.In yet another example, the route is a first route of a set of routes for the designated air vehicle, the set of processes further including determining a second route for the air vehicle that includes an arrival vertiport that is the same as a departure vertiport of the first route, assigning the second route to the air vehicle, and reordering the set of routes for the designated air vehicle to travel the second route before traveling the first route. In yet another example, the set of processes further includes receiving a journey request related to cargo including cargo characteristics, determining based on the cargo characteristics that a new route should be generated instead of transporting the cargo using the first route, generating the new route including a new departure vertiport and a new arrival vertiport based on the cargo characteristics, determining a new air vehicle for the new route based on the cargo characteristics, vehicle characteristics of the new air vehicle, and capability information related to the new arrival vertiport, and generating a journey including information related to the new route and the new air vehicle in response to the journey request. In an example, the set of processes further includes receiving a journey request associated with a load including load characteristics, evaluating the load characteristics, the route, and the designated air vehicle to determine that the route should be used to transport the load, and generating an itinerary including information related to the route and the designated air vehicle. In another example, assigning the air vehicle to the route further includes evaluating a predicted time for the designated air vehicle to reach a predetermined state of charge at the arrival vertiport.

[0106] The description and illustrations of one or more aspects set forth herein are not intended to in any way limit or restrict the scope of the present disclosure, as set forth in the claims. The aspects, examples, and details provided herein are believed to be sufficient to enable others to make and use the best mode of the present disclosure, as set forth in the claims. The present disclosure, as set forth in the claims, should not be construed as limited to any aspect, example, or detail provided herein. It is intended that various features (both structural and methodological) may be selectively rearranged, included, or omitted to create embodiments having a particular set of characteristics, whether shown and described in combination or separately. Having provided the description and illustrations herein, those skilled in the art will be able to devise variations, modifications, and alternatives within the spirit of the broader aspects of the general inventive concepts embodied herein, without departing from the broader scope of the present disclosure, as set forth in the claims.

Claims

1. 1. A method for determining an aircraft and route for transporting a number of passengers within a transportation network, the method comprising: at least one processor accessing a set of available routes in the transportation network based on historical vertiport demand information and vertiport capability information, each available route in the set of available routes including a departure vertiport and an arrival vertiport; the at least one processor accessing vehicle characteristics for a plurality of aircraft, the vehicle characteristics including a predicted state of charge for the aircraft calculated using a model for the aircraft type; the at least one processor accessing an itinerary request associated with air transportation of cargo including the number of passengers, the itinerary request including cargo characteristics, the cargo characteristics including the number of passengers in the cargo; and determining, by the at least one processor, a designated route from the set of available routes and a designated aircraft from the plurality of aircraft to provide the air transportation of the number of passengers based on an evaluation of the vehicle characteristics, including a predicted state of charge of the aircraft, and the cargo characteristics, wherein the designated aircraft maintains an energy budget above a threshold upon arrival at the arrival vertiport associated with the designated route; accessing, by the at least one processor, an actual state of charge for the designated aircraft; accessing, by the at least one processor, a subsequent route for the designated aircraft; and determining, by the at least one processor, a new aircraft to designate for the subsequent route in place of the designated aircraft based on the actual state of charge of the designated aircraft differing from the predicted state of charge; A method comprising:

2. the designated route is a first route of a set of routes for the designated aircraft; The method comprises: determining, by the at least one processor, a second route for the designated aircraft that includes an arrival vertiport that is the same as a departure vertiport of the first route; the at least one processor assigning the second route to the designated aircraft; the at least one processor reordering the set of routes for the designated aircraft so that the second route is traversed before the first route; The method of claim 1 further comprising:

3. The method of claim 1 , further comprising generating an itinerary that includes information associated with the specified route and the specified aircraft.

4. The method of claim 3 , further comprising a display providing the itinerary to a user.

5. 2. The method of claim 1, wherein the designated aircraft is further determined by the at least one processor based on a predicted time for the designated aircraft to reach a predetermined state of charge at the arrival vertiport.

6. 1. A method for validating an itinerary for transporting a load using an aircraft within a transportation network, the method comprising: determining, by at least one processor, a route based on the route request, the route including information indicating a starting vertiport, a destination vertiport, and a cargo including a number of passengers; the at least one processor accessing a set of vehicle characteristics for the aircraft, the set of vehicle characteristics for the aircraft including at least one of a state of charge of the aircraft or a power state of the aircraft; the at least one processor performing a verification using a model for the aircraft type indicating whether the aircraft is capable of performing the journey, the aircraft maintaining an energy budget above a threshold upon arrival at the destination vertiport, the energy budget based on at least one of the aircraft's state of charge or the aircraft's power state; the at least one processor providing information indicating whether to accept the journey or reject the journey based on the verification; A method comprising:

7. The method comprises: receiving, by the at least one processor, a second journey; and performing validation of the second journey based on evaluating the set of vehicle characteristics by the at least one processor; The method of claim 6 further comprising:

8. performing the verification indicating whether the aircraft is capable of performing the journey, a display providing a vehicle condition indicator based on evaluating the set of vehicle characteristics; said display receiving an input to accept or reject said journey; The method of claim 6 further comprising:

9. The method of claim 6 , wherein the set of vehicle characteristics is accessed at least in part from a vehicle state monitor of the aircraft.

10. 1. A system comprising: at least one processor; a memory operatively connected to the at least one processor, the memory storing instructions; Equipped with The instructions, when executed by the at least one processor, cause the system to perform a set of operations; The set of processes comprises: accessing a set of available routes in the transportation network based on historical vertiport demand information and vertiport capability information, each available route in the set of available routes including a departure vertiport and an arrival vertiport; accessing vehicle characteristics for a plurality of aircraft, the vehicle characteristics including a predicted state of charge for the aircraft calculated using a model for the aircraft type; accessing an itinerary request associated with air transportation of cargo including a number of passengers, the itinerary request including cargo characteristics, the cargo characteristics including the number of passengers in the cargo; determining a designated route from the set of available routes and a designated aircraft from the plurality of aircraft for providing the air transportation of the number of passengers based on an evaluation of the vehicle characteristics, including a predicted state of charge of the aircraft, and the cargo characteristics, wherein the designated aircraft maintains an energy budget above a threshold upon arrival at the arrival vertiport associated with the designated route; accessing the actual state of charge of the designated aircraft; and accessing a subsequent route for the designated aircraft; determining a new aircraft to designate for the subsequent route in place of the designated aircraft based on the actual state of charge of the designated aircraft differing from the predicted state of charge; Including, the system.

11. the designated route is a first route of a set of routes for the designated aircraft; The set of processes comprises: determining a second route for the designated aircraft that includes an arrival vertiport that is the same as a departure vertiport of the first route; assigning the second route to the designated aircraft; reordering the set of routes for the designated aircraft so that the second route is traversed before the first route; and The system of claim 10 further comprising:

12. The system of claim 10 , wherein the set of processes further comprises generating an itinerary that includes information associated with the specified route and the specified aircraft.

13. The system of claim 12 , wherein the set of processes further comprises generating a display including the itinerary for presentation to a user.

14. 11. The system of claim 10, wherein the designated aircraft is further determined based on a predicted time for the designated aircraft to reach a predetermined state of charge at the arrival vertiport.

Images