Advanced flight processing systems and / or methods

Abstract

A method may include: determining sensor information using an aircraft sensor suite; determining flight commands based on the sensor information using a set of models; confirming the flight commands (S130); and facilitating execution of the confirmed flight commands. The method may optionally include generating a trained model. However, the method (S100) may additionally or alternatively include any other suitable elements. The method may be used to facilitate aircraft control based on autonomously generated flight commands. The method may additionally or alternatively be used to implement human-in-the-loop autonomous aircraft control, and / or may be used to generate a trained neural network based on confirmation of autonomously generated aircraft flight commands.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 235,043, filed on August 19, 2021, which is incorporated herein by this reference in its entirety. Technical Field

[0003] The present invention relates generally to the field of aviation, and more particularly to a new and useful flight processing system and / or method in the field of aviation. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a flow chart diagrammatic representation of a variation of a method.

[0006] Figure 2 is a schematic representation of a variation of the system.

[0007] Figure 3 are schematic illustrations of variations of the systems and / or methods.

[0008] Figure 4 are example representations of variations of the systems and / or methods.

[0009] Figure 5 are example representations of variations of the systems and / or methods.

[0010] Figure 6 is an example representation of systems within aircraft 102 .

[0011] Figure 7 is a schematic representation of an example of aircraft control using a system example.

[0012] Figure 8 is a flow chart of an example of flight command validation in a variation of the method.

[0013] Fig. 9 are schematic illustrations of variations of the systems and / or methods.

[0014] Fig.10 is a schematic representation of an example of aircraft control using a system example.

[0015] Description of the Preferred Embodiments

[0016] The following description of the preferred embodiments of the invention is not intended to limit the invention to those preferred embodiments, but rather to enable any person skilled in the art to make and use the invention.

[0017] 1. Overview

[0018] Method S100 (an example of which is shown in Figure 1) may include: determining sensor information S110 using an aircraft sensor suite; determining a flight command S120 based on the sensor information using a set of models; validating the flight command S130; and facilitating execution of the validated flight command S140. The method may optionally include generating a trained model S150. However, the method S100 may additionally or alternatively include any other suitable elements. The method is preferably used to facilitate aircraft control based on autonomously generated flight commands (e.g., in a provable, fault-tolerant and / or failure resilient manner). The method may additionally or alternatively be used to implement human-in-the-loop autonomous aircraft control, and / or may be used to generate a trained neural network based on validation of autonomously generated aircraft flight commands.

[0019] System 100 (an example of which is shown in Figure 2 ) may include: a lower assurance system 110 and a higher assurance system 120. However, the system 100 may additionally or alternatively include any other suitable set of components.

[0020] In an illustrative example, method S100 may include: receiving an ATC audio stream, converting the ATC audio stream into an ATC text, and providing the ATC text and a predetermined set of queries to a question-answering model of the ATC adjustment, which analyzes the ATC text for query answers. Then, the query answer can be used to select a subsequent query and / or fill in a command parameter value. The ATC audio stream can be converted into an ATC text using an integrated sentence boundary detection and automatic speech recognition model of the ATC adjustment and a language model of the ATC adjustment, wherein an utterance hypothesis for inclusion in the ATC text can be selected based on a joint score from an SBD / ASR model and a language model. The command parameter value can be converted into a (verified) human-readable format (e.g., within a certified processing system; within a fault resilience processing system; deterministically; with triple redundant processing; etc.) using a command application protocol interface (API), and the command parameter value is relayed to a pilot-in-command (PIC), such as a pilot on an aircraft and / or a remote operator (e.g., via satellite, RF, cellular and / or other remote communications). The PIC may then confirm and / or modify the command (e.g., certified; resilient to failure conditions; within a higher assurance system; etc.) via the pilot interface, and the confirmed command may be used to control the aircraft via a certified / certifiable flight management system (FMS) and / or a certified / certifiable flight control system (FCS).

[0021] In a second illustrative example, method S100 may include determining imaging data and / or aircraft state data via an aircraft sensor suite. The imaging data and aircraft state data may be used by an AI / ML-based engine (e.g., uncertified or specifically certified, relying on multi-core processing, within a lower assurance system, etc.) that may perform detection, classification, tracking, and generation of resolution advisories (e.g., advisory actions in the form of command parameter values) of collision threats. The command parameter values ​​may be converted into a (validated) human-readable format (e.g., within a certified processing system; within a higher assurance system; deterministically; with triple redundant processing; etc.) using a command API, and the command parameter values ​​may be relayed to a pilot in charge (PIC), such as a pilot on board an aircraft or a remote operator (e.g., via satellite / RF telematics). The pilot may then confirm and / or modify the command (e.g., certified; resilient to failure conditions; within a higher assurance system; etc.) via the pilot interface, and the confirmed command may be used to control the aircraft via a certified / certifiable flight management system (FMS) and a certified / certifiable flight control system (FCS).

[0022] The system can be operated on any suitable vehicle. The vehicle is preferably an aircraft, such as a fixed-wing aircraft, a rotorcraft, a tilt-rotor aircraft, a tilt-propeller aircraft, a tilt-wing aircraft, a helicopter or a jet aircraft, but can additionally or alternatively be a spacecraft (e.g., a rocket, a satellite), a watercraft (e.g., a boat, a submarine, a hovercraft), a land vehicle (e.g., a train, a car, a bus, a tank, a truck, etc.), and / or any other suitable vehicle. It should be understood that all references to "aircraft" or "aviation" herein can be equally applicable to any other suitable vehicle or mode of transportation.

[0023] The system 100 and / or portions thereof (such as the higher assurance system 120) may be certified and / or integrated into a certified aircraft. Additionally or alternatively, one or more portions of the system (such as the lower assurance system 110) may be uncertified (or specially certified), isolated from the rest of the aircraft (e.g., via physical partitioning, virtual partitioning, software partitioning, and / or any other suitable partitioning), certified as a flight aid or flight assistive device, and / or may be implemented in other ways.

[0024] In a first example, the higher assurance system is separated from the lower assurance system in accordance with the ARINC 653 standard (Software Specification for Spatial and Temporal Partitioning in Safety Critical Avionics Real-Time Operating Systems (RTOS)) and / or using an ARINC 653 platform. In a second example, the higher assurance system is physically separated from the lower assurance system via physical hardware separation (e.g., physically separated hardware systems; hardware systems in separate physical enclosures; hardware systems separated by firewalls; etc.).

[0025] In some variations, the design assurance level (DAL) of the higher assurance system 120 is higher than the design assurance level of the lower assurance system 110. In an example, the higher assurance system may be a high DAL system that is DO-178 compliant, tested, and / or certified (e.g., whereas the lower assurance system may be a low DAL system that is uncertified, specially certified, and / or not governed by the same regulatory guidelines). Alternatively, the assurance and / or resilience of the higher assurance system 120 may be greater than the assurance and / or resilience of the lower assurance system due to fault resilience (and / or fault tolerance), computational structure (e.g., a higher assurance system may be single-core while a lower assurance system may be multi-core), testability, auditability, input constraints (e.g., inputs to a higher assurance system may be subject to greater verification and / or validation, inputs to a lower assurance system may be essentially infinitely variable, etc.), model-based computational structure, certification level (e.g., under any appropriate regulatory guidance), relative criticality (e.g., FMEA considerations), security (e.g., encryption standards, program edit or update accessibility, etc.), and / or the assurance of the higher assurance system may otherwise exceed the assurance of the lower assurance computing system (e.g., by any combination of the above assurance considerations). However, the assurance of the higher assurance system 120 may be greater relative to the lower assurance system 110 in other ways.

[0026] In a first example, a higher assurance system may be designed to address critical failure conditions (eg, to support type certification). In a second example, a lower assurance system may be a flight aid.

[0027] 2. Benefits

[0028] Variations of this technique may provide several benefits and / or advantages.

[0029] First, a variation of the technique may enable certifiable control of an aircraft using an autonomous agent. The autonomous agent may utilize non-certifiable (or non-directly certifiable) hardware and / or software components, such as a multi-core processor, a set of advanced models (e.g., neural networks, machine learning [ML] models, etc.), and / or other forms of advanced processing that are separate / partitioned from the main aircraft hardware / software (e.g., physically separated by hardware partitions, separated via software firewalls, etc.; via partition 105). In such a variation, the autonomous agent may be configured to convert a set of arbitrary (or unstructured) sensor inputs into a finite set of commands that may be validated and / or executed in a deterministic "man-in-the-loop" control scheme. For example, incoming audio data signals (such as from an ATC radio stream) and / or sensory data (e.g., radar returns, camera images, lidar point clouds, etc.) may be essentially unrestricted (e.g., unstructured), infinitely variable, and / or uncontrolled; and it may be very difficult or impossible to specify exactly how the advanced processing system responds to all sensor inputs (e.g., in order to certify the entire system).

[0030] Second, the variants can reduce the cognitive load on the pilot in safety-critical and / or stressful situations because they can provide continuous enhancement and / or command generation during some or all periods of aircraft operation. As an example, the pilot can be relied upon to confirm responses to air traffic control (ATC) audio rather than interacting directly with ATC. As a second example, the pilot can be relied upon solely to determine decision-making suggested actions (for obstacles / hazards) rather than directly generating / controlling responses. As a third example, the aircraft can fully automate the landing of the aircraft (e.g., with minimal or no pilot intervention) as directed by visual flight rules. However, the variants can otherwise reduce the cognitive load on the pilot and / or otherwise appropriately automate / enhance aircraft control.

[0031] Third, the variants may enable remote confirmation of (autonomously generated) aircraft commands / operations, which may reduce the number of pilots on board the aircraft. As an example, the system 100 may replace a co-pilot (e.g., where the primary pilot confirms the co-pilot's commands and / or may be used to train the system). In a second example, the system 100 may enable remote operation of a commercial aircraft (e.g., without a human pilot and / or without human passengers).

[0032] However, variations of the technology may additionally or alternatively provide any other suitable benefits and / or advantages.

[0033] 3. System

[0034] System 100 (an example of which is shown in Figure 2 ) may include: a lower assurance system 110 and a higher assurance system 120. However, the system 100 may additionally or alternatively include any other suitable set of components.

[0035] Lower assurance systems (e.g. Figure 3 ) may include an aircraft sensor suite 112 and one or more autonomous engines 114. The lower assurance system is used to generate commands used for aircraft control, such as flight changes or decision recommendations. Preferably, the lower assurance system is uncertified, specially certified, or certified as a flight aid, but may alternatively be designed to meet any suitable certification standard (e.g., a lower design assurance level [DAL] standard). The lower assurance system may include redundant (e.g., triple redundant) power and / or data connections between sources and / or sinks. The lower assurance system components (e.g., computing hardware / processors) may be encapsulated in an enclosure having any suitable protection (such as: electrical grounding and / or EMI shielding, physical firewalls, ingress protection (e.g., IP67 enclosure) and / or any other suitable protection).

[0036] The lower assurance system may optionally include or may be used with an aircraft sensor suite 112 for monitoring the operation of the system and / or receiving sensory input (e.g., ATC audio). The sensor suite may include: communication sensors (e.g., RF receivers, RF transmitters; ATC communications); imaging sensors (such as IR sensors), time of flight sensors (e.g., radar, lidar), optical sensors (e.g., RGB cameras); and aircraft sensors such as: inertial sensors (e.g., accelerometers, gyroscopes, IMUs, magnetometers, etc.), GPS / GNSS, air data sensors, effector sensors (e.g., impedance sensors, Hall effect sensors, optical sensors, audio sensors, position / displacement sensors, force sensors, pressure sensors, encoders, resolvers, proximity sensors, string potentiometers, ultrasonic sensors, and / or any other suitable device that can be configured to monitor / measure effector states); payload sensors; and / or any other suitable sensor.

[0037] In a specific example, the sensor suite may include: three 120° flight radar modules (e.g., collectively providing 360° surround vision for all active flight modes within a 2 km range); four cameras, including two front cameras: (1) a high-resolution 4K front camera with a 60° azimuth × 40° elevation angle (e.g., 5 km range; the tail-mounted front camera can be configured to detect areas beyond the wingtips for greater visibility for ground operations), and (2) a 120° × 80° medium-resolution camera (1 km range), plus two 120° × 80° upward- and downward-facing cameras to detect above and below; a lidar 360° H × 30° V coverage range of up to 120 m (e.g., which enables ground operations).

[0038] In a second example, the sensor suite may include a radio communications system (e.g., an ATC radio) substantially as described in U.S. application Ser. No. 17 / 500,358, filed on October 13, 2021, which is incorporated herein by reference in its entirety.

[0039] In a third example, the sensor suite may include sensors and / or perception systems substantially as described in U.S. application serial number 17 / 674,518, filed on February 17, 2022, which is incorporated herein by reference in its entirety.

[0040] In a fourth example, the sensor suite may include an onboard payload.

[0041] In some variations, the aircraft sensor suite may be part of a lower assurance system (and / or may include non-certified HW components / sensors or specifically certified HW components / sensors) and / or may be certified as part of the aircraft (e.g., ATC radio equipment integrated with the aircraft).

[0042] However, the aircraft sensor suite may include any other suitable sensors.

[0043] The lower assurance system may include an autonomous engine 114 for converting sensor information (e.g., from a sensor suite) into commands for the higher assurance system. The autonomous processing engine may include: a natural language processing (NLP) engine (e.g., adjusted for ATC speech), a collision avoidance engine (e.g., a "detect and avoid" agent based on imaging data), a ground operations engine (e.g., operating under VFR based on imaging data), an emergency management engine, an anomaly detection engine, a contingency planning / navigation engine, and / or any other suitable autonomous engine / function. The lower assurance system may additionally or alternatively include a payload API for determining flight commands based on an uncertified payload (e.g., a high-resolution camera payload that performs a specific mission). The autonomous processing engine may include uncertified hardware and / or software components (such as: a GPU) and / or uncertified multi-core computing hardware, a neural network (e.g., the neural network can be trained and / or updated based on command confirmation), and / or any other suitable elements. The lower assurance system processing may be centralized or distributed. The lower assurance system processing is preferably performed locally (eg, onboard the aircraft), but may additionally or alternatively include any suitable remote (eg, cloud) processing and / or other suitable processing elements.

[0044] In a specific example, a lower assurance system may include a natural language processing (NLP) system for semantic parsing of air traffic control (ATC) audio as described in U.S. application serial number 17 / 500,358, filed on October 13, 2021, which is incorporated herein in its entirety by this reference (and / or may be configured to perform any combination / permutation of the method elements described therein).

[0045] In a second example, a lower assurance system may include an autonomous navigation and / or landing system (aka a ground operating system) as described in 17 / 674,518, filed on February 17, 2022, which is incorporated herein in its entirety by this reference (and / or may be configured to perform any combination / permutation of the method elements described therein).

[0046] In a third example, a lower assurance system may include a payload API configured to determine flight commands and / or flight changes (eg, using an uncertified or specially certified process).

[0047] In a fourth example, the lower assurance system may include an autonomous collision avoidance system.

[0048] In a first set of variations, a processor separate from a higher assurance system is used to execute a lower assurance system. As an example, the higher assurance system and the lower assurance system can be separated by a partition 105 (such as a hardware-software (HW-SW) partition). Alternatively, the lower assurance system can be executed using partitioned computing of a higher assurance processing system (e.g., a single processor can include parts of both a higher assurance system and a lower assurance system, where a software partition exists between the higher assurance system and the lower assurance system). The software partition can be a logical partition, a memory partition, a disk partition, a different computing space instance (e.g., different containers, virtual machines, etc.), a firewall, and / or any other suitable software-implemented partition. However, the lower assurance system can be separated from the higher assurance system in other ways, and / or the system can include any other suitable partition or be used with any other suitable partition.

[0049] In variations, the lower assurance system may include an object detection and / or classification module (e.g., as part of a detect and avoid system). In some variations, the flight command may include a decision recommendation based on the object detection / classification. Additionally or alternatively, the flight command (and / or communication to the higher assurance system) may optionally include envelope protection / limiting based on object detection / classification, or otherwise include detected / classified objects in the environment (e.g., a representation of the environment including other aircraft and / or ground obstacles), wherein the higher assurance system may be responsible for object avoidance and / or path planning based on the detected / classified objects.

[0050] However, the lower assurance system may include any other suitable elements.

[0051] The higher assurance system 120 may include a command API 122 and a pilot validation interface 124. The higher assurance system may optionally include (and / or may be used with) a flight management system (FMS) 126 and a flight control system (FCS) 128. However, the higher assurance system may include any other suitable components. The higher assurance system is preferably certifiable and deterministically testable. For example, the higher assurance system may be certified to a high design assurance level (DAL) standard (e.g., a DO-178 software component). However, the higher assurance system may be otherwise certified / certifiable under any other suitable regulatory guidance / procedure.

[0052] The command API is used to confirm command compliance (e.g., before providing them to downstream systems (such as the driver confirmation interface 124)). Additionally or alternatively, the command API can be used to provide commands to the driver confirmation interface (e.g., in response to confirming format compliance; in a human-interpretable and / or human-readable format; in a machine-readable format; etc.). The command API preferably runs on a higher assurance system, but can additionally or alternatively run on a lower assurance system (e.g., where semantic commands can be sent to a higher assurance system) and / or run on any other suitable system. In a first example, the API can confirm that the format of the command matches a predetermined format convention, such as by performing a checksum or other protocol (e.g., a hash function; a cryptographic hash function; etc.), thereby converting the command into a "verified human-readable command" that can be provided to the PIC via the driver confirmation interface. In a second example, the API can transcribe multiple non-null command parameter values ​​into a human-readable format. In a third example, the API can confirm the command value (e.g., "1" is a valid command). However, the higher assurance system may include any other suitable command API.

[0053] The API may optionally transform the command into a human-readable format (e.g., a human-interpretable, semantic format). Alternatively, the command may be transformed into a human-readable format at the driver confirmation interface, received in a human-readable format at the command API (e.g., from a lower assurance system), and / or may otherwise be converted between formats or otherwise processed deterministically by the command API.

[0054] The driver confirmation interface 124 is used to provide human-readable commands (for human confirmation) from the command API to the PIC and receive confirmation (e.g., acceptance of the flight command) or rejection. The driver confirmation interface passes the PIC-confirmed command (PIC validatedcommand) to the FMS to facilitate execution according to S140. The driver confirmation interface can additionally or alternatively provide confirmation feedback to the lower assurance system (e.g., it can be used as a state input for various autonomous agents; it can be used to update the model according to S150). In a first variant, the driver confirmation interface can receive input in the form of a binary (confirm / reject) input. In a second variant, the driver confirmation interface can receive a text string and / or an audio signal (e.g., command modification, etc.) from the PIC. However, the PIC can confirm the command in other ways and / or can include any other suitable driver confirmation interface.

[0055] The optional FMS 126 and / or FCS 128 may be used to facilitate execution of PIC-confirmed commands from the pilot confirmation interface according to S140. In a variation, the FMS and / or FCS may be integrated into an existing certified aircraft (e.g., where the system 100 is implemented as an aircraft retrofit). Alternatively, the FMS and / or FCS may be integrated into the system 100 as a certified retrofit package. However, the system may facilitate execution of PIC-confirmed commands from the pilot confirmation interface in other ways.

[0056] In a variation, the higher assurance system 120 includes only certified components and / or processing elements. The higher assurance system preferably includes: a single core processor that performs deterministic operations and repeatable test operations; triple redundant power and / or data connections; and / or may be configured according to any other suitable set of certification requirements. In a specific example, the higher assurance system may be separated from the lower assurance system (e.g., according to the ARINC 653 standard; via partition 105; etc.).

[0057] In variations, operational checklists, confirmation / validation protocols, and / or other processes may be encoded within a higher assurance system. For example, a takeoff procedure and / or flight command confirmation (eg, at an API) may be encoded within a higher assurance system and / or higher assurance process.

[0058] However, the system may include any other suitable higher assurance system.

[0059] In some variations, there may be multiple (redundant) lower assurance modules that handle the same or similar autonomous functions. For example, multiple different / redundant autonomous engines may generate flight commands (e.g., synchronously, asynchronously, simultaneously, etc.) to accommodate the same external factors and / or emergency scenarios. In this case, the higher assurance system may handle voting and / or robust fusion of multiple commands received from different autonomous engines in the set (e.g., between contemporaneous commands, between commands received by parallel communication paths, etc.). For example, the lower assurance system may include two different ATC NLP modules: such as a model-based natural language processor and a syntax-based natural language processor, where the higher assurance system may handle voting / fusion between different NLP modules. In addition, the system may include any suitable communication and / or processing redundancy between the lower assurance system and the higher assurance system. In variations, the system may include triple redundancy (e.g., triple-triple redundancy) of communication and / or processing between the lower assurance system and the higher assurance system. For example, the autonomic engine may be triply redundant (e.g., multiple lower assurance computing systems performing the same operation / function), with command voting / fusion being performed at the higher assurance system. As a second example, the communication channel may be triply redundant (e.g., three different communication paths) between the lower assurance system and the higher assurance system, with signal voting being performed at the higher assurance system.

[0060] However, the systems and / or methods may include any other suitable communication and / or processing redundancy, which may be allocated between the lower assurance system and the higher assurance system in any suitable manner.

[0061] However, the system may include any other suitable components.

[0062] 4. Methods

[0063] Method S100 (an example of which is shown in Figure 1 ) may include: determining sensor information S110 using an aircraft sensor suite; determining a flight command S120 based on the sensor information using a set of models; confirming the flight command S130; and facilitating execution of the confirmed flight command S140. The method may optionally include generating a trained set of models S150. However, the method S100 may additionally or alternatively include any other suitable elements. The method is preferably used to facilitate aircraft control based on autonomously generated flight commands (e.g., in a certifiable and / or high assurance manner). The method may additionally or alternatively be used to implement human-in-the-loop autonomous aircraft control, and / or may be used to generate a trained neural network based on confirmation of autonomously generated aircraft flight commands.

[0064] The method and / or its sub-elements may be executed once, repeatedly, continuously, periodically, aperiodically, in response to satisfying an event trigger (e.g., pilot input, remote request, satisfying a navigation condition, initiating an aircraft mission, etc.), and / or at any other suitable frequency / timing. The method elements may be executed synchronously, simultaneously (e.g., with a common time interval, with different intervals), asynchronously, sequentially / serially, iteratively, in response to an event trigger, and / or at any other suitable timing / relationship.

[0065] Determining sensor information S110 using an aircraft sensor suite is used to provide input that can be used to determine flight commands (e.g., using an autonomous agent and / or via advanced processing techniques). The sensor information may include: audio data (e.g., received at a communication system such as an ATC radio), imaging data (e.g., from an IR camera, RGB camera, radar, lidar, etc.), aircraft status data, payload data (e.g., which may be generated by an onboard payload and parsed via a payload-specific API), and / or any other suitable information. The sensor information may be determined in the following ways: continuously, periodically (e.g., at a specified data rate), synchronously or asynchronously across multiple sensor categories (of the various sensors of the sensor suite), in response to an event trigger (e.g., receiving an ATC utterance), and / or at any other suitable timing / frequency. The sensor information may include: raw sensor data, pre-processed data (e.g., raw flight time data, flight time detection, etc.), filtered data, unfiltered data, and / or any other suitable sensor information.

[0066] The sensor information may be unstructured and / or substantially infinitely variable. In variations where the lower assurance system receives sensor data including unstructured information, the lower assurance system may include a set of pre-trained neural networks configured to autonomously determine flight commands in a predetermined, machine-readable format from the unstructured information. For example, the sensor information may include ATC audio or text strings that have no predetermined syntactic structure.

[0067] However, the sensor information may also be suitably determined in other ways.

[0068] Based on the sensor information, a set of models are used to determine flight commands S120 for determining flight commands based on the sensor information, which can be used to facilitate aircraft control according to S140. S120 is preferably performed at a lower assurance system, and the flight commands are subsequently confirmed (and / or executed) by a higher assurance system (e.g., Figure 7 An example is shown in ).

[0069] Flight commands can be semantic commands, such as high-level guidance commands or flight changes (e.g., "increase speed by 10 knots," "turn left heading zero ninety degrees," etc.), decision advice (e.g., navigation and / or guidance instructions to avoid an imminent collision), flight guidance parameters (e.g., altitude: 2000), absolute commands (e.g., "set altitude to two thousand"), relative commands (e.g., "descend one thousand feet," "reduce airspeed by ten knots"), and / or any other suitable commands.

[0070] Each flight command preferably includes a data format and a set of values. The flight commands preferably follow a strict predetermined format, but may alternatively have any data format. Different flight commands may have the same or different formats that may be specified to support authentication or otherwise processed. The flight commands may be human-readable (or its equivalent, such as a computer-readable ASCII string, which may be considered interchangeable with a corresponding human-readable semantic string), in a computer-readable format (e.g., JSON), and / or processed in any other suitable data format (e.g., flight path trajectory, waypoint coordinates, etc.).

[0071] The flight command value (e.g., the flight command content) is preferably selected from a predetermined set of values, but may alternatively be dynamically determined or otherwise restricted or unrestricted. In a variation, the set of values ​​and / or the range of values ​​may be specified (e.g., to support certification and / or fixed as part of certification) and / or predetermined, or may be processed in other ways. Examples of values ​​may include allowed parameter values ​​for a given command type (such as a flight change or decision proposal). Allowed parameter values ​​may be specified by a regulatory agency, by an aircraft (e.g., by the physical limitations of the aircraft, by flight actuator resolution, etc.), manually determined and / or otherwise specified. In a first variation, the flight command includes a template that includes a series of one or more parameters, wherein the parameter values ​​may be determined by a set of models. For example, a flight change template may include "ADJUSTMENT speed VALUE knots", wherein "ADJUSTMENT (adjustment)" may be selected from a group including "increase (increase)", "maintain (maintain)" and "decrease (decrease)", and "VALUE (value)" may be selected from a group including 0-200. In a second variation, the set of values ​​includes every achievable combination of possible parameter values, wherein the model selects one combination as the flight command. For example, the set of values ​​includes every permutation of "ADJUSTMENT speed VALUE knots", wherein "ADJUSTMENT" is selected from the group consisting of "increase" and "decrease", and "VALUE" is selected from the group consisting of 0-200. However, the flight command values ​​may be configured in other ways.

[0072] A set of models for generating flight commands ( Figure 5 An example is shown in ) may include: an NLP engine (e.g., adjusted for ATC utterances; which may include: a multi-query question / answer model, an ASR model, an SBD model, a language model, and / or any other suitable neural model; Figure 4 Examples are shown in ), collision avoidance engines (e.g., a "see and avoid" engine, which may include: object detectors, object classifiers, object trackers, object avoidance models, etc.), ground operation engines (e.g., which may include feature detectors and / or landing site identifiers, etc.), and / or any other suitable models. The set of models may include: neural networks (e.g., deep neural networks; CNN, RNN, FCN, ANN), cascades of neural networks, Bayesian networks, Markov chains, predetermined rules, probability distributions, heuristics, probabilistic graphical models, classifiers (e.g., binary classifiers, multiclass classifiers), or other models.

[0073] In operation, S120 may include: analyzing sensor information using one or more models. When the model generates multiple candidate outputs, such as when a multi-class classifier is used, S120 may optionally include selecting an output value (e.g., a flight command value) from the set of candidate outputs. The output value may be selected using a decision tree, a confidence score associated with the candidate output, a precision or accuracy of the candidate output (e.g., determined from a covariance or variance), and / or in other ways. S120 preferably outputs a single flight command for a given command type (e.g., a flight change, a decision recommendation, etc.), but may alternatively output a single flight command for each model at any point in time, output multiple flight commands of a given command type simultaneously from a lower assurance system, output multiple flight commands simultaneously from each model, and / or output any other suitable number of flight commands with any other suitable timing.

[0074] In a first variant, S120 may include using an NLP engine to: receive an ATC audio stream, convert the ATC audio stream into ATC text, and provide the ATC text and a predetermined set of queries to an ATC-adjusted question-answering model that analyzes the ATC text for query answers. The query answers may then be used to select subsequent queries and / or fill in command parameter values. The ATC audio stream may be converted into ATC text using an ATC-adjusted integrated sentence boundary detection and automatic speech recognition model and an ATC-adjusted language model, where a discourse hypothesis for inclusion in the ATC text may be selected based on a joint score from an SBD / ASR model and a language model. The command parameter values ​​may be provided to a command application protocol interface (API) (e.g., in a human-readable format) to be confirmed in S130.

[0075] In a second variation, S120 may include using a collision avoidance engine to: detect, classify, and track collision threats (e.g., non-transponder aircraft on a collision course), and generate a recommended course of action in the form of a decision suggestion (e.g., in semantic form; as a flight path trajectory or waypoint, etc.) to allow the own aircraft to avoid the collision without cooperation from the intruder. The decision suggestion may be provided (e.g., in a human-readable format) to a command application protocol interface (API) to be confirmed in S130.

[0076] In a third variation, S120 may include using a ground operations engine to: extract features from sensor information (e.g., lidar and / or optical imaging data); identify a landing site based on the extracted features; optionally locate the aircraft based on the extracted features; and determine flight commands (e.g., flight changes such as course corrections; which may be based on the aircraft position relative to the extracted features) to facilitate navigation to the identified landing site. The flight commands may be provided (e.g., in a human-readable format) to a command application protocol interface (API) to be confirmed in S130.

[0077] S120 and / or elements thereof may be performed continuously, repeatedly, iteratively, in response to receiving (updated) sensor data, in response to satisfying an event trigger (e.g., ATC request, collision threat determination, satisfying an approach / landing threshold, etc.), and / or at any other suitable timing / frequency.

[0078] During one or more operational periods (e.g., where the aircraft may continue to execute a previous flight command, a previous mission plan, and / or a previous set of navigation instructions), S120 may be additionally or alternatively performed without adjusting the flight path and / or generating updated flight commands. As an example, in response to determining that the aircraft is not the intended recipient of the ATC radio utterance, it may be determined that there are no new flight commands (e.g., null flight commands) for the ATC radio utterance (e.g., and / or no flight commands may be provided to a higher assurance system for confirmation in block S130).

[0079] In a first example, S120 may include: utilizing a speech-to-text module of a lower assurance system (e.g., an autonomous computing system) to determine an utterance hypothesis from an ATC audio signal using a first pre-trained neural network model; and utilizing a question-answering (Q / A) module of the lower assurance system to query the utterance hypothesis based on a structured sequence of natural language queries by utilizing a second pre-trained neural network model from a set of pre-trained models, and determining a flight command based on the utterance hypothesis.

[0080] In a second example, where the sensor suite includes a set of time-of-flight sensors and the sensor data includes time-of-flight data from the set of time-of-flight sensors, S120 may include utilizing a lower assurance system (e.g., an autonomous computing system) to: identify features based on the time-of-flight data using a pretrained neural network; and autonomously determine flight commands based on the identified features.

[0081] However, the flight command may also be suitably determined in other ways.

[0082] Validating flight commands S130 is used to generate validated flight commands for aircraft control according to S140. Additionally or alternatively, S130 is used to transform autonomously generated commands into (PIC) validated flight commands (e.g., as an implementation of a "man-in-the-loop" control scheme). The format, structure, substance (e.g., value), provenance (e.g., signature, random number, etc.), and / or any other suitable aspect of the flight commands can be validated. One or more validation methods can be used to validate the flight commands (and / or aspects thereof). Examples of validation methods that may be used include: checksum validation (e.g., position dependent checksum, sum complement validation, fuzzy checksum, etc.), hash-based validation (e.g., comparing a hash determined from a command, such as a hash of a header, a hash of a signature, etc.), data type validation, range and limit validation, structured validation, format checking (e.g., format validation), size checking, check digit validation, cardinality checking, presence checking, and / or any other suitable checking or validation method. Validated flight commands may be relayed to a pilot validation interface for pilot review and / or otherwise managed. Invalid flight commands (e.g., flight commands that do not conform to the format) may be rejected and the system may throw an error (e.g., which may be provided as feedback to a lower assurance system and / or may be provided to the pilot via an error message / indicator); alternatively, the invalid flight command may be re-determined (e.g., by a lower assurance system), an alternative command source may be used to determine the flight command, and / or the invalid flight command may be handled in other ways. In some variations, the command API of the higher assurance system may be separated from the lower assurance system via physical hardware and / or software partitioning (e.g., software firewall; ARINC 653 platform; etc.). In this case, only commands with valid formats may be accepted and / or interpreted by the higher assurance system. However, the format of the flight command may be confirmed in other ways, or exceptions to the prescribed command format may be handled appropriately in other ways.

[0083] Confirming the flight command S130 may include: optionally confirming the flight command at the API; providing the pre-confirmed flight command to the PIC via a pilot confirmation interface; receiving pilot feedback via the pilot confirmation interface; and optionally confirming the flight command based on satisfying a confirmation threshold. The (PIC) confirmed flight command may then be provided to the FMS (and / or FCS) to facilitate execution of the confirmed flight command according to S140. Confirming the flight command at the API may include: (e.g., before providing the flight command at the pilot confirmation interface) confirming the format, structure, and / or substance of the flight command.

[0084] Confirm flight orders (e.g. Figure 8 ) may optionally include confirming the format (or syntax) of the flight command at the API, which is used to regulate the command flow to other parts of the system, and / or to ensure that only meaningful (human-readable) commands are relayed to the pilot. Preferably, the format and / or syntax is confirmed by the command API when it is received from the lower assurance system at the higher assurance system, however, the format may additionally or alternatively be confirmed by a format confirmation module, confirmed at a pilot confirmation interface (e.g., before providing it to the pilot) and / or confirmed using any other suitable system. Confirming the format may include: confirming the syntax according to a set of predetermined heuristics / rules, confirming that one or more (non-null) command parameter values ​​fall within a predetermined range, confirming that the command parameter values ​​fall within the flight envelope (e.g., determined according to a lookup table and / or can be received as dynamic feedback from an FMS based on transient flight control), computational validation of the computational format (e.g., using checksum validation, format validation, etc.), confirming the signature of a lower assurance system (e.g., where the lower assurance system cryptographically signs the flight command or encrypts the flight command), and / or any other suitable validation. In an illustrative example, this may include confirming that the command is in a platform standard format or protocol. In another illustrative example, this may include confirming that the command references a valid call (e.g., a call, endpoint, or function defined by an API). In a variant, confirming the structure, call, and / or parameters of the flight command is performed as a means of confirming the flight command (e.g., at an API; at Figure 7 An example is shown in Figure 8 A portion of the command (a second example is shown in FIG. 1 ) may include: confirming the length of the command, confirming a parameter specified within the command (e.g., "altitude," "heading," etc.), confirming the length of the parameter value specified within the command, and / or confirming any other suitable structural attribute of the command. The structure may be confirmed using any method for confirming a command format, and / or otherwise confirmed.

[0085] Confirming the flight command may additionally or alternatively include confirming the substance of the flight command (e.g., in addition to and / or in lieu of a PIC confirmation). For example, this may include confirming that a parameter value in the command is within an allowed range of values ​​for that parameter, and / or otherwise determining. The substance may be confirmed using any method for confirming a command format, and / or otherwise confirming the substance.

[0086] Confirming the flight command may include providing the flight command to the PIC via a pilot confirmation interface (e.g., for manual confirmation), which allows the pilot to interpret it and make a decision (e.g., accept or reject the flight command; continue with the flight command or a modified version of the flight command; etc.). The flight command may be presented to the PIC at the following times: after format confirmation, independently of format confirmation, before format confirmation, and / or at any other time. The flight command is preferably confirmed automatically and manually (e.g., by the PIC), but may alternatively be confirmed only automatically (e.g., using one or more systems), only manually, and / or otherwise. The flight command value is preferably presented via a pilot confirmation interface, but other data may be provided in addition or alternatively. The flight command may be provided via a visual display, wireless communication to a ground station (e.g., where the PIC is remote relative to the aircraft), an audio signal (e.g., where the command may be read aloud), and / or the flight command may be provided in any other suitable format.

[0087] Confirming the flight command may include receiving driver feedback via a driver confirmation interface. The driver preferably confirms the substance (e.g., content, value, etc.) of the flight command, but may additionally or alternatively confirm the format, confirm the response to the flight command, and / or any other suitable information. Driver feedback may include: confirmation of the flight command (e.g., a flight command confirmed by the PIC), rejection of the flight command (e.g., a flight command rejected by the PIC), modification of the flight command, replacement of the flight command, and / or any other suitable driver feedback. Driver feedback may be received via the same communication mode as provided to the PIC (e.g., wireless signals, receiving audio responses, etc.), or via a different communication mode (e.g., receiving physical touch / button input in the case where the flight command supply is auditory or visual). Driver feedback may be binary (e.g., accept / reject) or non-binary (e.g., implementing a modification, adjustment, or clarification of the flight command). Updated or new flight commands may be received by verbal input, textual input, driver selection of a predetermined set of flight command options (e.g., selecting an icon representing a suboptimal flight command value determined by the model), and / or in other ways. However, driver feedback may be appropriately received in other ways via the driver interface.

[0088] In variations, driver feedback may be received from: an onboard PIC only, a remote PIC only (e.g., in the event of driver incapacitation, in the event of no driver on board the vehicle, in the event of driver non-responsiveness, etc.)—such as may be located at a ground station, or both an onboard PIC and a remote PIC (e.g., multi-factor confirmation); Figure 6 An example is shown in However, driver feedback may be received at any suitable endpoint and / or with any suitable redundancy.

[0089] In a variation, S130 may include, at a higher assurance system (e.g., its pilot confirmation interface): determining a PIC-confirmed flight command based on pilot confirmation (e.g., receipt of confirmation feedback accepting the flight command), or determining a rejected flight command based on pilot rejection (e.g., receipt of a rejection and / or replacement flight command). In either case, the pilot feedback may be relayed to the lower assurance system (e.g., via a command API) to inform generation of future commands. The pilot feedback may additionally or alternatively be used to retrain a model that generates a confirmed command or an invalidated command.

[0090] In some alternative situations, the PIC may not be able to provide feedback via the driver confirmation interface (e.g., such as in the case of PIC incapacity). In this case, confirming the flight command may optionally include confirming the flight command based on satisfying the confirmation threshold, which can be used to automatically confirm the flight command (i.e., determine the confirmed flight command) without PIC feedback. As an example, the driver confirmation interface can automatically confirm / accept the command executed in S140 after a predetermined duration (e.g., 15 seconds, 30 seconds, 1 minute, 5 minutes, etc.) and / or in response to satisfying the confirmation condition (e.g., timer expiration, dynamic threshold, separate determination of driver incapacity, fully autonomous state, violation of control envelope boundary, etc.). As a second example, if the aircraft has exceeded the control envelope (e.g., the duration exceeds the threshold duration), the driver confirmation interface can automatically confirm / accept the command. However, the higher assurance system can implement the confirmation threshold or bypass the PIC in other ways, or can be configured to not (e.g., never) override / bypass the PIC in other ways.

[0091] In a variation, S130 may include (e.g., at the API; before facilitating pilot confirmation using a confirmation interface): automatically confirming adherence to a predetermined, machine-readable data format, automatically confirming the flight command using a hash function or checksum, and / or automatically confirming the flight command based on a flight envelope.

[0092] In some variations, S130 may optionally include PIC confirmation of the command at the lower assurance system, which may be used to (partially) confirm the command before the lower assurance system provides the command to the higher assurance system (e.g., via an API). For example, the PIC may confirm the substance of the command and / or command parameters before confirming the format and / or value range at the API. In a second example, S130 may facilitate pilot-in-the-loop adjustments, in which the pilot may adjust the command and / or provide feedback to the lower assurance system (e.g., at the lower assurance system or the higher assurance system, on either side of partition 105, etc.), which may be used to adjust, modify, and / or update the command before providing it to the higher assurance system and / or executing it in S140.

[0093] In a variant ( Fig. 9 ), the lower assurance system may include a (first) pilot confirmation interface that may be formatted for confirmation at the higher assurance system (e.g., at an API of the higher assurance system; wherein the lower assurance system may be an autonomous flight aid; Fig. 9 The higher assurance system may also confirm the command at the API and / or (second) pilot confirmation interface as part of S130.

[0094] In one variation (e.g., Fig.10 ), the PIC may correct and / or validate the command within a lower assurance system (e.g., in a pilot-aircraft loop configuration where the system may operate as an autonomous flight aid) as part of S130 prior to format validation at the API. For example, when a command and / or a high-level intent associated therewith is processed within a lower assurance system, the PIC may adjust the command and / or a high-level intent associated therewith (e.g., adjust the flight path to increase altitude), and may validate the resulting command parameters / values ​​at the higher assurance system.

[0095] In another variation, a user (e.g., PIC, co-pilot, etc.) may confirm a command output by a lower-assurance system, where the user-confirmed command may be considered a high-assurance command. The user-confirmed command may be passed directly to a flight management system, passed to a higher-assurance system, and / or used in other ways.

[0096] However, the flight command may also be appropriately confirmed in other ways.

[0097] Facilitating the execution of a confirmed flight command S140 is used to implement a traversal of an aircraft based on a confirmed flight command. In a variation, S140 may include modifying a mission plan that includes a set of navigation parameters (such as waypoints) that a flight system (e.g., FMS and FCS) may utilize to control the aircraft from a departure location to a landing location (e.g., based on the aircraft state). In a variation, S140 may include controlling a flight actuator 104 (e.g., via an FMS and / or FCS) to modify the current aircraft state. In a variation, S140 may include controlling the aircraft according to a predetermined mission sequence in response to receiving a flight command (e.g., where the flight command may include an event trigger: such as a PIC validated confirmation that proceeds to a subsequent step of the mission sequence).

[0098] S140 preferably occurs in response to the PIC's (according to block S130) confirmation of the flight command, however execution of the flight command may continue in the following manner: continuously until the command is overwritten by a subsequent flight command, until an event trigger is met (e.g., a predetermined time threshold is met, a predetermined aircraft position is met, etc.; as may be specified by the termination condition of the flight command), and / or any other suitable frequency / timing. Additionally or alternatively, the flight command may be executed once (e.g., a single instance heading correction), repeatedly, and / or may be executed in other appropriate ways.

[0099] However, the flight command may be appropriately executed in other ways.

[0100] Optionally, generating trained models S150 is used to add, refine, update and / or replace a set of models within the lower assurance system. S150 may include receiving driver feedback and / or control feedback at the lower assurance system, which can be stored (e.g., locally or remotely) and used to train / update a neural network model or a machine learning (ML) model. The model can be dynamically modified during the flight mission or not modified during the flight mission, updated by wireless "over-air" updates, static (unmodified) after deployment, and / or can be implemented in other ways. The model can be trained locally (on the aircraft) or remotely (e.g., via cloud processing or processing at a remote data center). In a specific example, the model can be pre-trained (e.g., before the execution of S120, such as during a previous iteration of S150; pre-generated using remote computing; etc.), and can optionally be trained / updated during one or more iterations of the method.

[0101] However, the model may be suitably trained / updated in other ways. Alternatively, the model may be pre-trained (eg, using a previously generated training dataset) and may be static and / or unchanging based on execution according to S100.

[0102] 5. Examples

[0103] In a first variant, at a lower assurance system: the collision avoidance system detects, classifies, and tracks a set of collision threats (e.g., non-transponder aircraft on a collision course), and computes a recommended course of action in the form of a decision recommendation (RA) to allow the own aircraft to avoid the collision without cooperation from the intruder. The RA is passed to an application protocol interface (API) of an authenticated (higher assurance) system controlling the aircraft. The API performs a validation (e.g., checksum; hash function; cryptographic hash function, etc.) to validate the format of the RA command (but not its content). The API passes unconfirmed RA commands (e.g., turn left 30°) to a validation module.

[0104] In a first example of a first variant (e.g., for an aircraft with one onboard PIC and not linked to a ground station; for an aircraft without an onboard pilot and linked to a ground station), a confirmation module displays the text of the RA command to the pilot in charge (PIC). The PIC can be onboard the aircraft or remotely operated from a ground station (GS). The GS can be connected via a line-of-sight (LOS) radio (RF) link or a beyond-line-of-sight (BLOS) satellite link (SATCOM). The PIC accepts or rejects the RA command as an appropriate action heading. This confirmation feedback is provided back to the CA (collision avoidance) system via an API. The RA command accepted (confirmed) by the PIC is passed to the flight management system (FMS) to facilitate the execution of the RA (e.g., execution by the FCS). The FMS can additionally provide feedback to the CA regarding the state of the aircraft (e.g., attitude).

[0105] In a second example of the first variant (e.g., for an aircraft with one onboard pilot and linked to a ground station), the confirmation module displays the text of the RA command to the onboard responsible pilot (PIC). If the PIC responds, the (onboard) PIC accepts or rejects the RA command as the appropriate course of action. This confirmation feedback is provided back to the CA system via the API. If the PIC does not respond to the confirmation request (e.g., within a threshold duration), the confirmation request will be forwarded to a remote ground station (GS). The GS can be connected via a line-of-sight (LOS) radio (RF) link or a beyond-line-of-sight (BLOS) satellite link (SATCOM). If the GS responds to the confirmation request, the confirmation request can be processed when the PIC accepts or rejects the RA command. If neither the PIC nor the GS responds to the confirmation request within a specified time, the system can regard the command as (automatically) confirmed / accepted. The accepted (confirmed) RA command is passed to the flight management system (FMS) to facilitate execution via the FCS. The FMS can additionally provide feedback to the CA about the state (e.g., attitude) of the aircraft. In a third example, the method may include: at a lower assurance system: receiving a set of external inputs, generating a set of outputs (e.g., commands, explanations, etc.) based on the set of external outputs, and passing the set of outputs (e.g., in a machine-interpretable form) to a higher assurance system; wherein the higher assurance system confirms the set of outputs (e.g., format, substance, etc.; in a machine-interpretable form; etc.), optionally presents the set of outputs to a user (e.g., a pilot; in a semantic or human-readable form), optionally receives a confirmation of the outputs by the user, and passes the confirmed set of outputs to a downstream system (e.g., a flight management system, a flight control system, etc.; in a machine-readable form, etc.). In an illustrative example, the lower assurance system may generate a command value of "1", where "1" means "climb"; and pass "1" to the higher assurance system, where the higher assurance system confirms that "1" is a valid command value. The higher assurance system then determines a semantic equivalent of "1" (e.g., "climb"), displays the semantic equivalent of the command to the user, receives a confirmation of the command, and passes the machine-interpretable value (e.g., "1") to the downstream system.

[0106] Alternative embodiments implement the above methods and / or processing modules in a non-transitory computer-readable medium storing computer-readable instructions. Instructions can be executed by a computer-executable component integrated with a computer-readable medium and / or a processing system. The computer-readable medium may include any suitable computer-readable medium, such as RAM, ROM, flash memory, EEPROM, optical device (CD or DVD), hard drive, floppy disk drive, non-transitory computer-readable medium, or any suitable device. The computer-executable component may include a computing system and / or processing system (e.g., including one or more collocated or distributed, remote or local processors) connected to a non-transitory computer-readable medium such as a CPU, GPU, TPU, microprocessor, or ASIC, but the instructions may be executed alternatively or additionally by any suitable dedicated hardware device.

[0107] Embodiments of the systems and / or methods may include every combination and permutation of the various system components and the various method processes, wherein one or more instances of the methods and / or processes described herein may be performed asynchronously (e.g., sequentially), simultaneously (e.g., in parallel), or in any other suitable order by and / or using one or more instances of the systems, elements, and / or entities described herein.

[0108] As those skilled in the art will recognize from the previous detailed description and from the drawings and claims, modifications and changes may be made to the preferred embodiments of the invention without departing from the scope of the invention defined in the appended claims.

Claims

1. An aircraft system, comprising: an autonomous computing system communicatively coupled to a sensor suite on an aircraft, the autonomous computing system comprising a set of pre-trained neural networks, wherein the autonomous computing system is configured to determine flight commands based on sensor data from the sensor suite using the set of pre-trained neural networks; an aircraft computing system separate from and communicatively coupled to the autonomous computing system, the aircraft computing system comprising: A pilot confirmation interface, communicatively coupled to the flight management system FMS, the pilot confirmation interface being configured to: facilitating pilot confirmation of said flight orders in a human interpretable format; and automatically facilitating execution of the flight order via the flight management system (FMS) in response to a pilot confirmation of the flight order, The autonomous computing system is on board the aircraft, and the aircraft computing system is separated from the autonomous computing system by a firewall.

2. The aircraft system according to claim 1, wherein: The sensor data includes unstructured information, wherein the set of pre-trained neural networks is configured to autonomously determine the flight commands from the unstructured information in a predetermined, machine-readable data format.

3. The aircraft system according to claim 2, further comprising: an application programming interface (API) communicatively coupled to the autonomous computing system and the driver confirmation interface, the application programming interface (API) being configured to: receiving the flight command from the autonomous computing system; automatically confirming compliance of the flight order with the predetermined, machine-readable data format; and Based on the automatic confirmation of the flight order's compliance with the predetermined, machine-readable data format, the flight order is provided to the pilot confirmation interface.

4. The aircraft system according to claim 3, wherein: The application programming interface API is also configured to automatically confirm compliance of the flight command with the predetermined, machine-readable data format using a hash function or a checksum.

5. The aircraft system according to claim 3, wherein: The application programming interface API is further configured to automatically validate the flight command based on a flight envelope.

6. The aircraft system according to claim 1, wherein: The human-interpretable format includes a human-readable format, wherein the pilot confirmation interface includes a display, wherein the pilot confirmation interface is configured to provide the flight commands in the human-readable format at the display.

7. The aircraft system according to claim 6, wherein: The pilot confirmation includes: automatically accepting the flight command based on satisfying the confirmation conditions.

8. The aircraft system according to claim 7, wherein: The confirmation condition includes a driver response time threshold.

9. The aircraft system according to claim 1, wherein: The autonomic computing system includes a multi-core processor.

10. The aircraft system of claim 1, wherein: The flight orders include decision recommendations.

11. The aircraft system according to claim 1, wherein: The sensor data includes air traffic control (ATC) audio signals, wherein the autonomous computing system includes: a speech-to-text module configured to determine an utterance hypothesis from the air traffic control (ATC) audio signal using a first pre-trained neural network from the set of pre-trained neural networks; and A question-answering (Q / A) module is configured to determine the flight commands based on the utterance hypothesis using a plurality of natural language queries, wherein the question-answering (Q / A) module is configured to determine the aircraft commands by querying the utterance hypothesis using a second pre-trained neural network in the set of pre-trained neural networks based on a structured sequence of the natural language queries.

12. The aircraft system of claim 1, wherein: The sensor suite includes a set of time-of-flight sensors, and the sensor data includes time-of-flight data from the set of time-of-flight sensors, wherein the autonomous computing system is configured to: identifying features based on the time-of-flight data using a pre-trained neural network from the set of pre-trained neural networks; and The flight commands are autonomously determined based on the identified characteristics.

13. A method for controlling an aircraft, the method comprising: determining sensor information using a sensor suite of the aircraft; determining flight commands with the autonomous computing system on the aircraft based on the sensor information using a set of pre-trained models of the autonomous computing system; receiving the flight command at an application programming interface (API) separate from the autonomous computing system; Confirmation of said flight order, including: In response to receiving the flight command at the application programming interface API, confirming format compliance of the flight command received at the application programming interface API; In response to confirming the format compliance of the flight command received at the application programming interface (API), providing the flight command in a human-interpretable format at a pilot confirmation interface; and determining, using the pilot confirmation interface, pilot confirmation of the flight command based on providing the flight command in the human-interpretable format at the pilot confirmation interface; and In response to determining the pilot confirmation, execution of the flight command is automatically facilitated.

14. The method according to claim 13, wherein: The sensor information is unstructured, wherein the flight command comprises a predetermined machine-readable data structure, wherein confirming format compliance comprises confirming compliance with the predetermined machine-readable data structure.

15. The method according to claim 13, wherein: Determining the driver confirmation includes receiving a driver confirmation at the driver confirmation interface.

16. The method according to claim 13, wherein: Automatically facilitating the execution of the flight command comprises providing the flight command to a flight management system FMS and executing the command via a flight control system FCS.

17. The method according to claim 13, further comprising: determining second flight commands with the autonomous computing system using the set of pre-trained models of the autonomous computing system of the aircraft; Receiving the second flight command at the application programming interface API; providing the second flight command at the pilot confirmation interface; determining a pilot override of the second flight command using the pilot confirmation interface, the pilot override comprising a third flight command; and In response to determining the pilot override, execution of the third flight command is automatically facilitated.

18. The method according to claim 17, further comprising: At least one of the set of pre-trained models of the autonomous computing system is updated based on the driver override.

19. The method according to claim 13, wherein: The sensor information includes air traffic control (ATC) audio signals, wherein determining the flight command includes: determining, with a speech-to-text module of the autonomous computing system, an utterance hypothesis from the air traffic control (ATC) audio signal using a first pre-trained neural network model from the set of pre-trained models; and Utilizing the question-answering (Q / A) module of the autonomous computing system, according to a structured sequence of natural language queries, querying the discourse hypothesis by utilizing a second pre-trained neural network model in the set of pre-trained models, and determining the flight command based on the discourse hypothesis.

Images