Devices, systems, and methods for automatic flight path verification
By designing a device containing memory and processor, and using flight physics models to perform flight path verification, the problem of human error and time-consuming flight path verification in the prior art is solved, and automated verification is realized, improving efficiency and safety.
Patent Information
- Application Number
- CN202411550981.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-10-31
- Filing Date
- 2024-11-01
- Publication Date
- 2025-05-06
AI Technical Summary
The existing flight path verification process is prone to human errors, time-consuming and requires a lot of manual preparation, execution and documentation, resulting in inefficient verification and increased safety risks.
Design a device, including a memory circuit system and at least one processor circuit system, program inputs through instructions to determine a closed area with lower altitude limitations and lateral boundaries, generate flight capability assessments and hazard assessments using a flight physics model, thereby verifying the flight path and outputting verification instructions and definitions.
It realizes automated flight path verification, reduces human errors, improves verification efficiency, reduces safety risks, and enables dynamic generation and verification of flight paths.
Smart Images

Figure CN119942847A_ABST
Abstract
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 596,104, filed on November 3, 2023. U.S. Provisional Patent Application No. 63 / 596,104 is hereby incorporated herein by reference for all purposes. Technical Field
[0002] The present disclosure relates generally to flight path validation and, more particularly, to apparatus, systems, and methods for automated flight path validation. Background Art
[0003] Air vehicles (such as fixed-wing aircraft and helicopter aircraft) require instrument flight procedure verification (IFPV), which includes performance-based navigation (PBN) and area navigation (RNAV). Such verification traditionally includes ground verification, pre-flight verification and flight verification. For example, pre-flight verification can include simulator evaluation and obstacle assessment. Existing verification is prone to human error and involves a lot of time to prepare, perform and document. Summary of the invention This application provides a set of technical solutions, as follows. Technical solution 1. A device comprising: Memory circuit system; at least one processor circuitry programmed with instructions to: processing the input to determine an enclosed region having a lower altitude limit and lateral boundaries for a flight path from a first location to a second location; generating a flight capability assessment using a flight physics model that models movement of an aircraft along the flight path through the enclosed area; generating a hazard assessment regarding the enclosed area along the flight path; processing the flight path using the flight capability assessment and the hazard assessment to determine a validation of the flight path; and An indication of the validation of the flight path and a definition of the flight path are output. Technical Solution 2. An apparatus according to any one of the technical solutions, wherein the verification includes at least one of verification of a new flight path or re-verification of an existing flight path. Technical Solution 3. An apparatus according to any one of the technical solutions, wherein determining the verification includes accepting the flight path or rejecting the flight path. Technical Solution 4. An apparatus according to any one of the technical solutions, wherein the flight physics model is constructed based on at least one of a weighted factor analysis or a trained artificial intelligence model. Technical Solution 5. An apparatus according to any one of the technical solutions, wherein the at least one processor circuit system determines a priority assessment for the flight path. Technical Solution 6. An apparatus according to any one of the technical solutions, wherein the output is provided to a flight management system. Technical Solution 7. An apparatus according to any one of the technical solutions, wherein generating the hazard assessment includes processing at least one of images or radar data to identify hazards within the enclosed area along the flight path. Technical solution 8. At least one non-transitory computer-readable storage medium comprising instructions, which, when executed, cause at least one processor circuit system to at least: processing the input to determine an enclosed region having a lower altitude limit and lateral boundaries for a flight path from a first location to a second location; generating a flight capability assessment using a flight physics model that models movement of an aircraft along the flight path through the enclosed area; generating a hazard assessment regarding the enclosed area along the flight path; processing the flight path using the flight capability assessment and the hazard assessment to determine a validation of the flight path; and An indication of the validation of the flight path and a definition of the flight path are output. Technical Solution 9. At least one non-transitory computer-readable storage medium according to any one of the technical solutions, wherein the verification includes at least one of verification of a new flight path or re-verification of an existing flight path. Technical Solution 10. At least one non-transitory computer-readable storage medium according to any one of the technical solutions, wherein determining the verification includes accepting the flight path or rejecting the flight path. Technical Solution 11. At least one non-transitory computer-readable storage medium according to any one of the technical solutions, wherein the flight physics model is constructed based on at least one of a weighted factor analysis or a trained artificial intelligence model. Technical Solution 12. At least one non-transitory computer-readable storage medium according to any one of the technical solutions, wherein the instructions, when executed, also cause the at least one processor circuit system to determine a priority assessment of the flight path. Technical Solution 13. At least one non-transitory computer-readable storage medium according to any one of the technical solutions, wherein the output is provided to a flight management system. Technical Solution 14. At least one non-transitory computer-readable storage medium according to any of the technical solutions, wherein generating the hazard assessment includes processing at least one of images or radar data to identify hazards within the enclosed area along the flight path. Technical solution 15. A computer-implemented method for flight path verification, the method comprising: Processing inputs to determine an enclosed area having a lower altitude restriction for a flight path from a first location to a second location by executing instructions using at least one processor circuit; generating a flight capability assessment using a flight physics model, by executing instructions using the at least one processor circuit, the flight physics model modeling movement of the aircraft along the flight path through the enclosed area; generating a hazard assessment regarding the enclosed area along the flight path by executing instructions using the at least one processor circuit; executing instructions using the at least one processor circuit to process the flight path using the flight capability assessment and the hazard assessment to determine a validation of the flight path; and By executing instructions using the at least one processor circuit, an indication of the validation of the flight path and a definition of the flight path are output. Technical Solution 16. A method according to any one of the technical solutions, wherein determining the verification includes accepting the flight path or rejecting the flight path. Technical Solution 17. The method according to any one of the technical solutions also includes constructing the flight physics model based on at least one of weighted factor analysis or trained artificial intelligence models. Technical Solution 18. The method according to any one of the technical solutions also includes determining a priority assessment of the flight path. Technical Solution 19. A method according to any one of the technical solutions, wherein the output includes output to a flight management system. Technical Solution 20. A method according to any one of the technical solutions, wherein generating the hazard assessment includes processing at least one of images or radar data to identify hazards within the enclosed area along the flight path. BRIEF DESCRIPTION OF THE DRAWINGS
[0004] For those skilled in the art, a complete and enabling disclosure of the presently described technology, including the best mode thereof, is set forth in the specification with reference to the accompanying drawings, in which:
[0005] Figure 1 An example decision support system is shown that may select parameters for a flight management system.
[0006] Figure 2 yes Figure 1 An example implementation of a flight management system.
[0007] Figure 3 Shows the manual verification process.
[0008] Figure 4 An apparatus for automatic flight path verification is shown.
[0009] Figure 5 Show Figure 4 An example implementation of a flight path validation processor.
[0010] Figure 6 An example process of inputting data to generate output of accepting, prioritizing and / or rejecting flight paths is shown.
[0011] Figure 7-Figure 9 is a block diagram of some example processor platforms that are configured to execute instructions to implement the example elements disclosed and described herein.
[0012] Fig.10 is a block diagram of an example software / firmware / instruction distribution platform (e.g., one or more servers) that distributes software, instructions and / or firmware (e.g., corresponding to example machine-readable instructions) to client devices associated with end users and / or consumers.
[0013] The drawings are not drawn to scale. Instead, the thickness of the regions may be exaggerated in the drawings. In general, the same reference numerals will be used throughout the drawings (one or more) and the accompanying written description to refer to the same or similar parts. Connection references (e.g., attachment, coupling, connection, and engagement) are to be interpreted broadly and may include intermediate members between sets of elements and relative movement between elements, unless otherwise indicated. Likewise, connection references do not necessarily infer that two elements are directly connected and in a fixed relationship to each other. A statement that any part is "in contact" and / or "in direct contact" with another part means that there is no intermediate part between the two parts. DETAILED DESCRIPTION
[0014] Reference will now be made in detail to embodiments or examples of the presently described technology, one or more of which are illustrated in the accompanying drawings. Each example is provided by way of explanation of the presently described technology rather than as a limitation of the presently described technology. In fact, it will be apparent to those skilled in the art that various modifications and variations may be made in the presently described technology without departing from the scope or spirit of the presently described technology. For example, a feature illustrated or described as part of one embodiment or example may be used together with another embodiment or example to produce yet another embodiment or example. Therefore, it is intended that the presently described technology covers such modifications and variations as fall within the scope of the appended claims and their equivalents.
[0015] When introducing the elements of various embodiments of the present disclosure, the articles "one", "an", "the" and "said" are intended to mean that there are one or more of the elements. As used herein, the terms "first", "second" and "third" can be used interchangeably to distinguish one component from another component, and are not intended to represent the position or importance of individual components. The terms "including", "comprising" and "having" are intended to be inclusive, and mean that in addition to the listed elements, additional elements may also be present. When the terms "connected to", "coupled to", etc. are used in this article, an object (e.g., material, element, structure, member, etc.) can be connected or coupled to another object, regardless of whether the one object is directly connected or coupled to the other object, or whether there are one or more intermediate objects between the one object and the other object.
[0016] "Include" and "comprising" (and all their forms and tenses) are used herein as open-ended terms. Thus, whenever a claim employs any form of "include" or "comprising" (e.g., comprise, comprising, include, including, having, etc.) as a preamble or within any kind of claim recitation, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, the phrase "at least" when used as a transitional term, such as in the preamble of a claim, is open-ended in the same manner as the terms "include" and "comprising" are open-ended. The term "and / or" when used, for example, in the form of, for example, A, B, and / or C, refers to any combination or subset of A, B, C, such as (1) A alone, (2) B alone, (3) C alone, (4) A and B, (5) A and C, (6) B and C, and (7) A and B and C. As used herein in the context of describing structures, components, items, objects, and / or things, the phrase “at least one of A and B” is intended to refer to implementations that include any of the following: (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects, and / or things, the phrase “at least one of A or B” is intended to refer to implementations that include any of the following: (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the execution or operation of processes, instructions, actions, activities, and / or steps, the phrase “at least one of A and B” is intended to refer to implementations that include any of the following: (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the execution or operation of processes, instructions, actions, activities, and / or steps, the phrase "at least one of A or B" is intended to refer to implementations that include any of the following: (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.
[0017] As used herein, singular references (e.g., "a", "an", "first", "second", etc.) do not exclude plural references. As used herein, the term "a" or "an" entity refers to one or more of that entity. The terms "a" (or "an"), "one or more" and "at least one" may be used interchangeably herein. Furthermore, although individual features may be included in different examples or claims, these features may potentially be combined, and inclusion in different examples or claims does not imply that a combination of features is not feasible and / or disadvantageous.
[0018] Traditional IFPV involves ground verification, pre-flight verification and flight verification. This series of verification includes, for example, ground obstacle assessment, simulator verification, air obstacle assessment and flight verification.
[0019] Ground validation is a quality assurance review of the entire Instrument Flight Path (IFP) grouping to identify areas that may affect the flyability and safety of the IFP (e.g., ARINC 424 coding errors, obstacles, obstacle assessment / airport airspace analysis (OE / AAA) and mapping, etc.). Pre-flight validation includes an obstacle assessment and may include a simulator assessment. Flight validation involves reviewing the simulator and obstacle assessment and taking into account any specific training, operational and / or equipment requirements.
[0020] Flight verification involves comparison of the aircraft navigation database, chart depictions, Federal Aviation Administration (FAA) tables and / or equivalent tables, and flight check graphics. A flight capability assessment is performed to determine safe flight of all segments of the IFP, for example taking into account speed, climb gradient, descent gradient, coded flight path / glide path angle, and bank angle. Control obstacle verification provides an assurance that control obstacles have been correctly identified for each segment of the IFP. In addition, airport / heliport infrastructure (e.g., signs, lighting, and communications) is verified to be in place and operational. In addition, for example, other operational factors are verified, such as aircraft equipment (e.g., Terrain Avoidance and Warning System (TAWS) / Enhanced Ground Proximity Warning System (EGPWS)), performance limitations (e.g., minimum and maximum temperature limits), and human factors / cockpit workload.
[0021] While current processes use pilots, full motion simulators, and aircraft to provide subjective assessments, these intensive manual assessments are prone to human error and take a significant amount of time to prepare, perform, and document. Certain examples utilize high-resolution terrain data and / or utilize navigation charts from flight simulations to provide flight checks and flight verifications for instrument flight procedures. Certain examples eliminate the pilot's manual assessment of a flight path before that flight path is published for use by an aircraft (e.g., a human-piloted aircraft, an autopiloted aircraft, etc.).
[0022] The traditional flight path validation process may take three to six months to complete, which delays the activation of new flight paths for use. In addition, existing flight paths must be recertified periodically for continued use. Depending on the jurisdiction, this period can be anywhere from six months to five years (e.g., at least eighteen months, etc.). Due to the human factors and the number of steps involved, such a manual, human-driven process cannot be performed faster or more reliably and introduces risks. Certain examples address the technical shortcomings of manual, human-driven processes by providing a platform or infrastructure to support the automatic submission, processing and validation of new flight paths and the recertification of existing flight paths for continued use. Certain examples provide new technologies that interface with a flight management system (FMS) to drive flight path validation and computational processes associated with simulation, modeling, sensors, imaging, aircraft data, etc.
[0023] For example, geospatial analysis of high-resolution, synthetic aperture radar (SAR) data replaces analysis of flight path surfaces compared to: 1) (one or more) obstacle databases; 2) (one or more) ground obstacle surveys; and 3) observations of obstacles during flight verification. Flight capability analysis is performed by evaluating multiple four-dimensional (4D) trajectories and abnormal settings (e.g., engine flameout, loss of navigation, etc.) generated by existing FMS software in various weather (e.g., wind, temperature, precipitation, etc.), thereby evaluating flight capability, for example, according to a set of predefined parameters. Such flight capability analysis eliminates the need for pilots to evaluate flight capabilities in an aircraft or simulator. Objective rather than subjective electronic analysis provides technically superior flight path information, accurate analysis, consistency, and reliable (re) verification. Artificial intelligence (AI) models and / or other expert electronic systems can eliminate human errors and oversights while reducing time-to-value to near zero. Such models and associated systems can be provided in software as a service (SaaS) packages, thereby enabling dynamic, real-time (or near real-time) verification of flights of conventional and unmanned aerial vehicles.
[0024] In certain examples, automatic modeling and evaluation of ground obstacles, flight events, procedural complexity, workload, and feedback are provided to enable dynamic generation and validation of flight paths along with real-time or near real-time evaluation of flight paths prior to flight by an aircraft, such as a fixed-wing aircraft, a rotorcraft, an urban air mobility vehicle, a drone, etc. In this way, a flight path validation system (e.g., an IFPV system) can communicate with a flight management system (FMS) to, for example, generate, validate, and execute flight paths on demand (e.g., via human-assisted instrument flight, automated instrument flight, etc.). In certain examples, a flight path validation process can be performed to augment and / or otherwise assist traditional manual validation (referred to herein as an assisted flight path validation system, apparatus, and / or method).
[0025] In some examples, flight path validation is performed in a single process rather than a series of separate processes. The example validation process operates on a procedure definition file that provides the boundaries and altitude floors that must be protected during instrument flight.
[0026] The process determines the lateral containment zone and lower altitude limit or lower altitude limit for the instrument flight procedure being validated. The containment zone associated with the flight plan can be assessed by utilizing topographic data, imaging, radar, etc. to identify any objects that would be a conflict for an aircraft flying within the containment zone. The flight plan can be assessed section by section. Instead of manual pilot observation or survey, the automated validation process processes high-resolution SAR data from satellites (e.g., updated weekly, daily, monthly, etc.) and performs a geospatial comparison of the procedural radar data and the procedural definition associated with the containment zone of the proposed flight path. Any penetration of the containment zone by the surface of an external object is identified and annotated.
[0027] Instead of actual flying and testing, a flight management system (FMS) creates a set of test scenarios with expected temperature extremes, wind extremes, engine flameout events, etc., to account for different aircraft types of the same or different categories, different entry vectors, different headings, different altitudes, different energy levels, different airspeeds, etc. For example, an FMS is a component of a flight capability assessment system. The FMS processes various test scenarios to identify whether (one or more) errors occur, any disconnections, instances where the aircraft exceeds a maximum bank angle, etc. For example, the FMS can determine whether such an error / event will cause the aircraft to move outside a defined closed area. In some examples, the FMS performs physics-based modeling and analysis of the closed area environment and the external factors introduced. The FMS drives a physical model for multiple scenarios (e.g., one thousand scenarios, ten thousand scenarios, etc.), which tests the extreme limits that the aircraft may encounter along the flight plan. When a flight path validation model is provided (e.g., via the FMS, etc.).
[0028] In some examples, complexity and / or workload assessments are also performed. Complexity assessments and workload assessments can be proportional, or inversely proportional. In some examples, weighted factor analysis and / or training of artificial intelligence (AI) models are performed, in which different features are weighted differently in a manner that is favorable to workload or complexity. Even if the flight path has never been flown before, the complexity can be assessed from the start of the flight path. Complexity assessments also focus on back-to-back turns, environments (e.g., using the central runway of a three-runway airport versus a single runway, etc.), etc., so as to use maps and images to determine whether the road is aligned with a given runway, etc. Workload assessments review flight operation data, which includes controller dialogues, pilot workloads, and associated flight phases (e.g., phases farther from the runway are better than phases closer to the runway, etc.), etc., to generate scores that quantify workload. For example, a flight path that requires the use of a drag device to meet an altitude constraint is scored as requiring additional pilot workload, which is contrary to a flight path in which an altitude constraint can be performed without the use of a drag device. Similarly, for example, a flight path with multiple altitude constraints requiring additional pilot input is scored as more complex than a flight path with one or zero altitude constraints.
[0029] In some examples, navaid alignment is also assessed. For example, a navaid is assessed to determine if it is transmitting accurately. Flight operations quality assurance (FOQA) data (e.g., fuel management and flight efficiency data, maintenance data, program safety data, block time analysis, and ground turn optimization data, etc.) can be analyzed to determine location based on the navaid and based on the global positioning system (GPS) to determine if something in the flight plan imposes a risk on navaid alignment. For example, the risk to navaid alignment can be understood at a particular airport.
[0030] Additional assessments that form part of flight plan validation may include chart reviews (e.g., comparison of the pilot's chart with the procedure definition and associated coding). Such comparisons may be driven by artificial intelligence (AI), such as machine learning models. Communications (e.g., quality, content, etc.) may also be assessed (e.g., ultra-high frequency (UHF), very high frequency (VHF), etc.). An assessment of an enhanced ground proximity warning system (EGPWS) may also be performed. For example, risks may be assessed and EGPWS procedures scored. For example, for a first flight path placed very close to terrain, for which the EGPWS algorithm is expected to issue a terrain warning, that first flight path may score very low in terms of safety, while a second flight path placed far enough from the terrain to avoid an EGPWS alert is scored as safer than the first flight path.
[0031] Thus, an automated, quantifiable process is provided via an objective, rather than subjective infrastructure. The infrastructure or system acquires information from satellite, imaging and / or other sensor(s), etc. to generate high-resolution terrain data, FOQA data, etc., and provides simulation and knowledge-driven processing of the data to provide a binary output of approval / rejection of a proposed flight plan along with flight checks and flight validation of instrument flight procedures. The system can be used to validate flight paths, enhance validation of flight paths, revalidate flight paths, etc. The system can validate new procedures against existing runways, against the capabilities of specific aircraft, etc.
[0032] In some examples, the processes and systems disclosed herein can be implemented in conjunction with an FMS and / or other aircraft systems, which can drive flight path validation, supplement flight path validation, use validated flight paths in operations, etc. The FMS can be used to manage aircraft flight control, generate flight profile data, and provide navigation information, such as a flight path specified by waypoints represented by navigation position coordinates. In addition, the FMS can be configured to provide, for example, aircraft engine throttle settings for manual or automatic control of engine thrust.
[0033] The FMS calculates a detailed flight trajectory and controls the navigation of the aircraft. The trajectory defines the lateral and vertical profiles (including the aircraft speed along the profile) and is developed by the FMS using the flight plan and other constraints (such as altitude and speed limits, etc.). The FMS uses the current aircraft state and atmospheric data together with all the data entered by the crew or uploaded by the airline operation center (AOC) to generate the trajectory. Using various sensors to determine the exact position of the aircraft, the FMS guides the aircraft along the trajectory through the flight control system. For example, during aircraft takeoff and cruising, the FMS can determine the engine thrust requirements to fully lift the aircraft when taking off from the runway, so that the aircraft fully climbs at a pitch rate (usually according to a programmed schedule or requirement elaborated by air traffic control), and then level off and finally descend for landing.
[0034] Figure 1 An example decision support system 30 is shown that can select parameters for an FMS 32 that can be fixed or dynamically changed during a flight path. The FMS 32 receives initial and optionally updated parameter information from a flight parameter selection module 34. Information such as weather information and / or flight time information (e.g., departure time, current time, and / or estimated arrival time) is received by the flight parameter selection module 34, which outputs control parameters to the FMS 32. For example, the flight parameter selection module 34 can be used to set or update the cruise altitude and / or lateral flight path. The flight parameter selection module 34 can be implemented in hardware, software, or a combination thereof.
[0035] Figure 2 An example implementation of the FMS 32 is shown, which may be used to verify a flight path, control the flight of the aircraft 52, etc. Figure 2 In the example of FIG. 5 , the FMS 32 includes an FMS onboard computer processor 72 and a memory 74. The memory 74 includes a stored navigation database 76 that stores aircraft navigation information including determined waypoint information 78, which may be points along the flight plan at which one or more of the lateral and vertical profiles of the flight of the aircraft 52 are changed. Thus, the memory 74 may include navigation waypoints and corresponding aircraft control parameters 80 that are changed during flight by the FMS onboard computer processor 72, as determined by one or more of the various embodiments, such as using the flight parameter selection module 34.
[0036] The onboard computer processor 72 receives various inputs from the air data computer 90, including sensed aircraft altitude 82, sensed aircraft speed 84, and sensed air temperature 86. In addition, the processor 72 receives inputs from navigation sensors 100, such as position coordinates from a global positioning system (GPS) 102 and inertial data from inertial sensors 104. In addition, the processor 72 receives other inputs from other sensors, such as fuel level 88, and other sensed variables as should be apparent to one skilled in the art.
[0037] The onboard computer processor 72 is further shown in communication with a control and display unit (CDU) 110 having a display 112. It should be appreciated that the control and display unit 110 may be a human-machine interface that allows a pilot to input data and receive output data. For example, output data indicating calculated engine thrust may be provided in a display page presented on the display 112 to allow a pilot of the aircraft to operate the aircraft in accordance with the output data provided by the flight management system 32.
[0038] The FMS 32 is also shown having a Mach / airspeed indicator 114, an altitude direction indicator 116, and a horizontal position indicator 118. A symbol generator 120 is coupled between the processor 72 and each of the indicators 116 and 118. The FMS 32 also includes a mode control panel 130 that provides an output to an autopilot 132, which is also in communication with the processor 72. The autopilot 132 may be part of a flight control system and may operate a control wheel 134 in an autopilot mode.
[0039] The FMS 32 is further shown to include a throttle controller 140 for controlling the engine throttles. The throttle controller 140 may be manually actuated by the pilot of the aircraft in a manual mode. In an automatic or instrument-driven flight control mode, the throttle controller 140 may be automatically controlled by an auto-throttle signal 142 provided by the processor 72. It should be appreciated that the processor 72 may output a command signal for controlling the aircraft with a calculated throttle value by providing an output command via the display 112 or by automatically controlling the throttle controller 140 via the auto-throttle signal 142.
[0040] The FMS 32 shown and described herein is an example of a flight management system that can be configured to perform various embodiments to control an aircraft during aircraft takeoff, cruise, and arrival procedures. In some examples, a step climb schedule is stored in a memory 74. It should be appreciated that the memory 74 and the stored navigation database 76 may include an existing navigation database in an existing flight management system that is upgraded to perform a climb schedule or use one or more embodiments. In some examples, the memory 74 stores a flight path configuration that will be processed, simulated, and verified, for example, by a processor 72, etc. In this way, the FMS 32 can drive flight path verification and / or assist another external processor in verifying a flight plan (e.g., verification of a new flight path, revalidation of an existing flight path, etc.).
[0041] Figure 3 An example prior manual validation process 300 is shown, which includes manual procedure design 310, ground validation 320, pre-flight validation 330, and flight validation 340. Figure 3 As shown in the example of , in procedure design 310, instrument flight path (IFP) packets are manually assembled to satisfy a human reviewer. The IFP packets are provided to the human reviewer for ground validation 320. If the reviewer determines that the IFP packets are satisfactory with respect to ground interference and other subjective and / or objective criteria, a pre-flight validation 330 is performed. During pre-flight validation 330, the human user evaluates any obstacles in the flight path, and the flight path may also be simulated (e.g., under various normal, abnormal, and rare normal conditions). If satisfactory, flight validation 340 involves the user performing an in-flight evaluation of the procedure at implementation 350 (e.g., with FAA approval). If the human user finds any aspect unsatisfactory, the procedure design 310 is modified.
[0042] on the contrary, Figure 4 An infrastructure 400 for automated flight path validation is shown. The example infrastructure 400 includes a set of inputs 410 to a processor 420 (also referred to as a processor circuit system) to generate a validation 430. The example inputs 410 include a flight path definition 411, aircraft navigation data 412 (e.g., ARINC 424, etc.), high resolution hazard data 413, FOQA data 414, other weather and geospatial data 415, and configuration information 416. The example processor 420 includes a flight capability criteria engine 422, a flight physics model 424, and a hazard assessment engine 426. The flight capability criteria engine 422, the flight physics model 424, and the hazard assessment engine 426 process all or part of the inputs 410 to drive a validation 430 of a flight path. The example validation 430 includes a flight capability assessment 432 and a hazard assessment 434. For example, the validation 430 also drives a priority assessment 436.
[0043] In operation, the example flight path validation processor 420 generates flight capability criteria using a flight capability criteria engine 422 based on the data 412-415, the definition 411, and the configuration 416 provided by the input 410. The flight capability criteria engine 422 can be trained on data such as the data 412-415, tested with data such as the data 412-415, and deployed to process the data 412-415 to assess the flight capability of a flight path, such as that conducted by an aircraft. For example, a flight physics model 424 can also be trained on data such as the data 412-415, tested with data such as the data 412-415, and deployed to process the data 412-415 to model the flight of an aircraft along a target flight path being validated. In some examples, the flight physics model 424 uses Newtonian physics to simulate aircraft flight. If the aircraft flies at a given speed with a given wind speed, and performs a coordinated turn at a given bank angle while in level flight, the flight physics model 424 determines that the aircraft will fly a specific ground path within the constraints of the autopilot system, regardless of the aircraft and engine type. In reality, different aircraft have different constraints and characteristics that can modify the predictions, but physics is the basis for the path predictions made by the flight physics model 424, as opposed to a more subjective framework.
[0044] The hazard assessment engine 426 utilizes hazard data 413 about the flight path definition 411. For example, input to the hazard assessment engine 426 may include high resolution synthetic aperture radar (SAR) terrain data obtained from a satellite. Other hazards may be part of a dynamic system, such as convective weather or temporary airspace constraints obtained from existing distribution channels. Hazard data is collected, cleaned, and evaluated for areas where flight should and must be avoided. The hazard assessment engine 426 calculates the proximity of the aircraft to terrain and obstacles (such as trees, towers, and buildings) in four dimensions (including time). For example, for certain situations where a flight path intersects high terrain, a flight path approaching a hazard area may be weighted by the hazard assessment engine 426 as less desirable or even rejected entirely.
[0045] like Figure 4As shown in the example of FIG. 4 , the flight physics model 424 is used to generate a flight capability assessment 432 as part of the validation output 430. The flight capability assessment 432 is generated by modeling a proposed flight path using the flight physics model 424 based on the inputs of the flight path definition 411, the data 412-415, and the configuration 416. For example, the hazard assessment engine 426 generates the hazard assessment 434 as part of the validation output 430 based on the high-resolution hazard data 413, the other data 412, 414, 415, along the flight path defined by the flight path definition 411 as modified by the configuration setting(s) 416. For example, the flight capability assessment 432 may be modified by the hazard assessment 434 to determine the priority assessment 436.
[0046] For example, a flight path immediately adjacent to new construction may be ranked higher in the priority assessment than a flight path in an undeveloped area. A flight path that has recently undergone validation activity may be scored lower as needing an assessment. The priority assessment is a risk assessment and, as such, may be used to help determine whether further manual / existing flight path validation should be performed, and how soon the manual assessment should be performed.
[0047] Priority assessment 436 may be used to drive ranking or other prioritization of target flight paths. For example, a first flight path may be verified, but based on a high hazard assessment 434, may be given a higher priority assessment 436 when compared to a second flight path that is also verified to have a lower hazard assessment 434. For example, a hazard assessment may be scored higher based on factors such as proximity to high terrain, buildings, towers, and other flight path hazards. Other hazards may include the flight path's proximity to an airport or other traffic near an airport, proximity to an area known to have degraded communications, etc.
[0048] In certain examples, processor 420 and validation 430 may be packaged as a flight path validation processor 500 , which may be implemented in and / or in conjunction with an FMS (eg, example FMS 32 ). Figure 5 An example implementation of a flight path validation processor 500 is shown, which includes a flyability criteria 510 , a physical flight model 520 , a flyability assessment 530 , a hazard assessment 540 , and a priority assessment 550 .
[0049] In operation, the flight path verification processor 500 models and evaluates ground obstacles, flight events, program complexity, workload and feedback to verify the flight path based on the definition file including the flight capability criteria 510. The flight capability criteria 510 can define a closed area including (one or more) lower and upper altitude limits, (one or more) lateral boundaries, etc. The flight physics model 520 ensures that the aircraft can remain in the closed area under any normal, rare normal and abnormal flight conditions (such as extreme winds and temperatures, engine losses, etc.). The flight physics model 520 simulates the flight of the aircraft according to the flight path within the defined closed area. High-resolution terrain data, high-resolution synthetic aperture radar data, FOQA data, etc. can be used to train, test and operate the model 520 about the flight path. In this way, the model 520 can be used to identify (one or more) objects that conflict with the flight path being verified. For example, high-resolution synthetic aperture radar (SAR) data from a satellite (e.g., weekly, daily, monthly updates, etc.) can be used to perform geospatial comparisons of process radar data and program definitions associated with the closed area of the proposed flight path. In the flight capability assessment 530 and the hazard assessment 540 generated using the model 520, penetration of the enclosed area by external objects is identified and annotated.
[0050] For example, physical objects such as buildings, towers, terrain (e.g., mountains, trees, etc.), etc., may penetrate the containment area defined by the flight path definition, and the flight path may be rejected during the hazard assessment. Similarly, for example, even if the containment area is not hazardous, the aircraft may be assessed as being unable to remain within the defined containment under certain flight conditions (e.g., extreme winds or engine loss). Based on the flight capability assessment, such a flight path may be rejected. However, the flight capability assessment may be rejected due to an accumulation of less severe considerations, such as unacceptable pilot workload requirements, proximity to other known traffic, etc. For example, the accumulation of flight path issues may exceed a tolerable threshold of acceptability and is then rejected.
[0051] The flight capability assessment 530 and the hazard assessment 540 are combined and compared by the processor 500 to assess and determine a priority assessment 550 for the flight path. For example, the presence of errors, exceeding limits (e.g., lower limits, upper limits, bank angles, etc.), etc. are provided in the flight capability assessment 530 (e.g., how flyable a given flight path is for a pilot aircraft, an automatic aircraft, etc.) and the hazard assessment 540 (e.g., what hazard(s) exist along the flight path, etc.). The processor 500 can model 520 various scenarios to generate different flight capability assessments 530 and hazard assessments 540 to determine a final priority assessment 550 associated with the flight path.
[0052] Factors such as complexity, workload, etc. can be considered, for example, in the flight capability assessment 530 and help drive the priority assessment 550. In some examples, the processor 500 uses the model 520 to perform a weighted factor analysis in which different features are weighted differently in a manner that favors workload or complexity. Alternatively or additionally, navigation data, focus data, communications, etc. can be considered in the analysis. The priority assessment 550 generated by the flight path verification processor 500 can be used to verify the flight path, enhance the verification of the flight path, revalidate the flight path, etc. The processor 500 can verify the new flight path for existing runways, for the capabilities of a specific aircraft, etc. In some examples, the existing flight path can be revalidated by following the same process as the new flight path verification. In some examples, the existing flight path can be dynamically verified so that current and forecasted weather conditions are taken into account in the evaluation.
[0053] Although combined Figure 4-Figure 5 An example implementation is shown, but in conjunction with Figure 4-Figure 5 The elements, processes and / or devices shown may be combined, split, rearranged, omitted, eliminated and / or implemented in any other manner. In addition, the components disclosed and described herein may be implemented by hardware, machine-readable instructions, software, firmware and / or any combination of hardware, machine-readable instructions, software and / or firmware. Thus, for example, the components disclosed and described herein may be implemented by (one or more) analog and / or digital circuits, (one or more) logic circuits, (one or more) programmable processors, (one or more) application-specific integrated circuits ((one or more) ASICs), (one or more) programmable logic devices ((one or more) PLDs) and / or (one or more) field programmable logic devices ((one or more) FPLDs). When reading any device or system claim of this patent to be implemented by pure software and / or firmware, at least one of the components is hereby explicitly defined as a tangible computer-readable storage device or storage disk including storage software (including computer and / or other machine-readable instructions) and / or firmware, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disc, etc.
[0054] exist Figure 6 Flowcharts representing example hardware logic, machine readable instructions, hardware implemented state machines, and / or any combination thereof for programming an FMS and / or other flight path verification processor are shown in FIG. The machine readable instructions may be one or more executable programs or portions of executable programs for execution by a computer processor, such as the following in combination with Figure 7The processor 712 shown in the example processor platform 700 discussed above. The program may be embodied in software stored on a non-transitory computer-readable storage medium, such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with the processor 712, but the entire program and / or portions thereof may alternatively be executed by a device other than the processor 712 and / or embodied in firmware or dedicated hardware. In addition, although reference is made to Figure 6 The flowchart shown in describes an example process, but many other methods of programming the FMS and / or other flight path verification processors may alternatively be used. For example, the order of execution of the blocks may be changed, and / or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuit systems, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) that are configured to perform corresponding operations without executing software or firmware.
[0052] As described above, the example process(es) disclosed and described herein may be implemented using coded instructions (e.g., computer and / or machine readable instructions) stored on a tangible computer readable storage medium, such as a hard drive, flash memory, read only memory (ROM), compact disk (CD), digital versatile disk (DVD), cache, random access memory (RAM), and / or any other storage device or storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, for brief instances, temporarily buffered, and / or in a cache of information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and / or storage disk, and does not include propagating signals, and does not include transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" may be used interchangeably. Additionally or alternatively, the example process(es) may be implemented using coded instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium, such as a hard drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, for a brief instance, temporarily buffered, and / or in a cache of information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and / or storage disk, and does not include propagating signals, and does not include transmission media.
[0056] Figure 6 An example process 600 is shown for inputting data to generate output for accepting, prioritizing, and / or rejecting flight paths. Figure 6 As described in the example of , multiple inputs 610 are processed 620 to validate 630 the flight path. The inputs 610 may include definitions of flight paths 611 (e.g., new flight paths, current flight paths, etc.), aircraft navigation data 612 (e.g., ARINC424 data, etc.), high-resolution hazard data 613 (e.g., imaging, sensors, etc.), FOQA data 614 (e.g., fuel management and flight efficiency data, maintenance data, program safety data, block time analysis and ground turn optimization data, etc.), other geospatial data 615 (e.g., GPS, communications, etc.), configuration information 616, etc.
[0057] Inputs 610 are processed 620 to generate flight capability criteria 622 (e.g., boundaries of an aircraft flight enclosure, altitude limit(s), speed limit(s), etc.) against which the flight path is assessed. Process 620 also generates a flight physics model 624 with which the flight paths of one or more example aircraft are modeled / simulated and assessed within the bounds of the flight capability criteria 622. Process 620 also generates a hazard assessment 634 based on the flight physics model 624 and inputs 610. For example, obstacles and / or other objects in the flight path may be identified, and associated contact risks and / or other hazards may be determined.
[0058] Process 620 is then validated 630 to determine, for example, a flyability assessment 632 and a hazard assessment 634. For example, an assessment 632 of how flyable a flight path by one or more aircraft is generated based on the flyability criteria 622 and the flight physics model 624. An assessment 634 of possible hazards on the flight path is also generated, for example, based on the flight physics model 624 and the hazard assessment 626. The flight paths may then be scored, prioritized, etc. based on the assessments 632, 634.
[0059] For example, a flyability assessment 632 may be evaluated to determine if the flight path is flyable 640. If not, an instrument flight path (IFP) recommendation is rejected 650. The flight path is also evaluated 645 to determine if the flight path is hazardous based on a hazard assessment 634. If the flight path is hazardous, the IFP 650 is rejected. For example, if the flight path is flyable and not hazardous, the flight path is accepted and prioritized 660 relative to other flight paths.
[0060] In some examples, the flight physics models 424, 524, 624 can be implemented and evaluated using one or more artificial intelligence models (e.g., machine learning models, etc.). The flight physics models 424, 524, 624 can be trained and tested on previous flight paths and associated validation data to assess aircraft motion in closed areas, identify hazards, parse imagery and sensor data to identify objects and anomalies, correlate conditions with outcomes, and so on.
[0061] Figure 7 7 is a block diagram of an example processor platform 700 that is configured to execute instructions to implement the example elements disclosed and described herein. The processor platform 700 may be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, or any other type of computing device. For example, the example processor platform 700 may be used to implement an example FMS and / or other flight path verification processor.
[0062] The processor platform 700 of the illustrated example includes a processor 712 (also referred to as a processor circuit system). The processor 712 of the illustrated example is hardware. For example, the processor 712 can be implemented by an integrated circuit, a logic circuit, a microprocessor, or a controller from any desired family or manufacturer.
[0063] The processor 712 of the illustrated example includes local memory 713 (eg, cache) (which may form part of the memory circuitry). Figure 7 The example processor 712 executes instructions from the memory 713 and the like. The processor 712 of the illustrated example communicates with a main memory (also referred to as a memory circuit system) including a volatile memory 714 and a non-volatile memory 716 via a bus 718. The volatile memory 714 can be implemented by a synchronous dynamic random access memory (SDRAM), a dynamic random access memory (DRAM), a RAMBUS dynamic random access memory (RDRAM), and / or any other type of random access memory device. The non-volatile memory 716 can be implemented by a flash memory and / or any other desired type of storage device. Access to the main memory 714, 716 is controlled by a clock controller.
[0064] The processor platform 700 of the illustrated example also includes an interface circuit 720. The interface circuit 720 may be implemented by any type of interface standard, such as an Ethernet interface, a Universal Serial Bus (USB), and / or a PCI Express interface.
[0065] In the example shown, one or more input devices 722 are connected to the interface circuit 720. The input device(s) 722 permit a user to enter data and commands to the processor 712. The input device(s) may be implemented by, for example, a sensor, microphone, camera (still or video), keyboard, button, mouse, touch screen, track pad, trackball, isopoint, and / or voice recognition system.
[0066] One or more output devices 724 are also connected to the interface circuit 720 of the illustrated example. The output device 724 may be implemented, for example, by a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touch screen, a tactile output device, and / or a speaker). Therefore, the interface circuit 720 of the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.
[0067] The interface circuit 720 of the illustrated example also includes communication devices, such as transmitters, receivers, transceivers, modems and / or network interface cards, which are used to facilitate the exchange of data with an external machine (e.g., any kind of computing device) via a network 726 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular telephone system, etc.).
[0068] The processor platform 700 of the illustrated example also includes one or more mass storage devices 728 (which may also form part of the memory circuitry) for storing software and / or data. Examples of such mass storage devices 728 include floppy disk drives, hard disk drives, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.
[0069] For example, encoded instructions 732 representing instructions executable by processor 712 may be stored in mass storage device 728, in volatile memory 714, in non-volatile memory 716, and / or on a removable tangible computer-readable storage medium such as a CD or DVD.
[0070] Figure 8 yes Figure 7 712. In this example, Figure 7 The processor circuit system 712 is implemented by the microprocessor 800. For example, the microprocessor 800 can implement a multi-core hardware circuit system, such as a CPU, a DSP, a GPU, an XPU, etc. Although it may include any number of example cores 802 (for example, 1 core), the microprocessor 800 of this example is a multi-core semiconductor device including N cores. The cores 802 of the microprocessor 800 can operate independently, or can cooperate to execute machine-readable instructions. For example, machine code corresponding to a firmware program, an embedded software program, or a software program can be executed by one of the cores 802, or can be executed by multiple cores in the cores 802 at the same or different times. In some examples, the machine code corresponding to the firmware program, the embedded software program, or the software program is divided into threads and executed in parallel by two or more of the cores 802. For example, a software program may correspond to a thread executed by Figure 6 A flowchart may represent a portion or all of machine-readable instructions and / or operations.
[0071] The core 802 can communicate via an example bus 804. In some examples, the bus 804 can implement a communication bus to implement communications associated with one (or more) of the cores 802. For example, the bus 804 can implement at least one of an inter-integrated circuit (I2C) bus, a serial peripheral interface (SPI) bus, a PCI bus, or a PCIe bus. Additionally or alternatively, the bus 804 can implement any other type of computing or electrical bus. The core 802 can obtain data, instructions, and / or signals from one or more external devices via an example interface circuit system 806. The core 802 can output data, instructions, and / or signals to one or more external devices via the interface circuit system 806. Although the core 802 of this example includes an example local memory 820 (e.g., a level 1 (L1) cache that can be divided into an L1 data cache and an L1 instruction cache), the microprocessor 800 also includes an example shared memory 810 that can be shared by the core (e.g., a level 2 (L2_cache)) for high-speed access to data and / or instructions. Data and / or instructions may be transferred (eg, shared) by writing to and / or reading from the shared memory 810. The local memory 820 of each of the cores 802 and the shared memory 810 may be a plurality of levels of cache memory and main memory (eg, Figure 7 The cache memory is part of a hierarchy of storage devices (main memory 714, 716). Generally, memory at higher levels in the hierarchy exhibits shorter access times and has smaller storage capacity than memory at lower levels. Changes in various levels of the cache hierarchy are managed (e.g., coordinated) by a cache coherence policy.
[0073] Each core 802 may be referred to as a CPU, DSP, GPU, etc., or any other type of hardware circuit system. Each core 802 includes a control unit circuit system 814, an arithmetic and logic (AL) circuit system (sometimes referred to as an ALU) 816, a plurality of registers 818, an L1 cache 820, and an example bus 822. Other structures may exist. For example, each core 802 may include a vector unit circuit system, a single instruction multiple data (SIMD) unit circuit system, a load / store unit (LSU) circuit system, a branch / jump unit circuit system, a floating point unit (FPU) circuit system, etc. The control unit circuit system 814 includes a semiconductor-based circuit that is configured to control (e.g., coordinate) data movement within the corresponding core 802. The AL circuit system 816 includes a semiconductor-based circuit that is configured to perform one or more mathematical and / or logical operations on data within the corresponding core 802. The AL circuit system 816 of some examples performs integer-based operations. In other examples, the AL circuit system 816 also performs floating-point operations. In yet other examples, the AL circuit system 816 may include a first AL circuit system that performs integer-based operations and a second AL circuit system that performs floating-point operations. In some examples, the AL circuit system 816 may be referred to as an arithmetic logic unit (ALU). The register 818 is a semiconductor-based structure that is used to store data and / or instructions, such as the results of one or more operations performed by the AL circuit system 816 of the corresponding core 802. For example, the register 818 may include (one or more) vector registers, (one or more) SIMD registers, (one or more) general registers, (one or more) flag registers, (one or more) segment registers, (one or more) machine-specific registers, (one or more) instruction pointer registers, (one or more) control registers, (one or more) debug registers, (one or more) memory management registers, (one or more) machine check registers, etc. As shown in FIG. Figure 8 As shown in , registers 818 can be arranged in a memory bank. Alternatively, registers 818 can be organized in any other arrangement, format or structure, including being distributed throughout core 802 to shorten access time. Bus 822 can implement at least one of an I2C bus, an SPI bus, a PCI bus or a PCIe bus.
[0073] Each core 802 and / or, more generally, the microprocessor 800 may include additional and / or alternative structures in addition to those structures shown and described above. For example, there may be one or more clock circuits, one or more power supplies, one or more power gates, one or more cache home agents (CHA), one or more convergence / public mesh stations (CMS), one or more shifters (e.g., (one or more) barrel shifters) and / or other circuit systems. The microprocessor 800 is a semiconductor device that is manufactured to include many transistors that are interconnected to implement the above-mentioned structure in one or more integrated circuits (ICs) contained in one or more packages. The processor circuit system may include one or more accelerators and / or cooperate with one or more accelerators. In some examples, the accelerator is implemented by a logic circuit system to perform the task faster and / or more efficiently than a general-purpose processor can complete certain tasks. Examples of accelerators include ASICs and FPGAs, such as those discussed herein. GPUs or other programmable devices may also be accelerators. The accelerator may be on the processor circuit system, in the same chip package as the processor circuit system, and / or in one or more packages separated from the processor circuit system.
[0074] Fig. 9 yes Figure 7 900. In this example, the processor circuit system 712 is implemented by the FPGA circuit system 900. The FPGA circuit system 900 can be used, for example, to perform operations that can otherwise be performed by executing corresponding machine-readable instructions. Figure 8 However, once configured, FPGA circuitry 900 instantiates machine-readable instructions in hardware and can therefore typically perform operations faster than operations can be performed by a general-purpose microprocessor executing corresponding software.
[0075] More specifically, Figure 8 The microprocessor 800 (which is a general-purpose device that can be programmed to perform the Figure 6 In contrast, a flowchart may represent some or all of the machine-readable instructions, but the interconnections and logic circuitry of the general purpose device are fixed once manufactured. Fig. 9 The example FPGA circuit system 900 includes interconnect and logic circuit systems, which can be configured and / or interconnected in different ways after manufacturing to instantiate, for example, Figure 6In particular, FPGA 900 can be thought of as an array of logic gates, interconnects, and switches. The switches can be programmed to change how the logic gates are interconnected by the interconnects, effectively forming one or more dedicated logic circuits (unless and until FPGA circuitry 900 is reprogrammed). The configured logic circuits enable the logic gates to cooperate in different ways to perform different operations on data received by the input circuitry. Those operations may correspond to the operations performed by Figure 6 Thus, FPGA circuit system 900 can be constructed to effectively Figure 6 Some or all of the machine-readable instructions of the flowchart of the FPGA are instantiated into a dedicated logic circuit, thereby performing the operations corresponding to those software instructions in a dedicated manner similar to an ASIC. Therefore, the FPGA circuit system 900 can perform operations corresponding to the software instructions more efficiently than a general-purpose microprocessor. Figure 6 The operations of some or all of the machine-readable instructions are performed faster than those of the machine-readable instructions.
[0076] exist Fig. 9 In the example of FPGA circuit system 900, FPGA circuit system 900 is configured to be programmed (and / or reprogrammed one or more times) by an end user via a hardware description language (HDL) (eg, Verilog). Fig. 9 FPGA circuit system 900 includes example input / output (I / O) circuits 902 that are used to obtain and / or output data to and from example configuration circuit system 904 and / or external hardware (e.g., external hardware circuit system) 906. For example, configuration circuit system 904 can implement interface circuit system that can obtain machine-readable instructions to configure FPGA circuit system 900 or (one or more) parts thereof. In some such examples, configuration circuit system 904 can obtain machine-readable instructions from a user, a machine (e.g., a hardware circuit system (e.g., a programmed or dedicated circuit system) that can implement an artificial intelligence / machine learning (AI / ML) model to generate instructions), etc. In some examples, external hardware 906 can implement Figure 8 FPGA circuitry 900 also includes an array of example logic gate circuitry 908, a plurality of example configurable interconnects 910, and example storage circuitry 912. Logic gate circuitry 908 and interconnects 910 may be configured to instantiate one or more operations that may correspond to Figure 4-Figure 6 At least some machine readable instructions and / or other desired operations. Fig. 9The logic gate circuit system 908 shown in is manufactured in the form of groups or blocks. Each block includes a semiconductor-based electrical structure that can be configured into a logic circuit. In some examples, the electrical structure includes a logic gate (e.g., an AND gate, an OR gate, a NOR gate, etc.), which provides a basic building block for a logic circuit. An electrically controllable switch (e.g., a transistor) is present in each logic gate circuit system 908 to enable configuration of the electrical structure and / or the logic gate to form a circuit for performing a desired operation. The logic gate circuit system 908 may include other electrical structures, such as a lookup table (LUT), a register (e.g., a flip-flop or a latch), a multiplexer, etc.
[0077] The interconnect 910 of the illustrated example is a conductive path, trace, via, etc., which may include an electrically controllable switch (e.g., a transistor), the state of which may be changed by programming (e.g., using an HDL instruction language) to activate or deactivate one or more connections between one or more of the logic gate circuit system 908, thereby programming the desired logic circuit.
[0078] The storage circuit system 912 of the illustrated example is configured to store (one or more) results of one or more operations performed by corresponding logic gates. The storage circuit system 912 can be implemented by registers, etc. In the illustrated example, the storage circuit system 912 is distributed among the logic gate circuit system 908 to facilitate access and improve execution speed.
[0079] Fig. 9 The example FPGA circuit system 900 also includes an example special operation circuit system 914. In this example, the special operation circuit system 914 includes a special circuit system 916, which can be called to implement common functions to avoid the need to program these functions on site. Examples of such special circuit systems 916 include memory (e.g., DRAM) controller circuit systems, PCIe controller circuit systems, clock circuit systems, transceiver circuit systems, memory, and multiplier-accumulator circuit systems. There may be other types of special circuits. In some examples, the FPGA circuit system 900 may also include an example general programmable circuit system 918, such as an example CPU 920 and / or an example DSP 922. Other general programmable circuit systems 918 may exist additionally or alternatively, such as GPUs, XPUs, etc., which can be programmed to perform other operations.
[0080] As such, the example FPGA circuit system 900 may be used for (re)alignment and / or calibration of multi-laser alignment, stitching, other aspects of additional build execution, programming, etc. In certain examples, the FPGA circuit system 900 may be used for scoring and data processing along with and / or further combined with super logging of data / events, etc.
[0081] Although Figure 8 and Fig. 9 Shows Figure 7 These are two example implementations of the processor circuit system 712, but many other approaches are contemplated. For example, as described above, modern FPGA circuit systems may include an on-board CPU, such as Fig. 9 One or more of the example CPUs 920. Thus, Figure 7 The processor circuit system 712 can also be combined Figure 8 An example microprocessor 800 and Fig. 9 In some such hybrid examples, the Figure 6 The first portion of the machine-readable instructions represented by the flowchart may be represented by Figure 8 802 and is executed by one or more cores 802 of Figure 6 The second portion of the machine-readable instructions represented by the flowchart may be represented by Fig. 9 FPGA circuit system 900 executes.
[0082] Fig.10 A block diagram is shown in FIG. 1 , which shows an example software distribution platform 1005 that will, for example, Figure 7 The example software distribution platform 1005 may be implemented by any computer server, data facility, cloud service, etc. capable of storing and transmitting software to other computing devices. The third party may be a consumer of the entity that owns and / or operates the software distribution platform 1005. For example, the entity that owns and / or operates the software distribution platform 1005 may be, for example, Figure 7 The third party may be a consumer, user, retailer, OEM, etc., who purchases and / or licenses the software for use and / or resale and / or sublicense. In the illustrated example, the software distribution platform 1005 includes one or more servers and one or more storage devices. As described above, the storage device stores the machine-readable instructions 732, which may correspond to Figure 6One or more servers of the example software distribution platform 1005 communicate with the example network 1010, which may correspond to any one or more of the Internet and / or any of the example networks described above. In some examples, as part of a commercial transaction, one or more servers respond to a request to transfer software to a requestor. Payment for the delivery, sale, and / or license of the software may be processed by one or more servers of the software distribution platform and / or a third-party payment entity. The server enables a purchaser and / or licensor to download machine-readable instructions 732 from the software distribution platform 1005. For example, it may correspond to Figure 6 The example machine readable instructions of software can be downloaded to the example programmable circuit system platform 700, which will execute the machine readable instructions 732 to implement the example flight path verification processor 420. In some examples, one or more servers of the software distribution platform 1005 periodically provide, transmit and / or force updates to the software (e.g., Figure 7 Example machine readable instructions 732 of the system) to ensure that improvements, patches, updates, etc. are distributed and applied to the software at the end-user device. Although referred to as software above, the distributed "software" may alternatively be firmware.
[0083] In light of the foregoing, it will be appreciated that the methods, apparatus, and articles of manufacture disclosed above have been disclosed to provide new, improved apparatus and associated methods for flight path validation. Image data, sensor data, historical data, and (one or more) physics-based flight models may be generated to automatically process and assess flight capabilities and hazards imposed by a flight path. For example, the flight path may be a new flight path to be validated and / or an existing flight path to be revalidated. Current approvals rely on actual flights and manual analysis, and are unable to process images and other data as described herein, or to model a flight path and its associated environment within a confined area. Certain examples provide improved, faster, model-based approvals without the same risks to pilots, aircraft, and surroundings found in current methods.
[0084] Although certain example methods, apparatus, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, and articles of manufacture that fully fall within the scope of the claims of this patent.
Claims
1. A device comprising: Memory circuit system; at least one processor circuitry programmed with instructions to: processing the input to determine an enclosed region having a lower altitude limit and lateral boundaries for a flight path from a first location to a second location; generating a flight capability assessment using a flight physics model that models movement of an aircraft along the flight path through the enclosed area; generating a hazard assessment regarding the enclosed area along the flight path; processing the flight path using the flight capability assessment and the hazard assessment to determine a validation of the flight path; as well as An indication of the validation of the flight path and a definition of the flight path are output.
2. The device according to claim 1, wherein: The validation includes at least one of validation of a new flight path or revalidation of an existing flight path.
3. The device according to claim 1, wherein: Determining the validation includes accepting the flight path or rejecting the flight path.
4. The device according to claim 1, wherein: The flight physics model is constructed based on at least one of a weighted factor analysis or a trained artificial intelligence model.
5. The device according to claim 1, wherein: The at least one processor circuitry determines a priority assessment for the flight path.
6. The device according to claim 1, wherein: The output is provided to a flight management system.
7. The device according to claim 1, wherein: Generating the hazard assessment includes processing at least one of imagery or radar data to identify hazards within the enclosed area along the flight path.
8. At least one non-transitory computer-readable storage medium comprising instructions that, when executed, cause at least one processor circuit system to at least: processing the input to determine an enclosed region having a lower altitude limit and lateral boundaries for a flight path from a first location to a second location; generating a flight capability assessment using a flight physics model that models movement of an aircraft along the flight path through the enclosed area; generating a hazard assessment regarding the enclosed area along the flight path; processing the flight path using the flight capability assessment and the hazard assessment to determine a validation of the flight path; as well as An indication of the validation of the flight path and a definition of the flight path are output.
9. The at least one non-transitory computer-readable storage medium of claim 8, wherein: The validation includes at least one of validation of a new flight path or revalidation of an existing flight path.
10. The at least one non-transitory computer-readable storage medium of claim 8, wherein: Determining the validation includes accepting the flight path or rejecting the flight path.