Patent Description:
The increasing availability of electric-powered vehicles and improved remote vehicle control capabilities has recently led to increasing use of autonomous vehicles and development of autonomous vehicle fleets. The cost and complexity of autonomous vehicles, coupled with the increasing size of vehicle fleets calls for centralized fleet management systems.

<CIT> discloses a device for fleet control. The device receives a request for a mission that includes traversal of a flight path from a first location to a second location and performance of mission operations, and calculates the flight path from the first location to the second location based on the request. The device determines required capabilities for the mission based on the request, and identifies UAVs based on the required capabilities for the mission. The device generates flight path instructions for the flight path and mission instructions for the mission operations, and provides the flight path/mission instructions to the identified UAVs to permit the identified UAVs to travel from the first location to the second location, via the flight path, and to perform the mission operations at the second location.

According to a first aspect of the present invention, there is provided a computer implemented autonomous vehicle fleet control method as defined in claim <NUM>. According to a second aspect of the present invention, there is provided a fleet controller for controlling an autonomous vehicle fleet as defined in claim <NUM>. Some optional or preferred features are defined in the dependent claims.

In an aspect a method includes obtaining, by a fleet controller, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generating vehicle commands according to mission parameters associated with the mission, maintaining a persistent connection with the vehicle, sending the vehicle commands to the vehicle using the connection, the vehicle commands causing the vehicle to execute the mission under control of the fleet controller, and monitoring operation of the vehicle during performance of the mission.

In an embodiment, generating the vehicle commands may comprise identifying a flight path associated with the mission; verifying a usability of the flight path with a traffic management system; and generating the vehicle commands according to the flight path in response to verifying the usability of the flight path. Generating the vehicle commands may include assigning one or more of a flight or travel path, speed, altitude, arrival or departure time, target origin or target destination, mission type, setting a flight path according to geofencing restrictions, or the like.

In some embodiments the fleet controller may control said vehicles from said fleet of autonomous vehicles through a communications system. Said system may comprise an internet of things (IoT) backbone.

In an embodiment the step of obtaining the mission may comprise obtaining the mission from the master schedule according to a priority of mission entries in the master schedule.

In another embodiment the monitoring operation of the vehicle may comprise monitoring a connection of the vehicle to a communications network associated with the fleet controller. The connection may comprise monitoring, by an access point of the communications network, a connection between the vehicle and the access point; and reporting, by the access point, a last vehicle status to the fleet controller. In some examples A last vehicle status may be provided in response to a loss of connection between the vehicle and the access point.

In an embodiment the monitoring operation of the vehicle may comprise determining, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller. Additionally or alternatively the method may further comprise generating, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters. Further additionally or alternatively, the method may comprise sending the adjusted vehicle commands to the vehicle using the connection, the adjusted vehicle commands causing the vehicle to execute the mission under control of the fleet controller according to the adjusted vehicle command.

In an embodiment the sending the vehicle commands to the vehicle may comprise determining whether the vehicle is subject to single source control. The vehicle commands may be forwarded to the vehicle in response to the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle. A control arbitrator may verify that the vehicle is subject to single source control.

In an aspect, there is provided a device that may be a fleet controller, including a processor and a non-transitory computer-readable storage medium storing a program to be executed by the processor. The program may include instructions for obtaining, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generating vehicle commands according to mission parameters associated with the mission, maintaining a persistent connection with the vehicle through a communications network, sending the vehicle commands to the vehicle using the connection, the vehicle commands causing the vehicle to execute the mission under control of the fleet controller, and monitoring operation of the vehicle during performance of the mission.

The instructions for the generating the vehicle commands may comprise: identifying a flight path associated with the mission. The usability of the flight path may then be verified with a traffic management system; and vehicle commands may be generated according to the flight path in response to verifying the usability of the flight path.

In some examples the instructions for the obtaining the mission may include instructions for obtaining the mission from the master schedule according to a priority of mission entries in the master schedule.

In embodiments a predetermined rule may give vehicle commands with an emergency priority the highest priority, any non-emergency manual command the next highest priority, and any scheduled control instruction the lowest priority.

In embodiments the instructions for the monitoring operation of the vehicle may include instructions for receiving, from an access point of the communications network, a last vehicle status in response to loss of a connection between the vehicle and the access point hosting the persistent connection.

In embodiments the instructions for the monitoring operation of the vehicle include instructions for determining, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller. The program may also further include instructions for: generating, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters; and sending the adjusted vehicle commands to the vehicle using the connection, the adjusted vehicle commands causing the vehicle to execute the mission under control of the fleet controller according to the adjusted vehicle command. The mission impact data may comprise at least one of received event messages, traffic management system data, or exterior condition data.

In an embodiment the instructions for the sending the vehicle commands to the vehicle comprises determining whether the vehicle is subject to single source control; and forwarding the vehicle commands to the vehicle in response the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle.

In another aspect there is provided a system includes a vehicle, a communications network, and a fleet controller in communication with the vehicle by way of the communications network. The fleet controller may be configured to obtain, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generate vehicle commands according to mission parameters associated with the mission, maintain a persistent connection with the vehicle through the communications network, send the vehicle commands to the vehicle using the connection, with the vehicle being configured to receive the vehicle command and execute the mission according to the vehicle commands, and monitor operation of the vehicle during performance of the mission.

The fleet controller may be configured to: identify a flight path associated with the mission; verify a usability of the flight path with a traffic management system; and generate the vehicle commands according to the flight path in response to verifying the usability of the flight path.

In an embodiment the fleet controller may be configured to obtain the mission from the master schedule according to a priority of mission entries in the master schedule.

In another embodiment the fleet controller may be configured to receive, from an access point of the communications network, a last vehicle status in response to loss of a connection between the vehicle and the access point hosting the persistent connection.

In an embodiment the fleet controller may be configured to: determine, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller; generate, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters; and send the adjusted vehicle commands to the vehicle using the connection, and wherein the vehicle is configured to execute the mission according to the adjusted vehicle command.

In an embodiment the system may further comprise a control arbitrator configured to: determine whether the vehicle is subject to single source control; and forward the vehicle commands to the vehicle in response the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle.

It can be appreciated that although described in relation to specific aspects, the embodiments described above may be applicable to any relevant aspect.

Embodiments of a fleet management system are described herein, with the fleet management system providing control and monitoring of autonomous vehicles to optimize the effective use of the vehicles, while maintaining safety and maintenance standards. While some embodiments of the fleet management system are described as being directed to control and monitoring of flying vehicles, such as drones, aircraft, rotorcraft, or the like, it should be understood that the principles described herein are equally applicable to watercraft, ground vehicles, or mixed fleets including any number or combination of flying vehicles, ground vehicles, and watercraft.

In some embodiments, the fleet management system provides a persistent connection with each vehicle, which may include real-time, near real-time, monitoring, or tracking last known statuses of vehicles for use in the case of a connection failure by the vehicle. The fleet management system may permit a user to control vehicles from various interaction mediums such as tablets, augmented reality (AR) headsets, laptops, desktops, control centers, or the like.

Some embodiments of the fleet management system permits assignment of role-based access for command and control of vehicles to segregate users into various roles and allow management of user access to vehicles controlled by the fleet management system. The fleet management system may also use a control arbitrator to ensure a single point of control of a vehicle at any one time to prevent contradictory command or control from different users or sources. Additionally, the fleet management system may permit role based access to command or control of vehicles, with different roles being permitted different levels of control or authority over the vehicles.

In some embodiments, the fleet management system provides for tracking, monitoring and management at the device level, with individual connected components on each vehicle being tracked and monitored to provide for part localization, tracking of component location (such as in vehicle, in repair, or the like), protection against fraudulent or counterfeit parts, lifecycle management of individual parts, or the like. These individual components may be connected components that self-identify on the vehicle and use the vehicle datalink to send component telemetry. In some embodiments, each of the connected components may include a unique device identity, which may be represented by an on-device certificate, such as an X. <NUM> public key certificate or the like. The tracking of individual connected components and the reporting of connected component telemetry to the fleet management system permits the tracking of complete component histories for the lifetimes of each of the connected components, which may be made available via a cloud data storage system as a cloud-based component logbook.

Additionally, the tracking of individual connected components may include storing device performance, use or maintenance history, and the like, for use by prediction services such as a fleet scheduler, active connected component health monitoring, predictive maintenance, and the like. Tracking the histories of the connected components and having access to the connected component histories further permits software/firmware updates and the deployment and management of component-level systems.

<FIG> illustrates an arrangement <NUM> of a fleet management system <NUM> for command and monitoring of one or more vehicles <NUM> according to some embodiments. The fleet management system <NUM> is a system for launching and sustaining continuous operations for fleets of autonomous vehicles. The fleet management system <NUM> may include a fleet scheduler <NUM> that generates, or submits entries to, a master schedule <NUM>. The master schedule <NUM> is used by a fleet controller <NUM> to control one or more vehicles through a communications system such as an internet-of-things (IoT) backbone <NUM>. The vehicles <NUM> may feed operational data back through the IoT backbone <NUM>, which then delivers the operational data back to the fleet scheduler <NUM>, or otherwise makes the operational data available to the fleet scheduler <NUM>.

The fleet scheduler <NUM> monitors real-world data or mission impact data, including the operational data, and generates future-state predictions based on that data. The fleet scheduler <NUM> may then produce the optimized master schedule <NUM>, which may include vehicle positions, mission timing, flight plans, maintenance and service (such as vehicle recharge/refuel) schedules, and the like, for fleet operations.

Additionally, the fleet scheduler <NUM> may include an API or other system for permitting third parties to submit third parties entries or requests to the master schedule, or requests for scheduling by the fleet scheduler <NUM>. In some embodiments, third party requests <NUM> may be submitted directly to the master schedule <NUM>, or may be submitted to the fleet scheduler <NUM> for verification or scheduling. For example, a third party cargo carrier may submit a request to the fleet scheduler <NUM> for carrying a particular class of cargo at a particular time and location, and the fleet scheduler <NUM> may determine a vehicle <NUM> suitable for the requested mission, assign the mission to the vehicle, and submit the scheduled mission to the master schedule <NUM>. In other embodiments, a third party may perform the mission generation and scheduling, and submit a mission entry to the master schedule <NUM> for execution by the fleet controller <NUM>.

In some embodiments, the fleet scheduler <NUM> analyzes historical demand, such as payload or passenger movement between identified points, demand input such as manual user entry or integration with planning systems, and environmental data such as weather, public transit, or ground traffic, air traffic, and then outputs recommendations for vehicle placement across a region's nodes in anticipation of upcoming demand. This predictive modeling allows for anticipatory vehicle placement to handle future demand, avoiding the need to assign vehicles fixed, regular routes, which require a fixed schedule with a fixed number of vehicles. Such anticipatory positioning may also permit vehicles to be automatically prepositioned before an actual demand exists, rather than tasking vehicles to a particular site or assignment after demand occurs.

In some embodiments, the fleet scheduler <NUM> also monitors health characteristics of vehicle systems that are known to be associated with component degradation by analyzing real-time on-board sensor data in the operational data sent from the individual vehicles. The fleet scheduler <NUM> may apply machine learning to predict when the system or component is likely to fail or need maintenance, inspection or servicing. In such an embodiment, the fleet scheduler <NUM> uses predicted failure insights to determine when the vehicle <NUM> should be scheduled for maintenance or inspection in coordination with regular mission operations. Using data from operational vehicles permits the fleet scheduler <NUM> to correlate maintenance requirements for components/systems that follow similar maintenance cycles. This permits sequencing of vehicle maintenance downtime according to a predicted maintenance or servicing need at the fleet level, and the staggering or sequencing of scheduled maintenance activities ensures the fleet remains available to carry out daily mission operations.

The fleet controller <NUM> executes the master schedule <NUM>, while also monitoring real-time air and ground conditions. The fleet controller <NUM> observes vehicles <NUM> of the fleet, weather conditions, and other operating factors or mission impact data, and will delay, redirect, or otherwise modify commands to the vehicles <NUM> if executing the master schedule <NUM> would result in unsafe or undesirable conditions. The fleet controller <NUM> executes the master schedule <NUM> by maintaining communication with the vehicles <NUM>, monitoring the vehicles <NUM> in real-time or near real-time, and sending command instructions to the vehicles <NUM>. The fleet controller <NUM> monitors real-time or near real-time fleet information regarding vehicle state, performance and health, progress of each flight, and the state of each vertiport or ground location. The fleet controller <NUM> looks for conflicts during vehicle operations that result in unsafe or undesirable conditions and deviates from the master schedule <NUM> as necessary to enact contingencies that ensure safe and desirable fleet operations. In this way, the fleet controller <NUM> works independently from the fleet scheduler <NUM> to ensure a second layer of safe operation.

<FIG> illustrates operation of a fleet management system <NUM> for control and monitoring of one or more vehicles <NUM> according to some embodiments. The fleet management system <NUM> is in communication with one or more vehicles <NUM> via the IoT backbone <NUM>. In some embodiments, the fleet scheduler <NUM> generates the master schedule <NUM> and the fleet controller <NUM> uses entries in the master schedule <NUM> to generate command instructions <NUM> which are sent to the vehicles <NUM>. In some embodiments, the command instructions <NUM> are instructions to follow a particular flight path <NUM> to a destination, such as a maintenance facility <NUM>, a service facility <NUM>, a staging location <NUM> or a target origin <NUM>, or for a mission between a target origin <NUM> and a target destination <NUM>. For example, the fleet scheduler <NUM> may determine that a particular vehicle <NUM> has components in need of inspection or replacement, and may route the respective vehicle <NUM> to a maintenance facility <NUM>. Similarly, the fleet scheduler <NUM> may determine from vehicle telemetry <NUM>, or other data, that a battery of a vehicle <NUM> needs to be charged, that the vehicle <NUM> needs fuel, or the like, and may route the respective vehicle <NUM> to a service facility <NUM> or the like.

The fleet scheduler <NUM> may also provide entries in the master schedule <NUM> for missions such as passenger carriage, package or cargo pickup and delivery, and the like. In some embodiments, the fleet scheduler <NUM> may use predictive analytics to determine where potential demand exists. The fleet scheduler <NUM> may stage vehicles <NUM> at a staging location <NUM> associated with target origins <NUM> for missions between the target origins <NUM> and target destinations <NUM>, or between the target origins <NUM> and target destinations <NUM> which are not determined at the time of predicted demand. For example, the fleet scheduler <NUM> may use a transit schedule, such as a train schedule, to predict that demand for passenger carriage or taxi service will peak shortly after a train arrives at a train station, and may send vehicles <NUM> to a staging location <NUM> near the train station, with the train station being a target origin <NUM> for a potential passenger carriage mission. Thus, the fleet scheduler <NUM> may be able to have vehicles <NUM> ready to accept passengers at the anticipate demand time, reducing passenger wait times. The fleet scheduler <NUM> may also use a weather service or weather forecast to predict that adverse weather conditions will increase demand for passenger carriage service at the train station, and may task additional vehicles <NUM> to the staging location <NUM> prior to a train's arrival to handle the anticipated increase in passenger carriage mission demand. In such situations, the target destination <NUM> may be input by a passenger after the passenger requests carriage, or after the passenger enters the vehicle <NUM>. The fleet scheduler <NUM> may receive a request for a passenger carriage mission, may determine one or more vehicles <NUM> closest to the passenger's target origin <NUM>, and may provide an entry in the master schedule <NUM> assigning the vehicle <NUM> to the passenger carriage mission at the target origin <NUM>.

Similarly, cargo handling may be scheduled by the fleet scheduler <NUM>, with cargo vehicles <NUM> being sent to staging locations <NUM> near post offices, warehouses, distribution points, or the like according to predicted demand. The fleet scheduler <NUM> may be tied into data inputs such as retailers, distributors, package delivery logistic systems, third party request or scheduling systems, cargo terminal systems, or the like, and may use the data inputs, solely or in combination with, environmental monitoring, historical data, and the like to determine predicted and or actual package delivery demand. For example, cargo vehicles <NUM> may be staged near restaurants near meal times to handle food deliveries without requiring that the vehicles <NUM> be routed to the pickup point after the cargo mission is requested. In another example, cargo vehicles <NUM> may be sent to staging locations <NUM> near retail warehouses, package delivery hubs, or the like, to handle delivery of cargo or packages, with the number of vehicles <NUM>, staging locations <NUM> and arrival times determined by the fleet scheduler <NUM> according to anticipated and/or actual demand.

<FIG> illustrates an embodiment of a master schedule <NUM>. <FIG> illustrates an embodiment of a mission entry <NUM> in the master schedule <NUM>. The master schedule <NUM> may have one or more mission entries 302A. 302N set by the fleet scheduler <NUM>. Each mission entry <NUM> may include data fields such as a mission identifier (ID) field <NUM>, a vehicle ID field <NUM>, a priority field <NUM>, a flight origin field <NUM>, a flight destination field <NUM>, and one or more other data fields <NUM>. The mission ID field <NUM> may uniquely identify a specific mission which is stored in the master schedule <NUM>. The vehicle ID field <NUM> identifies a specific vehicle which will perform the specific mission. The vehicle ID field <NUM> may uniquely identify the specific vehicle <NUM> to allow the fleet controller <NUM> to control the specific vehicle <NUM> and permit the fleet scheduler <NUM> to track usage and anticipated location of the specific vehicle <NUM>.

The priority field <NUM> may include data identifying a priority of the mission so that the fleet controller <NUM> handles mission entries <NUM> in the priority order. In some embodiments, the priority field <NUM> may indicate that the mission is an immediate mission instructing the fleet controller <NUM> to handle the mission entry <NUM> with the highest priority or immediately.

The mission entry <NUM> may also have locations in the flight origin field <NUM> identifying where the vehicle <NUM> should be sent for the mission. In some embodiments, the flight destination field <NUM> may also have a location for the end location of the mission. However, in further embodiments, the flight destination field <NUM> may be left blank at the beginning of the mission. Leaving the flight destination field <NUM> blank may indicate that the mission route or destination is to be determined on-the-fly. For example, in a passenger carriage mission, a passenger may identify a destination after the mission is scheduled, or after the mission begins. The mission entry <NUM> may also include other data fields <NUM> with maybe used for supplemental data, or additional mission data such as data identifying mission start or end time, a particular flight route, account number for a particular mission, a mission identifier, requirements for the mission, or the like.

<FIG> illustrates operation of a system <NUM> using the fleet controller <NUM> according to some embodiments. The system <NUM> includes an IoT backbone <NUM> connecting one or more vehicles <NUM> to a control side subsystem that includes the fleet controller <NUM>. In some embodiments, the vehicles <NUM> may be in communication with the IoT backbone <NUM> by way of a wireless connection to an access point <NUM> of the IoT backbone <NUM>. The access point <NUM> may be a cellular system provided by a third party, may be a dedicated system for control of the vehicles <NUM>, or may be a hybrid system, or another communications system. The access point <NUM> communicates with an IoT gateway <NUM> of the IoT backbone <NUM>, which provides communication with the control side subsystem and routing of messages and commands to the appropriate destinations.

The vehicles <NUM> may include one or more connected components such as a motor <NUM> or a battery <NUM>. In some embodiments, the connected components may have one or more sensors that measure operational parameters of the connected components. In other embodiments, a separate device, such as a monitoring circuit, may monitor the operational parameters of the connected components. For example, a vehicle may have an electric motor <NUM> and may also have current and revolutions per minute (RPM) monitoring circuits that are either disposed on the motor <NUM> or as part of one or more monitoring circuits separate from the motor <NUM>. The current and RPM monitoring circuits may monitor the current and RPM operational parameters of the motor <NUM>, and the vehicle <NUM> may report the operational parameter data as telemetry through the IoT gateway <NUM> back to the control side subsystem for storage and analysis. In other embodiments, the vehicles <NUM> may report operational parameters such as location, altitude, airspeed, and the like, for use by the control side subsystem in tracking and verifying the location and control of the vehicles <NUM>.

The vehicles <NUM> may generate event messages or request information from the control side subsystem. The vehicles <NUM> transmit reporting data such as the telemetry, events, and requests to the access point <NUM>, which communicates the reporting data to the IoT gateway <NUM> for routing to the appropriate control side element. Events may include, for example, emergency events such as an unexpected lack of battery charge or component failure, an accident, an unexpected or uncontrollable deviation from the assigned flight path or mission, or the like. An event many also include mission related events such as reaching a designated start point, end point, or transit point in a mission, completion of a mission, acceptance of, or delivery of, a cargo package, loading or unloading of a passenger, a change to an anticipated or current mission such as a passenger changing a passenger carriage destination, or the like.

One or more vertiport sensors <NUM> may also be connected to the access point <NUM>, and may report telemetry <NUM> and event data <NUM> through the IoT backbone <NUM> to the control side subsystem. For example, a vertiport, such as a storage facility, maintenance facility, service facility, regular staging location, or the like, may have sensors that detect and report the arrival of a vehicle <NUM> so that the control side subsystem may verify the arrival of a vehicle <NUM>. In other embodiments, the vertiport may have weather monitoring equipment, and may report environmental conditions at the vertiport to provide finer grained weather reporting than may be available from third party services. In yet another embodiment, the vertiport may report on the conditions of vehicles <NUM> at the vertiport, demand for cargo or passenger missions at the vertiport, or the like. The IoT backbone <NUM> communicates telemetry, events and requests from the vertiport sensors <NUM> and the vehicles to the IoT gateway <NUM> for distribution to the relevant elements of the control side subsystem. The IoT backbone <NUM> also communicates command and control instructions <NUM> received at the IoT gateway <NUM> to the relevant access point <NUM> for delivery to the appropriate vehicle <NUM>.

In some embodiments, the IoT backbone <NUM> includes one or more access points <NUM> and one or more IoT gateways <NUM>. The access points <NUM> may be, for example, cellular access points, micro, macro, or femto cell base stations, WiFi base stations, Bluetooth stations, or any other communications transmission system. Thus, an IoT gateway <NUM> may connect to one or more existing wireless communications networks, or may connect to a dedicated wireless network, or a combination of a dedicated wireless network and an existing wireless network to provide broad coverage and bandwidth capabilities for the system <NUM>.

The access point <NUM> may, in some embodiments, provide edge decision making and edge services <NUM> such as offline services <NUM> for maintaining the vehicles in a safe state if the control side subsystem disconnects from the IoT backbone <NUM>, telemetry analysis <NUM> to rapidly determine and address of emergencies with the vehicles <NUM>, message routing <NUM> for directing messages to an appropriate IoT gateway <NUM> or vehicle <NUM>, and connection management <NUM> for handling connections to the vehicles <NUM> or monitoring for loss of a connection to the vehicles <NUM>. The access point <NUM> may analyze the classification of events and requests <NUM> to determine whether a priority of the event or request <NUM> is of a predetermined level, or whether the severity or type of event or request <NUM> falls into a category handled by the access point <NUM>. For events handled by the access point <NUM>, the access point <NUM> may apply a predetermined rule or procedure. Additionally, the access point <NUM> may hold or forward a message according to the classification of the event or request <NUM>. For example, a vehicle <NUM> may detect that an assigned landing space at a target location is occupied or obscured, and may request permission to land at a different location. The access point <NUM> may determine that it has an assigned rule for handling such a request and may grant that request if the access point 420determines that the different location is available. The access point <NUM> may check with another element such as a traffic management system, unmanned aircraft system (UAS) traffic management (UTM), or the like, and the permission or denial of the request to change the landing locations may be based on the access point check.

The IoT gateway <NUM> may, in some embodiments, provide gateway services <NUM> such as digital twin services <NUM> for recording the last state of a vehicle <NUM> and reporting the last state or status of the vehicle <NUM> back to the control side subsystem in the case of loss of a connection with the vehicle <NUM>. In some embodiments, the last vehicle status is a most recent status of the vehicle, and may include one or more of a location, a speed, an altitude, a heading, or vehicle telemetry. The IoT gateway <NUM> may also provide other gateway services <NUM> such as access management services <NUM> for handling security and controlling access to the vehicles or control side subsystem.

The IoT gateway <NUM> routes messages sent by the vehicles <NUM> through the access point <NUM> to the relevant elements in the control side subsystem. In some embodiments, events and requests <NUM> may be routed to an event manager <NUM>, and telemetry <NUM> data may be routed to a telemetry manager <NUM>. The IoT gateway <NUM> may also route control message or command instructions <NUM> from a control arbitrator <NUM> through the IoT backbone <NUM> to the relevant vehicle <NUM>.

The telemetry manager <NUM> and event manager <NUM> may each provide data to a dashboard <NUM> for presentation to a user monitoring the status of the system <NUM>, including missions and vehicles <NUM>. Thus, relevant events and requests <NUM> and telemetry <NUM> may be presented to a user at the dashboard <NUM> as a data visualization.

The telemetry manager <NUM> may also provide the telemetry <NUM> data to storage <NUM>, where current telemetry <NUM> is stored with past telemetry to permit the fleet scheduler <NUM> to access historical data or operational history data in generating the master schedule <NUM>. The operational history data may include flight duration, payload loading time, a history of on-time or delayed flights, and the like. Additionally, the telemetry manager <NUM> may provide live, current telemetry <NUM> directly to the fleet scheduler <NUM> for generation of mission entries for the master schedule <NUM>. In some embodiments, the event manager <NUM> provides event and request <NUM> data to the fleet controller <NUM>.

The fleet controller <NUM> obtains entries from the master schedule <NUM> for execution as a next mission <NUM>. In some embodiments, the fleet controller <NUM> executes missions in the master schedule <NUM> according to a priority of the missions, and may pre-empt lower priority missions for higher priority missions or directly submitted missions.

In some embodiments, the fleet controller may obtain the next mission <NUM> from the master schedule <NUM> through a fleet application programming interface (API) <NUM>, and in other embodiments, may obtain the next mission <NUM> directly from the master schedule <NUM>, or from another schedule or mission source such as a third party scheduling system or as a direct mission request from, for example, a control dashboard <NUM> or the like. The fleet controller <NUM> may generate a flight path for the next mission <NUM> according to information from a traffic management system <NUM>, the control dashboard <NUM>, historical mission information, and the like. For example, the fleet controller <NUM> may retrieve a next mission <NUM> entry indicating that a particular vehicle should move to arrive at a target location at a predetermined time. The fleet controller <NUM> may identify a particular flight path for the mission, and may verify the usability of the flight path with the traffic management system <NUM>, such as a UTM. A UTM may provide data or flight path checking related to traffic in a flight path, availability of a flight path due to flight restrictions or the like, weather, requirements for a flight path such as weight or size, minimum or maximum altitude or airspeed, or the like. For example, the UTM may indicate that the flight path has an unexpected volume of traffic, and the fleet controller <NUM> may determine an alternative flight path using data from the UTM, historical flight data, predetermined flight paths, or the like, or a combination of any of the same. Alternatively, the fleet controller <NUM> may determine that flight conditions, such as weather, wind, or the like, indicate that the flight path is unacceptable for flight operations, the fleet controller <NUM> may attempt to find a new, more acceptable flight path, may delay the mission, or may replace or cancel the mission.

In some embodiments, the control dashboard <NUM> may be an interface that permits a user to submit mission entries directly to the fleet controller <NUM>, or to take manual control, through a manual control system <NUM>, of a particular vehicle <NUM>. The manual control system <NUM> permits operator-in-the-loop control, which may allow for precise control of a particular vehicle <NUM>.

The fleet controller <NUM> may send command and control messages <NUM> to the IoT gateway <NUM> through a control arbitrator <NUM>. The control arbitrator <NUM> may receive control messages or command instructions <NUM> from the manual control system <NUM> after receiving or executing an existing set of command instructions <NUM> from the fleet controller <NUM>, or may receive command instructions <NUM> from the fleet controller <NUM> and manual control system <NUM> substantially simultaneously. The control arbitrator <NUM> determines which set of command instructions <NUM> has greater authority, and forwards the command instructions <NUM> with greater authority to the IoT gateway <NUM>. In some embodiments, the control arbitrator <NUM> may use a predetermined set of rules to determine which command instructions <NUM> have greater authority. For example, in an embodiment, the control arbitrator <NUM> may use a predetermined rule that give any command instructions with an emergency priority the highest priority, any non-emergency manual command the next highest priority, and any scheduled control instruction the lowest priority.

The elements of the system <NUM> may, in some embodiments, be implemented by a computer system. The computer system may have one or more processors and a non-transitory computer readable medium having a program stored thereon. The program may include instructions for performing the processes described herein. Additionally, one or more elements of the system <NUM> may be implemented as separate processes, programs or portions of one or more programs, or as separate programs on a computer or computer system having multiple computers. For example, the fleet controller <NUM> may be integrated with the control arbitrator <NUM>, event manager <NUM>, telemetry manager <NUM> or one or more other elements of the system <NUM>. In another embodiment, the fleet controller <NUM> may be implemented on a first computer system, network, or in a first program, and any one or more of the control arbitrator <NUM>, event manager <NUM>, telemetry manager <NUM> may be disposed together, or separately on a second, separate computer system, network or in a second, separate program. Additionally, the fleet scheduler <NUM> and the fleet controller <NUM> may be integrated together, disposed on a same computer system in separate programs or processes, or disposed on separate computer systems or networks.

<FIG> is a flow diagram illustrating a method <NUM> for handling vehicles missions in a fleet management system according to some embodiments. Initially, in block <NUM>, the fleet controller obtains a next mission. In some embodiments, the fleet controller retrieves, or receives, a next mission from a master schedule, either directly, through an API, or through another element. In some embodiments, the next mission is a mission having a highest priority in the master schedule, and in other embodiments, the next mission is a mission submitted directly to the fleet controller by a user through the control dashboard.

In block <NUM>, the mission is verified against monitored parameters or mission impact data. In an embodiment, the fleet controller compares the requirements of the next mission against monitored parameters such as traffic in a potential travel path, weather, flight restrictions or requirements along the potential travel path, capabilities of the assigned vehicle, geographic restrictions, and the like. For example, the mission may be verified using a UTM to verify that the potential flight path for the next mission is available and safe for the assigned vehicle. The fleet controller may attempt to modify the mission, select a new travel path that can be verified against the monitored parameters, reject the mission, reschedule the mission, or the like. The fleet controller may also apply geofencing restrictions on the vehicles using predetermined boundaries, using UTM data, or the like.

In block <NUM>, vehicle commands are generated in response to the mission being verified against the monitored parameters. In some embodiments, generating the vehicle commands includes, but is not limited to, assigning one or more of a flight or travel path, speed, altitude, arrival or departure time, target origin or target destination, mission type, setting a flight path according to geofencing restrictions, or the like.

In block <NUM>, the vehicle commands are sent to the vehicle. In some embodiments, the vehicle commands may be sent to a control arbitrator, and in block <NUM>, the control arbitrator may verify that the vehicle associated with the vehicle commands is subject to single source control, and after verifying that the vehicle commands have proper authority, or are a single source of control for the relevant vehicle, may be forwarded to the vehicle, in block <NUM> to control the vehicle. In other embodiments, the vehicle commands may be sent or forwarded to the vehicle in block <NUM> without a control arbitrator to control the vehicle. The vehicle commands may be sent through the IoT backbone, which routes the vehicle commands to the relevant vehicle.

In block <NUM>, the mission parameters are monitored by a monitoring element. In some embodiments, the fleet controller performs persistent monitoring of the operation of the individual vehicles and mission parameters during the mission to determine whether operation of a vehicle needs to be adjusted. The fleet controller performs persistent connection monitoring, and in block <NUM>, detects connection loss to a particular vehicle by monitoring messaging to and from the vehicle. In block <NUM>, the last vehicle status is reported when the connection is lost.

The fleet controller may use the connection management of the IoT backbone to detect the connection loss, or may use another connection monitoring technique. For example, the fleet controller may send a periodic message to each vehicle and monitor response messages, or may monitor for periodic message initiated by the vehicles. If a lost connection is detected, the last vehicle status reported status may be reported to, for example, the fleet controller, or the like. For example, the access point may perform connection monitoring, and report a lost connection with a last vehicle status, back to the fleet controller.

In some embodiments, when the connection between the vehicle and the IoT backbone is lost, the fleet controller may raise an exception, event or message, for example, at the dashboard, for investigation. In some embodiments, the fleet controller may assign a new vehicle to the mission of the vehicle associated with the lost connection, may request further instruction from a user, or the like.

In block <NUM>, the monitoring element receives message events, in block <NUM>, the monitoring element receives UTM data, and in block <NUM>, the monitoring element receives exterior condition data. The event messages may include event messages or requests sent by a vehicle, or sent through the control dashboard or another system. The UTM data may include updates to flight paths or flight requirements for particular flight paths, traffic updates or data, and the like. The exterior condition data may include weather data and the like.

The monitoring element may verify that the mission parameters are supported during performance of the mission by mission impact data such as the received event messages, UTM data, and exterior condition data, and the like. In block <NUM>, determines whether the vehicle operation adjustment is needed according to comparison between the mission parameters and the mission impact data. If vehicle operation adjustment is needed, then the fleet controller generates adjusted vehicle commands in block <NUM>. In some embodiments, the fleet controller adjusts the vehicle commands according to at least one of the event messages, UTM data or exterior condition data so that the vehicle commands reflect mission parameters that are supported by the received data. In some embodiments, the fleet controller performs vehicle deconfliction, for example, by providing control messaging to vehicles to avoid each other in transit.

In block <NUM>, the adjusted vehicles commands are sent to the vehicles. In some embodiments, the adjusted vehicle commands are sent to the control arbitrator, which, in block <NUM>, verifies that the vehicle is subject to single source control. Once the adjusted vehicle commands are confirmed to be a result of single source control, the adjusted vehicle commands are forwarded to the vehicle in block <NUM> to control the vehicle. In another embodiment where the control arbitrator is omitted, the adjusted vehicle commands are forwarded to the relevant vehicle in block <NUM> to control the vehicle. Once the vehicle receives the vehicle commands or adjusted vehicle commands, the vehicle executes the commands to perform the mission.

An embodiment method includes obtaining, by a fleet controller, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generating vehicle commands according to mission parameters associated with the mission, maintaining a persistent connection with the vehicle, sending the vehicle commands to the vehicle using the connection, the vehicle commands causing the vehicle to execute the mission under control of the fleet controller, and monitoring operation of the vehicle during performance of the mission.

In some embodiments, the generating the vehicle commands includes identifying a flight path associated with the mission, verifying a usability of the flight path with a traffic management system, and generating the vehicle commands according to the flight path in response to verifying the usability of the flight path. In some embodiments, the obtaining the mission includes obtaining the mission from the master schedule according to a priority of mission entries in the master schedule. In some embodiments, the monitoring operation of the vehicle includes monitoring a connection of the vehicle to a communications network associated with the fleet controller. In some embodiments, the monitoring the connection includes monitoring, by an access point of the communications network, a connection between the vehicle and the access point, and reporting, by the access point, a last vehicle status to the fleet controller. In some embodiments, the monitoring operation of the vehicle includes determining, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller, and the method further includes generating, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters, and sending the adjusted vehicle commands to the vehicle using the connection, the adjusted vehicle commands causing the vehicle to execute the mission under control of the fleet controller according to the adjusted vehicle command. In some embodiments, the sending the vehicle commands to the vehicle comprises determining whether the vehicle is subject to single source control, and forwarding the vehicle commands to the vehicle in response the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle.

An embodiment device may be a fleet controller, including a processor and a non-transitory computer-readable storage medium storing a program to be executed by the processor. The program may include instructions for obtaining, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generating vehicle commands according to mission parameters associated with the mission, maintaining a persistent connection with the vehicle through a communications network, sending the vehicle commands to the vehicle using the connection, the vehicle commands causing the vehicle to execute the mission under control of the fleet controller, and monitoring operation of the vehicle during performance of the mission.

In some embodiments, the instructions for the generating the vehicle commands include identifying a flight path associated with the mission, verifying a usability of the flight path with a traffic management system, and generating the vehicle commands according to the flight path in response to verifying the usability of the flight path. In some embodiments, the instructions for the obtaining the mission include instructions for obtaining the mission from the master schedule according to a priority of mission entries in the master schedule. In some embodiments, the instructions for the monitoring operation of the vehicle include instructions for receiving, from an access point of the communications network, a last vehicle status in response to loss of a connection between the vehicle and the access point hosting the persistent connection. In some embodiments, the instructions for the monitoring operation of the vehicle include instructions for determining, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller, and the program further includes instructions for generating, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters, and sending the adjusted vehicle commands to the vehicle using the connection, the adjusted vehicle commands causing the vehicle to execute the mission under control of the fleet controller according to the adjusted vehicle command. In some embodiments, the mission impact data includes at least one of received event messages, traffic management system data, or exterior condition data. In some embodiments, the instructions for the sending the vehicle commands to the vehicle includes determining whether the vehicle is subject to single source control, and forwarding the vehicle commands to the vehicle in response the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle.

An embodiment system includes a vehicle, a communications network, and a fleet controller in communication with the vehicle by way of the communications network. The fleet controller may be configured to obtain, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, where the mission is associated with a mission entry of the master schedule, generate vehicle commands according to mission parameters associated with the mission, maintain a persistent connection with the vehicle through the communications network, send the vehicle commands to the vehicle using the connection, with the vehicle being configured to receive the vehicle command and execute the mission according to the vehicle commands, and monitor operation of the vehicle during performance of the mission.

In some embodiments, the fleet controller is configured to identify a flight path associated with the mission, verify a usability of the flight path with a traffic management system, and generate the vehicle commands according to the flight path in response to verifying the usability of the flight path. In some embodiments, the fleet controller is configured to obtain the mission from the master schedule according to a priority of mission entries in the master schedule. In some embodiments, the fleet controller is configured to receive, from an access point of the communications network, a last vehicle status in response to loss of a connection between the vehicle and the access point hosting the persistent connection. In some embodiments, the fleet controller is configured to determine, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received at the fleet controller, generate, in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters, and send the adjusted vehicle commands to the vehicle using the connection, with the vehicle being configured to execute the mission according to the adjusted vehicle command. In some embodiments, the system further includes a control arbitrator configured to determine whether the vehicle is subject to single source control, and forward the vehicle commands to the vehicle in response the vehicle being subject to the single source control or a source of the vehicle commands being assigned an authority greater than any other set of vehicles commands associated with the vehicle.

Claim 1:
A computer implemented autonomous vehicle fleet control method (<NUM>), comprising:
obtaining (<NUM>), by a fleet controller, from a master schedule, a mission for a vehicle of a fleet of autonomous vehicles, wherein the mission is associated with a mission entry of the master schedule;
identifying a flight path associated with the mission;
verifying (<NUM>) a usability of the flight path with an unmanned aircraft system, UAS, traffic management, UTM,
wherein the UTM performs checking on the flight path for traffic in the flight path, availability of the flight path due to flight restrictions and requirements for use of the flight path;
modifying the flight path according to data from the UTM in response to the UTM indicating that the usability of the flight path is not verified;
generating vehicle commands (<NUM>) according to mission parameters associated with the mission based on the flight path;
maintaining a persistent connection with the vehicle;
sending (<NUM>) the vehicle commands to the vehicle using the connection, the vehicle commands causing the vehicle to execute the mission under control of the fleet controller;
monitoring (<NUM>) operation of the vehicle, in real-time or near real-time, during performance of the mission, wherein the monitoring the operation of the vehicle comprises determining, during performance of the mission, whether the mission parameters associated with the mission are supported by mission impact data received from the fleet controller, wherein the mission impact data includes UTM data received from the UTM;
generating (<NUM>), in response to the mission parameters not being supported by the mission impact data, adjusted vehicle commands according to the mission impact data and the mission parameters; and
sending (<NUM>) the adjusted vehicle commands to the vehicle using the connection, the adjusted vehicle commands causing the vehicle to execute the mission under control of the fleet controller according to the adjusted vehicle command.