Fault simulation method and device in complex flight scene

Abstract

The invention discloses a fault simulation method and equipment in a complex flight scene, belongs to the technical field of flight fault simulation, and aims to improve the fault-tolerant capability of a system and realize full-coverage simulation of the complex flight scene through state injection and fault simulation. The problems of insufficient fault scene coverage, real-time control and data reproducibility in the prior art can be solved; moreover, the method can inject the fault states of a plurality of devices in parallel in the same simulation process, and compared with a traditional method which only supports a single-device single-fault simulation mode, the method has the advantages that the capability of restoring a composite fault scene is greatly enhanced, and the method is suitable for limiting condition verification of a high-reliability aircraft system.

Description

Technical Field

[0001] The present invention belongs to the technical field of flight fault simulation, and in particular relates to a method and device for simulating faults in complex flight scenarios. Background Art

[0002] Pre-flight simulations of aircraft can comprehensively assess their stability, reliability, and potential design flaws, effectively mitigating potential economic losses and casualties. In the early days of aircraft development, physical simulations were often employed, such as wind tunnel testing (measuring the aerodynamic characteristics of aircraft using scaled-down models) or water tank testing (observing streamlines, vortices, and forces on models in a water flow). While these traditional methods provide valuable experimental data for aircraft design, they also have significant limitations, including high costs, difficulty replicating experimental conditions, and an inability to fully simulate real-world flight conditions.

[0003] With the rapid development of digital computers, modern flight simulation technology has gradually shifted to computer-based mathematical modeling and numerical simulation, which are then combined with physical hardware. This type of simulation is usually called hardware-in-the-loop simulation (HIL). This method has significant advantages in reducing costs, improving experimental repeatability, and improving flexibility.

[0004] Although existing hardware-in-the-loop (HIL) simulation systems can simulate basic flight conditions, they still have the following shortcomings in covering complex scenarios:

[0005] Fault simulation limitations: Current methods only support single fault modes (e.g., single sensor failure) and cannot simulate complex scenarios such as multi-sensor coordinated failure and multi-state faults. This results in insufficient verification of flight system stability under extreme operating conditions.

[0006] Weak dynamic adjustment capability: Existing technologies require code modification or offline configuration to implement fault injection, which lacks real-time performance and flexibility, making it difficult to dynamically switch fault states during simulation.

[0007] Therefore, existing simulation technologies are difficult to fully simulate complex and changeable flight conditions, and are unable to fully simulate fault conditions during the simulation process, resulting in the inability to fully verify the performance of aircraft under special working conditions. Summary of the Invention

[0008] The present invention provides a method and device for simulating faults in complex flight scenarios. Through state injection and fault simulation, the fault tolerance capability of the system is improved, and full coverage simulation of complex flight scenarios is achieved. This can solve the problems of insufficient fault scenario coverage, real-time control and data reproducibility in the prior art.

[0009] To achieve the above objectives, the present invention adopts the following technical solutions:

[0010] A method for simulating failures in complex flight scenarios includes the following steps:

[0011] S1: Design a unified fault injection protocol to support modular encapsulation and decoupled modeling of multiple aircraft subsystems. This allows each module to receive and parse injected data on demand, enabling parallel simulation across multiple devices, modules, and fault scenarios.

[0012] S2: The host computer has a graphical interface, and users can freely set the fault type during operation. The system sends standardized injection protocol packets on time and on demand through the network UDP. During the process, the simulation state can be dynamically changed without interrupting the simulation, and operations such as fault switching, combination, and cancellation can be implemented during operation.

[0013] S3: After receiving the fault injection data from the host computer, the real-time simulation platform running at the bottom layer receives and parses the protocol packets sent by the host computer. Based on the injection instructions, it dynamically changes the output values ​​of the relevant simulation models (for example, replacing the acceleration data output by the inertial navigation system with the injected interference value, or simulating the propulsion system output thrust drop), thereby forming a closed loop of fault behavior at the model level.

[0014] S4: The signals after fault simulation are input into the flight management computer as "real data." Its built-in fault detection, state identification, and control law algorithms will identify, filter, and respond to the input, triggering the exception handling process (such as reallocating control surface resources, switching to backup channels, issuing emergency status alerts, etc.), ensuring that the anti-interference capabilities of the flight software can be fully verified during the simulation stage.

[0015] S5: All injection behaviors, fault response processes, and flight system status changes are recorded. The system supports fault process backtracking, visual analysis, offline replay, and data export, which is convenient for flight control algorithm optimization, test verification report generation, and design closed-loop improvement.

[0016] A device for simulating failures in complex flight scenarios, comprising:

[0017] Simulator: used to run the airborne dynamics model and environmental model, and can generate simulation data such as the flight vehicle's attitude, speed, and trajectory in real time;

[0018] Flight control computer: used to deploy flight control software, receive various input information and calculate output control instructions;

[0019] Flying tube disconnect box: used to support physical layer fault injection control such as signal interruption and power cutoff;

[0020] Host computer: Serves as the fault simulation control terminal, enabling the setting, scheduling, and injection of fault types for sensors, actuators, communication links, and more;

[0021] Ground station: used to receive system operation data in real time and display information such as flight status and fault response process;

[0022] Visual software: Receives the position and attitude data of the simulator and generates a three-dimensional flight picture for visual observation of flight status changes.

[0023] Beneficial effects: The present invention provides a method for simulating faults in complex flight scenarios, which has the following advantages over the prior art:

[0024] 1. Support for multi-fault collaborative simulation: The method of the present invention can inject fault conditions of multiple devices in parallel during the same simulation process, including but not limited to inertial navigation system drift, atmospheric data anomalies, servo jams, power supply fluctuations, sensor distortion, etc. Compared with traditional methods that only support the simulation of single device single faults, the ability to restore complex fault scenarios (such as "simultaneous failure of inertial navigation and control surfaces") is greatly enhanced, making it suitable for extreme operating condition verification of high-reliability aircraft systems;

[0025] 2. Dynamic injection capability at runtime: Fault injection is sent dynamically during the simulation via protocol packets. Fault configurations can be modified, combined, or revoked without interrupting the system or restarting the simulation task, significantly improving test efficiency and flexibility. This is particularly suitable for experimental scenarios requiring high-frequency adjustments, such as emergency response testing and anti-interference capability assessment.

[0026] 3. Support for graphical configuration and batch management: The host computer provides a visual interactive interface, allowing users to quickly set fault parameters according to flight missions. It supports template management and script injection control, meeting the needs of batch verification of multiple flights and different scenarios in engineering testing, and improving debugging efficiency and consistency.

[0027] 4. Full-process data recording and reproduction, supporting a posteriori analysis and expansion: All injection parameters, timestamps, and flight response data are automatically recorded and can be exported with one click. Fault reproduction and offline playback functions are supported, facilitating algorithm comparison, control logic tracing, and verification link review. The modularization and protocol standardization of the entire system facilitate subsequent expansion and integration, making it suitable for the testing needs of various flight platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A schematic diagram of a fault simulation device cross-linking in an embodiment of the present invention;

[0029] Figure 2 This is a schematic diagram of a fault simulation process in an embodiment of the present invention;

[0030] Figure 3 A diagram showing the cross-linking relationship between modules in a simulation model according to an embodiment of the present invention;

[0031] Figure 4 This is a schematic diagram of the structure of a fault simulation device in an embodiment of the present invention;

[0032] Figure 5 This is a diagram showing a modeling structure of the mass center of gravity and inertia in an embodiment of the present invention;

[0033] Figure 6 Graph showing the correlation between shape parameters and aerodynamic characteristics in an embodiment of the present invention. DETAILED DESCRIPTION

[0034] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments:

[0035] like Figure 1 and Figure 4 As shown, a device for simulating failures in complex flight scenarios includes:

[0036] Simulator: used to run the airborne dynamics model and environmental model, and can generate simulation data such as the flight vehicle's attitude, speed, and trajectory in real time;

[0037] Flight control computer: used to deploy flight control software, receive various input information and calculate output control instructions;

[0038] Flying tube disconnect box: used to support physical layer fault injection control such as signal interruption and power cutoff;

[0039] Host computer: Serves as the fault simulation control terminal, enabling the setting, scheduling, and injection of fault types for sensors, actuators, communication links, and more;

[0040] Ground station: used to receive system operation data in real time and display information such as flight status and fault response process;

[0041] Visual software: Receives the position and attitude data of the simulator and generates a three-dimensional flight picture for visual observation of flight status changes.

[0042] like Figure 2 As shown, the method for simulating failures in complex flight scenarios using the above-mentioned equipment includes the following steps:

[0043] 1. Fault Injection Protocol Design

[0044] The present invention develops a unified and extensible data injection protocol for introducing user-defined abnormal data or state values ​​into the target model during flight simulation to simulate various control system failures.

[0045] (1) Protocol structure definition

[0046] The injection protocol uses a structured data format, and the main fields include:

[0047] Data field: supports multiple types such as integer and floating point, used to carry dynamic variables such as sensor readings and actuator instructions;

[0048] Status word field: Each byte contains 8 bits, each bit represents a status flag (0 indicates normal, 1 indicates fault), which can simultaneously express the status of multiple channels or devices;

[0049] Checksum and identification field: includes frame header, CRC checksum, data source identification and other information to ensure communication integrity and data source traceability.

[0050] (2) Host computer injection mechanism

[0051] The injection data is automatically generated by the host computer console. The console is written in C++ and has a graphical operation interface that allows users to set:

[0052] 1. Target device identification;

[0053] 2. Channel number;

[0054] 3. Injection value;

[0055] 4. Corresponding status bit.

[0056] After the settings are completed, the system packages and generates data packets in standard protocol format according to the settings, and sends them to the underlying simulation machine through the UDP network interface.

[0057] (3) Shadow package design and data source identification

[0058] In order to achieve dynamic switching of data sources and signal priority control, the protocol introduces a shadow packet mechanism. The shadow packet structure includes:

[0059] Data unique ID: identifies the corresponding channel or signal variable;

[0060] Data source ID: defined as follows:

[0061] 0: real physical device collection;

[0062] 1: User injects data;

[0063] 2: Simulation model calculation results.

[0064] After receiving the shadow packet, the simulator determines whether to use the injected data to replace the current channel signal based on the data source ID, supporting real-time dynamic signal redirection.

[0065] (4) Bottom-level parsing and injection processing flow

[0066] After receiving the injected data packet and shadow packet, the simulation platform processes them according to the following logical flow:

[0067] First, parse the shadow package to determine the source of the current data;

[0068] If the source ID is "user injection" and the command value is "digital 1", the injected value is read and replaced with the original channel value;

[0069] The replaced signal is input into the simulation model for calculation;

[0070] The calculation results are output to the flight control system through the serial port interface;

[0071] Synchronously record data injection events and response logs for subsequent analysis and verification.

[0072] 2. State Injection and Fault Simulation Mechanism

[0073] In addition to supporting numerical value injection, the present invention also supports device status bit injection to simulate multiple types of fault situations, including but not limited to sensor failure, communication anomalies, actuator stuck, etc.

[0074] (1) Status field definition

[0075] The status information is represented by a single-byte identifier, where each bit corresponds to a status or fault type. The definition example is as follows:

[0076] 0: normal status;

[0077] 1: A fault occurs.

[0078] The status field can coexist with the data field in the same data packet to achieve synchronous injection and synchronous parsing.

[0079] (2) Typical state injection examples

[0080] Propulsion system: engine ignition abnormality, throttle control failure, controller channel abnormality;

[0081] Electromechanical systems: door jamming, hydraulic pressure loss, brake abnormality, steering failure;

[0082] Mission system: power supply unit abnormality, link interruption;

[0083] Flight control system: attitude angle drift, flaperon failure, satellite navigation loss, etc.

[0084] The above fault types are all defined through structure fields and sent to the simulation computer through the host computer in the form of binary values ​​0 or 1. The simulation computer transmits them to the model reserved interface in the form of variables for solution. At the same time, the simulation machine transmits the data of the model reserved output interface to the flight control computer through the serial bus.

[0085] After receiving the relevant status field, the flight control computer makes a judgment based on the status value and triggers corresponding fault expansion options, emergency response measures, or control strategy switching operations.

[0086] This mechanism is scalable, portable, and reusable. Different simulation platforms can independently define and manage fault sets based on the types of mounted devices and test requirements, thereby implementing customized fault simulation and verification processes.

[0087] (3) Injection response process

[0088] The injection operation process is as follows:

[0089] The user sets the target device and injection parameters in the console;

[0090] The system generates protocol data packets and sends them to the simulation platform;

[0091] The underlying simulation platform parses the status field and source ID;

[0092] After it is determined to be injected data, it replaces the original channel value and participates in the model calculation;

[0093] The calculation results are fed back to the flight control system via the serial port;

[0094] The flight control system determines whether the status is abnormal based on the received data and triggers control logic adjustments or alarm strategies.

[0095] This process supports dynamic injection and real-time cancellation during operation without restarting the simulation system, and is adaptable to various dynamic flight test scenarios.

[0096] 3. Self-built simulation model design

[0097] This paper constructs a self-designed flight simulation model as the core support module of the system. It has a highly modular structure and is independently built according to the aircraft dynamic characteristics, sensor response laws and control law requirements. It mainly includes the following submodules:

[0098] Aircraft six-degree-of-freedom dynamics simulation module;

[0099] External disturbance modeling module (simulating wind field changes, atmospheric disturbances, etc.);

[0100] Modeling modules for various typical sensors (such as inertial navigation, GPS, pitot tube, etc.);

[0101] Actuator modeling module (covering control surface system, engine thrust system, etc.);

[0102] Communication link characteristic modeling module (supports simulation of data delay, packet loss, etc.);

[0103] Fault injection interface and signal selection control module (for dynamic injection and data path switching).

[0104] The modules of this model are interconnected through clear interfaces, such as Figure 3 As shown, during the operation of the system, the host computer sends fault injection instructions and channel identification codes to the simulator through the network. After parsing the instructions, the simulator transmits the user-injected data to the corresponding interface of the model. For example, after a certain sensor channel receives an injection command, its original output signal will be replaced by the specified abnormal data, thereby triggering a system-level response. The model realizes the dynamic evolution of the aircraft state under fault conditions through the joint operation of the mass center of gravity model, aerodynamic model, and engine thrust model, and outputs the simulation results to the flight control computer in real time. The mass center of gravity and inertia modeling structure is shown in Figure 1. Figure 5 As shown in the figure, the relationship between the shape parameters and aerodynamic characteristics is as follows Figure 6 shown.

[0105] It should be noted that the module structure in the simulation model is an implementation currently designed for a specific fixed-wing aircraft model. The specific module division and parameter settings can be adjusted based on the actual flight platform used. The fault injection mechanism itself does not depend on the specific aircraft model structure and is therefore not affected by model differences.

[0106] The above model is exported as embedded C code through code generation tools and integrated into the software running environment of the underlying simulator. It works in parallel with other real-time task running modules. The input and output of the model are controlled by C code, making the fault injection stable and scalable. The relationship between each module is as follows: Figure 3 As shown in the figure, the aerodynamic model completes the fault injection output by comparing the relationship between the shape change and the aerodynamic force.

[0107] At the same time, this implementation method has high execution efficiency and stability, meeting the real-time and reliability indicators required by hardware-in-the-loop simulation. Compared with existing general simulation platforms or closed black box models, this model has the following main advantages:

[0108] 1. Transparent structure and strong tailorability

[0109] Each submodule has a clear structure, allowing users to flexibly adjust parameters, delete subsystems or expand components according to aircraft models or mission requirements, making it easy to integrate into different simulation tasks.

[0110] 2. Support multi-level data intervention and path control

[0111] The model sets up standardized fault injection interfaces at multiple key nodes such as sensor output, bus communication, and control interface. It can intervene in signals in real time during the simulation process to form an "injection-propagation-response" closed-loop chain, which is suitable for high-frequency fault simulation and response analysis.

[0112] 3. Highly integrated with injection protocol

[0113] The model can identify shadow packets and data packets sent by the host computer, and automatically switch the signal input path (real data, simulated data or user-injected data) according to the source identification, realizing dynamic redirection of data access and improving the real-time performance and stability of the injection process.

[0114] 4. Have joint debugging capabilities and verification interfaces

[0115] It supports connecting the flight control computer (or control law model) to the simulation system to form a closed-loop test structure for hardware and software. It is suitable for control algorithm joint debugging, online diagnosis and verification, and has strong engineering applicability.

[0116] In summary, the model in the present invention not only provides a stable and efficient fault simulation platform for the present invention, but also builds an open simulation foundation with expansion capabilities and engineering compatibility. It has wide applicability in aircraft fault-tolerant control verification, abnormal state reconstruction and multi-aircraft simulation testing, and has good scalability and industrial application potential.

[0117] Experimental verification

[0118] In order to verify the effectiveness and practicality of the "fault simulation method in complex flight scenarios" described in this invention, a set of engineering representative experimental system - iron bird test bench was constructed.

[0119] The platform has complete closed-loop functions for the flight control system and is a commonly used ground simulation device in current flight control system testing and verification. It is widely used in aircraft control strategy development and system-level verification.

[0120] The experimental platform includes the following core modules:

[0121] Simulator: Runs the onboard dynamics model and environmental model to generate real-time simulation data such as the flight vehicle's attitude, speed, and trajectory;

[0122] Flight control computer: deploys flight control software, receives various input information and calculates and outputs control instructions;

[0123] Flying tube disconnect box: supports physical layer fault injection control such as signal interruption and power cutoff;

[0124] Host computer: Serves as the fault simulation control terminal, enabling the setting, scheduling, and injection of fault types for sensors, actuators, communication links, and more;

[0125] Ground station: Receives system operation data in real time and displays information such as flight status and fault response process;

[0126] Visual software: Receives the position and attitude data of the simulator and generates a three-dimensional flight picture for visual observation of flight status changes.

[0127] Experimental Procedure

[0128] System initialization and stable flight test:

[0129] First, communication links are established between the platform's modules, initializing the flight state. The system enters the normal flight phase, simulating an aircraft following a predetermined trajectory. The flight control system outputs stable control variables, the visual system displays a stable attitude, and ground station data indicates normal parameters. This phase primarily verifies data stability and platform integrity in the initial state of the system.

[0130] Fault injection experiment:

[0131] During flight, control commands are sent from the host computer to inject fault trigger signals according to preset scenarios to simulate the following fault types:

[0132] Sensor failures: such as speed sensor output fixed value or abnormal drift;

[0133] Actuator failures: such as aileron stuck and rudder failure to respond;

[0134] Communication failures: such as flight control bus data loss, interruption or delay.

[0135] Fault data is injected into the flight control computer or control link by the simulator or disconnect box, and the system automatically switches to the corresponding fault scenario.

[0136] The visual system displays changes in the aircraft's attitude, trajectory, and other conditions in real time, while the ground station simultaneously records flight parameters and response processes.

[0137] Flight parameter download and analysis: Download flight parameters through the flight parameter recorder and analyze the fault injection situation to see if the results meet the injection expectations.

[0138] Response and Assessment:

[0139] After a fault occurs, the flight control system handles it according to fault-tolerant strategies, such as switching sensor sources and autonomously degrading control, to maintain flight safety. By comparing flight data and attitude changes before and after the fault, key indicators such as the system fault detection response delay, control accuracy changes, and attitude recovery capabilities are evaluated.

[0140] By solving the data from the flight parameter recorder and analyzing the experimental data in the form of plotting tables, the experimental data show that the received data delay is within the expected range, and the fault data injection situation is consistent with the expected results. For example, a system parameter fault is injected at a fixed time and recorded. It can be observed from the data analysis diagram that the data value at that moment fluctuates from 0 to 1. The experimental records of each pre-set fault item are in line with expectations.

[0141] Experiments have shown that this method for simulating faults in complex flight scenarios can effectively simulate various types of system-level faults in a realistic closed-loop flight control environment, with good controllability and real-time performance. Its fault simulation and injection process offers the following advantages:

[0142] Supports scenario construction under various complex flight conditions;

[0143] High repeatability, suitable for large-scale system testing;

[0144] Can trigger the internal detection mechanism of the flight control system to verify the effectiveness of the fault-tolerant control strategy;

[0145] The ground station and visual system support full-process data recording and visual playback, allowing you to view parameter injection status and special situation parameter triggering.

[0146] In summary, the fault simulation method of the present invention has good practicality and scalability in engineering applications and can be widely used in the testing, evaluation and iterative optimization of flight control systems.

[0147] The above are only preferred embodiments of the present invention. Ordinary technicians in this field should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the various embodiments of the present invention, and they should all be included in the protection scope of the present invention.

Claims

1. A method for simulating failures in complex flight scenarios, characterized in that: The following steps are involved: S1: Design a unified fault injection protocol to support modular encapsulation and decoupling modeling of multiple aircraft subsystems; S2: The host computer has a graphical interface, and the user can freely set the fault type during operation. The system sends standardized injection protocol packets on time and on demand. The simulation status can be dynamically changed without interrupting the simulation. S3: After receiving the fault injection data from the host computer, the real-time simulation platform running at the bottom layer parses the protocol packet sent by the host computer and dynamically changes the output value of the relevant simulation model according to the injection instructions, thus forming a closed loop of fault behavior at the model level. S4: The signal after fault simulation is input into the flight management computer as "real data". Its built-in fault detection, state recognition and control law algorithms identify, filter and respond to the input, triggering the exception handling process to ensure that the anti-interference ability of the flight software can be fully verified during the simulation stage.

2. The method for simulating failures in complex flight scenarios according to claim 1, characterized in that: The injection protocol adopts a structured data format, and its status field can express multiple channels or device states at the same time.

3. The method for simulating failures in complex flight scenarios according to claim 1 or 2, characterized in that: The injection protocol introduces a shadow packet mechanism. After receiving the shadow packet, the simulator determines whether to use the injected data to replace the current channel signal based on the data source ID, supporting real-time dynamic signal redirection.

4. The method for simulating failures in complex flight scenarios according to claim 3, characterized in that: The shadow package structure includes: Data unique ID: identifies the corresponding channel or signal variable; Data source ID: 0: real physical device collection; 1: User injects data; 2: Simulation model calculation results.

5. The method for simulating failures in complex flight scenarios according to claim 1, characterized in that: The fault type is defined by a structure field and sent as a binary value of 0 or 1.

6. The method for simulating failures in complex flight scenarios according to claim 1, characterized in that: All injection behaviors, fault response processes, and flight system status changes are recorded. The system supports fault process backtracking, visual analysis, offline replay, and data export, which is convenient for flight control algorithm optimization, test verification report generation, and design closed-loop improvement.

7. A device for simulating failures in complex flight scenarios, characterized in that: include: Simulator: used to run the onboard dynamics model and environmental model, and generate simulation data of the flight vehicle in real time; Flight control computer: used to deploy flight control software, receive various input information and calculate output control instructions; Flight control disconnect box: used to support physical layer fault injection control such as signal interruption and power cutoff; Host computer: Serves as the fault simulation control terminal to implement fault type setting, scheduling, and injection; Ground station: used to receive system operation data in real time and display flight status and fault response process information.

8. The device for simulating failures in complex flight scenarios according to claim 7, characterized in that: The simulator builds a flight simulation model based on the aircraft's dynamic characteristics, sensor response laws, and control law requirements, including an aircraft six-degree-of-freedom dynamics simulation module, an external disturbance modeling module, a sensor modeling module, an actuator modeling module, a communication link characteristic modeling module, a fault injection interface, and a signal selection control module.

9. The device for simulating failures in complex flight scenarios according to claim 8, characterized in that: The modules in the flight simulation model are interconnected through interfaces. During system operation, the host computer sends fault injection instructions and channel identification codes to the simulator through the network. After parsing the instructions, the simulator transmits the user-injected data to the corresponding interface of the model. Its original output signal will be replaced with the specified abnormal data, thereby triggering a system-level response. The model internally realizes the dynamic evolution of the aircraft state under fault conditions through the joint calculation of the mass center of gravity model, aerodynamic model, and engine thrust model, and outputs the simulation results to the flight control computer in real time.

10. The device for simulating failures in complex flight scenarios according to claim 8 or 9, characterized in that: The flight simulation model is exported as embedded C code via a code generation tool and integrated into the software running environment of the underlying simulator, working in parallel with other real-time task running modules, and the input and output of the model are controlled by C code.

Images