UNMANNED VEHICLE RISK ASSESSMENT SYSTEM

A method includes receiving a first navigation path risk request that includes first navigation path information associated with a first navigation path for a first unmanned vehicle through a first environment. The method also includes selecting a first risk model from a plurality of risk models based on the first navigation path information. The method also includes obtaining first data used as one or more inputs to run the first risk model from one or more data sources. The method also includes operating the first risk model with the first data to output a first risk score. The method also includes providing a first navigation path risk response in response to the first navigation path risk request that includes the first risk score that is associated with at least a portion of the first navigation path.

FIELD OF THE DISCLOSURE

This disclosure relates generally to unmanned vehicles, such as unmanned aerial vehicles, and, more particularly, to accessing risk for trajectory paths of unmanned vehicles.

BACKGROUND

Unmanned vehicles, such as unmanned aerial vehicles (UAVs) or unmanned ground vehicles (UGVs), are mobile platforms capable of acquiring (e.g., sensing) information, delivering goods, manipulating objects, etc., in many operating scenarios. Unmanned vehicles typically have the ability to travel to remote locations that are inaccessible to manned vehicles, locations that are dangerous to humans, or any other location. Upon reaching such locations, a suitably equipped unmanned vehicles may perform actions, such as acquiring sensor data (e.g., audio, images, video and/or other sensor data) at a target location, delivering goods (e.g., packages, medical supplies, food supplies, engineering materials, etc.) to the target location, manipulating objects (e.g., such as retrieving objects, operating equipment, repairing equipment etc.) at the target location, etc.

Unmanned vehicles are often controlled by a remote user from a command center (e.g., using a remote control, computer device, smart phone, and/or other remote monitor) such that the remote user provides commands to the unmanned vehicle through a wireless communications link to perform actions. More advanced unmanned are also being developed that are more autonomous (e.g., fully autonomous, semi-autonomous) such that unmanned vehicle guidance systems may assist the remote user or remove the need for the remote user altogether.

SUMMARY

Some aspects include a process including: receiving, by a computer system, a navigation path risk request that includes navigation path information associated with a navigation path for an unmanned vehicle through an environment; selecting, by the computer system, a risk model from a plurality of risk models based on the navigation path information; obtaining, by the computer system, data used as one or more inputs to run the risk model from one or more data sources; operating, by the computer system, the risk model with the data to output a risk metric; and providing, by the computer system, a navigation path risk response in response to the navigation path risk request that includes the risk metric that is associated with at least a portion of the navigation path.

Some aspects include an aircraft, including: one or more processors; and memory storing instructions that when executed by the processors cause the processors to effectuate operations of the above-mentioned process.

DETAILED DESCRIPTION

Systems and methods of the present disclosure provide an unmanned vehicle risk assessment service platform that is a hosted service based on an application programming interface (API) that integrates multiple geospatial-geotemporal data sources with multiple risk models, providing real-time geospatial-geotemporal risk metrics that are then optimized into segment, risk-assessed trajectories or a set of defined geospatial-geotemporal points (e.g., one or more geospatial-geotemporal points) for optimization and used to provide instructions to an unmanned vehicle. The unmanned vehicle risk assessment service platform may be used in multiple ways. For example, a Risk Authority (e.g., the Federal Aviation Administration (FAA), an insurance company, or a state regulator) can use it to develop and publish formal, validated risk models. In another example, a Flight Manager (e.g., an operator, an air traffic service provider, or a regulator) may use the unmanned vehicle risk assessment service platform to assess the risk of a given flight or navigation path and risk-optimized trajectory. In another example, a Tools Developer (e.g., a provider of navigation planning, compliance, vehicles, or ground control software) can use the unmanned vehicle risk assessment service platform to integrate risk assessment and monitoring seamlessly into their end products as a white label service, allowing autonomous/semi-autonomous vehicles to make real-time context bound decisions for routing and re-routing for assured autonomy. The unmanned vehicle risk assessment service platform is, in some embodiments, expected to provide cross-platform, inter-model real time risk assessment and continuous risk monitoring as a broadly adoptable, integrated capability.

As the unmanned vehicle industry moves toward beyond visual line of sight (BVLOS) and autonomous capabilities, near real time (e.g., within 3 seconds or less, such as less than one second or less than a millisecond) risk assessment and continuous risk monitoring are going to be an aspect of the safety case and creating assured autonomy. While the FAA is developing standards and requirements for what the FAA will consider to be a “safe” BVLOS flight, the implementation of these guidelines is still being treated as a manual, offline activity: certification of vehicles, manuals, human flight planning, human-in the-loop risk management. While the unmanned vehicle industry is developing excellent technology, including advanced sensing, detect-and-avoid technologies, and autonomous flight routing the current path makes it likely that these systems will exist as components within the overall context of FAA or other regulatory body regulation. The ability to provide all of these systems with real time, continuous risk assessment and monitoring calculated using logical models derived from FAA standards, state and local regulations, and other experts has the potential to put all of these different systems on a “common baseline” that would allow for higher density operations and “common consensus” among the unmanned vehicles. This is especially relevant in creating the context for autonomous, BVLOS operations by creating boundary conditions for autonomous operations that recognize the changing contextual environment while also bounding autonomous vehicles in a manner that is consistent, clear, and automated.

The unmanned vehicle risk assessment system, in some embodiments having real time risk assessment and continuous risk monitoring using an open system, may be aligned with the “federated” model of unmanned aircraft systems (UAS) traffic management (UTM)/urban air mobility (UAM)/advanced aerial mobility (AAM) services.

The federated UTM/UAM/AAM model, in some embodiments, allows the system to grow and develop organically, within the guidelines and boundaries set by federal, state, and local government, with: i) a cost profile that works for state and local government; ii) the ability, in some embodiments, to make modest investments today that work for use cases now; iii) potentially improved safety because it, in some embodiments, allows for multiple participants to create redundant data and services coverage; and iv) the decentralized nature of a federated approach means it is less vulnerable to failure and attack because it doesn't have choke points (e.g., the original ARPAnet design).

The unmanned vehicle risk assessment system can, in some embodiments, provide risk assessment services in the federated model of UTM/UAM/AAM, and it, in some embodiments, is designed to do so by supporting multiple Risk Authorities owning and sharing models; provision of data by multiple sources; and open integration with UAS Service Supplier (USS)/UTM/Ground Control Software (GCS) tools.

The inventors of the present disclosure have demonstrated that the risk assessment/risk monitoring task of UAS and autonomous flight can be automated by translating safety standards into logical models and then demonstrate that these models could be applied in a federated systems context with multiple authorities contributing risk models, collecting and normalizing multiple disparate data sources, and creating a service that can be queried by multiple users using different USS/GCS tools. The top line result is that the unmanned vehicle risk assessment system, in some embodiments, is a product with demonstrated performance, such that it can: (1) acquire the data to validate and demonstrate the feasibility of the unmanned vehicle risk assessment system innovation based on the literature review; (2) provide two or more reference models for test and validation purposes based on the FAA Safety Management System Flight Risk Assessment Tools (FRATs) and the JARUS SORA report; (3) provide a Model Interpreter Service that hosts models, dynamically retrieves and normalizes data, and provides a near-real time risk assessment; (4) provide an API that returns a risk assessment segmented against the navigation path plan that supports risk mitigation and trajectory optimization; and (5) integrate the unmanned vehicle risk assessment system into an approved production FAA LAANC USS flight planning tool (e.g., Beeline) or other planning tools for ground and amphibious vehicles, allowing for testing and validation in a fully operational navigation planning environment that is pre-production for actual navigation testing, achieving technology readiness level (TRL)-4.

The systems and method of the present disclosure provides an API based production service that calculates risk based trajectories by integrating multiple geospatial-geotemporal data sources with independent risk models to provide real-time geospatial-geotemporal risk assessment and continuous risk monitoring using risk metrics that are then optimized into risk-optimized trajectories. The risk based trajectories, in some embodiments, may be used in UAS operations by human Remote Pilot in Command (RPIC), by autonomous vehicles in the Flight Planning and En Route phases of flight, and by managers of air traffic or local systems to make decisions about approving operations or opening/closing airspace and ground space. Features of the unmanned vehicle risk assessment system, in some embodiments, include but are not limited to: collecting disparate source data and normalizing for use in risk assessment and continuous risk monitoring; adding independent risk model content from independent Risk Authorities, risk models, and additional data sources; developing model specification and validation tools for use by Risk Authorities within the unmanned vehicle risk assessment service; supporting the federated UTM/UAM/AAM model by integrating with external USS/GCS/Flight Planning Tools; making the tool operational for remote pilot in command (RPIC) vehicles and autonomous vehicles to provide trajectory optimization modes; presenting risk trajectories through user interface design and reference implementations; subscribing to various data sources and Risk Authorities; and other features discussed below. In some embodiments, the unmanned vehicle risk assessment system provides a capability that significantly improves the safety of high density, crewed or uncrewed, piloted or autonomous vehicle operations in the National Airspace System (NAS).

In an example embodiment, industry has largely focused on the traffic management and operational aspects of UAS and other unmanned vehicle operations, with risk management largely being treated as either a manual, offline process, or a design issue for the airframe/vehicle chassis. The unmanned vehicle risk assessment system of the present disclosure, in some embodiments, seeks to address the lack of investment into risk management approaches for unmanned vehicle operations by creating a service to help unmanned vehicle operators manage the risk of their trajectory, in addition to other risk mitigation measures. The unmanned vehicle risk assessment service, in some embodiments, will include several components: access to substrate data for operator informational awareness and to perform and return risk calculations; a service hosting one or more risk calculation models that can leverage the data to calculate model-specific, geospatial-geotemporal risk estimates on the fly (with a “failure modes, effects, and criticality analysis” (FMECA) model as a baseline); a geospatial-geoptemporal zoning capability that uses input coordinates to identify applicable risk elements, calculate associated risk metrics, optimize the given trajectory into a series of “risk” segments, and map and return one or more optimized and/or preferred diversion routes; and an on-demand API that external consumers use to query the unmanned vehicle risk assessment service using entered flight plans other navigation plans and return a set of risk based trajectory segments or a set of defined geospatial-geotemporal points (e.g., one or more geospatial-geotemporal points).

The unmanned vehicle risk assessment system, in some embodiments, is an “open” service that leverages available data, Supplemental Data Service Providers (SDSPs), other Risk Authority specified sources of data, and provides open access to the API rather than requiring use of the service as part of a bundled UTM package. A component of the unmanned vehicle risk assessment service, in some embodiments, is to integrate with any authoritative SDSP or other specified data provider. By proving out the concept of state and local government as an authoritative provider of supplemental information, combined with other sources of public and commercially available data, the possibility for an automated, scalable, detailed risk-based trajectory service with national coverage is possible. Similar to the FAA SMS FRAT guidelines for traditional manned flight, the unmanned vehicle risk assessment system, in some embodiments, can expand the FRAT to an automated, near-real-time risk assessment and planning capability for both human controlled (Remote Pilot in Command) and autonomous (software controlled) UAS or other unmanned ground or amphibious vehicles.

The FAA Safety Management System and waiver process for beyond visual line of sight (BVLOS) and advanced operations use the same techniques (air space characterization and ground risk assessment) as the FRAT and are laborious and manual. Finally, the new FAA Operation of Small Unmanned Aircraft Systems Over People rule leaves a gap: while it accounts for UAS vehicle attributes and enhanced pilot training, it reduces the requirement for Remote Pilots in Command or operators of autonomous UAS to analyze and understand the risk factors of a given operation (as was required under the waiver process), abandoning the assessment component of the waiver process for Operations Over People. The unmanned vehicle risk assessment system, in some embodiments, addresses this gap and provides a readily available, scalable, quick solution for operational flight risk assessment consistent with the FAA SMS.

In the UAS sector, the investment and research has been focused on developing the fabric of UAS Traffic Management: surveillance, flight planning, flight scheduling, airspace management, regulatory compliance, and the onboard systems and sensors making UAS vehicle themselves more intelligent, more networked, and lower risk. However, there are some conventional approaches and solutions to managing UAS flight risk assessment: (1) FAA Waiver Process—while the waiver process now excludes Operations Over People and Operations at Night, the waiver process and its risk analysis and narrative are the predominant method for managing risk in advanced UAS operations; (2) Pilot Training—the baseline for risk management includes knowledge about procedures for airmen, control of a vehicle in flight, understanding of regulations, how to interpret airspace configuration, and navigation principles. Pilot training and certification help UAS RPICs understand the risks associated with flight; however, it does not provide the level of situational awareness that integrated data can. Further, autonomous vehicles do not benefit from this training; (3) FAA SMS FRAT—can be applied to UAS operations, and some organizations have created checklists and training tools to help RPICs apply the SMS FRAT approach to UAS. The unmanned vehicle risk assessment service of the present disclosure incorporates the FRAT components as well as other data to provide the same rigor in an automated service that also benefit autonomous vehicles; and (4) Commercial Software Products—Flight Planning products provide information about infrastructure, airports, and areas where operations have a higher risk relative to manned aviation. However, while this provides useful situational awareness, it is not fully integrated and still puts the onus on the pilot to formulate a risk assessment.

The unmanned vehicle risk assessment system and methods, in some embodiments, at the end of Phase II follows several core design principles to implement the open service architecture concept of some embodiments of risk based trajectory. The first was to develop a solution architecture and design around “personas” that represent the users and stakeholders in the system. The second was to make the system as configurable as possible, by allowing “swappable” models (the ability to onboard and use multiple data sets). The third was to develop an API that supports the submission of route/navigation plans (e.g., flight plans) using standard objects to request specific outputs, and to return these outputs in as standard and simple a format as possible. Fourth was to use loosely coupled interfaces to support future integrations with external systems. The result was a set of user personas, an overall system design, and a set of functionally integrated, tested, and validated modules.

User personas identified in the Phase I research include, in some embodiments, the Risk Authority, the Flight Manager, and the Tools Developer. The Risk Authority, in some embodiments, is a trusted, independent expert on aviation risk. The authority may be an individual expert, such as a researcher, or a trusted organization such as a regulator, university, or insurance company. The Risk Authority is, in some embodiments, responsible for creating, curating, and validating models. The Flight Manager is, in some embodiments, a remote pilot in command, an operator, or a stakeholder such as a regulator, insurer, or community that has a vested interest in the safety of UAS operations. The Flight Manager, in some embodiments, is the consumer of risk assessment services and engages directly in risk mitigation activities. The Tools Developer is a provider of equipment and software to the UAS industry, such as an OEM, USS, UTM provider, or developer of flight planning and ground control software.

The solution architecture includes, in some embodiments, four groups: the system users/consumers, the constituent data sources, the model tracking and management server, and the Model Interpreter Service. As described in further detail below, the Risk Authority, in some embodiments, interacts with the API on the Model Interpreter Service to specify and submit a model which is then managed by the model tracking and management server (e.g., MLFlow Tracking Server) or a model hosting service and rendered available for loading when a risk assessment against a specific flight plan/route plan is requested.

The Flight Manager, in some embodiments, (e.g., Operator) or Tools Developer (e.g., OEM) submits a flight plan with model specification as a geoJSON attribute (or other suitable format, such as KML or XML) against the Model Interpreter Service API. The request is, in some embodiments, handled in the Risk Assessment module, which loads the risk model (e.g., in real-time) from the Model Hosting module which specification is then used to forward a contextual data request to the Geospatial Data Aggregation module. The Geospatial Data Aggregation, in some embodiments, formulates the individual data request queries to the distributed data services and normalizes the returned data (e.g., in real time) before passing it back to the Risk Assessment module. The Risk Assessment module, in some embodiments, calculates the geospatial-geotemporal risk assessment for the proposed operation and then passes the risk topology back to the Model Interpreter Service API. The API, in some embodiments, segments and packages the risk assessed, segmented operation and returns it to the Flight Manager or Tools developer as a geoJSON (or other suitable format, such as KML or XML).

In addition to the unmanned risk assessment system's modular architecture, in some embodiments, architecture activities include development of the model specification. This describes the reference JSON schema for how a “swappable” risk model would be specified by the user, design criteria for the model interpreter service, and a Logical Architecture for the prototype.

Referring now toFIG.1, an embodiment of an unmanned vehicle risk assessment system100is illustrated. In the illustrated embodiment, the unmanned vehicle risk assessment system100includes an unmanned vehicle105provided in an environment102. The environment102may be any indoor or outdoor space that may be contiguous or non-contiguous. The environment102may be defined by geofencing techniques that may include specific geographic coordinates such as latitude, longitude, or altitude, or operate within a range defined by a wireless communication signal, during a specified or defined window of time.

The unmanned vehicle105may be implemented by any type of drone, such as an unmanned aerial vehicle (UAV). In alternative embodiments, a robot, an unmanned ground vehicle (e.g., a car, a truck, a tractor, military equipment, construction equipment, etc.), an unmanned amphibious vehicle (e.g., a boat, a submersible, a hovercraft, etc.), or other vehicular devices may be employed. In the illustrated examples of the present disclosure, the unmanned vehicle105is depicted as a UAV and may include a flight control unit108and a payload unit110. For example, the flight control unit108of the unmanned vehicle105may include any appropriate avionics, control actuators, or other equipment to fly the UAV. The payload unit110of the unmanned vehicle105may include any equipment implementing features supported by the given UAV. For example, the payload unit110may include one or more sensors, such as one or more cameras or other imaging sensors110a, one or more environmental sensors (e.g., such as one or more temperature sensors, pressure sensors, humidity sensors, gas sensors, altitude sensors, location sensors and the like) or any other sensor. Additionally or alternatively, an example payload unit110for the unmanned vehicle105may include tools, actuators, manipulators, etc., capable of manipulating (e.g., touching, grasping, delivering, measuring, etc.) objects. For example, as illustrated inFIG.1, the UAV may include a robotic arm110bthat is configured to deploy the one or more sensors include on the robotic arm110b. Additionally or alternatively, an example payload unit110for the unmanned vehicle105may include a portable base station, signal booster, signal repeater, etc., to provide network coverage to an area. Additionally or alternatively, the robotic arm110bmay operate a mechanism for delivery of goods to a recipient on the ground in the defined geospatial area102.

The unmanned vehicle105may include communication units having one or more transceivers to enable the unmanned vehicle105to communicate with a remote monitor120, a service platform125via a communication network135, or any other computing devices (e.g., other unmanned vehicles, sensors, a docking station, etc.) in the environment102that would be apparent to one of skill in the art in possession of the present disclosure. Accordingly, and as disclosed in further detail below, the remote monitor120may be in communication with the unmanned vehicle105directly or indirectly. As used herein, the phrase “in communication,” including variances thereof, encompasses direct communication or indirect communication through one or more intermediary components and does not require direct physical (e.g., wired or wireless) communication or constant communication, but rather additionally includes selective communication at periodic or aperiodic intervals, as well as one-time events.

For example, the unmanned vehicle105in the unmanned vehicle risk assessment system100ofFIG.1include first (e.g., long-range) transceiver(s) to permit the unmanned vehicle105to communicate with the communication network135. The communication network135may be implemented by an example mobile cellular network such as a radio access network (RAN) that includes a core network and one or more base stations140. As such, the RAN may include a long-term evolution (LTE) network or other third generation (3G), fourth generation (4G) wireless network, or fifth-generation (5G) wireless network. However, in some examples, the communication network135may be additionally or alternatively be implemented by one or more other communication networks, such as, but not limited to, a satellite communication network, a microwave radio network, or other communication networks.

The unmanned vehicle105additionally or alternatively may include second (e.g., short-range) transceiver(s) to permit the unmanned vehicle105to communicate with sensors, docking stations, other unmanned vehicles, the remote monitor or other computing devices in the environment102. In the illustrated example ofFIG.1, such second transceivers are implemented by a type of transceiver supporting short-range wireless networking. For example, such second transceivers may be implemented by Wi-Fi transceivers, Bluetooth® transceivers, infrared (IR) transceiver, and other transceivers that are configured to allow the unmanned vehicle105to intercommunicate via an ad-hoc or other wireless network.

The unmanned vehicle risk assessment system100also includes or may be used in connection with a remote monitor120. The remote monitor120may be provided by a desktop computing system, a laptop/notebook computing system, a tablet computing system, a mobile phone, a set-top box, a remote control, a wearable device, and implantable device, or other remote monitor for controlling the unmanned vehicle105. However, in other embodiments, the unmanned vehicle105may be autonomous or semi-autonomous. The remote monitor120may be responsible for managing the unmanned vehicle105deployed in the environment102. For example, the remote monitor120may communicate indirectly through the communication network135or directly to locate the unmanned vehicle105in the environment102, identify the unmanned vehicle105in the environment102, ascertain capabilities of the unmanned vehicle105in the environment102, monitor the operating status of the unmanned vehicle105in the environment102, receive sensor data provided by the unmanned vehicle105in the environment102, provide instructions to the unmanned vehicle105, or provide other functionality.

The unmanned vehicle risk assessment system100also includes or may be in connection with an unmanned vehicle risk assessment service platform130. For example, the unmanned vehicle risk assessment service platform130may include one or more server devices, storage systems, cloud computing systems, or other computing devices (e.g., desktop computing device(s), laptop/notebook computing device(s), tablet computing device(s), mobile phone(s), etc.). As discussed in further detail below, the unmanned vehicle risk assessment service platform130may be configured to provide unmanned vehicle risk models, data for operating the risk models, or other instructions and data that would be apparent to one of skill in the art in possession of the present disclosure. The service platform may also include a services engine for communicating instruction and risk results to the unmanned vehicle105. While a specific unmanned vehicle risk assessment system100is illustrated inFIG.1, one of skill in the art in possession of the present disclosure will recognize that other components and configurations are possible, and thus will fall under the scope of the present disclosure. For example, the system may include many more unmanned vehicles (e.g., 2, 5, 10, 100, 1000, or more) or many other remote monitors (e.g., 2, 5, 10, 100, 1000, or more) in the environment102and the system may include many other separate environments102.

Referring now toFIG.2, an embodiment of an unmanned vehicle200is illustrated that may be the unmanned vehicle105discussed above with reference toFIG.1, and which may be provided by a UAV, a robot, an unmanned ground vehicle, an unmanned amphibious vehicle, or other unmanned vehicular device. In the illustrated embodiment, the unmanned vehicle200includes a chassis202that houses the components of the unmanned vehicle200. Several of these components are illustrated inFIG.2. For example, the chassis202may house a processing system (not illustrated) and a non-transitory memory system (not illustrated) that includes instructions that, when executed by the processing system, cause the processing system to provide an unmanned vehicle controller204that is configured to perform the functions of the unmanned vehicle controllers or the unmanned vehicles, discussed below. In the specific example illustrated inFIG.2, the unmanned vehicle controller204is configured to provide a risk controller206that computationally processes risk scores and risk assessments as well as the functionality discussed below. In the specific example illustrated inFIG.2, the unmanned vehicle controller204is also configured to provide a mobility controller207to control the example flight control unit108of unmanned vehicle105and to implement any control and feedback operations appropriate for interacting with avionics, control actuators, or other equipment included in the flight control unit to navigate the unmanned vehicle105illustrated inFIG.1.

The chassis202may further house a communication system208that is coupled to the unmanned vehicle controller204(e.g., via a coupling between the communication system208and the processing system). The communication system208may include software or instructions that are stored on a computer-readable medium and that allow the unmanned vehicle200to send and receive information through the communication networks discussed above. For example, the communication system208may include a communication interface210to provide for communications through the communication network135as detailed above (e.g., first (e.g., long-range) transceiver(s)). In an embodiment, the communication interface210may be a wireless antenna that is configured to provide communications with IEEE 802.11 protocols (Wi-Fi), cellular communications, satellite communications, other microwave radio communications or communications. The communication system208may also include a communication interface212that is configured to provide direct communication with other unmanned vehicles, a docking station, sensors, the remote monitor120, or other devices within the environment102discussed above with respect toFIG.1(e.g., second (e.g., short-range) transceiver(s)). For example, the communication interface212may be configured to operate according to wireless protocols such as Bluetooth®, Bluetooth® Low Energy (BLE), near field communication (NFC), infrared data association (IrDA), ANT®, Zigbee®, Z-Wave® IEEE 802.11 protocols (Wi-Fi), and other wireless communication protocols that allow for direct communication between devices.

The chassis202may also house a storage system214that is coupled to the unmanned vehicle controller204through the processing system. The storage system214may store navigation paths216, risk assessments217, or other information or instructions used to navigate or operate components of the unmanned vehicle200based on risk scores or risk assessments217.

The chassis202may also house a sensor system220that may be housed in the chassis202or provided on the chassis202. The sensor system220may be coupled to the unmanned vehicle controller204via the processing system. The sensor system220may include one or more sensors that gather sensor data about the unmanned vehicle200, an environment around the unmanned vehicle200or other sensor data that may be apparent to one of skill in the art in possession of the present disclosure. For example, the sensor system220may include a positioning system224that includes a geolocation sensor (e.g., a global positioning system (GPS) receiver, a real-time kinematic (RTK) GPS receiver, a differential GPS receiver, a Wi-Fi based positioning system (WPS) receiver, an accelerometer, a gyroscope, a compass, an inertial measurement unit (e.g., a six axis IMU) or any other sensor for detecting or calculating orientation, position, or movement); an imaging sensor222that may include ultra-wideband sensors, a camera, a depth sensing camera (for example based upon projected structured light, time-of-flight, a lidar sensor, or other approaches), a three-dimensional image capturing camera, an Infrared image capturing camera, an ultraviolet image capturing camera, similar video recorders, or a variety of other image or data capturing devices that may be used to gather visual information from a physical environment102surrounding the unmanned vehicle200); or other sensors such as, but not limited to, a barometric pressure sensor, a beacon sensor, biometric sensors, an actuator, a pressure sensor, a temperature sensor, an RFID reader/writer, an audio sensor, an anemometer, a chemical sensor (e.g., a carbon monoxide sensor), or any other sensor that would be apparent to one of skill in the art in possession of the present disclosure. While a specific unmanned vehicle200has been illustrated, one of skill in the art in possession of the present disclosure will recognize that unmanned vehicles (or other devices operating according to the teachings of the present disclosure in a manner similar to that described below for the unmanned vehicle200) may include a variety of components and/or component configurations for providing conventional computing device functionality, as well as the functionality discussed below, while remaining within the scope of the present disclosure as well.

Referring now toFIG.3, an embodiment of an unmanned vehicle risk assessment service platform300is illustrated that may be the unmanned vehicle risk assessment service platform130discussed above with reference toFIG.1. In the illustrated embodiment, the unmanned vehicle risk assessment service platform300includes a chassis302that houses the components of the unmanned vehicle risk assessment service platform300, only some of which are illustrated inFIG.3. For example, the chassis302may house a processing system (not illustrated) and a non-transitory memory system (not illustrated) that includes instructions that, when executed by the processing system, cause the processing system to provide a risk assessment controller304that is configured to perform the functions of the risk assessment controllers or unmanned vehicle risk assessment service platforms discussed below. In the specific example illustrated inFIG.3, the risk assessment controller304is configured to provide a risk-based trajectory application programming interface (API) described above. The risk assessment controller304may include a model interpreter service305that is configured to perform the functions of the model interpreter services discussed herein. In various embodiments, the model interpreter service305may interpret a specified risk model against integrated contextual data, calculates or splits a navigation path into risk-based segments, calculates risk for a specified set of geospatial points, creates a risk topography or risk assessment, or any other functionality discussed herein. The risk assessment controller304may include a model hosting service306that is configured to perform the functions of the model hosting services discussed below. In various embodiments, the model hosting service306may generate risk models, track risk models, manage risk models, or any other functionality discussed herein. The risk assessment controller304may also include a data query service307that is configured to perform the functions of the data query services discussed below. In various embodiments, the data query service307may retrieve contextual data and other data from remote or local data sources, processes and structures the contextual data into a format for ingestion of risk models or any other functionality discussed herein.

The chassis302may further house a caching system312. As an example, and not by way of limitation, to execute instructions, a risk assessment controller304may retrieve (or fetch) instructions from an internal register, an internal cache, a memory, or storage system314; decode and execute them; and then write one or more results to an internal register, an internal cache, memory, or storage system314. In particular embodiments, the risk assessment controller304may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates a processor that provides the risk assessment controller304to include the caching system312that may include any suitable number of any suitable internal caches, where appropriate. As an example, and not by way of limitation, that caching system312may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory or storage system314and the instruction caches may speed up retrieval of those instructions by the risk assessment controller304. Data in the data caches may be copies of data in memory or storage system314(which may initially be retrieved via the network from an external storage database) for instructions executing at the processor to operate on; the results of previous instructions executed at the processor for access by subsequent instructions executing at the processor, or for writing to memory, or storage system314; or other suitable database. The data caches may speed up read or write operations by the risk assessment controller304. The TLBs may speed up virtual-address translations for the risk assessment controller304. In particular embodiments, the processor providing the risk assessment controller304may include one or more internal registers for data, instructions, or addresses. Depending on the embodiment, the processor may include any suitable number of any suitable internal registers, where appropriate. Where appropriate, the processor may include one or more arithmetic logic units (ALUs); be a multi-core processor; include one or more processors; or any other suitable processor. In various embodiments, of the present disclosure, the caching system312may cache data from data sources (e.g., remote and locally) or risk models based on a variety of conditions such as, amount of data, demand of the data or risk model, type of navigation path risk assessment being performed (e.g., enroute unmanned vehicles may require faster processing than unmanned vehicles that are stationary or in a holding pattern) or other conditions that would be apparent to one of skill in the art in possession of the present disclosure.

The chassis302may further house a communication system308that is coupled to the risk assessment controller304(e.g., via a coupling between the communication system308and the processing system) and that is configured to provide for communication through the communication network135as detailed below. The chassis302may also house a storage system314that is coupled to the risk assessment controller304through the processing system and that is configured to store the rules or other data utilized by the risk assessment controller304to provide the functionality discussed below. The storage system314may store one or more data sources316for contextual data, a risk model repository317that includes one or more risk models317a-nthat uses the contextual data to generate one or more risk assessments318that may include a risk score, risk metrics, risk-based navigation path segments, or updated navigation path recommendations. While a specific unmanned vehicle risk assessment service platform300has been illustrated, one of skill in the art in possession of the present disclosure will recognize that other risk assessment service platforms (or other devices operating according to the teachings of the present disclosure in a manner similar to that described below for the unmanned vehicle risk assessment service platform300) may include a variety of components and/or component configurations for providing conventional computing device functionality, as well as the functionality discussed below, while remaining within the scope of the present disclosure as well.

Referring now toFIG.4an embodiment of a remote monitor400is illustrated that may be the remote monitor120discussed above with reference toFIG.1. In the illustrated embodiment, the remote monitor400includes a chassis402that houses the components of the remote monitor400. Several of these components are illustrated inFIG.4. For example, the chassis402may house a processing system (not illustrated) and a non-transitory memory system (not illustrated) that includes instructions that, when executed by the processing system, cause the processing system to provide an unmanned vehicle application404that is configured to perform the functions of the unmanned vehicle applications, unmanned vehicle applications, or remote monitors discussed below. In the specific example illustrated inFIG.4, the unmanned vehicle application404is configured to receive notifications from an unmanned vehicle that include audio feeds and video feeds, provide those notifications to a user through an application, receive instructions from the user through the application, and provide those instructions over a communication network (e.g., the communication network135) to unmanned vehicles as well as the functionality discussed below.

The chassis402may further house a communication system406that is coupled to the unmanned vehicle application404(e.g., via a coupling between the communication system406and the processing system) and that is configured to provide for communication through the network as detailed below. The communication system406may allow the remote monitor400to send and receive information over the communication network135ofFIG.1. The chassis402may also house a storage system408that is coupled to the unmanned vehicle application404through the processing system that is configured to store the rules, graphics, or other data utilized by the unmanned vehicle application404to provide the functionality discussed below. While the storage system408has been illustrated as housed in the chassis402of the remote monitor400, one of skill in the art will recognize that the storage system408may be connected to the unmanned vehicle application404through the communication network135via the communication system406without departing from the scope of the present disclosure. While a remote monitor400has been illustrated, one of skill in the art in possession of the present disclosure will recognize that other remote monitors (or other devices operating according to the teachings of the present disclosure in a manner similar to that described below for the remote monitor400) may include a variety of components and/or component configurations for providing conventional computing device functionality, as well as the functionality discussed below, while remaining within the scope of the present disclosure as well.

FIG.5depicts an embodiment of a method500of scenario injection, which in some embodiments may be implemented with at least some of the components ofFIGS.1,2,3and4discussed above. As discussed below, some embodiments make technological improvements to unmanned vehicles and improvements to risk assessment for unmanned vehicles and unmanned vehicle navigation. The method500is described as being performed by the risk assessment controller304included on the unmanned vehicle risk assessment unmanned vehicle risk assessment service platform130/300. Furthermore, it is contemplated that the unmanned vehicle105/200or the remote platform120/400may include some or all the functionality of the risk assessment controller304. As such, some or all of the steps of the method500may be performed by the unmanned vehicle105/200or the remote platform120/400and still fall under the scope of the present disclosure. For example, the unmanned vehicle risk assessment service platform300may provide a risk model to the unmanned vehicle105/200for the unmanned vehicle105/200to run the risk model and obtain data for the risk model. Furthermore, and as mentioned above, the unmanned vehicle risk assessment unmanned vehicle risk assessment service platform130/300may include one or more processors or one or more servers, and thus the method500may be distributed across the those one or more processors or the one or more servers.

The method500begins at operation502where a navigation path risk request is received where the navigation path risk request includes navigation path information associated with a navigation path for an unmanned vehicle through an environment. In an embodiment, at operation502, a user550may provide the navigation path risk request to the unmanned vehicle risk assessment service platform300. In various embodiments, the navigation path risk request may be received by the model interpreter service305(e.g., by interacting with the API on the model interpreter service305). The navigation path risk request may include navigation path information that may include a navigation path (e.g., a flight path), a trajectory, a time of operation of the unmanned vehicle105/200, a location or locations of the navigation path, characteristics of the unmanned vehicle105/200(e.g., model, type, vehicle identification), or other operational characteristics associated with the unmanned vehicle105/200that would be apparent to one of skill in the art in possession of the present disclosure. In various embodiments, the navigation path information may also include information associated with the user550that is making the request as well (e.g., a user identifier). The user550may include the unmanned vehicle105/200, the remote monitor120/400, a third-party computing system (e.g., a computing device associated with a flight controller, an insurance company, a flight manager, a software tools developer, or any other third-party that would want risk assessed for a particular unmanned vehicle or operation of unmanned vehicles in a particular location), or any other user that would be apparent to one of skill in the art in possession of the present disclosure.

In various embodiments, the navigation path information may include a plurality of navigation path segments that are defined two or more vectors. For example, each navigation path segment may include points in the environment102that are each defined by longitude and latitude; a volume in the environment102that is defined by longitude, latitude, and altitude; a time vector in combination with the point or volume, or any other vector that would be apparent to one of skill in the art in possession of the present disclosure. In some embodiments, navigation path information includes a set of defined geospatial-geotemporal points (e.g., one or more geospatial-geotemporal points) that define path segments. In some embodiments, the model interpreter service305may perform the segmenting of the navigation path. Each navigation path segment may include its own set of navigation path information. However, it is contemplated that the unmanned vehicle105/200or the remote monitor120/400may perform the segmenting of the navigation path prior to providing the navigation path request.

The method500may then proceed to operation504where a risk model is selected from a plurality risk models based on the navigation path information. In an embodiment, at operation504, the model interpreter service305may select a risk model (e.g., any of the risk models317a-317n, or any other risk model in the risk model repository317). The risk model may be selected based on the navigation path information received. For example, the user identifier may be used to identify a particular risk model for a particular user. In other examples, a risk model may be selected based on a location of the navigation path. In other examples, a risk model may be selected based on a type or a make of the unmanned vehicle105/200, the jurisdiction of the environment specified in102, or any combination of the information provided in the navigation path information received in the navigation path risk request. As illustrated inFIG.5, operation504may include querying the risk model repository317included in the storage system314and retrieving the risk model from the risk model repository317based on the navigation path information.

In some embodiments, a risk model may be selected for each navigation path segment of the navigation path based on the set of navigation path information for each navigation path segment. As such, for each navigation path provided to the model interpreter service305, one or more risk models may be selected and each navigation path segment may be analyzed individually based on its corresponding selected risk model, as discussed further below.

In various embodiments, prior, during, or subsequent to the method500and represented in operation506, the risk model A and up to the risk model N may have been provided by a risk authority554to the model interpreter service305. However, it is contemplated that any of the users550may be considered a “risk authority” or provide a risk model to the model interpreter service305. The risk authority554may include a researcher, a regulator, a university, an insurance company, or any other individual expert or trusted entity. The risk model may then be stored via the model hosting service306in the risk model repository317provided by the storage system314.

The risk models317a-317nmay include a variety of risk models. For example, the risk models317a-317nmay include a Bayesian belief network that determines a likelihood of bad outcomes, severity of bad outcomes, risk factors or any other probabilistic result. As such, the risk models317a-317nmay include root nodes that are not dependent on any other state/node and that have a probability distribution based on prior probabilities given prior knowledge/beliefs, intermediate nodes that are proximate causes of outcomes and conditional dependent on other events that are represented in conditional probability tables, and terminal nodes where the probabilities of these events are outputs of the network and provided by conditional probability tables.

The root nodes may ingest data from the navigation path information or from data sources local or remote to the unmanned vehicle risk assessment service platform300. The terminal nodes may output a risk metric.FIGS.6A and6Billustrate an example risk model600. The risk model600may include an FAA FRAT risk model. The risk model600may include a plurality of navigation path information inputs602that require inputs provided by the navigation path information. The risk model600may provide a plurality of data source information inputs604. The inputs may be used to calculate a probability of a midair collision in the terminal node606.FIGS.7A-7Cillustrate another example risk model700. The risk model700may include a JARUS SORA risk model. The risk model700may include a plurality of navigation path information inputs702that require inputs provided by the navigation path information. The risk model700may also provide a plurality of data source information inputs704. The inputs may be used to calculate a probability of human casualty in the terminal node706. While specific examples of risk models600and700are illustrated, one of skill in the art in possession of the present disclosures will recognize that other conventional or future risk models may be contemplated.

The method500may then proceed to operation508where data used as one or more inputs to run the risk model is obtained from one or more data sources. In an embodiment, at operation508, the model interpreter service305may determine from the risk model inputs what data is needed to run the selected risk model. The model interpreter service305may determine that some data is required from the navigation path information, the local data source316, the remote caching system312, or a remote data source such as the remote database552. When data is needed from the remote database552or the data source316, the model interpreter service305may provide a relevant operational characteristics request510to the data query service307. The data query service307may forward, at512, that relevant operation characteristics request to the remote database552or data source316. That request may be provided to each data source (e.g., remote or local) that provides the data. At514, the contextual data requested may be returned to the data query service307and provided to the model interpreter service305at516, e.g., subsequent to the normalization of the source data by the data query service307subject to normalization requirements as specified in risk models317a-317nin the system.

In some embodiments, the remote data source provided by one or more remote databases552or the data source316may include a weather data source, a civil twilight data source, a population density data source, a UAS facility map and class airspace data source, a national security UAS flight restricted areas/special use airspace data source, an infrastructure data source (e.g., natural area preserves, state parks, wildlife management areas, bridges, cell towers, ground hazards, correctional facilities), an FAA obstacle data source, a unmanned vehicle profile (e.g., weight, max speed, range, etc.) data source, or any other data source that would be apparent to one of skill in the art in possession of the present disclosure.

In some embodiments, portions of the risk model may be selected based on a risk metric being determined. For example, and with reference toFIG.7B, the risk metric being sought for the navigation path risk request may be a likelihood of a midair collision in node708. As such, the systems and methods of the present disclosure can reduce the computational complexity and computer resource intensive operations of conventional systems that would require a full model and data for the full model to be present. Due to the on-demand/swappable nature of the risk models317a-317nin the system, only data and portions of risk models that are required to satisfy the navigation path risk assessment request are obtained and processed. This lowers the storage and processing footprint of the system and even allows the risk model to be operated by devices such as the unmanned vehicle105or remote monitor120that would otherwise likely not have the storage, processing, or networking resources to store, operate, and obtain data and risk models.

The method500may then proceed to operation518where the risk model is operated with the data to output a risk assessment. In an embodiment, at operation518, the model interpreter service305may operate the risk model or the portion of the risk model identified and obtained with the data obtained from the various data sources (e.g., the navigation path information, data from the remote database552, cached data, or the data from the local data source316). A risk metric may be outputted by operating the risk model. The risk model or risk models may be operated for each navigation path segment of the navigation path and a risk metric may be outputted for that navigation path segment. The risk metrics may be combined or aggregated in a risk assessment which may include an overall risk score/metric or a navigation path map or a graphical user interface indicating the risk metric for each navigation path segment or one or more points along the navigational path segments.FIG.8illustrates an example navigation path map graphical user interface800that includes segments802that are associated with a low-risk metric and segments804that are associated with a medium-risk metric that indicates higher risk than the low-risk metric.

The method500may then proceed to operation520where a navigation path risk response is provided in response to the navigation path risk request that includes the risk assessment that is associated with at least a portion of the navigation path. In an embodiment, at operation520, the model interpreter service305may provide a navigation path risk response to the user550that made the navigation path risk request. However, in other embodiments, the model interpreter service305may provide the navigation path risk response to another user device. In yet other embodiments, the model interpreter service305may include logic to determine instructions or recommendations based on the risk assessment and provide the instructions or recommendations to the user550in the navigation path risk response. For example, the model interpreter service305may determine one or more alternative navigation paths/routes through the environment102that are less risky and provide those alternative paths to the user550.

The method500may then proceed to operation522where an action is performed based on the received navigation path risk response. In an embodiment, at operation522, the user550(e.g., the unmanned vehicle controller204of the unmanned vehicle200or the unmanned vehicle application404of the remote monitor400) may use a risk assessment, a risk metric, a recommendation, an instruction, or any other data provided in the navigation path risk response to perform an action such as determining whether a risk condition is satisfied and performing an action associated with that risk condition. For example, if a risk condition is satisfied, the unmanned vehicle105/200may perform an operational change. In some embodiments, the operational change may be in relation to navigation instructions associated with the navigation path if the risk metric satisfies a risk metric condition. In a specific example, the operational change may include a change in velocity of the unmanned vehicle105/200, ceasing operation of the unmanned vehicle105/200, changing the altitude of the unmanned vehicle105/200, operation of an instrument on the payload unit110, activating or initiating the navigation path, changing the trajectory of the unmanned vehicle105/200such that the unmanned vehicle follows an updated navigation path, or any other operational change that would be apparent to one of skill in the art in possession of the present disclosure.

FIG.9illustrates a specific example of a logical architecture900for the unmanned vehicle risk assessment system100and the method500of unmanned vehicle risk assessment described inFIG.5. The solution architecture includes, in some embodiments, four groups: the system users/consumers902, the constituent data sources904, the model tracking and management server906, and the Model Interpreter Service908. As described inFIG.9, the Risk Authority, in some embodiments, interacts with the API on the Model Interpreter Service to specify and submit a model which is then managed by the model tracking and management server906(MLFlow Tracking Server) and rendered available for loading when a risk assessment against a specific flight plan is requested. The Flight Manager, in some embodiments, (e.g., Operator) or Tools Developer (e.g., OEM) submits a flight plan with model specification as a geoJSON object (or other suitable format, such as KML or XML) against the Model Interpreter Service API. Then, the request is, in some embodiments, handled in the Risk Assessment module, which loads the risk model from the Model Hosting module which specification is then used to forward a contextual data request to the Geospatial Data Aggregation module. The Geospatial Data Aggregation, in some embodiments, formulates the individual data request queries to the distributed data services and normalizes the returned data before passing it back to the Risk Assessment module. The Risk Assessment module, in some embodiments then, calculates the risk assessment for the proposed operation and then passes the risk topology back to the Model Interpreter Service API. The API, in some embodiments, segments and packages the risk assessed, segmented operation and returns it to the Flight Manager or Tools developer as a geoJSON (or other suitable format, such as KML or XML).

Thus, systems and methods have been presented that provide for an unmanned vehicle risk assessment system that provides a plurality of risk models that may be swappable depending on the circumstances of an unmanned vehicle risk assessment request. The system may obtain only the data that is necessary to operate the risk mode and lightweight such that the risk assessment can occur in near real-time such that risk assessment can be performed during operation of the unmanned vehicle. As location or other variables as of unmanned vehicle changes, different risk models may be applied to help an operator or the unmanned vehicle to determine risk and make adjustments to the operation of the unmanned vehicle. As such, processing resources, network resources and storage resources are reduced and safety of unmanned vehicles is enhanced thus improving the operation of unmanned vehicles and autonomous vehicles.

FIG.10is a diagram that illustrates an exemplary computing system1000in accordance with embodiments of the present technique. Various portions of systems and methods described herein, may include or be executed on one or more computer systems similar to computing system1000. For example, unmanned vehicle105/200, the unmanned vehicle risk assessment service platform130/300, or the remote monitor120/400may include the computing system1000. Further, processes and modules described herein may be executed by one or more processing systems similar to that of computing system1000.

Computing system1000may include one or more processors (e.g., processors1010a-1010n) coupled to system memory1020, an input/output I/O device interface1030, and a network interface1040via an input/output (I/O) interface1050. A processor may include a single processor or a plurality of processors (e.g., distributed processors). A processor may be any suitable processor capable of executing or otherwise performing instructions. A processor may include a central processing unit (CPU) that carries out program instructions to perform the arithmetical, logical, and input/output operations of computing system1000. A processor may execute code (e.g., processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof) that creates an execution environment for program instructions. A processor may include a programmable processor. A processor may include general or special purpose microprocessors. A processor may receive instructions and data from a memory (e.g., system memory1020). Computing system1000may be a uni-processor system including one processor (e.g., processor1010a), or a multi-processor system including any number of suitable processors (e.g.,1010a-1010n). Multiple processors may be employed to provide for parallel or sequential execution of one or more portions of the techniques described herein. Processes, such as logic flows, described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating corresponding output. Processes described herein may be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Computing system1000may include a plurality of computing devices (e.g., distributed computer systems) to implement various processing functions.

I/O device interface1030may provide an interface for connection of one or more I/O devices1060to computer system1000. I/O devices may include devices that receive input (e.g., from a user) or output information (e.g., to a user). I/O devices1060may include, for example, graphical user interface presented on displays (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, or the like. I/O devices1060may be connected to computer system1000through a wired or wireless connection. I/O devices1060may be connected to computer system1000from a remote location. I/O devices1060located on remote computer system, for example, may be connected to computer system1000via a network and network interface1040.

Network interface1040may include a network adapter that provides for connection of computer system1000to a network. Network interface1040may facilitate data exchange between computer system1000and other devices connected to the network. Network interface1040may support wired or wireless communication. The network may include an electronic communication network, such as the Internet, a local area network (LAN), a wide area network (WAN), a cellular communications network, or the like.

I/O interface1050may be configured to coordinate I/O traffic between processors1010a-1010n, system memory1020, network interface1040, I/O devices1060, and/or other peripheral devices. I/O interface1050may perform protocol, timing, or other data transformations to convert data signals from one component (e.g., system memory1020) into a format suitable for use by another component (e.g., processors1010a-1010n). I/O interface1050may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.

Embodiments of the techniques described herein may be implemented using a single instance of computer system1000or multiple computer systems1000configured to host different portions or instances of embodiments. Multiple computer systems1000may provide for parallel or sequential processing/execution of one or more portions of the techniques described herein.

In this patent, to the extent any U.S. patents, U.S. patent applications, or other materials (e.g., articles) have been incorporated by reference, the text of such materials is only incorporated by reference to the extent that no conflict exists between such material and the statements and drawings set forth herein. In the event of such conflict, the text of the present document governs, and terms in this document should not be given a narrower reading in virtue of the way in which those terms are used in other materials incorporated by reference.

The present techniques will be better understood with reference to the following enumerated embodiments:1. A method, comprising: receiving, by a computer system, a first navigation path risk request that includes first navigation path information associated with a first navigation path for a first unmanned vehicle through a first environment; selecting, by the computer system, a first risk model from a plurality of risk models based on the first navigation path information; obtaining, by the computer system, first data used as one or more inputs to run the first risk model from one or more data sources; operating, by the computer system, the first risk model with the first data to output a first risk metric; and providing, by the computer system, a first navigation path risk response in response to the first navigation path risk request that includes the first risk metric that is associated with at least a portion of the first navigation path.2. The method of embodiment 1, wherein the providing the first navigation path risk response causes the first unmanned vehicle to perform a navigation instruction change in relation to navigation instructions associated with the first navigation path if the first risk metric satisfies a first risk metric condition.3. The method of any one of embodiments 1 and 2, further comprising: receiving the first risk model from a first risk authority; and receiving a second risk model of the plurality of risk models from a second risk authority.4. The method of any one of embodiments 1-3, further comprising: caching, by the computer system, the first data on a local memory system; and discarding, by the computer system, the first data from the local memory system in response to a discard condition begin satisfied, wherein the obtaining the first data from the one or more data sources includes obtaining at least a first portion of the first data from the local memory system.5. The method of embodiment 4, wherein the obtaining the first data from the one or more data sources includes obtaining at least a second portion of the first data over a network from one or more external databases.6. The method of any one of embodiments 1-5, wherein the obtaining the first data from the one or more data sources includes obtaining at least a portion of the first data over a network from one or more external databases.7. The method of any one of embodiments 1-6, wherein the first risk metric is associated with a first segment of a plurality of segments of the first navigation path.8. The method of embodiment 7, wherein first segment information associated with the first segment is included in at least one of the first navigation path information for selecting the first risk model or the first data for operating the first risk model.9. The method of embodiment 7, further comprising: operating, by the computer system, the first risk model with the first data to output a second risk metric, wherein the second risk metric is associated with a second segment of the first navigation path.10. The method of embodiment 9, further comprising:aggregating, by the computer system, the first risk metric, the second risk metric, and risk metrics for others of the plurality of segments into a navigation path risk metric for the first navigation path.11. The method of embodiment 7, wherein the first segment is defined by at least two vectors.12. The method of embodiment 7, wherein the first segment is defined by at least three vectors.13. The method of embodiment 7, wherein the first segment is defined by at least four vectors.14. The method of embodiment 13, wherein the at least four vectors include a time vector, an altitude vector, a longitude vector, and a latitude vector.15. The method of any one of the embodiments 1-14, further comprising: receiving, by the computer system, a second navigation path risk request that includes second navigation path information associated with a second navigation path for a second unmanned vehicle through the first environment; selecting, by the computer system, a second risk model from the plurality of risk models based on the second navigation path information; obtaining, by the computer system, second data used as one or more inputs to run the second risk model from the one or more data sources; operating, by the computer system, the second risk model with the second data to output a second risk metric; and providing, by the computer system, a second navigation path risk response in response to the second navigation path risk request that includes the second risk metric that is associated with at least a portion of the second navigation path.16. The method of any one of embodiments 1-15, further comprising: receiving, by the computer system, a second navigation path risk request that includes second navigation path information associated with the first navigation path for the first unmanned vehicle through the first environment; selecting, by the computer system, a second risk model from the plurality of risk models based on the second navigation path information; obtaining, by the computer system, second data used as one or more inputs to run the second risk model from the one or more data sources; operating, by the computer system, the second risk model with the second data to output a second risk metric; and providing, by the computer system, a second navigation path risk response in response to the second navigation path risk request that includes the second risk metric that is associated with at least a portion of the first navigation path.17. The method of any one of embodiments 1-16, further comprising: segmenting, by the computer system, the first navigation path into a first segment and a second segment; selecting, by the computer system, a second risk model from the plurality of risk models based on second segment information for the second segment included in the first navigation path information, wherein the selecting the first risk model from the plurality of risk models is based on first segment information for the first segment included in the first navigation path information; obtaining, by the computer system, second data used as one or more inputs to run the second risk model from the one or more data sources; operating, by the computer system, the second risk model with the second data to output a second risk metric; and providing, by the computer system, in the first navigation path risk response that includes the second risk metric that is associated with the second segment, wherein the first risk metric is associated with the first segment.18. The method of any one of embodiments 1-17, further comprising: segmenting, by the computer system, the first navigation path into a first segment and a second segment; determining, by the computer system, second data associated with the second segment used as one or more inputs to run a second risk model of the plurality of risk models, wherein the first data is associated with the first segment; obtaining, by the computer system, obtaining, by the computer system, second data used as one or more inputs to run the second risk model from the one or more data sources, wherein the first data is associated with the first segment; operating, by the computer system, the second risk model with the second data to output a second risk metric; and providing, by the computer system, in the first navigation path risk response that includes the second risk metric that is associated with the second segment, wherein the first risk metric is associated with the first segment.19. The method of any one of embodiments 1-18, wherein the operations further comprise steps for obtaining the first data used as the one or more inputs to run the first risk model from the one or more data sources.20. A non-transitory, machine-readable medium storing instructions that, when executed by one or more processors, effectuate operations comprising: receiving, by a computer system, a first navigation path risk request that includes first navigation path information associated with a first navigation path for a first unmanned vehicle through a first environment; selecting, by the computer system, a first risk model from a plurality of risk models based on the first navigation path information; obtaining, by the computer system, first data used as one or more inputs to run the first risk model from one or more data sources; operating, by the computer system, the first risk model with the first data to output a first risk metric; and providing, by the computer system, a first navigation path risk response in response to the first navigation path risk request that includes the first risk metric that is associated with at least a portion of the first navigation path.