Aircraft simulation test control method, device and test system

Abstract

The application provides an aircraft simulation test control method and device and a test system, relates to the field of aircraft hardware-in-the-loop test, and the aircraft simulation test system of the scheme is realized through a plurality of mutually independent closed-loop simulation nodes. The backup channel and the main channel are mutually independent, and each simulation node is provided with an independent clock module and a power module. When any node fails, other nodes can still operate. Compared with the traditional single simulation machine scheme, the system availability is significantly improved. In addition, the mutually independent backup channel and the main channel can completely reproduce the channel isolation of the aircraft in the real flight environment, can expose abnormal behaviors caused by physical differences, and greatly improve the test coverage and accuracy.

Description

Technical Field

[0001] This invention relates to the field of hardware-in-the-loop (HIL) testing of aircraft, and in particular to an aircraft simulation test control method, device and test system. Background Technology

[0002] The general HIL solution runs model instances of all redundant channels within the same simulator, sharing the same power supply and hardware resources. In a real flight environment, each redundant channel of the flight control computing device is installed in an independent chassis, using independent power supplies and signal conditioning circuits, with complete physical isolation. Differences between channels due to physical isolation include: Differences in signal propagation delay caused by differences in the length of the signal lines in each channel (for example, if the cable in channel A is 1 meter longer than that in channel B, it will produce a delay difference of about 5 nanoseconds). Voltage ripple differences in the independent power supplies of each channel; Differences in temperature drift characteristics of signal conditioning circuits in each channel.

[0003] The aforementioned minor differences may lead to valid but not equivalent measurements of the same physical quantity in different channels during actual flight; some defects are only triggered when there are minor input differences between channels (for example, when the airspeed difference between two channels exceeds a certain threshold, a normal channel may be incorrectly identified as a fault); however, the single simulator solution cannot expose such defects because all channels share the same signal source. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide an aircraft simulation test control method, device, and test system. The aircraft simulation test system achieves the independence of backup channels and main channels through multiple independent closed-loop simulation nodes. Each simulation node is equipped with an independent clock module and power supply module. The failure of any node does not affect the operation of other nodes. Compared with the traditional single simulator solution, its system availability is significantly improved. In addition, the independent backup channels and main channels can completely reproduce the channel isolation of the aircraft in the real flight environment, and can expose behavioral anomalies caused by physical differences, greatly improving test coverage and accuracy.

[0005] In a first aspect, embodiments of the present invention provide an aircraft simulation test control method, applied to the flight control equipment of an aircraft simulation test system; the aircraft simulation test system is provided with multiple closed-loop simulation nodes connected to the flight control equipment, each simulation node being provided with an independent clock module and power supply module; the method includes: After creating a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, the simulation ontology model of the target aircraft is loaded based on the backup channel and the main channel; wherein, the backup channel and the main channel correspond to the loading parameters of different aircraft simulation ontology models; Test cases for the target aircraft are constructed using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters. Generate corresponding test scripts for the simulation ontology model based on the processing instructions for the target variables in the test cases; After controlling the clock and power modules in each simulation node to perform synchronous simulation tests on the simulation model based on the test script, the simulation test results of the flight control equipment are generated according to the test cases.

[0006] Optionally, a backup channel is created in at least one simulation node, and a primary channel is created in the remaining simulation nodes, including: Obtain the redundancy channel interface and backup channel interface corresponding to the closed-loop simulation node in the flight control equipment; A corresponding backup channel is created in at least one simulation node using the backup channel interface, and the first loading parameters of the target aircraft are determined based on the backup channel. Multiple corresponding main channels are created in the remaining simulation nodes using the redundancy channel interface, and the second loading parameters of the target aircraft are determined.

[0007] Optionally, a simulation ontology model of the target aircraft is loaded based on the backup channel and the main channel, including: After constructing the simulation backup model of the target aircraft and its corresponding first interface model using the hot backup status parameters of the backup channel, the backup channel is controlled to load the simulation backup model and the first interface model according to the first loading parameters. After constructing the simulation ontology model of the target aircraft and its corresponding second interface model based on the multi-degree-of-freedom dynamics model, sensor model and actuator model corresponding to the target aircraft in the main channel, the backup channel loads the simulation ontology model and the second interface model according to the second loading parameters.

[0008] Optionally, test cases corresponding to the target aircraft can be constructed using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters, including: Obtain the backup takeover strategy between the main channel and the backup channel, as well as the mode switching strategy for each simulation node in the main channel; Based on the backup takeover strategy and mode jump strategy, determine the expected behavior description parameters corresponding to the primary channel and backup channel in the loading parameters; The target redundancy channel corresponding to the target simulation node is determined based on the parallel processing strategy of the target simulation node in the main channel, and the injection parameters of the redundancy channel of the main channel in the loading parameters are determined based on the injection relationship between the target redundancy channel and the target simulation node. In a pre-defined structured file, construct the target fields corresponding to the expected behavior description parameters and redundancy channel injection parameters, and construct the test cases corresponding to the target aircraft through the target fields.

[0009] Optionally, based on the processing instructions for the target variable in the test cases, corresponding test scripts for the simulation ontology model are generated, including: The loading and startup commands for each simulation node are generated by describing the expected behavior parameters, and the injection fault instructions for the target simulation node in each simulation node are generated by injecting parameters through the redundancy channel. Generate data acquisition instructions corresponding to the simulation ontology model based on the master control flag, control commands, and state machine mode parameters of the flight control device in the test cases; By using a matching strategy between the actual behavior data and the expected behavior data of the flight control equipment, result judgment instructions corresponding to the simulation ontology model are generated; The test scripts corresponding to the simulation ontology model are generated based on the loading command, startup command, fault injection command, data acquisition command, and result judgment command.

[0010] Optionally, the step of generating result determination instructions corresponding to the simulation ontology model by utilizing a matching strategy between the actual behavior data and expected behavior data of the flight control equipment includes: Based on the structured document of the test cases, obtain one or more target variables from the variable names, data types, and physical scopes corresponding to the simulation ontology model, and use the preset ID values ​​to build an index table of variable names corresponding to the target variables; A variable name index table is used to construct an existence verification strategy and a type matching strategy for the actual behavior data and expected behavior data of the flight control equipment. The result determination instructions corresponding to the simulation ontology model are generated based on the existence verification strategy and the type matching strategy.

[0011] Optionally, based on the test script, the clock module and power module in each simulation node are controlled to perform synchronous simulation tests on the simulation model, including: Obtain the loading command, startup command, fault injection command, data acquisition command, and result judgment command contained in the test script; After the test script is distributed to each simulation node using the load command, the clock module and power module in each simulation node are started synchronously using the start command. The simulation data of the simulation body model at each simulation node is acquired in real time under the action of the clock module and the power module. When the simulation data meets the preset injection conditions, the fault is injected into the target simulation node corresponding to the simulation body model using the fault injection command, and the output signals of the main channel and backup channel are acquired in real time through the data acquisition command. After comparing and testing the output signal using the result judgment command, the simulation verification result of the simulation body model is obtained.

[0012] Optionally, generate simulation test results for the flight control device according to the test cases, including: Based on the tilt structure of the target aircraft, determine one or more fault types included in the injected fault command, such as tilt jamming, abnormal tilt rate, or bilateral tilt asynchrony. Based on the fault type, obtain the passability conclusion, difference description and traceability information of the simulation ontology model, and obtain the simulation test results of the flight control equipment under the test cases through the passability conclusion, difference description and traceability information.

[0013] Secondly, the present invention provides an aircraft simulation test control device, applied to the flight control equipment of an aircraft simulation test system; the aircraft simulation test system is provided with multiple closed-loop simulation nodes connected to the flight control equipment, each simulation node being provided with an independent clock module and power supply module; the device includes: Initialization module: Used to create a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, and then load the simulation ontology model of the target aircraft based on the backup channel and the main channel; wherein, the backup channel and the main channel correspond to the loading parameters of different aircraft simulation ontology models; Test case management module: used to construct test cases for the target aircraft using the expected behavior description parameters of each channel in the loading parameters and the redundant channel injection parameters; Test script generation module: used to generate corresponding test scripts for the simulation ontology model based on the processing instructions of the target variables in the test cases; Simulation test processing module: It is used to control the clock module and power module in each simulation node to perform synchronous simulation test on the simulation body model based on the test script, and then generate the simulation test results of the flight control equipment according to the test cases.

[0014] Thirdly, embodiments of the present invention also provide an aircraft simulation testing system, which includes flight control equipment and multiple closed-loop simulation nodes connected to the flight control equipment. Each simulation node is equipped with an independent clock module and a power supply module. The clock module and the power supply module are used to perform synchronous simulation testing on the target aircraft corresponding to the flight control equipment. The flight control device includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor. The processor executes the computer-executable instructions to implement the steps of the aircraft simulation test control method provided in the first aspect.

[0015] This invention provides an aircraft simulation test control method, apparatus, and test system, applied to the flight control equipment of an aircraft simulation test system. The aircraft simulation test system includes multiple closed-loop simulation nodes connected to the flight control equipment, each with an independent clock module and power supply module. During hardware testing of the aircraft's flight control equipment, the method first creates a backup channel in at least one simulation node and a main channel in the remaining simulation nodes. Then, it loads the target aircraft simulation model based on the backup and main channels. The backup and main channels correspond to loading parameters for different aircraft simulation models. Next, it constructs test cases for the target aircraft using the expected behavior description parameters of each channel and the redundancy channel injection parameters in the loading parameters. Subsequently, it generates test scripts for the simulation model based on the processing instructions for the target variables in the test cases. Finally, it controls the clock and power supply modules in each simulation node to perform synchronous simulation testing of the simulation model based on the test scripts, and generates simulation test results for the flight control equipment according to the test cases. The aircraft simulation test system implemented in this scheme achieves the independence of backup channels and main channels through multiple independent closed-loop simulation nodes. Each simulation node is equipped with an independent clock module and power supply module, so the failure of any node will not affect the operation of other nodes. Compared with the traditional single simulator solution, its system availability is significantly improved. In addition, the independent backup channels and main channels can fully reproduce the channel isolation of the aircraft in the real flight environment, and can expose behavioral anomalies caused by physical differences, greatly improving test coverage and accuracy.

[0016] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart of an aircraft simulation test control method provided in an embodiment of the present invention; Figure 2 A flowchart of another aircraft simulation test control method provided in an embodiment of the present invention; Figure 3 A template diagram of the first type of test case provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a test report in an aircraft simulation test control method provided in an embodiment of the present invention; Figure 5 This is a template diagram of the second type of test case provided in an embodiment of the present invention; Figure 6 This is a template diagram of the third type of test case provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an aircraft simulation test control device provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an aircraft simulation test system provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of a flight control device provided in an embodiment of the present invention.

[0020] icon: 100 - Initialization module; 200 - Test case management module; 300 - Test script generation module; 400 - Simulation test processing module; 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] To facilitate understanding of this embodiment, a flight simulation test control method disclosed in this invention will first be introduced, which is applied to the flight control equipment of a flight simulation test system. The flight simulation test system has multiple closed-loop simulation nodes connected to the flight control equipment, and each simulation node has an independent clock module and power supply module. The method is as follows: Figure 1 As shown, it includes: Step S101: After creating a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, load the simulation ontology model of the target aircraft based on the backup channel and the main channel; wherein, the backup channel and the main channel correspond to the loading parameters of different aircraft simulation ontology models.

[0023] This step is executed by the upper control unit of the aircraft simulation test system—the flight control equipment. The specific process is as follows: Based on the redundancy architecture of the flight control equipment, a physically independent closed-loop simulation node is assigned to each redundancy channel. At least one simulation node is configured as the node corresponding to the backup channel, and the remaining simulation nodes are configured as the nodes corresponding to the main channel, establishing a mapping relationship between "simulation node - flight control redundancy channel". After the channel configuration is completed, the simulation model of the target aircraft is loaded into each simulation node as the controlled object, covering the six-degree-of-freedom dynamic model of the aircraft, the sensor simulation model, and the actuator simulation model. Each simulation node is connected to the corresponding redundancy channel of the flight control equipment through an independent physical signal cable, forming an independent excitation-feedback closed-loop simulation loop.

[0024] Among them, the backup channel and the main channel use different loading parameters: all main channel nodes are configured with the same initial model state and physical parameters; the initial model state of the backup channel nodes is set to have a preset small deviation from the main channel within the legal range (such as a small offset of airspeed and attitude angle), in order to simulate the difference in normal measurement values ​​caused by the physical isolation of each channel, the difference in cable length, the power ripple and the temperature drift characteristics of the conditioning circuit in real flight scenarios, so that the test input environment is closer to the real flight conditions.

[0025] Meanwhile, each simulation node operates independently based on its own independent clock module and power module. There is no shared clock, power and hardware bus resources between nodes. A single node failure will not spread to other nodes, thus eliminating the risk of single point of failure from the architecture and improving the operational reliability of the test system itself.

[0026] Step S102: Construct test cases corresponding to the target aircraft using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters.

[0027] Based on the redundancy management verification requirements of the target aircraft and the aircraft loading parameters of each channel, structured test cases adapted to the "multi-master channel + backup channel" architecture are constructed. Each test case contains at least two types of core parameters: The first category is redundancy channel injection parameters, which are used to define the target object of fault injection (a single main channel, multiple main channels or backup channels can be specified), fault type, fault triggering conditions (such as specifying simulation time nodes or triggering specific flight states). It supports traversing fault scenarios with different redundancy levels and covers various operating conditions such as single-channel faults and multi-channel concurrent faults.

[0028] The second category is expected behavior description parameters, which are used to define the expected response of the flight control equipment after fault injection. Specifically, these include the master control switching result, flight control working mode jump, fault alarm code output, and the legal range of control commands, which are unique behavioral characteristics of the redundancy architecture. For example, after a single master channel failure, the remaining master channel takes over the master control; after multiple master channel failures, the backup channel is woken up and takes over; after a fault is triggered, the flight control enters a degraded operation mode.

[0029] Test cases are defined using a standardized, structured format, fully including test number, test steps, trigger conditions, observed variables, and expected results, providing a standardized and parsable input source for subsequent automated script generation.

[0030] Step S103: Generate the corresponding test script for the simulation ontology model based on the processing instructions for the target variable in the test case.

[0031] The structured test cases are parsed, the target variables and processing instructions are extracted, and test scripts that can be executed on each closed-loop simulation node are automatically generated. The specific generation process includes: First, the relevant data dictionary files of the flight control equipment are preloaded, and a variable index table containing variable names, data types, physical value ranges, and units is established. Then, all target variables involved in the test cases are verified line by line to verify the existence of variable names and the matching of data types. If the verification fails, an error report containing file location, line number, and error variable information is generated, and the script generation process is terminated. This moves the discovery of variable configuration errors from the test run phase to the script generation phase, reducing debugging costs.

[0032] After the variable verification is passed, the test cases are converted into complete test scripts containing multiple types of execution instructions by combining the preset fault template library and simulation platform API mapping rules. Specifically, these include: simulation ontology model loading and startup control instructions for each simulation node, timed / condition-triggered fault injection instructions, flight control channel output signal acquisition instructions, and comparison and judgment instructions between actual behavior and expected results.

[0033] Step S104: After controlling the clock module and power module in each simulation node to perform synchronous simulation test on the simulation body model based on the test script, generate the simulation test results of the flight control equipment according to the test cases.

[0034] Based on the generated test script, the flight control equipment synchronously sends simulation start commands to all closed-loop simulation nodes. Relying on the independent clock and power modules of each node, it starts distributed closed-loop simulation to realize synchronous simulation testing of the simulation model. During the simulation operation, the test script injects corresponding faults into the target simulation node according to the preset triggering time. At the same time, it continuously collects the output signals of each redundancy channel of the flight control equipment at the set sampling rate, which may include key status quantities such as master control flag, flight control mode word, control command value, and fault alarm code.

[0035] After the simulation test is completed, the collected actual operating data is compared one by one with the expected behavior description parameters in the test cases to determine the pass status of each test item, and finally generate a complete simulation test result report for the flight control equipment. In addition to the judgment conclusion and the explanation of the difference between the actual value and the expected value, the report can also embed the source identifier and location traceability information of the corresponding test cases, forming a complete evidence chain from test requirements to test execution and then to test results, which meets the requirements of airworthiness standards such as DO-178C for test traceability.

[0036] Meanwhile, since each simulation node is physically independent, the simulation process will naturally reproduce the subtle signal differences between channels in the real flight environment. This can effectively trigger the redundancy management logic defects that only appear when there are differences in channel inputs, thereby improving test coverage and the ability to detect potential problems.

[0037] Optionally, a backup channel is created in at least one simulation node, and a primary channel is created in the remaining simulation nodes, including the following steps: Step S201: Obtain the redundancy channel interface and backup channel interface corresponding to the closed-loop simulation node in the flight control equipment.

[0038] First, obtain the hardware interface configuration information of the flight control device under test, identify the redundancy channel interface corresponding to each working redundancy on the flight control device, and the backup channel interface corresponding to the cold / hot backup link; the redundancy channel interface and the backup channel interface cover a variety of signal types such as analog input / output interface, CANFD bus interface, serial communication interface, Ethernet interface, etc., and extract the pin definition, communication protocol, signal range, sampling rate and electrical characteristic parameters of each interface.

[0039] Subsequently, the aforementioned flight control side interfaces were mapped one-to-one with multiple physically independent closed-loop simulation nodes in the test system. The flight control channel attributes (primary redundancy channel or backup channel) connected to each simulation node were clarified, and a binding relationship between "simulation node and flight control channel" was established, providing a configuration basis for subsequent physical connection construction and channel logic creation.

[0040] Step S202: Create a corresponding backup channel in at least one simulation node using the backup channel interface, and determine the first loading parameters of the target aircraft based on the backup channel.

[0041] Based on the interface mapping results, at least one closed-loop simulation node is selected as a dedicated backup channel node. The hardware I / O interface of this node is used to establish a one-to-one signal connection with the backup channel interface of the flight control equipment through an independent physical signal cable, forming an independent backup channel closed-loop simulation circuit. This simulation node is equipped with an independent embedded system clock and an independent power supply module, and does not share clock, power and memory bus resources with any other simulation nodes, maintaining complete physical isolation at the electrical and timing levels.

[0042] Simultaneously, the first loading parameters of the target aircraft are determined as the basis for the model configuration of the backup channel node: the first loading parameters include the aircraft body model parameters such as the six-degree-of-freedom dynamic model, sensor simulation model, and actuator simulation model of the target aircraft (such as the tilt-ducted duct eVTOL), as well as the initial state parameters of the model; among them, the initial state parameters can be configured to have a legal small deviation within a preset range from the main channel (such as an initial airspeed difference of 0.5m / s), which is used to simulate the normal differences such as signal line propagation delay, power ripple, and signal conditioning temperature drift caused by the physical isolation characteristics of the backup channel in the real flight environment, so as to verify the flight control redundancy management algorithm's ability to distinguish between "normal channel differences" and "real channel faults".

[0043] Step S203: Use the redundancy channel interface to create multiple corresponding main channels in the remaining simulation nodes, and determine the second loading parameters of the target aircraft.

[0044] For the remaining closed-loop simulation nodes, the hardware I / O interface of each node is used to establish a one-to-one signal connection with the corresponding redundancy channel interface of the flight control equipment through independent physical signal cables. A main channel corresponding to each main redundancy channel is created, and each main channel forms an independent closed-loop simulation loop. The simulation node corresponding to each main channel is also equipped with an independent clock and an independent power supply. The nodes are completely physically isolated from each other, which can naturally reproduce the small signal differences between the main channels in real flight.

[0045] Simultaneously, a second loading parameter for the target aircraft is determined as the basis for unified model configuration of all main channel nodes: the second loading parameter includes aircraft body model parameters with the same architecture as the first loading parameter, and all main channel nodes are configured with identical initial model state parameters (such as initial altitude, airspeed, and attitude angle are all set to consistent reference values) to ensure the consistency of the main channel input reference; on this basis, relying on the physical isolation characteristics of each node, small signal deviations will naturally occur during the simulation operation due to differences in cable length, power ripple, and temperature drift characteristics, thereby reproducing the channel input characteristics of real flight and exposing the redundancy management software defects that cannot be triggered by the same source signal of a single simulator.

[0046] Optionally, the simulation model of the target aircraft is loaded based on the backup channel and the main channel, including the following steps: Step S301: After constructing the simulation backup model of the target aircraft and its corresponding first interface model using the hot backup status parameters of the backup channel, the backup channel loads the simulation backup model and the first interface model according to the first loading parameters.

[0047] Obtain the hot backup status parameters corresponding to the backup channel. The hot backup status parameters include the legal initial state deviation threshold between the backup channel and the main channel, and the state constraints of the backup channel following the operation. Based on the unified architecture of the target aircraft's body model, construct a simulation backup model with the same architecture as the main channel as the controlled object. This model can cover the six-degree-of-freedom dynamic model of the tilt-ducted wing eVTOL, simulation models of multiple types of sensors, and actuator simulation models. The model also has pre-set interface variables that support fault injection, which can adapt to the simulation of fault scenarios such as sensor data freezing and actuator jamming. Simultaneously construct a first interface model that matches the hardware interface of the flight control equipment's backup channel. The first interface model corresponds to the signal conversion logic, communication protocol, and electrical characteristic matching parameters of interfaces such as analog I / O, CANFD bus, serial communication, and Ethernet.

[0048] After the model is built, according to the pre-configured first loading parameters, the independent hardware-in-the-loop simulation node corresponding to the backup channel loads the simulation backup model and the first interface model. The first loading parameters include the real-time running step size and the initial state parameter set of the simulation backup model. The initial state parameters are based on the reference initial value of the main channel with a small legal deviation within a preset range (such as setting the initial airspeed to 0.5 m / s, forming a controllable difference from the reference value of 0 m / s of the main channel). This makes the excitation signal output by the backup channel have a normal deviation from the main channel that conforms to the real physical characteristics. This simulates the inherent differences in signal line propagation delay, power ripple, and signal conditioning circuit temperature drift caused by physical isolation in the backup channel in the real flight environment. This is used to verify the ability of the flight control redundancy management algorithm to distinguish between normal channel differences and real channel faults.

[0049] Step S302: After constructing the simulation ontology model of the target aircraft and its corresponding second interface model based on the multi-degree-of-freedom dynamics model, sensor model and actuator model corresponding to the target aircraft in the main channel, the backup channel is controlled to load the simulation ontology model and the second interface model according to the second loading parameters.

[0050] To meet the testing benchmark requirements of the main channel, a complete simulation model is constructed based on the aerodynamic, structural, and propulsion system parameters of the target aircraft. This model includes a six-degree-of-freedom dynamic model of the tilt-ducted wing eVTOL, simulation models of various types of sensors such as atmospheric data / inertial navigation, a distributed ducted electric propulsion actuator model, and a tilt mechanism actuation model. The model also includes pre-defined injection interface variables for various types of faults, supporting the simulation of configuration-specific faults such as tilt jamming, abnormal tilt rate, single-ducted motor failure, and abnormal thrust distribution in multi-ducted systems. Simultaneously, a second interface model is constructed, matching the hardware interfaces of each primary and redundant channel of the flight control equipment. This second interface model adapts to the signal range, communication protocol, and sampling timing of the corresponding channel's analog input / output, CANFD bus, serial communication, and Ethernet communication.

[0051] After the simulation ontology model is constructed, the independent hardware-in-the-loop simulation nodes corresponding to each main channel are controlled to load the simulation ontology model and the second interface model according to the pre-configured second loading parameters. The second loading parameters are the model parameters and baseline initial state parameters uniformly configured for all main channels (such as initial altitude 0m, initial airspeed 0m / s, initial attitude angle 0°), ensuring that the model input baseline of each main channel is consistent. Relying on the complete physical isolation characteristics of the independent clock, independent power supply, and independent hardware link of each main channel simulation node, nanosecond to millisecond-level tiny signal deviations will naturally occur during model operation due to differences in signal line length, power ripple, and signal conditioning temperature drift. This realistically reproduces the input characteristics of each main redundancy channel in the actual flight environment, thereby triggering and exposing redundancy management defects that cannot be detected by the single simulator homogeneous signal scheme.

[0052] Optionally, test cases for the target aircraft can be constructed using the expected behavior description parameters of each channel in the aircraft loading parameters and the redundancy channel injection parameters, including the following steps: Step S401: Obtain the backup takeover strategy between the main channel and the backup channel, as well as the mode switching strategy of each simulation node in the main channel.

[0053] Taking three main channels and one backup channel as an example, the corresponding redundancy management design rules are obtained, including the backup takeover strategy between the main channel and the backup channel, as well as the flight control state machine mode jump strategy corresponding to each main channel.

[0054] The backup takeover strategy covers: the priority of master control switching for the remaining master channel when a single master channel fails; the wake-up triggering conditions and takeover logic for the backup channel when two or more master channels fail concurrently; and the isolation and status reporting rules for the faulty channel. The mode transition strategy covers: the transition conditions and legal transition paths for multiple states such as flight control power-on self-test, low-voltage standby, power-on, normal flight, and degraded operation; and constraint rules prohibiting cross-state transitions. For the tilt-ducted wing eVTOL configuration, redundancy arbitration and mode adjustment rules corresponding to tilt mechanism failures in transition modes are extracted synchronously, covering the fault response logic for this special configuration.

[0055] Step S402: Determine the expected behavior description parameters corresponding to the primary channel and backup channel in the loading parameters based on the backup takeover strategy and mode jump strategy.

[0056] Based on backup takeover and mode switching strategies, corresponding expected behavior description parameters for the main channel and backup channel are generated, transforming abstract redundancy management rules into quantifiable and verifiable test judgment criteria.

[0057] The expected behavior description parameters specifically include: the expected state of the channel master control flag, the expected enumeration value of the flight control working mode word, the expected output value of the fault alarm code, the legal value range of the core control command, and the target state and timing constraints of the state machine transition. For the dedicated verification scenario of the triple redundancy and backup architecture, the parameters cover unique expected behaviors such as "the remaining master channel takes over master control after a single master channel failure", "the backup channel wakes up and takes over after all master channels fail", "the faulty channel enters the degraded operation mode", and "the corresponding fault code is reported as designed". Each parameter is mapped to a specific variable in the flight control software, providing a clear benchmark for subsequent automation result judgment.

[0058] Step S403: Determine the target redundancy channel corresponding to the target simulation node according to the parallel processing strategy of the target simulation node in the main channel, and determine the redundancy channel injection parameters of the main channel in the loading parameters based on the injection relationship between the target redundancy channel and the target simulation node.

[0059] Based on the parallel processing strategy of multiple simulation nodes running independently in parallel, and combined with the fault coverage requirements of the test scenario, the target redundancy channel to be injected with faults is determined, and it supports selecting a single main channel, a combination of multiple main channels, or a backup channel as the fault injection object; based on the mapping injection relationship between the target redundancy channel and the corresponding simulation node, the redundancy channel injection parameters corresponding to the main channel are generated.

[0060] The redundancy channel injection parameters include: target channel identifier, fault type, fault triggering condition, and fault duration. The fault type covers both general flight control faults and tilt-ducted wing configuration-specific faults, the latter including tilt mechanism jamming, abnormal tilt rate, asynchrony of tilt on both sides, single ducted motor failure, abnormal thrust distribution of multi-ducted wing, and abnormal transition mode flag. The fault triggering condition supports two modes: simulation time-based triggering and flight state event triggering. For example, when the tilt angle in the simulation model reaches a preset threshold, fault injection is triggered to adapt to the testing requirements of complex conditions such as transition modes.

[0061] Step S404: Construct the target fields corresponding to the expected behavior description parameters and redundancy channel injection parameters in the preset structured file, and construct the test cases corresponding to the target aircraft through the target fields.

[0062] In a pre-defined structured file template (such as an Excel spreadsheet template), specific target fields corresponding to the expected behavior description parameters and redundancy channel injection parameters are pre-set, while general fields such as test case number, test scenario description, test steps, and step descriptions are configured. The previously generated expected behavior description parameters and redundancy channel injection parameters are mapped and filled into the corresponding target fields, ultimately forming a standardized test case set corresponding to the target aircraft.

[0063] Test cases adopt a unified structured field specification, which not only supports testers to write test scenarios in batches according to the specification, but also provides standardized input for the automated parsing and generation of subsequent test scripts. At the same time, each test case has a built-in traceability identifier, which can be linked to the original flight control requirement item to form a traceability link of "requirement-test case", which meets the traceability requirements of airworthiness standards such as DO-178C and DO-331 for the test evidence chain.

[0064] Optionally, based on the processing instructions for the target variable in the test cases, a corresponding test script for the simulation ontology model is generated, including the following steps: Step S501: Generate loading and startup commands for each simulation node using expected behavior description parameters, and generate injection fault instructions for the target simulation node in each simulation node using redundancy channel injection parameters.

[0065] The expected behavior description parameters and redundancy channel injection parameters in the structured test cases are analyzed. First, the pre-built data dictionary variable index table in the flight control equipment is called to perform existence checks and data type matching checks on all variable names involved in the command. After the checks pass, the command generation work is carried out.

[0066] Based on the timing logic of test execution, model loading commands and synchronous start commands are generated to adapt to each independent hardware-in-the-loop simulation node: The model loading command is used to control the corresponding simulation node to load the specified aircraft controlled object model, interface model and initial state parameters, to ensure that the main channel node loads model parameters with consistent reference, and the backup channel node loads the initial state with preset slight deviation; The synchronous start command is uniformly issued by the host computer to all simulation nodes in parallel, to control the synchronous start of simulation by multiple nodes, and to ensure the consistency of the initial timing of the test.

[0067] Simultaneously, based on the target channel identifier, fault type, and triggering conditions in the redundancy channel injection parameters, a fault injection command is generated for the target simulation node. The fault injection command supports two modes: timed triggering and event triggering. The former triggers the fault at a preset simulation time point, while the latter triggers the fault when the model state meets specified conditions (such as the tilt angle reaching a preset threshold). The fault types cover general sensor / actuator faults and tilt duct specific faults, including atmospheric engine data freezing, tilt mechanism jamming, abnormal tilt rate, bilateral tilt asynchrony, single duct motor failure, etc. Fault injection is achieved by modifying the preset fault interface variables in the corresponding node model.

[0068] Step S502: Generate data acquisition instructions corresponding to the simulation ontology model based on the master control flag, control commands, and state machine mode parameters of the flight control device in the test case.

[0069] Based on the verification dimensions defined in the test cases, the core observation variables of the flight control equipment are extracted, corresponding data acquisition instructions are generated, and the acquisition channel range, sampling frequency, acquisition duration, and data storage rules are clarified.

[0070] The core observation variables include at least: master control flags for each primary redundancy channel and backup channel, state machine mode variables, core control command values, and fault alarm codes; for the tilting duct eVTOL configuration, dedicated monitoring variables such as tilt angle commands, transition mode flags, and distributed duct motor status are also included.

[0071] The data acquisition command can be configured to continuously acquire data from the simulation model throughout the entire simulation cycle, or to acquire output data for a target duration at a specified sampling rate (e.g., 100Hz) after fault injection is triggered, and to bind the local timestamp of the corresponding simulation node to each set of acquired data for subsequent behavior timing determination and redundancy switching delay analysis.

[0072] Step S503: Using the matching strategy between the actual behavior data and the expected behavior data of the flight control equipment, generate the result judgment command corresponding to the simulation ontology model.

[0073] Based on a preset matching strategy between actual and expected behavior, result judgment instructions are generated for each test verification point. These instructions are used to automatically compare and verify the actual output data collected by the flight control equipment with the expected behavior description parameters in the test cases.

[0074] The judgment command covers multi-dimensional verification logic: First, status-based judgment, which verifies whether the master control channel, flight control working mode, and fault alarm code are consistent with the expected status; second, value range-based judgment, which verifies whether the control command and status value are within the preset legal value range; and third, timing-based judgment, which verifies whether the specified status transition after fault injection is completed within the allowable time window.

[0075] Each judgment instruction corresponds to a unique test verification point. If the actual data matches the expectation, the verification point is marked as passed. If they do not match, the specific difference between the actual value and the expected value is automatically recorded, providing a complete judgment basis for the generation of subsequent test reports.

[0076] Step S504: Generate the corresponding test scripts for the simulation ontology model based on the loading command, start command, fault injection command, data acquisition command, and result judgment command.

[0077] The aforementioned generated model loading command, simulation start command, fault injection command, data acquisition command, and result judgment command are integrated and arranged according to the sequential logic of test execution to form the execution logic link for the flight control equipment to perform a complete closed-loop test on the simulation model.

[0078] During the generation process, an intermediate format script (such as JSON format) independent of the specific hardware platform is first output. This intermediate script uniformly encapsulates the test process logic and variable definitions, and is not bound to the API interface of a specific simulation platform. When it is necessary to adapt to different simulation hardware platforms (such as dSPACE, NI, Speedgoat or self-developed real-time machine), it is only necessary to call the API mapping rules of the corresponding platform to convert the intermediate format script into a test script that can be directly executed by the target platform, so as to achieve compatibility and adaptation of multiple test platforms.

[0079] Meanwhile, the source file identifier and line number traceability information of the corresponding test cases are embedded in the generated test scripts to establish a mapping relationship between test cases and test scripts, ensuring the traceability of the entire testing process and meeting the test evidence chain requirements of airworthiness standards such as DO-178C and DO-331.

[0080] Optionally, the step of generating result determination instructions corresponding to the simulation ontology model by utilizing the matching strategy between the actual behavior data and expected behavior data of the flight control equipment includes the following steps: Step S601: Obtain one or more target variables from the variable names, data types, and physical scopes corresponding to the simulation ontology model based on the structured document of the test cases, and establish a variable name index table corresponding to the target variables using preset ID values.

[0081] Read the data dictionary file and test case structured document of the flight control device under test, and extract all target variable information involved in the simulation ontology model throughout the entire test process. The target variable information includes one or more of the variable name, data type, physical value range, unit of measurement, and enumeration value set of enumeration type variables. The target variables cover the master control flag, state machine mode parameters, fault alarm codes, core control commands required for redundancy management verification, as well as customized variables such as tilt angle commands, transition mode flags, and ducted motor states specific to the tilt duct configuration.

[0082] Each variable is assigned a unique identifier ID, and a variable name index table is constructed based on a preset ID mapping rule. The variable name index table adopts a hash mapping structure, using the variable name as the search key and the corresponding data type, physical range, unit attribute, and variable ID as the mapping value, forming a standardized variable benchmark library. This provides a unified comparison basis for subsequent variable verification and result judgment, while also enabling the mutual correlation and traceability between test variables and test cases.

[0083] Step S602: Construct an existence verification strategy and a type matching strategy for the actual behavior data and expected behavior data of the flight control device using a variable name index table.

[0084] Based on the variable name index table, existence verification strategies and type matching strategies are constructed for the actual behavior data and expected behavior data of flight control equipment, forming a pre-verification rule system.

[0085] The existence verification strategy is used to: before generating result judgment instructions, traverse all expected behavior variables, fault injection variables, and data acquisition variables in the test cases, and match and verify them one by one with the variable names in the variable name index table; if a variable name not included in the index table is detected in the test case, an error message containing the test case file name, corresponding line number, and erroneous variable name is immediately generated, and the subsequent instruction generation process is terminated. This moves the discovery of variable configuration errors from the test execution phase to the script generation phase, reducing debugging and troubleshooting costs.

[0086] The type matching strategy is used to further compare the data type of the variable assigned in the test case with the data type defined in the variable name index table for variables that have passed the existence check. This includes matching the precision of floating-point numbers, validating the value of enumerated variables, and verifying the consistency of the state definition of Boolean variables. At the same time, it verifies whether the expected value falls within the physical range of the variable definition, so as to avoid test script execution errors caused by type incompatibility or out-of-bounds values.

[0087] Step S603: Generate result determination instructions corresponding to the simulation ontology model based on the existence verification strategy and type matching strategy.

[0088] Based on the existence verification strategy and the type matching strategy, the result judgment instruction corresponding to the simulation ontology model is generated. The result judgment instruction integrates the pre-verification logic and the multi-dimensional judgment logic.

[0089] During the command execution phase, the pre-verification logic is first invoked to perform variable existence and data type verification on the real-time behavioral data collected by the flight control equipment, confirming the legality of the collected data. After the verification is passed, multi-dimensional result judgment logic is executed: for status variables, the actual status enumeration value is compared with the expected status, such as the master control channel, flight control operation mode, fault code output, etc.; for numerical variables, it is determined whether the actual collected value is within the expected legal value range, such as tilt command angle, control command amplitude, etc.; for timing verification points, it is determined whether the state transition after fault injection is completed within the preset time window.

[0090] Each judgment instruction is bound to a unique identifier and traceability information of the corresponding test case. After the judgment is completed, the pass / fail conclusion is automatically recorded, as well as the details of the difference between the actual value and the expected value in the failure scenario. This provides complete data support for the generation of subsequent test reports and the traceability of the evidence chain for airworthiness standards such as DO-178C and DO-331.

[0091] Optionally, based on the test script, the clock module and power module in each simulation node are controlled to perform synchronous simulation tests on the simulation model, including the following steps: Step S701: Obtain the loading command, startup command, fault injection command, data acquisition command, and result judgment command contained in the test script.

[0092] The flight control equipment loads and parses the pre-generated test script, extracting the complete instruction set from the script's sequential execution logic. Specifically, this includes model loading commands for each simulation node, global synchronous simulation start commands, fault injection commands with trigger conditions, multi-channel signal data acquisition commands, and automatic result determination commands. The instruction set clearly marks the target simulation node attributes (main channel node or backup channel node), trigger timing, execution parameters, and associated flight control variable information for each command, providing a complete execution basis for distributed collaborative testing.

[0093] Step S702: After the test script is sent to each simulation node using the load command, the clock module and power module in each simulation node are started synchronously using the start command.

[0094] First, based on the model loading command, the corresponding configured aircraft controlled object model and interface model are sent to the three main channel simulation nodes and one backup channel simulation node respectively, completing the model deployment and initialization parameter configuration. Then, the host computer sends the simulation start command to all simulation nodes in parallel, synchronously triggering the independent clock module and independent power supply module of each simulation node to enter the running state, so that each node can synchronously start closed-loop simulation operation under the premise of complete electrical resource isolation and no shared clock and hardware bus.

[0095] In conventional testing scenarios for verifying the correctness of redundant logic, the simulation clock deviation of each node can be controlled within 10 milliseconds by using the host computer synchronous triggering method, which meets the timing requirements of logic judgment. If performance tests such as microsecond-level switching delay are required, a PTP high-precision time synchronization device can be connected to achieve clock calibration.

[0096] Step S703: Real-time acquisition of simulation data of the simulation body model at each simulation node under the action of the clock module and power supply module. When the simulation data meets the preset injection conditions, inject a fault into the target simulation node corresponding to the simulation body model using the fault injection command, and collect the output signals of the main channel and backup channel in real time through the data acquisition command.

[0097] Each simulation node performs closed-loop simulation of the simulation body model under the drive of independent clock and power modules, generating simulation data in real time, including the six-degree-of-freedom dynamic state of the aircraft, sensor output, and actuator feedback. The flight control equipment can monitor the simulation progress and status data of each node in real time. When the simulation running time reaches the preset time trigger condition, or the simulation state quantity meets the preset event trigger condition (such as the tilt angle reaching the preset threshold or the flight mode switching to the transition mode), the fault injection command is called to inject the preset fault into the target simulation node corresponding to the simulation body model.

[0098] Faults are injected by modifying the pre-set fault interface variables in the simulation model, covering general sensor data freezing, signal anomalies, and configuration-specific faults such as tilt mechanism jamming, tilt rate anomalies, single-duct motor failure, and multi-duct thrust distribution anomalies specific to the tilt ducted wing eVTOL. While injecting faults, the system continuously collects the output signals of all main and backup channels of the flight control equipment at a preset sampling rate through data acquisition commands, including key variables such as master control flag, state machine mode parameters, core control commands, and fault alarm codes, and stores each set of collected data by binding the local timestamp of the corresponding node.

[0099] Step S704: After comparing and testing the output signal using the result judgment command, the simulation verification result of the simulation body model is obtained.

[0100] The system calls the result judgment command to compare and verify the actual output signals of each channel of the flight control equipment collected in real time with the expected behavior parameters preset in the test cases. The verification dimensions include consistency verification of state variables, legal range verification of numerical variables, and time sequence compliance verification of state transitions. It can also automatically determine the pass / fail status of each test verification point and automatically record the specific difference information between the actual value and the expected value for items that are determined to fail.

[0101] The final output is the simulation verification result of the flight control redundancy management logic of the simulation ontology model. At the same time, the source identification and traceability information of the corresponding test cases are embedded in the results, forming a complete evidence chain from test requirements to test execution and then to test results, which is compatible with the test traceability requirements of airworthiness standards such as DO-178C and DO-331.

[0102] Optionally, generate simulation test results for the flight control device according to the test cases, including the following steps: Step S801: Determine one or more fault types, such as tilt jamming, abnormal tilt rate, or bilateral tilt asynchrony, contained in the injected fault command based on the tilt structure of the target aircraft.

[0103] Based on the tilt mechanism configuration and transition mode operating characteristics of the target tilt-ducted eVTOL aircraft, the fault types included in this fault injection command are determined by matching from the preset configuration-specific fault template library. Specifically, one or more of tilt jamming, abnormal tilt rate, and bilateral tilt asynchrony can be selected. According to the verification requirements, fault modes related to the same configuration, such as single-ducted motor failure, multi-ducted thrust distribution abnormality, and transition mode flag abnormality, can also be expanded to include.

[0104] Each fault type corresponds to a pre-set fault interface variable in the simulation model (such as the tilt fault enable variable Tilt_Fault_Enable and the fault type variable Tilt_Fault_Type). By modifying the value of the corresponding variable, the corresponding fault scenario can be triggered. The selection of fault types is based on the mechanical failure mode of the tilt mechanism, the verification target of flight control redundancy management, and typical flight conditions such as hovering, transition, and cruise, to ensure that the fault injection scenario fully covers the unique risk points of tilt-ducted wing aircraft.

[0105] Step S802: Obtain the passability conclusion, difference description and traceability information of the simulation ontology model based on the fault type, and obtain the simulation test results of the flight control equipment under the test case through the passability conclusion, difference description and traceability information.

[0106] Based on all test verification points corresponding to the determined fault type, and combined with the automatic comparison results of the actual collected values ​​of the output signals of each channel of the flight control equipment with the expected behavior parameters preset by the test cases, the passability conclusion, behavior difference description and full-link traceability information of the corresponding test cases are generated in sequence. The three are integrated to form the complete simulation test results of the flight control equipment.

[0107] The pass / fail conclusion outputs a pass / fail result for each test case, covering dimensions such as whether the master control switching channel meets expectations, whether the flight control equipment correctly switches operating modes, whether fault alarm codes are reported as designed, and whether tilt control commands are within the legal value range. The difference description records the specific deviations between the actual behavior and the expected behavior in failure scenarios, including detailed information such as the actual takeover channel identifier, actual flight control mode parameters, and actual control command values. The traceability information embeds the source file identifier, line number information, and test script generation time of the corresponding test case, establishing a complete evidence chain of "test requirements - test cases - test scripts - test results". Finally, the simulation test results are output in the form of a standardized test report, including three major modules: test summary statistics, detailed test case judgment results, and traceability information.

[0108] A flowchart of another aircraft simulation test control method is shown below. Figure 2 As shown, it includes the following steps: Step S1: Hardware deployment and physical connection.

[0109] The four independent simulation nodes are physically connected to the three main channels and one backup channel of the flight control equipment to ensure electrical isolation between the channels.

[0110] Step S2: Simulation model configuration.

[0111] The aircraft simulation model of the tilt-ducted duct eVTOL is loaded at each node. For the main channel node, the same model parameters and initial state are loaded; for the backup channel node (node ​​D), its initial state can be configured to be slightly different from that of the main channel node (e.g., airspeed is set to 0.5 m / s while the main channel is set to 0 m / s) to simulate the slight signal deviation caused by physical differences between the channels under real hot backup conditions. This configuration ensures that the excitation signal of the backup channel has a slight difference from that of the main channel within a legal range, thereby verifying the robustness of the flight control redundancy management software in dealing with normal channel differences.

[0112] Step S3: Writing automated test cases.

[0113] Testers create test cases in Excel format within the aircraft simulation testing system. Each test case must contain at least the following fields: Test Case ID, Description, TestStep, Automation Test Step, Test Step Introduction, Test Step Expected Result, and Automation Test Step Expected Result.

[0114] The test cases will also define specific field types for the "three redundancy, one backup" architecture: Expected_Behavior supports descriptions of expected behaviors specific to this architecture, such as backup takeover and degradation mode switching; Fault_Channel allows specifying injection into any one or more redundancy channels to simulate fault scenarios at different redundancy levels; a template diagram of the test cases is shown below. Figure 3 As shown.

[0115] Step S4: Test scripts are generated automatically.

[0116] The flight control equipment of the aircraft simulation testing system reads an Excel spreadsheet and automatically generates an executable test script based on preset custom libraries, fault template libraries, mapping software variable relationships, and API mapping rules. The script content includes: Commands for loading and starting the model of each simulation node; Inject fault instructions into the target node at a specified time; Data acquisition commands (acquiring output signals from various flight control channels, such as master control flags, control commands, state machine modes, fault codes, etc.); Result Judgment Instruction: Compare the collected actual behavior with the expected behavior to generate a judgment conclusion.

[0117] During the script generation phase, the system first reads the data dictionary file of the flight control equipment (containing information such as variable names, data types, and physical ranges) and establishes a variable name index table. Then, it parses the Excel test cases line by line, performing existence checks and type matching checks on the variable names in each row. If a variable name does not exist in the data dictionary or the data type does not match, the system immediately generates an error report (including the Excel file name, row number, and erroneous variable name) and terminates script generation, thus shifting the discovery of variable errors from "runtime" to "generation time".

[0118] Step S5: Perform the test.

[0119] The flight control equipment issues and executes the script. During execution: the script controls the synchronous startup of each node; when the specified simulation time or event conditions are met, it injects a fault into the corresponding node through the API; it continuously collects the output signals of each channel of the flight control; and the script automatically determines whether each verification point passes based on the preset expected behavior.

[0120] For the tilt duct special actuator (tilt mechanism), fault injection is achieved by modifying the preset fault interface variables (such as Tilt_Fault_Enable and Tilt_Fault_Type) in the model. The types of faults that can be simulated include: tilt jamming, abnormal tilt rate, and asynchrony of tilting on both sides.

[0121] Step S6: Automatic Result Determination and Report Generation After the test is completed, the automated testing platform outputs a test report, such as... Figure 4 As shown, it includes the pass / fail conclusion for each test case, a description of the difference between the actual observed behavior and the expected behavior, and the traceability information of the original test case; In the implementation scenario of system construction and basic function testing, the test object is a "triple redundancy, one backup" aircraft simulation test system for a certain type of tilt-ducted ducted eVTOL aircraft. The hardware platform consists of four dSPACE SCALEXIO racks (or equivalent real-time simulation platforms), each configured with analog I / O boards, CANFD boards, UART boards, Ethernet boards, programmable power supplies, etc. Automated testing software (such as ECU TEST or the Python framework) runs on the flight control computing equipment. The network equipment is a standard gigabit Ethernet switch.

[0122] Connect the analog I / O interfaces of nodes A, B, C, and D to channels A, B, C, and D of the aircraft simulation test system, respectively. All nodes are connected to the flight control equipment via an Ethernet switch.

[0123] Load the aircraft model into each node (built and compiled into a real-time executable file in Simulink, such as a .sdf file compiled on the dSPACE platform). Nodes A, B, and C are loaded with identical model parameters and initial states (altitude 0m, airspeed 0m / s, attitude angle 0°). Node D is loaded with the same model, with an initial airspeed set to 0.5m / s to simulate a hot backup following state.

[0124] Test case definition (Excel spreadsheet) as follows Figure 5 As shown.

[0125] During script generation, the automated testing platform reads the Excel spreadsheet and automatically generates the test script. Taking Test-001 as an example, the script logic is as follows (pseudocode): Start all nodes synchronously; Send the start command to nodes A, B, C, and D; Waiting for the simulation time to reach 5.0 seconds; Calling Node A's API: Creating an atmospheric engine system data fault; Start collecting the main control flags of each channel (sampling rate 100Hz, lasting 1 second); Wait and check: whether the master control flag of channel A has become invalid, and whether the master control flag of channel B has become valid; If it becomes valid within 1 second, it is considered PASS; otherwise, it is FAIL. Record the results and associate them with the Excel row number of TC001.

[0126] Expected Execution Result: Based on the design logic of the flight control equipment, when the atmospheric system data of channel A is frozen due to a fault, an anomaly in the channel A data is detected, and the master control is switched to channel B through cross-comparison. The assertion in the script expects to observe the channel B master control flag being valid within 1 second after fault injection. If the actual behavior matches the expectation, a PASS is determined.

[0127] The test report specifically includes: Test-001: The PASS-Channel B master control flag becomes valid again approximately 120ms after a failure (based on the local timestamp).

[0128] Test-002: PASS - The flight control mode word for channel A has changed to degraded mode, and the flight control mode word for channel B has changed to normal mode.

[0129] In the implementation scenario of the tilt-ducted wing-specific fault injection test, the test objective is to verify the redundancy switching behavior of the flight control system under the fault of "canard tilt mechanism jamming during transition mode".

[0130] For example, for testing Figure 6 As shown, in the specific implementation process, the signal TILT_F_actual can be pre-set in the model of node A. After successful setting of this signal, the canard tilt mechanism will tilt from 0° to 45°. Then, the conditional expression is converted into loop detection code. When the tilt angle in the node A model exceeds 30°, fault injection is triggered, and the tilt return command is locked to 45°. After the script is executed, it automatically checks: whether the master control has switched to channel B, whether flight controller A has entered degraded mode, and whether the tilt command output by flight controller B is within the safe range. The above process demonstrates the flexible adaptability of this solution to the special configuration of the tilt ducted wing.

[0131] In the specific implementation scenario of data dictionary linkage verification, the data dictionary file format (example) is as follows: xml <variable> <name> AOA_Sensor< / name> <type> float< / type> <range> [-20, 45]< / range> <unit> deg< / unit> < / variable> <variable> <name> CTRL_MODE< / name> <type> enum< / type> <enum_values>HOVER,TRANSITION,CRUISE< / enum_values> < / variable> The verification process is as follows: 1. The automated testing platform reads the data dictionary file, creates a hash index table of variable names-{type, range, unit}, and finally outputs it as a data dictionary table file.

[0132] 2. Read the Excel test cases line by line and extract the variable names from the test cases.

[0133] 3. If the variable names in the test cases and the variable names in the data dictionary are consistent, continue generating; if they are inconsistent, report an error and stop.

[0134] 4. Only after all variables have passed validation will the script generation stage begin.

[0135] Beneficial Effects: Suppose a flight control software upgrade renames Left_Tilt_Angle to Tilt_Angle_Left. In traditional solutions, all test scripts using the old variable name will fail at runtime, making troubleshooting difficult. In this solution, Excel test cases are intercepted during the generation phase, allowing testers to quickly locate and correct errors based on error reports.

[0136] It should be noted that high-precision time synchronization devices (such as PTP) were not used in the above embodiments. This is because the verification objective is the logical correctness of software behavior (such as whether a switch occurs or whether the instruction value is correct), rather than measuring microsecond-level switching latency. When each node runs independently, its simulation clock deviation is usually within an acceptable range (less than 10 milliseconds) and does not affect logical judgment.

[0137] If the testing scope needs to be expanded to performance verification in the future (e.g., whether the measurement redundancy switching delay is less than 50ms), a time synchronization device (such as a GPS disciplined clock + PTP switch) can be added to the system. The method framework of this solution is fully compatible with such expansion.

[0138] The above-mentioned aircraft simulation test control method has the following technical effects: 1. Eliminate single points of failure and improve the reliability of the test system: Each of the four independent nodes is equipped with an independent power supply and clock. The failure of any node will not affect the operation of other nodes. Compared with the single simulator solution, the system availability is significantly improved.

[0139] 2. Realistic simulation of physical channel isolation characteristics: The physically independent signal channels fully reproduce the channel isolation in the real flight environment, which can expose software behavior anomalies caused by physical differences and has higher test coverage.

[0140] 3. Significantly improves testing efficiency: The fully automated conversion from Excel spreadsheets to executable HIL scripts reduces test preparation time by over 80%. Automated result evaluation eliminates the subjectivity of manual judgment, achieving 100% test repeatability.

[0141] 4. Adaptable to redundant single backup architecture: The structured test case fields are specifically designed with expected behavior types, which can systematically verify unique scenarios such as backup wake-up and fallback mode jump.

[0142] 5. Airworthiness Traceability: The generated scripts and reports automatically embed the source information of the original test cases, which meets the requirements of airworthiness standards such as DO-178C and DO-331 for the chain of test evidence.

[0143] 6. Flexible adaptation to tilt duct eVTOL: The fault template library includes specialized fault types such as tilt mechanism jamming, multi-duct thrust distribution abnormality, transition mode flag abnormality, and single-duct motor failure, ensuring complete test coverage.

[0144] As demonstrated by the aforementioned aircraft simulation test control method, this approach constructs the localization problem between a monocular image and a two-dimensional indoor structural map as a probabilistic observation matching process. Specifically, it utilizes image features to generate geometric and semantic observation distributions, reduces the influence of unreliable geometric rays through ray reliability weight estimation, and preserves semantic uncertainty using a probabilistic distribution matching method. By fusing geometric and semantic matching, this method can more accurately select the final localization result from candidate poses, thereby improving the localization accuracy and robustness in complex indoor scenes.

[0145] Corresponding to the above embodiments of the aircraft simulation test control method, this embodiment of the invention also provides an aircraft simulation test control device, applied to the flight control equipment of an aircraft simulation test system; the aircraft simulation test system is provided with multiple closed-loop simulation nodes connected to the flight control equipment, and each simulation node is provided with an independent clock module and power supply module; such as Figure 7 As shown, the device includes: Initialization module 100: used to create a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, and then load the simulation body model of the target aircraft based on the backup channel and the main channel; wherein, the backup channel and the main channel correspond to the loading parameters of different aircraft simulation body models; Test Case Management Module 200: Used to construct test cases corresponding to the target aircraft using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters; Test script generation module 300: used to generate test scripts corresponding to the simulation ontology model based on the processing instructions of the target variables in the test cases; Simulation test processing module 400: It is used to control the clock module and power module in each simulation node to perform synchronous simulation test on the simulation body model based on the test script, and then generate the simulation test results of the flight control equipment according to the test cases.

[0146] As can be seen from the above-mentioned aircraft simulation test control device, the aircraft simulation test system operated by this device achieves the independence of backup channels and main channels through multiple independent closed-loop simulation nodes. Each simulation node is equipped with an independent clock module and power supply module. When any node fails, it does not affect the operation of other nodes. Compared with the traditional single simulator solution, its system availability is significantly improved. In addition, the independent backup channels and main channels can completely reproduce the channel isolation of the aircraft in the real flight environment, and can expose behavioral anomalies caused by physical differences, greatly improving test coverage and accuracy.

[0147] The aircraft simulation test control device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned aircraft simulation test control method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned aircraft simulation test control method embodiment.

[0148] This embodiment also provides an aircraft simulation testing system, such as Figure 8 As shown, the aircraft simulation test system includes flight control equipment and multiple closed-loop simulation nodes connected to the flight control equipment. Each simulation node is equipped with an independent clock module and power supply module. The clock module and power supply module are used to perform synchronous simulation tests on the target aircraft.

[0149] The aircraft simulation test system is a four-independent hardware-in-the-loop simulation node platform: dSPACE test bench, with resources including n CANFD, n serial ports, n analog I / O boards, n Ethernet, programmable power management, etc.

[0150] The first hardware-in-the-loop simulation node (Node A): Connected to the redundancy channel A of the flight control equipment via a physical signal cable, it independently runs the first controlled object model (including the six-DOF dynamic model of the tilt-ducted wing, sensor model, actuator model, and other aircraft body models) and interface model. Its function is to provide excitation signals equivalent to the real flight environment to channel A, while simultaneously receiving control commands output from channel A and updating the model state in real time. The node is equipped with an independent embedded system clock and power supply.

[0151] This node is equipped with an independent embedded system clock and power supply, and does not share any hardware resources (such as clock, power supply, or memory bus) with other nodes, making it completely independent in terms of electrical and timing. The purpose of this physical isolation structure is to realistically reproduce the independent physical characteristics of each channel in the flight environment, allowing each node to independently generate minute signal differences caused by physical factors such as power supply ripple differences and signal line delay differences, thereby exposing software defects that cannot be detected by single-simulation solutions where all channels share a completely identical signal source.

[0152] The second hardware-in-the-loop simulation node (node ​​B): connected to the redundancy channel B of the flight control equipment, it independently runs the second controlled object model (which can be the same as node A or set differently as needed) and the interface model. It is also equipped with an independent clock and independent power supply.

[0153] The third hardware-in-the-loop simulation node (node ​​C): connected to the redundancy channel C of the flight control equipment, it independently runs the third controlled object model and interface model. It is also equipped with an independent clock and independent power supply.

[0154] The fourth hardware-in-the-loop simulation node (node ​​D): connected to backup channel D of the flight control equipment, it independently runs the backup controlled object model and interface model. This model is usually consistent with the main channel model, but different initial states can be set according to test needs (e.g., slight differences in airspeed) to simulate real hot backup states. This node is also equipped with an independent clock and independent power supply. In particular, the initial state of this node's model can be configured to be slightly different from that of the main channel node (e.g., a difference in airspeed of 0.5 m / s) to simulate normal small deviations in the backup channel due to physical differences during real flight, used to verify whether the flight control redundancy management algorithm can correctly distinguish between "normal channel differences" and "real channel faults".

[0155] Aircraft simulation test control device corresponding Figure 7 The control device includes: The initialization module is used to create a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, and then load the target aircraft based on the backup channel and the main channel; wherein the backup channel and the main channel correspond to different aircraft loading parameters; The test case management module provides a graphical interface or Excel interface for testers to define and write structured test cases, which are used to construct test cases for the target aircraft by utilizing the expected behavior description parameters of each channel in the aircraft loading parameters and the redundancy channel injection parameters. Test script generation module: Used to generate test scripts for the target aircraft based on the processing instructions for the target variables in the test cases; Simulation test processing module: It is used to control the clock module and power module in each simulation node to perform synchronous simulation test on the target aircraft based on the test script, and then generate the simulation test results of the target aircraft according to the test cases.

[0156] The test script generation module includes a built-in data dictionary parsing function. During script generation, it automatically verifies whether variable names in the Excel test cases exist in the flight control software's data dictionary. If a variable name is missing or its type doesn't match, it immediately reports an error and terminates the generation process. The module can generate a JSON-formatted test script from the Excel test cases by matching them with the flight control data dictionary. This script can be directly used with the flight control equipment. If the flight control equipment changes, it can also be further customized. This JSON-formatted script acts as a virtual layer between the Excel test cases and the directly executable test file, and can be widely used across multiple testing platforms.

[0157] The structural diagram of the flight control device is shown below. Figure 9 As shown, the device includes a processor 101 and a memory 102; wherein, the memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the above-described aircraft simulation test control method.

[0158] Figure 9 The flight control device shown also includes a bus 103 and a communication interface 104. The processor 101, the communication interface 104 and the memory 102 are connected through the bus 103.

[0159] The memory 102 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0160] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.

[0161] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0162] This invention also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the aircraft simulation test control method described in the foregoing embodiments.

[0163] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0164] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0166] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0167] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for controlling aircraft simulation testing, characterized in that, A flight control device applied to an aircraft simulation testing system; the aircraft simulation testing system is equipped with multiple closed-loop simulation nodes connected to the flight control device, each simulation node being equipped with an independent clock module and power supply module; the method includes: After creating a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, the simulation ontology model of the target aircraft is loaded based on the backup channel and the main channel; wherein the backup channel and the main channel correspond to the loading parameters of different aircraft simulation ontology models; Test cases for the target aircraft are constructed using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters. Generate the corresponding test script for the simulation ontology model based on the processing instructions for the target variable in the test cases; Based on the test script, the clock module and power module in each simulation node are controlled to perform synchronous simulation tests on the simulation body model, and then the simulation test results of the flight control device are generated according to the test cases.

2. The aircraft simulation test control method according to claim 1, characterized in that, Create a backup channel in at least one simulation node and a primary channel in the remaining simulation nodes, including: Obtain the redundancy channel interface and backup channel interface corresponding to the closed-loop simulation node in the flight control device; Using the backup channel interface, a corresponding backup channel is created in at least one simulation node, and the first loading parameters of the target aircraft are determined based on the backup channel. Using the redundancy channel interface, multiple corresponding main channels are created in the remaining simulation nodes, and the second loading parameters of the target aircraft are determined.

3. The aircraft simulation test control method according to claim 2, characterized in that, The simulation model of the target aircraft, based on the backup channel and the main channel, includes: After constructing the simulation backup model of the target aircraft and its corresponding first interface model using the hot backup status parameters of the backup channel, the backup channel is controlled to load the simulation backup model and the first interface model according to the first loading parameters. After constructing the simulation ontology model of the target aircraft and its corresponding second interface model based on the multi-degree-of-freedom dynamics model, sensor model and actuator model corresponding to the target aircraft in the main channel, the backup channel is controlled to load the simulation ontology model and the second interface model according to the second loading parameters.

4. The aircraft simulation test control method according to claim 1, characterized in that, Using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters, construct test cases corresponding to the target aircraft, including: Obtain the backup takeover strategy between the main channel and the backup channel, as well as the mode switching strategy of each simulation node in the main channel; Based on the backup takeover strategy and the mode switching strategy, determine the expected behavior description parameters corresponding to the main channel and the backup channel in the loading parameters; The target redundant channel corresponding to the target simulation node is determined according to the parallel processing strategy of the target simulation node in the main channel, and the redundant channel injection parameter of the main channel in the loading parameters is determined based on the injection relationship between the target redundant channel and the target simulation node. In a pre-defined structured file, target fields corresponding to the expected behavior description parameters and the redundancy channel injection parameters are constructed, and test cases corresponding to the target aircraft are constructed using the target fields.

5. The aircraft simulation test control method according to claim 1, characterized in that, Generate the corresponding test script for the simulation ontology model based on the processing instructions for the target variable in the test cases, including: The loading and startup commands for each simulation node are generated using the expected behavior description parameters, and the injection fault command for the target simulation node in each simulation node is generated using the redundancy channel injection parameters. Based on the master control flag, control commands, and state machine mode parameters of the flight control device in the test cases, generate the data acquisition commands corresponding to the simulation ontology model; Using a matching strategy between the actual behavior data and the expected behavior data of the flight control device, a result determination instruction corresponding to the simulation ontology model is generated; The test scripts corresponding to the simulation ontology model are generated based on the loading command, the startup command, the fault injection command, the data acquisition command, and the result determination command.

6. The aircraft simulation test control method according to claim 5, characterized in that, The step of generating the result determination instruction corresponding to the simulation ontology model by using a matching strategy between the actual behavior data and the expected behavior data of the flight control device includes: Based on the structured document of the test case, obtain one or more target variables from the variable name, data type, and physical scope corresponding to the simulation ontology model, and establish a variable name index table corresponding to the target variables using preset ID values; The existence verification strategy and type matching strategy corresponding to the actual behavior data and expected behavior data of the flight control device are constructed using the variable name index table. The result determination instruction corresponding to the simulation ontology model is generated based on the existence verification strategy and the type matching strategy.

7. The aircraft simulation test control method according to claim 1, characterized in that, Based on the test script, the clock module and power module in each simulation node are controlled to perform synchronous simulation tests on the simulation model, including: Obtain the loading command, startup command, fault injection instruction, data acquisition instruction, and result determination instruction contained in the test script; After the test script is sent to each simulation node using the loading command, the clock module and power module in each simulation node are started synchronously using the start command. The simulation data of the simulation body model at each simulation node is acquired in real time under the action of the clock module and the power module. When the simulation data meets the preset injection conditions, the fault is injected into the target simulation node corresponding to the simulation body model using the fault injection command, and the output signals of the main channel and the backup channel are acquired in real time through the data acquisition command. After comparing and testing the output signal using the result determination instruction, the simulation verification result of the simulation ontology model is obtained.

8. The aircraft simulation test control method according to claim 7, characterized in that, The simulation test results of the flight control device are generated according to the test cases, including: Based on the tilt structure of the target aircraft, determine one or more fault types included in the injected fault command, such as tilt jamming, abnormal tilt rate, and bilateral tilt asynchrony. Based on the fault type, the passability conclusion, difference description, and traceability information of the simulation ontology model are obtained, and the simulation test results of the flight control device under the test case are obtained through the passability conclusion, the difference description, and the traceability information.

9. An aircraft simulation test control device, characterized in that, A flight control device for use in an aircraft simulation testing system; the aircraft simulation testing system is equipped with multiple closed-loop simulation nodes connected to the flight control device, each simulation node having an independent clock module and power supply module; the device includes: Initialization module: used to create a backup channel in at least one simulation node and a main channel in the remaining simulation nodes, and then load the simulation body model of the target aircraft based on the backup channel and the main channel; wherein, the backup channel and the main channel correspond to the loading parameters of different aircraft simulation body models; Test case management module: used to construct test cases corresponding to the target aircraft using the expected behavior description parameters of each channel in the loading parameters and the redundancy channel injection parameters; Test script generation module: used to generate the corresponding test scripts for the simulation ontology model based on the processing instructions of the target variables in the test cases; Simulation test processing module: used to control the clock module and the power module in each simulation node to perform synchronous simulation test on the simulation body model based on the test script, and then generate the simulation test results of the flight control device according to the test cases.

10. An aircraft simulation testing system, characterized in that, The aircraft simulation test system includes flight control equipment and multiple closed-loop simulation nodes connected to the flight control equipment. Each simulation node is equipped with an independent clock module and a power supply module. The clock module and the power supply module are used to perform synchronous simulation tests on the target aircraft corresponding to the flight control equipment. The flight control device includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor. The processor executes the computer-executable instructions to implement the steps of the aircraft simulation test control method according to any one of claims 1 to 8.

Images