Data source injection method for redundancy fixed-wing aircraft simulation
By designing a dedicated data transmission protocol and shadow packet mechanism, flexible selection and switching of data sources in redundant fixed-wing aircraft simulation is achieved, and the problem of weak selectivity of data sources in the existing technology is solved, and simulation accuracy and applicability are improved.
Patent Information
- Application Number
- CN202510373204.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-27
- Publication Date
- 2025-07-11
AI Technical Summary
The existing simulation systems have weak selectivity for the data sources of aircraft equipment, and cannot select the data sources of each equipment in the simulation. There are limitations in the acquisition and display of dynamic characteristic data, which affects the simulation accuracy and reliability of the results.
A dedicated data transmission protocol is designed to inject data through the upper computer console program, supporting three sources: real device data, user injected data and simulation computing data. Shadow packets and data packets are used to transmit together with UDP protocol. The underlying simulation machine software dynamically selects data sources to achieve flexible switching and seamless integration of data sources.
It improves the diversity and adaptability of simulation scenarios, realizes seamless switching of simulation data, user injected data and real equipment data, meets the diversified needs of redundant fixed-wing aircraft simulations, and improves the flexibility and applicability of the simulation system.
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of flight simulation, and particularly relates to a data source injection method for the simulation of a redundant fixed-wing aircraft. Background Art
[0002] The simulation before the flight of an aircraft can comprehensively evaluate its stability, reliability, and potential design defects, thereby effectively avoiding potential economic losses and risks of casualties. In the early stage of aircraft development, physical simulation was usually adopted, such as wind tunnel experiments (measuring the aerodynamic characteristics of the aircraft through a scaled model) or water tank experiments (observing the streamline, eddy current, and force on the model in the water flow), etc. Although these traditional methods provide important experimental data for aircraft design, they also have significant limitations, such as high cost, difficult to repeat experimental conditions, and unable to fully simulate real flight conditions, etc.
[0003] With the rapid development of digital computers, modern flight simulation technology has gradually shifted to computer-based mathematical modeling and numerical simulation, and then combined the modeling with physical hardware. Usually, such simulations are called hardware-in-the-loop simulations (hereinafter referred to as simulations). This method has significant advantages in reducing costs, improving experimental repeatability, and flexibility.
[0004] However, the existing simulation system has weak selectivity for the data sources of aircraft equipment and cannot select the data sources of each equipment in the simulation. At the same time, there are limitations in the acquisition and display of dynamic characteristic data, unable to display real-time data according to the data source, or there may be errors in the data, indirectly affecting the simulation accuracy and the reliability of the results. Summary of the Invention
[0005] The present invention provides a data source injection method for the simulation of a redundant fixed-wing aircraft, enabling the selection of the data source for the simulation according to requirements during the simulation process, solving the problem of weak selectivity of the data source, and greatly improving the diversity of the simulation scenario and the accuracy of the simulation results.
[0006] To achieve the above object, the present invention adopts the following technical solutions:
[0007] A data source injection method for the simulation of a redundant fixed-wing aircraft, comprising the following steps:
[0008] S1: Design a dedicated data transmission protocol;
[0009] The protocol structure includes: Data field: Support conventional data types (such as floating-point type, integer type, etc.); Status Word Field: Used to identify the status of data. Each byte of the status word contains 8 bits and can represent 8 independent statuses. The status bits are defined as follows: Normal Status: The status bit is 0; Fault Status: The status bit is 1; The protocol is defined in the form of a structure to ensure the standardization of the data packet format, facilitating parsing and processing.
[0010] S2: Inject all data sources from the host console program. Users can input data through the control interface. After being processed by the general packet packaging function, the data is encapsulated into data packets that conform to the protocol; the data packets are transmitted to the underlying simulation software through the network to achieve data injection;
[0011] The console program is compiled using the Mingw 8.10 build toolset and managed through CMake;
[0012] After being processed by the general packet packaging function, the data is encapsulated into data packets that conform to the protocol. The specific process is as follows: First, call the initialization function to fill the entire packet buffer with 0x5A. Then, write the fixed packet header, message identifier, and message length at the beginning of the data packet in sequence. Then, copy the message content of the specified length into the packet; Subsequently, the function calculates the CRC16 checksum for the message part and appends the low byte and high byte after the message. To ensure that the total length of the data packet is a multiple of 4, if the current number of bytes is exactly divisible by 4, then an additional 4 0x5A are added; otherwise, 0x5A is cyclically filled until the alignment requirement is met; Finally, return the total length of the generated data packet. The function passes in a data packet buffer through a pointer. After filling the data in the internal fixed format, it returns the total number of bytes of the entire data packet. If the return value is greater than zero, it usually means that the data packet has been successfully constructed, and the data will be stored and transmitted to the underlying simulation software in the packaged data packet through the network.
[0013] S3: Design the shadow packet and data identifier. The shadow packet and the data packet are transmitted to the underlying simulation software through the UDP protocol together;
[0014] To identify the data source, design a shadow packet. The structure of the shadow packet is as follows: Data Unique ID: Identifies the uniqueness of each data packet. Data Source ID: Identifies the category of the data source, and only contains three values: 0, 1, 2: 0: Real device source; 1: User-injected data; 2: Simulation calculation data;
[0015] S4: Data parsing and processing of the underlying simulation software After receiving the data packet, the simulator software first parses the data source ID in the shadow packet; Dynamically select the corresponding data source according to the data source to participate in the simulation calculation; Store the data in the corresponding data source identification bit to ensure the accuracy and flexibility of data processing.
[0016] Beneficial effects: The present invention provides a data source injection method for the simulation of a redundant fixed-wing aircraft, introducing a data injection and data source injection scheme, supporting three data sources: real device data, user-injected data, and simulation calculation data; solving the problem that traditional simulation systems only support a single data source, greatly improving the diversity and adaptability of the simulation scenario, realizing seamless switching of simulation data, user-injected data, and real device data through dynamic selection of data sources, and the gating logic based on the event mechanism enables the system to respond to data source changes in real time, thus meeting the diverse needs of the simulation of redundant fixed-wing aircraft, improving the flexibility and applicability of the simulation system, and allowing users to flexibly switch data sources according to different needs to meet various experimental requirements. Specific implementation mode
[0017] The present invention will be described in detail below in conjunction with specific embodiments:
[0018] The core of the present invention lies in the flexible selection of data sources, which can dynamically switch real device data, user-injected data, and simulation calculation data with high precision, and the minimum unit supports bit; ensuring that the system can meet different test and simulation requirements.
[0019] A data source injection method for the simulation of a redundant fixed-wing aircraft, comprising the following steps:
[0020] S1: Design a dedicated data transmission protocol; The protocol structure includes: Data field: Support conventional data types (such as floating-point type, integer type, etc.); Status word field: Used to identify the status of the data. Each byte of the status word contains 8 bits and can represent 8 independent statuses. The status bits are defined as follows: Normal status: The status bit is 0; Fault status: The status bit is 1;
[0021] The protocol is defined in the form of a structure to ensure the standardization of the data packet format, facilitating parsing and processing.
[0022] After successfully obtaining the structure data, the data will be formed into a data packet format, adding a frame header, message number, message length, and CRC check, etc. The packet is transmitted to the simulator software in the form of UDP. The simulator software parses the content based on the data packet, ID number, and message length, and stores it in global variables. At this time, the data injected by the user is obtained.
[0023] S2: Inject all data sources by the host computer console program. The user can input data through the control interface. The data is processed by the general packaging function and encapsulated into a data packet that conforms to the protocol; the data packet is transmitted to the underlying simulator software through the network to achieve data injection.
[0024] The console is developed based on C++. The console software is compiled using the Mingw 8.10 build toolset and is built and managed through CMake. The software mainly consists of the following two parts:
[0025] 1. Data acquisition part: Rewrite the control through a custom class to achieve the function of batch creating data display controls and obtaining control data. Use a container to store control information and number the controls in the form of key-value pairs for subsequent query. The interface uses TabWidget for paging management, dividing different pages according to device categories. When the user clicks on a control, a sub-window will pop up to modify the value of the control, such as adjusting the label value, checkbox state, etc.; in addition, three selection boxes are provided at the top of the sub-window, which are used to select the data source of the device respectively, that is, first select the data source box, then fill in the injected data according to the selected data source, and hand over the obtained control data to a variable for packaging;
[0026] 2. Data sending part: Design a timer in the main class to periodically send the injected data. The packet format of the data packet follows the communication protocol. Among them, numerical data is stored in float, double or int type, and status data is stored in uint8_t or larger unsigned type. The fixed bytes defined in the protocol have specific meanings and support refining the status by bit.
[0027] The data is processed by the general packaging function and encapsulated into a data packet that conforms to the protocol. The specific process is as follows: First, call the initialization function to fill the entire packet buffer with 0x5A. Then, write the fixed packet header, message identifier, and message length in sequence at the beginning of the data packet. Then, copy the message content of the specified length into the packet; Subsequently, the function calculates the CRC16 checksum for the message part and appends the low byte and high byte after the message. To ensure that the total length of the data packet is a multiple of 4, if the current number of bytes is exactly divisible by 4, then an additional 4 0x5A are added; otherwise, 0x5A is filled in a loop until the alignment requirement is met; Finally, return the total length of the generated data packet. The function passes a data packet buffer through a pointer. After filling the data in a fixed format internally, it returns the total number of bytes of the entire data packet. If the return value is greater than zero, it usually means that the data packet has been successfully constructed, and the data will be stored in the packet and transmitted to the underlying simulator software through the network.
[0028] S3: Design the shadow packet and data identifier. The shadow packet and the data packet are transmitted to the underlying simulator software together through the UDP protocol;
[0029] To identify the data source, design a shadow packet. The structure of the shadow packet is as follows: The data source management adopts the following mechanism: Data source identifier: 0: Real device data 1: User-injected data 2: Simulation data
[0030] Device and data number: Device ID number (for example, 01 represents an inertial navigation device, 02 represents another device, etc.) Data ID number (for example, 02 represents latitude information) Data source (composed of 0, 1, 2, representing real device data, user-injected data, and model simulation data respectively)
[0031] All data IDs and their corresponding device information are stored in a JSON-formatted configuration file. When the console software starts, it reads this JSON file and organizes the initial device status data based on the content read. By combining the data into a message transmission packet and then transmitting it through UDP to the simulator software.
[0032] Real device data interacts with real devices through serial ports, standard buses, PCIe acquisition cards, etc., collects real device (such as inertial navigation, flight control, etc.) data, analog data, and discrete data according to the protocol, and globally manages the collected data.
[0033] User-injected data: Users can directly input data in the console software. After the data is aggregated and packetized, it is sent to the simulator through UDP. The simulator software parses the data and, after verification, parses the data content and replaces or integrates it into the current data stream.
[0034] Simulation Data: The simulator is based on a high-precision flight dynamics model, integrating real-time flight management system commands, control parameters, and user-defined simulation control strategies to calculate in real-time the dynamic characteristics and attitude changes of the aircraft. The system accurately simulates key physical quantities such as engine thrust, aerodynamic force, and inertial effects, and simulates and generates various sensor data to reproduce the flight environment in a highly realistic manner. All calculation results are stored in local global variables in real-time, supporting precise monitoring and in-depth analysis, providing efficient and reliable data support for the verification and optimization of the flight control system.
[0035] S4: Strobe Logic and Data Update
[0036] After the simulator software receives the data packet sent by the console, it parses out the device ID, data ID, data content, and data source. The specific parsing process is as follows: First, define a parser function that parses the data packet byte by byte through a state machine; During initialization, set the state, successful packet count, and error count to zero, and fill the buffer with 0x5A. During the parsing process, first check in states 0 and 1 whether the packet header bytes 0xEB and 0x90 are received to confirm the start of the data packet; In states 2 and 3, read the message ID and message length in sequence, and calculate the length of the message part in the entire data packet based on this (i.e., message length + 4); Subsequently, continuously receive the message content in state 4, including the device number, message number, and message content. After reaching the specified length, start receiving the CRC check code. In state 5, combine the two received CRC bytes and use the CRC algorithm to check the message content. If the check is successful, update the success count; otherwise, update the error count. The return value of the function is the cumulative number of bytes during the parsing process.
[0037] After the parsing function finishes parsing, match the data with the local data table to determine the data type and size; then modify the local strobe parameters according to the received source information to determine the finally selected data information.
[0038] The strobe logic is based on an event mechanism: The console software monitors the data source change signal. If a change occurs, it triggers an event and resends the strobe instruction to the simulator; after receiving the instruction, the simulator processes it and responds with the updated strobe status; after receiving the response, the console software updates the interface display.
[0039] In addition, when the simulator software restarts, it will actively request the latest strobe instruction from the console to maintain the consistency of the simulation data.
[0040] Experimental Verification
[0041] This experiment aims to verify the data source selection mechanism, simulation calculation accuracy, and data consistency of the present invention, ensuring that the system can operate stably under three modes: pure software simulation, user data injection, and real device access, and guaranteeing the correctness and consistency of data transmission. 1. Experimental Environment
[0042] The experiment was conducted on an iron bird test bench, which included the following physical devices: Console Computer: Runs the console software and is used for functions such as data monitoring, data source switching, and user data injection. Simulation Computer: Responsible for performing simulation calculations, handling data source switching, and transmitting data to other devices. Flight Control Disconnection Box: As a data interface conversion device, it connects the simulation computer, flight control computer, etc., to ensure the stability of data transmission. Flight Control Computer: Responsible for performing flight control tasks, processing, and responding to simulation data or real device data input. Flight Parameter Recorder: Used to record data during the flight simulation process to ensure the traceability of experimental data. 2. Experimental Steps
[0043] The experiment was divided into three rounds of tests to verify the consistency and usability of pure software simulation, user-injected data, and real device data in sequence.
[0044] First Round of Test: Verification of Pure Software Simulation
[0045] System Initialization: Only the simulation computer was run, and no physical devices were connected. The pure software simulation method was adopted.
[0046] Simulation Execution: The simulation computer ran the flight dynamics model, calculated flight parameters (such as attitude, speed, acceleration, etc.), and sent them to the console software for display via UDP.
[0047] Data Recording and Comparison: The flight parameter recorder recorded various parameters during the simulation; the data of the flight parameter recorder was analyzed and compared with the data displayed on the console; the results showed that the two sets of data were consistent, verifying the correctness of the simulation calculation and the reliability of data transmission.
[0048] Second Round of Test: Verification of User Data Injection
[0049] System Initialization: Keep the simulation computer running, but no physical devices are connected.
[0050] Data Source Switching:
[0051] During the flight, the user manually switched the data source and switched the data to the user injection mode at the beginning, middle, and end of the flight respectively.
[0052] Input different data of different simulation devices through the console software and send them to the simulator for processing.
[0053] Data recording and comparison: Record the data injected by the user and the data stored in the flight parameter recorder. After parsing the data, compare them. The results show that the two are exactly the same, proving the correctness of the data injection function and that the system can accurately identify and process the user input data.
[0054] The third round of testing: Verification of real device access
[0055] System initialization: Connect the real flight control device and connect it to the simulator through the flight management disconnection box.
[0056] Data source switching:
[0057] Select the data source as the real device in the console software to ensure that the data of the flight control device can be correctly transmitted to the simulator;
[0058] Conduct flight simulation. The flight management computer receives the data calculated by the simulator in real time and executes the flight control task. At the same time, it feeds back the real-time status data to the simulator and then transmits it to the console software for display.
[0059] Data recording and comparison: Record the data of the real device during the flight and compare it with the simulation data; Parse the data of the flight parameter recorder. The results show that the data of the real device can be completely matched with the data provided by the finished device manufacturer, and the system data flow is normal, verifying the reliability of the real device data access.
[0060] The above experiments verify the effectiveness and data consistency of the data source selection mechanism of the present invention. There is no error between the data calculated by the simulator and the data displayed on the console during the pure software simulation verification stage, proving the correctness of the simulation calculation model; During the user data injection verification stage, the data injected by the user can be accurately transmitted, stored and displayed, which is consistent with the recorded data, verifying the correctness of the data switching and user input functions; During the real device access verification stage, the data of the real device can be correctly accessed and seamlessly integrated with the simulation data, and the system can monitor the status of the flight management in real time, proving the practical application feasibility of the present invention; Verify the data source selection mechanism of the present invention. The system can seamlessly switch between different data sources (simulation data, user data, real device data) and ensure the consistency and correctness of the data.
[0061] The above is only the preferred embodiment of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.
Claims
1. A data source injection method for redundant fixed-wing aircraft simulation, characterized in that, It includes the following steps: S1: Design a dedicated data transmission protocol; S2: Inject all data sources by the host computer console program. The user inputs data through the control interface. After being processed by the general packaging function, the data is encapsulated into data packets that conform to the protocol. The data packets are transmitted to the underlying simulator software through the network to achieve data injection; S3: Design shadow packets and data identifiers. The shadow packets and data packets are transmitted to the underlying simulator software together through the UDP protocol; S4: After receiving the data packets, the underlying simulator software parses the data source ID in the shadow packets, dynamically selects the corresponding data to participate in the simulation calculation according to the data source, and stores the data in the corresponding data source identification bit.
2. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1, wherein The structure of the data transmission protocol includes: Data field: Supports conventional data types; Status word field: Used to identify the status of the data. Each byte of the status word contains 8 bits, representing 8 independent statuses. The status bits are defined as: normal status, status bit is 0; faulty status, status bit is 1.
3. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1, characterized in that When the data in S2 is processed by the general packaging function and encapsulated into data packets that conform to the protocol, it specifically includes the following steps: First, call the initialization function to fill the entire packet buffer with 0x5A. Then, write the fixed packet header, message identifier, and message length in sequence at the beginning of the data packet. Then, copy the message content of the specified length into the packet. Subsequently, the function calculates the CRC16 checksum for the message part and appends the low byte and high byte after the message. To ensure that the total length of the data packet is a multiple of 4, if the current number of bytes is exactly divisible by 4, then an additional 4 0x5A are added; otherwise, 0x5A is filled in a loop until the alignment requirement is met. Finally, return the total length of the generated data packet. The function passes in a data packet buffer through a pointer. After filling the data in the internal fixed format, it returns the total number of bytes of the entire data packet. If the return value is greater than zero, it usually means that the data packet has been successfully constructed, and the data will be stored and transmitted to the underlying simulator software after being packed in the data packet through the network.
4. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1 or 3, characterized in that The console includes: Data acquisition part: Use a container to store control information, number the controls in the form of key-value pairs, and use TabWidget for paging management of the interface. Different pages are divided according to device categories. When the user clicks on a control, a sub-window will pop up to modify the value of the control. Three selection boxes are provided at the top of the sub-window, respectively used to select the data source of the device; Data sending part: Design a timer in the main class to periodically send injection data. The packet format of the data packet follows the communication protocol.
5. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1, characterized in that The structure of the shadow packet is as follows: Data unique ID: Identifies the uniqueness of each data packet. Data source ID: Identifies the category of the data source, only contains three values: 0, 1, and 2. Among them, 0 is the real device source, 1 is the user-injected data, and 2 is the simulation calculation data.
6. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1 or 5, characterized in that All data IDs and their corresponding device information are stored in a configuration file in JSON format. When the console software is started, this JSON file is read, and the initial device status data is organized based on the content read. By combining the data into message transmission packets, and then transmitted to the simulator software through UDP.
7. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1, wherein The parsing process in S4 is specifically as follows: First, define a parser function that parses the data packet byte by byte through a state machine; During initialization, set the state, successful packet count, and error count to zero, and fill the buffer with 0x5A. During the parsing process, first check whether the packet header bytes 0xEB and 0x90 are received in states 0 and 1 in sequence to confirm the start of the data packet; In states 2 and 3, read the message ID and message length in sequence, and calculate the length of the message part in the entire data packet based on this; Subsequently, continuously receive the message content in state 4, including the device number, message number, and message content. After reaching the specified length, start receiving the CRC check code. In state 5, combine the two received CRC bytes, and use the CRC algorithm to check the message content. If the check is successful, update the success count; otherwise, update the error count. The return value of the function is the cumulative number of bytes during the parsing process.
8. The data source injection method for redundant fixed-wing aircraft simulation according to claim 7, characterized in that After the parsing function finishes parsing, match the data with the local data table to determine the data type and size; then modify the local gating parameters according to the received source information to determine the finally selected data information.
9. The data source injection method for redundant fixed-wing aircraft simulation according to claim 8, characterized in that The gating logic is based on the event mechanism: the console software monitors the data source change signal. If a change occurs, it triggers an event and resends the gating instruction to the simulator; after receiving the instruction, the simulator processes it and responds with the updated gating status; after receiving the response, the console software updates the interface display.
10. The data source injection method for redundant fixed-wing aircraft simulation according to claim 1 or 9, characterized in that When the simulator software restarts, it actively requests the latest gating instruction from the console to maintain the consistency of the simulation data.