Integrated system of systems simulation framework for aircraft

Abstract

A computer-implemented method for simulating an aircraft system in a closed-loop functional simulation environment is disclosed. The computer-implemented method may include: receiving, at a computer system, one or more control inputs from an interface; processing, by a control system model, the one or more control inputs to generate one or more system command signals; applying the one or more system command signals to one or more virtual system models; simulating a physical response of the aircraft based on output generated by the one or more virtual system models in response to application of the one or more system command signals; generating, responsive to monitoring the output generated by the one or more virtual system models, sensor data; transmitting the sensor data to the control system model; and outputting simulation results, wherein the simulation results at least comprise an indication of the physical response of the aircraft.

Description

INTEGRATED SYSTEM OF SYSTEMS SIMULATION FRAMEWORK FOR AIRCRAFTCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63 / 656,201 filed June 5, 2024, which is incorporated by reference herein in its entirety.TECHNICAL FIELD

[0002] Various aspects of the present disclosure relate generally to simulation technologies for advanced aerial vehicles, and more particularly, to an integrated, model-based, system-of-systems simulator for electric vertical take-off and landing (eVTOL) aircraft incorporating full closed-loop simulation of hardware, software, physics-based dynamics, and avionics systems.INTRODUCTION

[0003] eVTOL aircraft are emerging as a cornerstone of the Advanced Air Mobility (AAM) landscape. The development of such aircraft involves complex integration of highly interdependent subsystems - propulsion, flight controls, energy storage, actuation, and thermal systems, among others. Existing simulators focus primarily on flight dynamics and control system evaluation in isolation, lacking the fidelity and integration necessary for system-level validation, failure mode testing, or pilot-in-the-loop assessments. Accordingly, there is a need for a high-fidelity, integrated simulation environment that unifies all relevant physical, software, and electrical systems into a cohesive framework.

[0004] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art, or suggestions of the prior art, by inclusion in this section.SUMMARY OF THE DISCLOSURE

[0005] According to certain aspects of the disclosure, systems and methods are disclosed for providing an intelligent control and coordination hub for UAM operations.

[0006] In one embodiment, the present disclosure is drawn to a computer- implemented method for simulating an aircraft system in a closed-loop functional simulation environment, including: receiving, at a computer system, one or more control inputs from an interface; processing, using one or more processors associated with the computer system and by a control system model associated with the computer system, the one or more control inputs to generate one or more system command signals; applying, using the one or more processors, the one or more system command signals to one or more virtual system models, wherein each of the one or more virtual system models represent a subsystem of an aircraft; simulating, using the one or more processors, a physical response of the aircraft based on output generated by the one or more virtual system models in response to application of the one or more system command signals; generating, using the one or more processors and responsive to monitoring the output generated by the one or more virtual system models, sensor data; transmitting, using the one or more processors, the sensor data to the control system model; and outputting, using theone or more processors, simulation results, wherein the simulation results at least comprise an indication of the physical response of the aircraft.

[0007] Various aspects of the present disclosure may also include: wherein the interface is one of a virtual interface or a physical interface; further including: wherein the one or more virtual system models comprise: a thermal system model, an actuation system model, an energy system model, a powertrain system model, and a flight dynamics model; further including: generating, using the one or more processors and by modifying the one or more system command signals based on the sensor data, one or more updated system command signals; and simulating, using the one or more processors, the physical response of the aircraft based on additional output generated by the one or more virtual system models in response to the application of the one or more updated system command signals; further including: introducing, using the one or more processors, one or more faults into the sensor data; and identifying, using the one or more processors, degradation of a subsystem resultant from the introduction of the one or more faults via identifying a deviation of a simulated operating condition of the subsystem from an on-design operating condition of the subsystem; further including: executing, using the one or more processors, a fault detection and isolation protocol at the control system model; and isolating, using the one or more processors, an isolation protocol responsive to detecting one or more anomalies in the sensor data; further including: interfacing, using the one or more processors, one or more of the virtual system models with one or more physical hardware components; wherein the one or more physical hardware components are configured to transmit and receive signals to and from the closed- loop functional simulation environment; further including: wherein the control system model comprises compiled flight control software hosted on a real-time operatingenvironment; further including: wherein the interface comprises a physical or simulated cockpit control system; and wherein the closed-loop functional simulation environment is configured to accept live user input during execution; and further including: wherein the outputting the simulation results comprises: displaying a virtual cockpit instrument panel; and generating a real-time visualization of the aircraft behavior in a three-dimensional environment on the instrument panel.

[0008] In another embodiment, the present disclosure is drawn to a system for simulating an aircraft system in a closed-loop functional simulation environment, including: a memory including instructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: receiving one or more control inputs from an interface; processing, by a control system model associated with the aircraft system, the one or more control inputs to generate one or more system command signals; applying the one or more system command signals to one or more virtual system models, wherein each of the one or more virtual system models represent a subsystem of an aircraft; simulating a physical response of the aircraft based on output generated by the one or more virtual system models in response to application of the one or more system command signals; generating, responsive to monitoring the output generated by the one or more virtual system models; sensor data; transmitting the sensor data to the control system model; and outputting simulation results to one or more display modules, wherein the simulation results at least comprise an indication of the physical response of the aircraft.

[0009] Various aspects of the present disclosure may also include: wherein the aircraft is an electric vertical take-off and landing vehicle (eVTOL); further including: wherein the one or more virtual system models comprise: a thermalsystem model, an actuation system model, an energy system model, a powertrain system model, and a flight dynamics model; further including: wherein the instructions are further executable by the at least one processor to perform operations comprising: generating, by modifying the one or more system command signals based on the sensor data, one or more updated system command signals; and simulating the physical response of the aircraft based on additional output generated by the one or more virtual system models in response to the application of the one or more updated system command signals; and further including: wherein the instructions are further executable by the at least one processor to perform operations comprising: introducing one or more faults into the sensor data; and identifying degradation of a subsystem resultant from the introduction of the one or more faults via identifying a deviation of a simulated operating condition of the subsystem from an on-design operating condition of the subsystem.

[0010] In another embodiment, the present disclosure is drawn to a computer- implemented method for simulating and testing a target system within a multi-system simulation environment, including: configuring, using one or more processors, a simulation environment to represent a target system and one or more adjacent systems; initializing, using the one or more processors, the simulation environment by applying predefined internal initial states to one or more components of the target system; executing, using the one or more processors, a driver to apply input events and / or environmental conditions to the target system and one or more of the adjacent systems; simulating, using the one or more processors and responsive to the executing, a response of the target system; generating, using the one or more processors, one or more simulation outputs indicative of behavior of the target system based on the response; and evaluating, using the one or more processors,performance of the target system by comparing a set of expected outputs against the one or more simulation outputs.

[0011] Various aspects of the present disclosure may also include: wherein the simulation environment comprises: a system software module, an interface unit, a plant model, and a sensor model; and further including: wherein the simulation the responsive of the target system comprises: receiving, at the target system, one or more scenario inputs and simulated data from the one or more adjacent systems; generating, via a system software module, one or more control signals; updating a plant model based on the one or more control signals; generating updated sensor data from a sensor model; and introducing the sensor data back to the system software module.

[0012] In another embodiment, the present disclosure is drawn to a system for simulating and testing a target system within a multi-system simulation environment, including: a memory including instructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: configuring a simulation environment to represent a target system and one or more adjacent systems; initializing the simulation environment by applying predefined internal initial states to one or more components of the target system; executing a driver to apply input events and / or environmental conditions to the target system and one or more of the adjacent systems; simulating, responsive to the executing, a response of the target system; generating, one or more simulation outputs indicative of behavior of the target system based on the response; and evaluating performance of the target system by comparing a set of expected outputs against the one or more simulation outputs.

[0013] Various aspects of the present disclosure may also include: wherein the multi-system simulation environment is hosted on a distributed computing platform and wherein the distributed computing platform enables real-time interaction between the target system and the one or more adjacent system.

[0014] Additional objects and advantages of the disclosed embodiments will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

[0015] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and together with the description, serve to explain the principles of the disclosed embodiments.

[0017] FIG. 1 depicts an exemplary system architecture of a functional simulator designed to emulate an aircraft, according to one or more aspects of the present disclosure.

[0018] FIG. 2 depicts an exemplary diagram that illustrates how individual aircraft systems may be tested, according to one or more aspects of the present disclosure.

[0019] FIG. 3 depicts an exemplary workflow for configuring the internal conditions of a system under test, according to one or more aspects of the present disclosure.

[0020] FIG. 4 depicts an exemplary workflow for adding additional systems to the functional simulator, according to one or more aspects of the present disclosure.

[0021] FIG. 5 depicts an exemplary workflow for simulating an aircraft system in a closed-loop simulation environment, according to one or more aspects of the present disclosure.

[0022] FIG. 6 depicts an exemplary workflow for configuring a simulation environment to represent a target system and one or more adjacent systems, according to one or more aspects of the present disclosure.

[0023] FIG. 7 depicts an exemplary computing system, according to one or more aspects of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[0024] Both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the features, as claimed. As used herein, the terms “comprises,” “comprising,” “has,” “having,” “includes,” “including,” or other variations thereof, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements, but may include other elements not expressly listed or inherent to such a process, method, article, or apparatus. In this disclosure, unless stated otherwise, relative terms, such as, for example, “about,” “substantially,” and “approximately” are used to indicate a possiblevariation of ±10% in the stated value. In this disclosure, unless stated otherwise, any numeric value may include a possible variation of ±10% in the stated value.

[0025] The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

[0026] Modern aircraft, especially electric vertical take-off and landing (eVTOL) vehicles represent a fundamental departure from traditional aerospace architectures. Unlike conventional rotorcraft or fixed-wing aircraft, which rely on legacy propulsion technologies and mechanical control linkages, eVTOL systems are usually multi-domain and distributed. They typically incorporate electric propulsion systems, multiple tilting rotors or vectored thrust configurations, distributed actuation, large-scale battery arrays, thermal management systems, advanced avionics, and fly-by-wire control logic. This results in a tightly coupled system-of-systems architecture in which mechanical, electrical, software, and human-machine interface components interact in complex and often nonlinear ways.

[0027] Historically, simulation tools used during aircraft development have been built around compartmentalized models. For instance, flight dynamics models are typically developed and analyzed in isolation to design and verify stability and control characteristics. Subsystems such as propulsion, electrical power, or thermal control are modeled separately, often using domain-specific tools with limited interoperability. While model-based design tools like Simulink have enabled greater fidelity in control software development and preliminary system modeling, theseapproaches have not been extended to create an integrated simulation of the complete aircraft as a closed-loop system. Consequently, subsystem interactions are often approximated or neglected altogether, leaving developers to rely on integration testing, which often involves real hardware late in the program (e.g., when the program is being deployed on a live vehicle), to uncover systemic failures or unexpected behaviors.

[0028] These limitations may be particularly prevalent in eVTOL programs. Specifically, the high degree of software-dependency, dynamic interdependence, and novel configurations make early integration testing both necessary and difficult. Traditional simulation frameworks do not support real-time, cross-domain feedback between subsystems, nor do they facilitate the introduction of failure scenarios, fault injection, or degraded mode operation in a realistic, system-wide context. Additionally, they are ill-suited for incorporating vendor-supplied or subsystem models, and generally lack the interfaces required for hardware-in-the-loop (HIL), software-in-the-loop (SIL), or pilot-in-the-loop (PIL) testing. As a result, program risk is elevated, development timelines are extended, and critical design flaws may go undetected until costly and high-risk flight test phases.

[0029] Various attempts have been made to improve simulation fidelity through the use of Model-Based Systems Engineering (MBSE) practices, digital twins, and modular test benches. MBSE tools (e.g., Cameo, System Composer, etc.) may be used to define system architecture and requirements, but they are typically descriptive and not executable in a physics-based simulation sense. Digital twins often focus on post-deployment diagnostics or predictive maintenance, rather than supporting iterative design or real-time systems testing. Standalone test benches enable some level of HIL or SIL testing, but they remain limited to individualsubsystems and are not scalable to the full aircraft configuration. Additionally, these conventional simulations are inherently fragmented. More particularly, they lack realtime feedback between subsystems, have minimal support for fault injection or anomaly propagation, and cannot represent the closed-loop interactions between flight software and physical components under realistic dynamic loads. Moreover, these tools often omit or oversimplify hardware interfaces and operational context such as pilot inputs, cockpit switches, or communication latencies across avionics buses.

[0030] The limitations of these isolated approaches may create significant blind spots in the development cycle. For example, a subsystem may perform well in isolation but may behave unpredictably when integrated with real-time electrical or thermal loads from adjacent systems. Control laws optimized in an idealized model may destabilize when subjected to noisy sensor data or delayed actuator feedback. Importantly, the absence of an integrated testing environment delays fault detection and increases the cost and risk of flight testing.

[0031] To address these or other shortcomings, the concepts described herein provide a functional simulator - an integrated simulation environment designed to emulate some or all major systems and subsystems of an eVTOL aircraft in a closed-loop, high-fidelity, and real-time executable model. The functional simulator described herein may extend the traditional control system development processes by integrating detailed dynamic models of flight mechanics, actuation systems, electric propulsion, energy storage and management, thermal regulation, avionics, flight control software, and pilot interfaces into a single executable simulation environment. This environment may be implemented in various high-performance computing environments (e.g., MATLAB, Simulink, etc.) and may also be augmentedby one or more modeling and analysis tools such as FLIGHTLAB for rotorcraft aerodynamics and GT-SUITE for thermal / fluid systems.

[0032] Unlike traditional simulation frameworks, the functional simulator described herein may enable real-time, or near real-time, bidirectional coupling between subsystem models, thereby allowing for the dynamic interaction of load conditions, control responses, and energy or thermal constraints across the system. In an aspect, the functional simulator may support SIL testing for both control and system-level flight software, HI L validation by simulation of actual avionics components, and PIL procedures development through emulated cockpit switches, inceptors, and display logic. In an aspect, the functional simulator may also facilitate failure mode analysis and fault injection, allowing anomalies to be introduced at the signal, component, or system level to evaluate the behavior of redundant systems, error recovery mechanisms, and crew alert system (CAS) logic.

[0033] The subject matter of the present disclosure will now be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments. An embodiment or implementation described herein as “exemplary” is not to be construed as preferred or advantageous, for example, over other embodiments or implementations; rather, it is intended to reflect or indicate that the embodiment(s) is / are “example” embodiment(s). Subject matter may be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any exemplary embodiments set forth herein; exemplary embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices,components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof. The following detailed description is, therefore, not intended to be taken in a limiting sense.

[0034] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter include combinations of exemplary embodiments in whole or in part.

[0035] The terminology used below may be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the present disclosure. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

[0036] In the context of this disclosure, identification of a degradation in performance may refer to a deviation from an on-design operating condition of a system or component. The on-design condition may represent the nominal or intended level of efficiency, output, thermal load, or timing behavior for a given subsystem (e.g., a motor, battery, actuator, thermal management unit (TMU), etc.) under standard or optimal operational parameters. Degradation may manifest as a measurable reduction in efficiency (e.g., increased power draw for a given output), a shift in thermal behavior (e.g., elevated steady-state temperatures or faster thermal rise rates), increased actuation latency (e.g., longer cycle times), or excess demandon ancillary systems (e.g., cooling subsystems operating above nominal load). Such deviations may be quantified relative to the on-design state using sensor feedback, simulated baselines, and / or predefined performance thresholds. In various aspects, these degradations may propagate through interconnected subsystems, leading to compounding effects that may impact aircraft operability and / or control system performance, e

[0037] FIG. 1 depicts an exemplary system architecture (“system” or “computer system”) 100 of a functional simulator designed to emulate an eVTOL aircraft as a system-of-systems. System 100 may integrate multiple subsystems under closed-loop dynamics, supporting SIL, HIL, and PIL simulations. System 100 may achieve such functionalities by implementing, on one or more computing devices, pilot controls subsystem 105, flight control computer subsystem 110, aircraft subsystem 115, sensor subsystem 120, and output subsystem 125. In an aspect, each of the foregoing subsystems 105-125 may be specifically configured to simulate its corresponding physical or functional counterpart. In an aspect, each of the foregoing subsystems 105-125 may contain one or more functional modules, which are further described herein, that may be needed for carrying out a particular task related to the module’s respective subsystem.

[0038] Pilot controls subsystem 105 may model the physical interface devices used by human operators, including cyclic sticks, collective throttles, rudder pedals, and multifunction button interfaces. Inputs from these devices may be mapped to command variables used in flight control logic. The pilot controls subsystem 105 may support both nominal operation and fault conditions such as stuck inputs, debounce failures, and uncommanded deflections. Pilot controls sub system 105 may allow for manual and scripted control input profiles to support both human-in-the-loopevaluations and automated regression testing. This capability may enable the development of intuitive flight handling characteristics, workload assessments, and emergency procedure refinement.

[0039] In an aspect, the inceptors module 1051 may represent the pilot’s primary flight control interface within the pilot controls subsystem 105. For example, inceptors module 1051 may be modeled to simulate pilot intent and translate it into digital command signals, e.g., altitude, velocity, force directives, and the like. In an aspect, inceptors module 1051 may be configured to support PIL testing, enabling real-time human inputs using hardware controls or virtual inputs through a simulation interface. These inputs may be utilized to evaluate control law performance, handling qualities, and pilot workload.

[0040] In an aspect, the cockpit switches module 1052 may model all non- inceptor pilot controls, such as hardwired switches, knobs, touch panels, and rotary encoders. These switches may control systems such as electrical power distribution, propulsion arming, lighting, and avionics mode selection. In an aspect, the cockpit switches module 1052 may support manual and automated switching sequences to validate pilot procedures for startup, shutdown, mode transitions, and emergency actions.

[0041] Flight control computer subsystem 110 may be the central computational element that is responsible for executing the aircraft’s core control laws and flight decision logic within the system 100. Flight control computer subsystem 110 may be configured to ingest real-time inputs from the pilot controls subsystem 105 and sensors subsystem 120 to generate precise command signals for downstream subsystems, including the various modules 1501-1505 in the aircraft subsystem 115. In this regard, flight control computer subsystem 110 may leveragecontrol laws module 1151 to support multi-mode control algorithms, which may allow seamless transition between different flight regimes such as hover, vertical-to- horizontal transition, and forward cruise. These algorithms may include logic for control allocation, stability augmentation, flight mode switching, and trajectory tracking.

[0042] In an aspect, the control modes and control gains may be further refined and tuned depending on: how the pilot needs to fly the aircraft, the application of the controller, how the aircraft is being used, and flight conditions under which the aircraft will be expected to operate. For instance, for high speed forward flight, the control algorithms may be configured to provide pitch and roll rate control to behave like a fixed wing aircraft. For hover flight, the control laws may provide stabilized feedback similar to a helicopter, or even provide more velocity control to make the flying task easier. For intermediate transition speeds, a different control mode may be used to bridge the behavior between hover and fixed wing flight.

[0043] Aircraft subsystem 115 may be the part of system 100 that models the functionality of the physical parts of the aircraft, e.g., the components that move, generate power, respond to the environment, and ultimately keep the vehicle flying, in response to a specific simulation scenario. In an aspect, aircraft subsystem 115 may contain a plurality of key modules, including: the thermal module 1501 , the energy module 1502, the powertrain module 1503; the actuation module 1504; and the flight dynamics module 1505. Collectively, these modules may respond in realtime to commands from the flight control computer subsystem 1 10. For example, when the flight control computer subsystem 110 tells a motor to spin or a surface to tilt in accordance with a simulated flight scenario, the aircraft subsystem 115 maysimulate how that would happen physically, taking into account electrical limits, aerodynamic forces, and thermal effects, for example.

[0044] In an aspect, the thermal module 1501 may simulate how heat is generated and managed throughout the aircraft, such as during high-power operations like takeoff or hover. In an aspect, the thermal module 1501 may model thermal sources that are directly tied to components such as the motors and inverters, meaning when these systems are under greater strain, they produce more heat. To control this, the thermal module 1501 may include a cooling loop system that simulates the behavior of pumps, fans, and fluid accumulators, working together to move coolant and keep critical parts from overheating. The thermal module 1501 may also include sensors that monitor things like temperature, pressure in the cooling loop, coolant fluid levels, and the electrical supply to the cooling system. Accordingly, the thermal module 1501 may simulate a resultant effect of the failure of any part of the thermal management system, e.g., as a result of a broken fan, a leak in a fluid line, overheating of a component, etc., showing how the system 100 would respond or degrade in performance (e.g., relative to on-design performance parameters). For instance, if a battery capacity drops below X% of its on-design condition, the motor may draw Y% more current to maintain the same output, causing a temperature increase of Z°C. In an aspect, to reflect how real aircraft systems communicate, the thermal module 1501 may include a data interface unit that handles both digital and analog signals, allowing it to send and receive commands and status updates to other systems. This makes it possible to test how thermal behavior affects aircraft performance and to ensure that warning systemsand emergency responses work correctly during overheating scenarios or system faults.

[0045] In an aspect, energy module 1502 may simulate the aircraft’s full battery system, from the individual cells to the complete pack, to show how electrical energy is stored, managed, and delivered during various flight scenarios. At the cell level, energy module 1502 may model how each battery cell behaves under different conditions, taking into account real chemical, thermal, and electrical effects (e.g., such as how fast a battery can discharge, how it heats up, and how it wears down over time). In a pack-level model, these cells may be grouped into modules and, which may simulate how they work together and how current flows across them. Energy module 1502 may also track thermal behavior throughout the battery system, including the temperature of cells, modules, and busbars, and how heat may be removed through built-in cooling systems.

[0046] In an aspect, energy module 1502 may also include sensor data synchronization, modeling the kinds of timing delays, noise, and signal mismatches that happen in real battery systems during different situations. In an aspect, energy module 1502 may support fault injection, such as simulating a bad cell or overheating condition, and may also include failure effects, like power loss or reduced performance. Energy module 1502 may also handle both high-voltage and low-voltage distribution, deciding how power gets routed to the other modules in aircraft subsystem 1 15 in specific simulated scenarios. In an aspect, a data interface unit may be associated with energy module 1502 to simulate how battery data is encoded and transmitted to other subsystems, thereby mimicking real communication protocols. In an aspect, energy module 1502 may also accommodate different flight profiles (e.g., aggressive takeoffs, steady cruise, emergency landings,etc.) and may calculate how energy demands rise or fall in each case. Lastly, energy module 1502 may further account for transient behaviors, state delays, clock drift, and how systems interact in real-time.

[0047] In an aspect, powertrain module 1503 may simulate the system that generates thrust and lift for the aircraft, turning electrical power into motion. Powertrain module 1503 may include key components such as the inverter (which converts electrical energy into a usable form), the electric motor (which drives rotation), the gearbox (which adjusts torque and speed), and the rotor system, including the swashplate that controls blade pitch for lift and maneuvering. In an aspect, powertrain module 1503 may be tightly coupled with the aerodynamic load — meaning that the powertrain module 1503 also simulates how the air pushes back against spinning parts. In practice, air resistance (or air load) may be the largest force acting on the powertrain, and the powertrain module 1503 may calculate how that affects the performance of the motors and gear systems. When the aircraft flies, especially in hover or climb, this load increases and impacts how hard the motors must work, how much power they draw, and how they respond to control commands. By modeling these interactions, the powertrain module 1503 may help test motor performance, energy use, and control response under real-world flying conditions, including heavy loads and rapid changes in thrust.

[0048] In an aspect, the actuation module 1504 may simulate the aircraft’s moving parts that physically respond to control commands, such as control surfaces (like ailerons or rudders), conversion mechanisms (used for tilting rotors or wings), and the swashplate, which adjusts the rotor blade angles for lift and maneuverability. In an aspect, each actuator may be modeled not just as a simple moving part but as a full system that includes both the mechanical actuator and its internal controller,which manages how fast and how far it moves based on commands from the flight control computer subsystem 110. In an aspect, the actuation module 1504 may also account for mechanical stress and aerodynamic forces by being coupled with the flight dynamics module 1505, meaning that the actuation module 1504 may receive real-time feedback on how much resistance the actuator is facing from air pressure and the aircraft’s motion. This may make the simulation more realistic. For instance, an actuator might respond more slowly or behave differently under heavy loads or at high speeds. By modeling these physical responses and internal control behaviors, the actuation module 1204 may help ensure the aircraft can be safely and precisely controlled in all flight conditions.

[0049] In an aspect, the flight dynamics module 1505 may be responsible for modeling how the aircraft actually moves through the air in response to forces and control inputs. Flight dynamics module 1505 may start with the equations of motion, which are mathematical formulas used to calculate the aircraft’s position, orientation, speed, and acceleration over time. These calculations may be performed in an Oblate Earth axis system, which may account for the Earth's shape and curvature, and may be influenced by an embedded atmospheric model that includes wind, air density, and altitude effects. On top of this base, a detailed aerodynamic simulation may be layered using a third-party tool that models complex aerodynamic behaviors (e.g., FLIGHTLAB, etc.). This may include how rotor forces and torques, body-airflow interactions, translational lift, ground effect, and landing gear forces impact the aircraft, especially at low altitudes and during hover. As the aircraft speeds up, the dynamics shift — control surfaces like ailerons and elevators become more effective, and aerodynamic loads provide feedback to actuators and propulsion systems, such as swashplate actuators and motor torque control. In an aspect, flight dynamicsmodule 1505 may simulate the transition from hover to forward flight, which is an important and complex phase for powered-lift aircraft. At even higher speeds, forces on the wings and fuselage may become dominant. The flight dynamics module 1505 may ensure that all these behaviors are accurately represented so the simulator can respond realistically to pilot inputs, control system commands, and environmental conditions across the full flight envelope.

[0050] Sensors subsystem 120 may represent the collection of simulated sensing systems that provide the state awareness necessary for the aircraft’s autonomous operation, flight control, and health monitoring. Sensors subsystem 120 may include detailed models of multiple sensor categories, reflecting real-world avionics and airframe instrumentation. Sensor subsystem 120 may encompass mechanical and structural sensors such as landing gear position sensors 1101 , which may indicate ground contact and gear state; powertrain sensors 1102, which may monitor motor status, torque, RPM, and electrical loads; navigation systems sensors 1103 such as GPS / GNSS receivers, inertial navigation systems (INS), and magnetometers for aircraft position and orientation tracking; and air data sensors 1104. In an aspect, modules 1501 - 1505 may generate responses to actuator and motor commands transmitted by flight control computer subsystem 110. These responses may be in the form of simulated physical behaviors, which may be transmitted to sensor subsystem 120 and read by the appropriate sensor module 1201-1204. Sensor data generated from this analysis may be fed back to the flight control computer subsystem 110, thereby closing the loop.

[0051] Output subsystem 125 may show what is happening during a test and may help users understand how the aircraft and its systems are behaving. Output subsystem 125 may include everything from visual feedback for the pilot to detaileddata that engineers can analyze afterward. One part of output subsystem 125 may include instruments module 1251 , which may handle the instruments seen in the cockpit (e.g., flight displays, alert messages, etc., so pilots or testers may see simulated altitude, speed, warnings, and system statuses just as they would in a real aircraft. Output subsystem 125 may also include an analysis module 1252, which may be configured to collect data throughout the simulation and generate plots, logs, and performance summaries that help identify issues, validate behaviors, and / or support design decisions. Output subsystem 125 may further include a visualization module 1253, which may include 3D views of the aircraft in flight or other visual tools to help users track how the aircraft responds over time.

[0052] In FIG. 1 , the arrows show how information flows between different parts of the simulation. In this regard, the flow may start with the pilot controls subsystem 105, e.g., from the provision of input via interaction with inceptors and / or cockpit switches. These inputs may be sent to the flight control computer subsystem 110, which may then send control commands, e.g., such as how much thrust to apply or how to tilt a rotor, to the aircraft subsystem 115, where the different modules may simulate how the aircraft physically reacts. These modules may respond and send updated performance or state data back through sensors, which report conditions like speed, altitude, or motor status. That sensor data may flow back into the flight control computer subsystem 110, closing the loop so it can continuously adjust commands based on how the aircraft is behaving. Finally, information may bepassed to the output subsystem 125, where it's displayed to the pilot on instruments or recorded for analysis.

[0053] Although not illustrated in FIG. 1 , system 100 may further include some or all of the following subsystems, modules, and / or components.

[0054] The warning and alerts subsystem, also known as the Crew Alert System (CAS), may model the logic used to notify the pilot of system failures, degradations, and other important events. The warning and alerts subsystem may integrate with virtually all subsystems described herein to monitor state variables and trigger warning messages based on pre-defined thresholds, logic conditions, or event sequences. In an aspect, outputs from this subsystem may be modeled as discrete alert signals and associated textual / audio messages routed to pilot displays and annunciators. The simulation may support failure injection, delayed alerts, false positives, and cascading failure scenarios to evaluate subsystem accuracy, timeliness, and pilot workload under duress.

[0055] Avionics bus interface modeling subsystem may provide detailed simulation of digital communication protocols used between avionics components. This subsystem may simulate bus scheduling, frame structure, transmission delays, encoding schemes, bit-level timing, and fault scenarios like bus contention or dropout. The avionics bus interface modeling may enable hardware-in-the-loop testing of Line Replaceable Units (LRUs) and supports simulation of end-to-end message paths. The bus modeling infrastructure includes capabilities for message injection, frame logging, and protocol compliance verification, serving as a test harness for embedded software under representative communication conditions.

[0056] Avionics system and flight software subsystem may model the redundant computing architecture and onboard system software that orchestratesaircraft operations outside of the control laws. Avionics system and flight software subsystem may include logic for power distribution management, system initialization, debounce filtering, signal validation, and inter-module communication. In an aspect, redundant software instances may be supported to simulate multicomputer architectures. The system 100 may allow injection of faults such as delayed startup, data desynchronization, logical race conditions, and mid-flight computer restarts. This enables evaluation of timers, system reset strategies, and data synchronization robustness across fault-tolerant avionics architectures.

[0057] The command and control subsystem may model the radio frequency or wired communications link between the aircraft and a ground station. The command and control subsystem may include message encoding, transmission delays, bandwidth constraints, signal dropout, and recovery behavior. The GCS component nay include a real hardware interface or a virtual simulation of command uplinks and telemetry downlinks. The command and control subsystem may enable closed-loop testing of remote pilot commands, command prioritization logic, and system behavior under intermittent connectivity. Failures such as control lag, partial data loss, and degraded control authority can be simulated to evaluate pilot response and system fallback modes.

[0058] The failure modeling subsystem may introduce fault injection mechanisms across all levels of the system 100. Failure modeling subsystem may allow for the simulation of partial or complete failures of hardware components, signal anomalies, sensor degradations, electrical faults, thermal excursions, and software malfunctions. Faults may be manually triggered, randomly injected, or scheduled via scenario profiles. The failure modeling subsystem may include logic to monitor downstream system responses, trigger CAS alerts, and evaluate pilotreaction and recovery protocols. Cascading failures and fault propagation through interconnected systems may be supported, enabling full evaluation of system robustness and redundancy logic in complex operational contexts.

[0059] Referring now to FIG. 2, diagram 200 illustrates how individual aircraft systems may be tested, according to one or more aspects of the present disclosure. On the left side of diagram 200, a schematic 205 is presented that represents a simplified aircraft-level system architecture that includes three interacting subsystems: System A 2051 , System B 2052, and System C 2053. In this context, System B 2052 has been designated as the system under test (SUT), meaning that it is the focus of the current testing activity. In a real aircraft, System B 2052 would not operate in isolation, but rather, it would rely on dynamic inputs and outputs exchanged with neighboring systems. Utilization of the functional simulator may enable realistic recreation of the environment around the SUT, enabling it to behave as it would in the full aircraft system, even if the actual neighboring systems are not physically present.

[0060] On the right side of diagram 200, schematic 210 illustrates how the functional simulator may provide wrap-around coverage for the SUT by recreating its operational context using a modular digital simulation framework. Schematic 210 depicts internal simulated representations of the components inside System B 2052, which may include: system software 2101 (e.g., the control logic or embedded code running in / on the system), interface unit 2102 (e.g., the communication interface between the system and the rest of the aircraft), plant model 2103 (e.g., the model representing what the system does in the real world), and sensors 2104 (e.g., simulated instruments providing measurements to the software). Subsystem 1 maycorrespond to System B 2052, and subsystems 2 and 3 may correspond to Systems A 2051 and C 2053, respectively.

[0061] Referring concurrently to FIG. 3, at step 305, the functional simulator may configure the initial internal conditions of the SUT (i.e., System B 2052) so that components of the SUT begin the simulation in a known and controlled condition. More particularly, each of the components 2101 - 2104 may be set to specific values that align with a starting point of an intended simulation scenario. This ensures that the SUT behaves as if it is already in the correct mode, environment or flight phase (e.g., such as idle on the ground, in steady cruise, mid-maneuver, etc.) when the simulation begins. Accurately initializing these values ensures that the simulation starts from a realistic and test-relevant point, mirroring the aircraft’s condition at the start of a flight segment or operational scenario.

[0062] At step 310, a scenario driver (e.g., a tool or module within the simulation that controls what happens during a test based on a predefined set of instructions or inputs) provides time-based inputs or flight events into the simulation. These may represent mission segments such as takeoff, cruise, or descent, or operational triggers like loss of sensor data, battery depletion, or temperature rise. These scenarios stimulate the SUT and surrounding systems, allowing users to evaluate system behavior under predefined conditions and transitions.

[0063] At step 315, after the scenario driver in step 310 injects a simulated event (e.g., such as a takeoff maneuver, a battery voltage drop, or a sudden temperature spike), the functional simulator may determine how the components within System B 2052 will realistically respond. This may include simulating the physical and functional behavior of the system in reaction to that event. For example, if the scenario triggers a steep climb, the system software 2101 might command themotors to increase speed. The system dynamics model 2103 may then calculate how the motors actually behave under those condition, e.g.,: how fast they spin up, how much current they draw, how much heat they generate, and whether any part of the system slows down due to mechanical or electrical load. These physical responses may then be modeled in real time and passed through the system's simulated sensors 2104, which then feed data back into the system software 2101. This closed-loop process may allow users to see not just how the system software 2101 reacts to commands or events, but how the entire system would behave if it were operating in a real aircraft.

[0064] At step 320, to complete the simulation loop, the functional simulator may generate the responses of neighboring systems, e.g., such as System A 2051 and System C 2053 in schematic 205, using open-loop or closed-loop models. In open-loop mode, adjacent systems may deliver scripted outputs based on expected behavior; in closed-loop mode, the adjacent systems may interact dynamically with the SUT based on feedback from the simulation. This may enable testing of interface behaviors, timing dependencies, and fault tolerance as if the SUT were operating within the complete aircraft environment.

[0065] By integrating all these elements — initial states, dynamic scenarios, high-fidelity modeling, and simulated system interactions — the functional simulator may provide a robust and reusable framework for conducting L2-level testing with wrap-around realism. This approach may allow hardware-in-the-loop (HIL) and software-in-the-loop (SIL) testing to capture not only how a system behaves in isolation, but how it performs in context — responding to real-world scenarios, adjacent system interactions, and control dynamics that mirror full-system operation.

[0066] Referring now to FIG. 4, an exemplary workflow 400 is described for adding additional systems to the functional simulator. Aspects of the exemplary workflow 400 may be performed in accordance with some or all components described in FIG. 1.

[0067] In an aspect, workflow 400 depicts a process for adding new systems, e.g., flight software, into the functional simulator. More particularly, workflow 400 outlines the steps a user (e.g., an engineer) may follow to bring real system software into a virtual test environment. At step 405, a system owner may provide a software interface specification to the simulator. This specification may define how their software communicates, including the structure and types of inputs it expects to receive (e.g., sensor readings, mode commands, etc.) and the outputs it will generate. This interface may serve as a type of contrast between the subsystem software and the rest of the simulator, ensuring that when it is integrated, the software can properly send and receive data within the simulated aircraft environment.

[0068] At step 410, while the interface specification is being prepared, the actual system software may either have been imported into or developed directly within a modeling program (e.g., such as Simulink, etc.). The modeling program may be a graphical modeling environment that may be utilized, for instance, in aerospace for designing and simulating control systems. In an aspect, if the software already exists, users may build the software logic natively in the modeling program.

[0069] At step 415, once both the interface definition and the system software are complete, users may proceed to add input and output modules within the modeling program to connect the software to the broader simulation environment. These modules may act as bridges between the system software and the rest of thefunctional simulator, allowing signals, e.g., sensor inputs, control commands, health status, etc., to flow in and out of the software model. In an aspect, the input modules may receive simulated data from other subsystems or scenario drivers, while the output modules may send the software’s responses to a plant model or downstream components.

[0070] At step 420, once the input and output connections are configured, the system software may be formally integrated into the functional simulator, thereby allowing the system software to operate within the full aircraft simulation environment. This means that the software now interacts in real time with other visual subsystems and modules, responds to scenario events, and may participate in the closed-loop simulation cycle. In effect, the software may be treated as a functional component of the simulated aircraft, enabling users to observe how it behaves under realistic flight conditions and system interactions.

[0071] At step 425, after the software is integrated into the functional simulator, users may execute a range of simulation tests to evaluate how the software performs under various operational scenarios. These tests may simulate normal flight conditions (e.g., like takeoff, cruise, landing, etc.) as well as edge cases or fault conditions, such as sensor failures or sudden changes in power demand. Through this process, users may observe whether the software behaves as expected, maintains correct system logic, and properly responds to changing inputs and environmental factors within the simulation loop.

[0072] At step 430, if the software exhibits unexpected behavior (e.g., generates logic errors, incorrect mode transitions, poor response to inputs, etc.) users may utilize various built-in tools of the functional simulator to trace signals, monitor system states, and diagnose root causes. This troubleshooting process mayallow users to identify and fix bugs or integration mismatches in a safe, repeatable environment. By resolving these issues before deploying the software to real hardware, users may significantly reduce risk, save time, and ensure that the flight software is stable, reliable, and well-understood - all without needing to expose a physical aircraft to early-stage software testing.

[0073] Referring now to FIG. 5, an exemplary workflow 500 is described for simulating an aircraft system in a closed-loop simulation environment. Aspects of the exemplary workflow 500 may be performed in accordance with some or all components described in FIG. 1.

[0074] At step 505, one or more control inputs may be received at a simulation system from a user interface that represents pilot commands. More particularly, the simulation system may include a pilot-facing interface configured to receive inputs such as stick movements, throttle changes, or switch activations from a simulated cockpit control panel. These inputs reflect pilot intent and serve as the initial commands that drive aircraft behavior. The user interface may include virtual inceptors, touchscreen controls, or real hardware connected via a simulation bus. These control inputs may be timestamped and passed into the simulator’s control logic for real-time processing.

[0075] At step 510, the one or more control inputs may be processed by a control system model to generate one or more system command signals. More particularly, upon receiving the pilot commands, the simulator may route these inputs into a control system model that emulates the behavior of an aircraft’s flight control computer. This model may include logic such as control laws, mode switching algorithms, and actuator command generation routines. The control system may process the pilot’s input in the context of current simulated conditions and maygenerate appropriate command signals, such as motor commands, actuator commands, flight mode transitions, etc.

[0076] At step 515, the system command signals may be applied to one or more virtual system models that each represent a component or subsystem of the aircraft. In an aspect, each of these models may represent a physical aircraft module such as propulsion, energy, storage, actuation, or thermal management. These modules may emulate the dynamic response of real-world components when subject to control commands.

[0077] At step 520, as commands are applied to the virtual models, the simulation system may calculate the resulting physical behavior of the aircraft in real time. This may include changes in position, orientation, forces, temperatures, voltages, or other dynamic states. These behaviors may emerge from the physical rules embedded in the models and may reflect how the real aircraft would respond under similar conditions. This simulation step may ensure realism and may enable cause-and-effect relationships between control inputs and aircraft motion.

[0078] At step 525, sensor models may be configured to monitor the simulated physical responses and generate corresponding sensor data, just as real sensors would. These models may incorporate characteristics like signal delay, resolution limits, drift, and noise. In an aspect, the resulting sensor data may include measurements such as airspeed, altitude, RPM, actuator position, or battery voltage. This data may mirror what the aircraft’s avionics system would receive from onboard sensors in flight.

[0079] At step 530, the simulated sensor data may be passed back to the control system model, forming a closed-loop feedback system. This may allow the control logic to continuously update its outputs to the virtual system models based onreal-time sensor readings, enabling dynamic responses to changes in system state or pilot input. In an aspect, the synchronization ensures that all system components may be operating on a unified simulation clock, preserving causality and ensuring realistic timing behavior.

[0080] At step 535, the simulation results may be output and / or transmitted, e.g., to one or more display modules or to one or more other locations. In an aspect, the simulation environment may include a suite of output modules that may provide real-time and post-processing access to system behavior. These outputs may be routed to virtual cockpit instruments, engineering dashboards, and / or 3D visualization tools. In an aspect, the results may include both raw simulation data, as well as rendered visualization (e.g., flight path animations, etc.), thereby enabling analysis, testing, and presentation of aircraft performance under simulated conditions.

[0081] Referring now to FIG. 6, an exemplary workflow 600 is described for configuring a simulation environment to represent a target system and one or more adjacent systems. Aspects of the exemplary workflow 600 may be performed in accordance with some or all components described in FIG. 2.

[0082] At step 605, a simulation environment may be configured to digitally represent not only the system under test but also the systems it interacts with in an operation aircraft setting. In an aspect, each system may be composed of modular elements that reflect how it behaves and communicates. The target system may include, for instance, a system software module that replicates its embedded control logic, an interface unit that simulates the communication interfaces typically found on aircraft, ensuring that data exchange may adhere to proper timing, encoding, and protocol structure, a plant model that mirrors the physical behavior of the targetsystem, simulating mechanical, thermal, electrical, or fluid dynamics responses to control commands, and a sensor model that may generate simulated sensor data based on outputs from the plant model, thereby creating a realistic feedback loop within the simulation.

[0083] At step 610, before a simulation scenario is run, the simulation environment may be initialized using predefined initial states. These values ensure that each module starts the test in a known and controlled condition. For the system software, this may include startup mode, active flags, memory contents, or pre- loaded command schedules. The interface unit is initialized to reflect correct data bus configurations, link status, and protocol registers. The plant model may start with defined positions, thermal conditions, or voltages, depending on the subsystem being simulated. By establishing these initial states, the system may ensure consistency and repeatability in test execution, especially when simulating edge cases or replicating specific fault conditions.

[0084] At step 615, a scenario driver may be executed to inject timed events or environmental conditions into the simulation. These may include pilot command sequences, vehicle state transitions, system faults, or mission-specific actions such as takeoff, hover, or landing. The driver may manipulate both the target system and its adjacent systems, simulating real-world scenarios like wind shear, power loss, or data link interruptions. Events may be scripted, random, or driven from external input files, and may be processed in sync with the simulation clock to maintain accurate cause-and-effect relationships. The scenario driver may ensure that the simulation effects realistic mission progression and stress conditions.

[0085] At step 620, a response by the target system may be simulated in a closed-loop configuration. More particularly, during execution, the simulation mayoperate in a closed-loop configuration, meaning data flows continuously between subsystems. The target system may receive both scenario-driven inputs and simulated data outputs from adjacent systems to mimic operational dependencies. In an aspect, the system software may process these inputs and computes updated control commands. These commands may be fed into the plant model, which may simulate the resulting physical system response. The sensor model may then measure this updated physical state and generate new sensor data, which may be routed back to the software module. This real-time loop allows the simulation to emulate adaptive and responsive behavior, just as a real embedded system would experience in-flight.

[0086] At step 625, as the simulation progresses, it may generate a range of outputs that provide visibility into the target system’s performance and health. These outputs may include internal system states (e.g., flight mode, energy levels), communication statistics (e.g., message timing, dropped packets), and real-time operational metrics (e.g., actuator positions, thermal load, fault flags). The data may be displayed on virtual instruments, recorded in logs for later analysis, or fed into visualization tools to animate system behavior. These outputs may enable engineers to observe, quantify, and analyze the system under test across a range of operational conditions.

[0087] At step 630, the system performance may be evaluated by comparing expected outputs to simulation outputs. This may include validation against design specifications, performance thresholds, or previously recorded data from hardware testing. In an aspect, the simulation environment may support automated checks for anomalies such as mode mismatches, response delays, or failure to meet timing constraints. The simulation system may also allow for fault injection testing, whereunexpected conditions are introduced to verify that the system responds in a safe and predictable manner. This evaluation process may support both software verification and hardware-in-the-loop validation, and may be used to inform design iteration or readiness assessments

[0088] With all of the major systems and subsystems accurately modeled, the functional simulator may become a tool that can be utilized in many different ways. Provided below are a plurality of different types of exemplary use cases in which the functional simulator may be deployed.

[0089] In one application, a functional simulator may be utilized in desktop testing of a complete, closed-loop system, in which the functional simulator may model how all parts of the aircraft interact in real time and under realistic flight conditions. In this setup, users (e.g., engineers, etc.) may run full flight scenarios and see how the entire aircraft responds as a whole. For example, users may evaluate flight control performance, looking at how different subsystems — like propulsion, actuators, and the power system — work together to affect how stable, smooth, and responsive the aircraft feels during flight. Another useful test is simulating power cycling during takeoff or landing, where sudden movements by the pilot can cause a spike in power demand. These rapid changes may push the system beyond its limits, making it important to analyze how the aircraft handles these stresses. This kind of testing may help users understand how much power the electrical system can realistically deliver, how quickly the propulsion system consumes or regenerates energy, and where to set safe limits in the software. As a result, they can design the aircraft to avoid unsafe maneuvers while still giving pilots a responsive and capable vehicle. Overall, these simulations help ensure that the aircraft performs well, stayswithin its physical limits, and gives pilots predictable and safe control throughout different phases of flight.

[0090] In another application, a functional simulator may be utilized in desktop testing of control and system software, which may enable users to run and evaluate the aircraft’s onboard software in a controlled, computer-based test environment without needing any real hardware or a full flight simulator. This functionality may be helpful in debugging and improving parts of the software like control algorithms, mode logic, data filtering, and fault management. One important area of focus is modal logic, which refers to how the system switches between different operating modes (such as takeoff, hover, cruise, or landing). By combining pilot inputs, e.g., like cockpit switch positions, etc., with the internal logic from various systems, users may create unusual or rare combinations of conditions. This may help uncover corner cases where the system might behave incorrectly or unpredictably, such as triggering race conditions (where two commands interfere with each other) or entering conflicting modes. Another benefit of desktop testing is the ability to inject faults or noise into the system. For example, users may be able to simulate a broken sensor, a voltage spike, or corrupted data values to see how the software reacts. This may help verify that the system can still operate safely, or at least respond appropriately to problems. Because this is all done virtually, it’s fast, low-risk, and easy to repeat. Desktop testing may also support redundancy testing, where backup systems and logic, like Input Signal Management (ISM), can be tested to ensure they work properly under failure conditions. For instance, navigation sensors may beintentionally faulted to test if the software correctly switches to a backup source or triggers an alert.

[0091] In yet another application, SIL testing for avionics software may be a more realistic way to test flight and system software because it runs the actual software on real or representative hardware, rather than just on a desktop simulation. This creates a test environment that may closely mirror what would happen in a real aircraft, making it ideal for finding issues that might not show up in simpler tests. One key use case is testing multiple instances of the same software running in parallel — like in a redundant flight computer setup. In these cases, the SIL test allows users to see how well the redundancy logic works: for example, how the system manages coordination between primary and backup computers. Another important scenario is in-flight restart testing, where one of the computers may be intentionally restarted mid-simulation to see if the system recovers properly. This help may help verify that the software can rejoin the flight in the correct mode and stay synchronized with the other systems, without causing incorrect behavior or mode mismatches. SIL testing may be important for proving that the system software can handle unexpected events and still function safely and correctly in real flight conditions.

[0092] In yet another application, HIL testing for targeted systems may be a method for testing where a real piece of hardware, such as a flight controller, sensor module, power unit, etc., is connected directly to the functional simulator. More particularly, instead of testing everything in a purely virtual environment, this approach may allow engineers to replace part of the simulated system with real hardware, while the simulator still handles the rest of the aircraft's behavior. This works because the simulator may be capable of accurately mimicking thecommunication traffic and timing that the real hardware would experience during flight. One common use of HIL is interface testing, where the goal is to check that the real hardware can properly send and receive messages using the correct avionics protocols. The simulator may send signals that represent realistic flight conditions, allowing the test to be meaningful and thorough. Another use case may involve wrap-around testing, where the hardware being tested either needs to consume inputs (like sensor data or flight commands) or produce outputs (like motor control signals) that would normally interact with other aircraft systems. In this case, the simulator may "wrap around" the real hardware, acting as the rest of the aircraft so the hardware can be tested in context. Additionally to the foregoing, focused system testing for integration may be employed when an entire subsystem is swapped in, such as a real actuator control module, while the simulator pretends to be all the other systems it connects with. This may allow users to fully exercise the system’s modes, transitions, and fault handling in a realistic way, without needing the entire aircraft. Overall, HIL testing helps ensure that real hardware works as expected before it’s installed on the aircraft, by letting it interact with a simulated but lifelike digital environment.

[0093] In a final application, PIL testing allows a real pilot to interact directly with the functional simulator using a complete, realistic cockpit setup. This may include instruments, switches, visual displays, flight controls, and potentially even a ground control station (GCS) with command-and-control interfaces. Unlike automated or pre-recorded scenarios, PIL may be fully interactive and dynamic. More particularly, the pilot may make real-time decisions and inputs, and the simulator may respond just like a real aircraft would. One important use is evaluating handling qualities, where the pilot can experience how the aircraft feels andresponds to their inputs across different flight phases, as a result of the accurate simulation of multiple subsystems working together. Another benefit is failure handling; because multiple systems are being simulated, the test may introduce realistic failures — like sensor loss, power faults, or control malfunctions — and observe how the pilot identifies the issue, reacts, and attempts recovery. This makes PIL a powerful tool not only for validating aircraft behavior, but also for crew training. Pilots can practice both normal and emergency scenarios, even ones that would be unsafe or difficult to test in a real aircraft. Additionally, PILS is ideal for developing and refining pilot procedures. Since the simulator can reliably recreate the same conditions every time, engineers and pilots can test out checklists, button sequences, and emergency protocols in a controlled, repeatable environment. Overall, PILS brings together technical testing and human performance, making it essential for both aircraft validation and pilot readiness.

[0094] In general, any process discussed in this disclosure that is understood to be computer-implementable, such as the processes illustrated in FIGS. 3-6, may be performed by one or more processors of a computer system, such as computer system 100 described above. A process or process step performed by one or more processors may also be referred to as an operation. The one or more processors may be configured to perform such processes by having access to instructions (e.g., software or computer-readable code) that, when executed by the one or more processors, cause the one or more processors to perform the processes. The instructions may be stored in a memory of the computer server. A processor may be a central processing unit (CPU), a graphics processing unit (GPU), or any suitable types of processing unit.

[0095] A computer system, such as the computer system 100, may include one or more computing devices. If the one or more processors of the computer systems are implemented as a plurality of processors, the plurality of processors may be included in a single computing device or distributed among a plurality of computing devices. If the computer system 100 comprises a plurality of computing devices, the memory of the computer system 100 may include the respective memory of each computing device of the plurality of computing devices.

[0096] FIG. 7 is a simplified functional block diagram of a computer system 700 that may be configured as a computing device for executing the process illustrated in FIGS. 3-6, according to exemplary embodiments of the present disclosure. FIG. 7 is a simplified functional block diagram of a computer that may be configured as the computer system 100 according to exemplary embodiments of the present disclosure. In various embodiments, any of the systems herein may be an assembly of hardware including, for example, a data communication interface 720 for packet data communication. The platform also may include a central processing unit (“CPU”) or processor 702, in the form of one or more processors, for executing program instructions. The platform may include an internal communication bus 708, and a drive unit 706 (such as ROM, HDD, SDD, etc.) that may store data on a computer readable medium 722, although the system 700 may receive programming and data via network communications via electronic network 725 (e.g., voice, video, audio, images, or any other data over the electronic network 725). The system 700 may also have a memory 704 (such as RAM) storing instructions 724 for executing techniques presented herein, although the instructions 724 may be stored temporarily or permanently within other modules of system 700 (e.g., processor 702 and / or computer readable medium 722). The system 700 also may include input andoutput devices 712 and / or a display 710 to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. The various system functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the systems may be implemented by appropriate programming of one computer hardware platform.

[0097] Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and / or associated data that is carried on or embodied in a type of machine-readable medium. “Storage” type media include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer of the mobile communication network into the computer platform of a server and / or from a server to the mobile device. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links, or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible “storage” media, terms such as computer or machine “readable medium” refer to any medium that participates in providing instructions to a processor for execution.

[0098] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

[0099] In general, any process discussed in this disclosure that is understood to be performable by a computer may be performed by one or more processors. Such processes include, but are not limited to the processes shown in FIGS. 2-4, and the associated language of the specification. The one or more processors may be configured to perform such processes by having access to instructions (computer-readable code) that, when executed by the one or more processors, cause the one or more processors to perform the processes. The one or more processors may be part of a computer system (e.g., one of the computer systems discussed above) that further includes a memory storing the instructions. The instructions also may be stored on a non-transitory computer-readable medium. The non-transitory computer-readable medium may be separate from any processor. Examples of non-transitory computer-readable media include solid-state memories, optical media, and magnetic media.

[0100] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention needs more features than are expressly recited in each claim. Rather, as the following claimsreflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

[0101] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0102] Thus, while certain embodiments have been described, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

[0103] The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other implementations, which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description. While various implementations of the disclosure have been described, it will be apparent to thoseof ordinary skill in the art that many more implementations are possible within the scope of the disclosure. Accordingly, the disclosure is not to be restricted except in light of the attached claims and their equivalents.

Claims

What is claimed is:1 . A computer-implemented method for simulating an aircraft system in a closed-loop functional simulation environment, the computer-implemented method comprising: receiving, at a computer system, one or more control inputs from an interface; processing, using one or more processors associated with the computer system and by a control system model associated with the computer system, the one or more control inputs to generate one or more system command signals; applying, using the one or more processors, the one or more system command signals to one or more virtual system models, wherein each of the one or more virtual system models represent a subsystem of an aircraft; simulating, using the one or more processors, a physical response of the aircraft based on output generated by the one or more virtual system models in response to application of the one or more system command signals; generating, using the one or more processors and responsive to monitoring the output generated by the one or more virtual system models, sensor data; transmitting, using the one or more processors, the sensor data to the control system model; and outputting, using the one or more processors, simulation results, wherein the simulation results at least comprise an indication of the physical response of the aircraft.

2. The computer-implemented method of claim 1 , wherein the interface is one of a virtual interface or a physical interface.

3. The computer-implemented method of claim 1 , wherein the one or more virtual system models comprise: a thermal system model, an actuation system model, an energy system model, a powertrain system model, and a flight dynamics model.

4. The computer-implemented method of claim 1 , further comprising: generating, using the one or more processors and by modifying the one or more system command signals based on the sensor data, one or more updated system command signals; and simulating, using the one or more processors, the physical response of the aircraft based on additional output generated by the one or more virtual system models in response to the application of the one or more updated system command signals.

5. The computer-implemented method of claim 1 , further comprising: introducing, using the one or more processors, one or more faults into the sensor data; and identifying, using the one or more processors, degradation of a subsystem resultant from the introduction of the one or more faults via identifying a deviation of a simulated operating condition of the subsystem from an on-design operating condition of the subsystem.

6. The computer-implemented method of claim 5, further comprising: executing, using the one or more processors, a fault detection and isolation protocol at the control system model; and isolating, using the one or more processors, an isolation protocol responsive to detecting one or more anomalies in the sensor data.

7. The computer-implemented method of claim 1 , further comprising: interfacing, using the one or more processors, one or more of the virtual system models with one or more physical hardware components; wherein the one or more physical hardware components are configured to transmit and receive signals to and from the closed-loop functional simulation environment.

8. The computer-implemented method of claim 1 , wherein the control system model comprises compiled flight control software hosted on a real-time operating environment.

9. The computer-implemented method of claim 1 , wherein the interface comprises a physical or simulated cockpit control system; and wherein the closed-loop functional simulation environment is configured to accept live user input during execution.

10. The computer-implemented method of claim 1 , wherein the outputting the simulation results comprises:displaying a virtual cockpit instrument panel; and generating a real-time visualization of the aircraft behavior in a three- dimensional environment on the instrument panel.11 . A system for simulating an aircraft system in a closed-loop functional simulation environment, comprising: a memory including instructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: receiving one or more control inputs from an interface; processing, by a control system model associated with the aircraft system, the one or more control inputs to generate one or more system command signals; applying the one or more system command signals to one or more virtual system models, wherein each of the one or more virtual system models represent a subsystem of an aircraft; simulating a physical response of the aircraft based on output generated by the one or more virtual system models in response to application of the one or more system command signals; generating, responsive to monitoring the output generated by the one or more virtual system models; sensor data; transmitting the sensor data to the control system model; and outputting simulation results to one or more display modules, wherein the simulation results at least comprise an indication of the physical response of the aircraft.

12. The system of claim 11 , wherein the aircraft is an electric vertical take-off and landing vehicle (eVTOL).

13. The system of claim 11 , wherein the one or more virtual system models comprise: a thermal system model, an actuation system model, an energy system model, a powertrain system model, and a flight dynamics model.

14. The system of claim 11 , wherein the instructions are further executable by the at least one processor to perform operations comprising: generating, by modifying the one or more system command signals based on the sensor data, one or more updated system command signals; and simulating the physical response of the aircraft based on additional output generated by the one or more virtual system models in response to the application of the one or more updated system command signals.

15. The system of claim 11 , wherein the instructions are further executable by the at least one processor to perform operations comprising: introducing one or more faults into the sensor data; and identifying degradation of a subsystem resultant from the introduction of the one or more faults via identifying a deviation of a simulated operating condition of the subsystem from an on-design operating condition of the subsystem.

16. A computer-implemented method for simulating and testing a target system within a multi-system simulation environment, the computer-implemented method comprising: configuring, using one or more processors, a simulation environment to represent a target system and one or more adjacent systems; initializing, using the one or more processors, the simulation environment by applying predefined internal initial states to one or more components of the target system; executing, using the one or more processors, a driver to apply input events and / or environmental conditions to the target system and one or more of the adjacent systems; simulating, using the one or more processors and responsive to the executing, a response of the target system; generating, using the one or more processors, one or more simulation outputs indicative of behavior of the target system based on the response; and evaluating, using the one or more processors, performance of the target system by comparing a set of expected outputs against the one or more simulation outputs.

17. The computer-implemented method of claim 16, wherein the simulation environment comprises: a system software module, an interface unit, a plant model, and a sensor model.

18. The computer-implemented method of claim 16, wherein the simulation the responsive of the target system comprises:receiving, at the target system, one or more scenario inputs and simulated data from the one or more adjacent systems; generating, via a system software module, one or more control signals; updating a plant model based on the one or more control signals; generating updated sensor data from a sensor model; and introducing the sensor data back to the system software module.

19. A system for simulating and testing a target system within a multi-system simulation environment, comprising: a memory including instructions; and at least one processor configured to execute the instructions stored in the memory to perform operations comprising: configuring a simulation environment to represent a target system and one or more adjacent systems; initializing the simulation environment by applying predefined internal initial states to one or more components of the target system; executing a driver to apply input events and / or environmental conditions to the target system and one or more of the adjacent systems; simulating, responsive to the executing, a response of the target system; generating, one or more simulation outputs indicative of behavior of the target system based on the response; and evaluating performance of the target system by comparing a set of expected outputs against the one or more simulation outputs.

20. The system of claim 19, wherein the multi-system simulation environment is hosted on a distributed computing platform and wherein the distributed computing platform enables real-time interaction between the target system and the one or more adjacent system.

Images