An aircraft landing gear real-time simulation test method, system, device, computer equipment and storage medium

Abstract

The application discloses an airplane landing gear real-time simulation test method, system and device, computer equipment and a storage medium, so that each frame of a three-dimensional animation is driven by real-time calculation results of a current simulation step of a simulation model, and a simulation model determines a switching time of a retracting and deploying process according to a reaching condition of each stroke stage, so that a three-dimensional picture and a state of the simulation model are always kept synchronous, and retracting and deploying control logic and timing can be intuitively verified online during a simulation running process.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, system, device, computer equipment, and storage medium for real-time simulation testing of aircraft landing gear. Background Technology

[0002] In aircraft development and system integration testing, flight simulators and iron bird test benches use simulation models to calculate the landing gear retraction and extension process, verifying the retraction and extension control logic and the interconnection between the landing gear system and other airborne systems. To visually present the retraction and extension process, the test environment is usually equipped with a 3D animation interface, displaying the movement of various landing gear components through 3D models.

[0003] In related technologies, one method for 3D displaying the landing gear retraction and extension process is keyframe animation. The movement of each component of the 3D model is driven by pre-made keyframe animation, which plays according to a preset trajectory and timing. The creation of keyframe animation is independent of the simulation model; however, when changing aircraft models, a complete set of keyframe animation needs to be recreated for the landing gear structure of the new model.

[0004] Another demonstration method in related technologies is post-event playback. Parameter data is recorded during the flight or test process, and the recorded parameters are read in frame order afterwards to drive a 3D model to reproduce the motion process for post-event analysis and playback.

[0005] Keyframe animation is essentially "playback" rather than "reflection." The timing and attitude of the animation are preset manually, which is disconnected from the solution results of each calculation cycle of the simulation model. The arrival times and sequences of each stage during the extension and retraction process cannot be determined by the simulation model, therefore it cannot be used to verify the extension and retraction control logic, arrival timing, and abnormal operating conditions. Furthermore, the landing gear structures of different aircraft models are different, and keyframe animations need to be remade for each aircraft model, resulting in poor reusability.

[0006] Furthermore, although the post-event playback method uses real parameters to drive the 3D model, the parameters it uses come from the completed flight or test records. The driving process occurs after the fact and cannot be linked with the running simulation model in real time. It cannot synchronously reflect the launch and recovery dynamics during the simulation process, nor can it participate in the online verification of the launch and recovery process.

[0007] Existing 3D display methods cannot keep the landing gear 3D animation consistent with the real-time calculation of the simulation model and reflect the switching of each stage of the retraction and extension process, making it difficult to intuitively verify the retraction and extension control logic and timing through 3D animation online. Summary of the Invention

[0008] This application provides a method, system, device, computer equipment, and storage medium for real-time simulation testing of aircraft landing gear, which enables the real-time calculation of the landing gear 3D animation and simulation model to be synchronized, and allows for online verification of the retraction and extension control logic and timing. The technical solution of this application is as follows.

[0009] Firstly, a real-time simulation testing method for aircraft landing gear is provided. This method involves the collaborative execution of a motion control module, a data interaction middleware, and a 3D animation engine. The motion control module runs the landing gear simulation model, acting as the solution side; the 3D animation engine maintains the landing gear 3D model, acting as the rendering side; and the data interaction middleware, deployed in an independent process or thread, establishes a data interaction channel between the two, acting as the transmission side. The method includes the following steps.

[0010] First, the motion control module uses a simulation model to perform real-time calculations on the aircraft landing gear retraction and extension process according to simulation steps, obtaining the motion parameters of each landing gear component at each simulation step. These motion parameters characterize the real-time attitude of the corresponding component during the retraction and extension process, such as continuously changing values ​​like door angles and strut angles, rather than frame numbers from animation clips. The simulation model solves the kinematic equations for each landing gear component once for each simulation step. The retraction and extension process includes at least two sequentially executed stroke phases, each corresponding to the attitude changes of different landing gear components.

[0011] Then, the motion control module sends the motion parameters calculated for each simulation step to the 3D animation engine in real time via the data interaction channel. The data interaction channel connects the simulation model and the 3D animation engine, and the motion parameters flow from the simulation model to the 3D animation engine. Specifically, the motion control module encapsulates the motion parameters along with timestamps into data packets, which are then forwarded by the data interaction middleware to the receiving interface on the 3D animation engine side.

[0012] Next, based on the received motion parameters, the 3D animation engine drives the skeletal posture of the components in the landing gear 3D model corresponding to the motion parameters in real time, so as to present the retraction and extension animation synchronized with the real-time solution results of the simulation model on the 3D interface. It should be noted that the landing gear 3D model itself does not pre-store any retraction and extension animation clips; the posture of each component of the model is entirely determined by the values ​​passed in at each simulation step. For example, the rotation angle of the strut skeletal node is assigned the strut angle calculated by the current step, and the strut component in the 3D interface then presents the corresponding posture.

[0013] During the landing gear retraction and extension process, the motion control module generates a positioning signal when the simulation model detects that the positioning conditions for the current travel stage are met. This signal is then fed back to the 3D animation engine via a data interaction channel, triggering the transition from the current travel stage to the next. The positioning signal is a status indicator that the component corresponding to the current travel stage has moved to the target state. After switching to the next travel stage, the simulation model's calculation object changes to the component corresponding to the next travel stage. The calculated motion parameters are also sent to the 3D animation engine in real time via the data interaction channel to drive the skeletal posture of the component corresponding to the next travel stage in the landing gear 3D model. This calculation, transmission, and driving process is repeated within each travel stage until all travel stages of the landing gear retraction and extension process are completed.

[0014] Finally, the 3D interface displays the extension / retraction animation and data curves based on motion parameters in parallel to verify the extension / retraction process. The 3D animation provides an intuitive means of judging spatial posture, while the data curves provide a precise means of numerical interpretation. The two display channels are driven by the same set of motion parameters and are synchronized with each other in time.

[0015] This method directly drives the skeletal posture of each component in the 3D model to the motion parameters calculated in real time for each simulation step. The 3D visuals no longer rely on any pre-recorded animation clips but update frame-by-frame with the calculated values. Therefore, when operating conditions such as retraction speed and starting angle change, the posture of each landing gear component in the animation remains consistent with the simulation model's calculation results. Furthermore, since the switching of each travel stage is triggered by the simulation model generating a positioning signal after detecting that the positioning conditions are met, the timing of stage switching is determined by the calculation process, not by a preset playback duration. Therefore, the animation's timing progression is precisely aligned with the actual execution timing of the retraction control logic, forming a real-time closed loop of "simulation calculation—animation-driven—positioning feedback—stage switching." This allows the retraction control logic and timing to be visually verified online through the 3D visuals during simulation operation.

[0016] In one possible implementation, the aforementioned at least two travel phases include a door opening / closing phase, a strut retraction / extension phase, and a chassis retraction / extension phase. The door opening / closing phase corresponds to the attitude change of the landing gear door components, the strut retraction / extension phase corresponds to the attitude change of the landing gear strut components, and the chassis retraction / extension phase corresponds to the attitude change of the landing gear chassis components. The arrival condition corresponding to the current travel phase includes the component corresponding to the current travel phase moving to a preset arrival position. For example, the arrival position in the strut retraction / extension phase is when the strut angle reaches the angle corresponding to being fully retracted or fully extended. With this implementation, since the calculation object and animation driving object of each travel phase are clearly defined as the component corresponding to that phase, there is no object confusion between the calculation switching and screen switching between phases. Furthermore, the arrival judgment is based on the continuously calculated angle values ​​rather than relying on timer estimation. Therefore, the timing of the arrival signal generation is strictly aligned with the actual end point of the component's movement, thus ensuring that the phase switching timing of the landing gear retraction / extension animation is consistent with the mechanical action sequence of the actual retraction / extension mechanism.

[0017] In some implementations, the transmission of motion parameters is accomplished using a configurable aircraft model mapping engine. Specifically, an aircraft model parameter configuration file corresponding to the aircraft model is loaded. This configuration file predefines the mapping rules between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model. These mapping rules include semantic mapping relationships between motion parameters and skeletal nodes, as well as coordinate system transformation rules. One format of the aircraft model parameter configuration file is a JavaScript object notation (JSON) file. Subsequently, according to the mapping rules, the motion parameters are converted into the corresponding skeletal pose parameters of the skeletal nodes, and these skeletal pose parameters are sent in real-time to the 3D animation engine via a data interaction channel. This allows the 3D animation engine to drive the skeletal pose of the component to which the skeletal node belongs based on the skeletal pose parameters. The semantic mapping relationship answers the question of which parameter drives which skeletal node, and the coordinate system transformation rules answer the question of how parameter values ​​are converted into pose values ​​on that skeletal node. With this implementation, since the mapping relationship between motion parameters and skeletal nodes is defined in an external configuration file and dynamically loaded by the middleware at runtime instead of executing a fixed conversion algorithm, the mapping relationship is decoupled from the program code. Therefore, when adapting to a new model, only the configuration file needs to be updated to establish a new mapping, without the need to modify, recompile, and redistribute the middleware program, thus supporting simulation testing of multiple models at a lower adaptation cost.

[0018] In one possible implementation, the coordinate system transformation rules mentioned above include scaling factors, offsets, and axial remapping relationships. During transformation, the values ​​of motion parameters are converted according to the scaling factors and offsets, and the rotation axis on the skeletal nodes is determined according to the axial remapping relationship, thus obtaining the skeletal attitude parameters. When adapting to a new aircraft model, the mapping rules in the aircraft parameter configuration file can be updated to establish a mapping between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model corresponding to the new aircraft model. Through this implementation, the three common aircraft model differences—differences in default skeletal orientation, model scale and rotation pivot point, and initial skeletal attitude exported from different modeling software—are corrected by three independent factors: axial remapping relationship, scaling factor, and offset. Differences in any dimension can be resolved by adjusting the corresponding field without affecting the mapping results of other dimensions. Therefore, the configuration and maintenance of mapping rules are more flexible, thereby further reducing the workload and error probability of multi-aircraft adaptation.

[0019] In some implementations, the method also covers turning tests during the ground taxiing phase. The simulation model determines the target deflection angle of the landing gear's nose wheel based on the received turning command; it determines the turning radius based on the target deflection angle and the aircraft's wheelbase; and it determines the wheel speed difference between the inner and outer main wheels based on the turning radius, the aircraft's center of gravity velocity, and the main wheel track, obtaining the wheel speed parameters for each wheel. The target deflection angle and wheel speed parameters are then sent in real-time to the 3D animation engine via a data interaction channel to drive the deflection attitude of the nose wheel component and the rotation attitude of each wheel component in the landing gear 3D model. Through this implementation, since the target deflection angle, turning radius, and the inner and outer wheel speed difference are derived sequentially from the same set of inputs within the same kinematic model, the kinematic coupling relationship between the nose wheel deflection and wheel rotation is fully preserved. Therefore, the rotational speed of each wheel in the animation is strictly coordinated with the fuselage turning motion at each simulation step, thus realistically reproducing the physical characteristic that "the sharper the turn, the more obvious the inner and outer wheel speed difference," improving the realism of the ground taxiing simulation.

[0020] In one possible implementation, the simulation model also determines the braking torque distribution ratio between the inner and outer main wheels based on the target deflection angle. Specifically, the braking torque of the outer main wheel is greater than that of the inner main wheel, and the difference in braking torque between the outer and inner main wheels increases with the target deflection angle, thus forming an auxiliary turning torque. Braking parameters characterizing the braking torque distribution ratio are sent to the 3D animation engine in real time via a data interaction channel, ensuring that the braking parameters are presented synchronously with the deflection attitude of the front wheel components and the rotation attitude of each wheel component. One implementation of this synchronous presentation is as follows: the braking torque ratio of the left and right main wheels is displayed on the 3D interface using numerical gauges or varying color gradations, and the display frames of the braking torque are synchronized with the display frames of the front wheel deflection and wheel rotation, carrying the same timestamp. With this implementation method, since the distribution of differential braking torque is linked to the front wheel deflection angle, the auxiliary effect of braking behavior on turning is incorporated into the same simulation framework. Therefore, the braking distribution, front wheel deflection, and wheel rotation are synchronously reflected in the same turning condition on the three-dimensional interface, so that engineers can observe the coupling effect of turning and braking in the same picture, which improves the completeness and observation efficiency of turning braking test.

[0021] In some implementations, the timestamp of the simulation model's solution is compared with the frame counter of the 3D animation engine to obtain the synchronization deviation. If the synchronization deviation exceeds a preset synchronization threshold, it is caught up by skipping frames or adjusting the playback speed of the animation to keep the animation synchronized with the real-time solution of the simulation model. The solution timestamp is the time stamp written to the data packet by the simulation model at each simulation step, and the frame counter is the cumulative number of rendered frames by the 3D animation engine. Skipping frames means discarding lagging intermediate poses and directly updating the skeletal pose to the pose corresponding to the latest received motion parameters; adjusting the playback speed means playing the animation at an interpolated speed higher or lower than the normal rate. Through this implementation, since the comparison of the clock references on both sides is continuously performed, the synchronization deviation is actively caught up and eliminated once it exceeds the limit. The accumulated drift will not increase indefinitely with the test duration. Therefore, the synchronization relationship between the animation and the real-time solution remains valid in long-term continuous testing, thus ensuring the credibility of the 3D display in simulation subjects lasting several hours.

[0022] In one possible implementation, the data interaction channel is a network channel or a shared memory channel based on the User Datagram Protocol (UDP). The data interaction channel is bidirectional, transmitting motion parameters and position signals from the simulation model to the 3D animation engine, and transmitting frame synchronization signals from the 3D animation engine to the simulation model. The frame synchronization signals are used by the simulation model to perform closed-loop verification of the 3D animation engine's display progress. One aspect of the frame synchronization signal is that after each frame rendering, the 3D animation engine sends back the current value of the frame counter and the corresponding timestamp of the displayed motion parameters. The simulation model compares the sent-back progress with its own calculation progress to determine whether the display side has consumed the sent parameters as expected. Through this implementation, since the progress on the display side is transmitted back to the control side via the frame synchronization signal, the animation's catching-up test changes from an implicit assumption to a quantifiable and verifiable state. Therefore, the control side can promptly detect lags or anomalies on the rendering side, thus forming a bidirectional closed loop between testing and display. Simultaneously, the UDP channel supports cross-computer deployment with lower transmission overhead, and the shared memory channel supports intra-machine deployment with lower latency, thus providing adaptation methods for different hardware environments.

[0023] In some implementations, when a preset abnormal condition occurs during the landing gear's retraction and extension process, a 3D animation engine presents the skeletal posture of the component experiencing the preset abnormal condition in the 3D model of the landing gear, using a display method distinct from the normal operating condition. Preset abnormal conditions include component jamming, abnormal retraction and extension speed, or failure to trigger the positioning signal. For example, a jammed component may exhibit a visual effect of slight reciprocating jerking or complete pause; when low hydraulic pressure causes abnormal retraction and extension speed, the movement speed of the 3D model naturally slows down according to real-time parameters; when the positioning signal is not triggered, although the component moves to the target position, the positioning highlight or color change that would occur under normal operating conditions does not occur. Through this implementation, since the abnormal condition is directly mapped to a differentiated presentation in the 3D image, the abnormal posture, speed, or state of the abnormal component appears in the same frame as the engineer observes the retraction and extension animation. Therefore, the engineer can locate the abnormality without manually establishing a correlation between the alarm list and the component status, thereby shortening the abnormality location time and improving the efficiency of the abnormality injection test.

[0024] In one possible implementation, motion parameters and position signals transmitted via a data interaction channel are recorded throughout the process to obtain a test log file. Each record in the test log file includes a timestamp and the corresponding motion parameters. Upon receiving a playback command, the test log file is read in chronological order according to the timestamps, and the read motion parameters are resent to the 3D animation engine to reproduce the release and take-off animation process. The playback data stream and the real-time test data stream enter the 3D animation engine through the same data interaction channel, and the skeletal driving logic during playback is completely consistent with that during real-time testing. Through this implementation, since the playback screen and the real-time screen during historical testing are strictly consistent in principle, engineers can accurately reproduce the process of the problem at any time afterward without repeating physical experiments, thus providing an intuitive and reliable visual verification method for fault location and fault resolution.

[0025] In some implementations, the simulation step size ranges from 1 millisecond to 10 milliseconds. One possible value for the simulation step size is 1 millisecond, 2 milliseconds, 5 milliseconds, or 10 milliseconds. With this implementation, because the frequency of solution updates is higher than the refresh requirements of conventional 3D displays, and the angle increment within a single simulation step is less than a threshold perceptible to the naked eye, the animation's expansion and contraction process is continuous and smooth. Simultaneously, the computational overhead of the solution task remains at a level that the real-time simulation platform can handle, thus achieving a balance between display quality and computational resources. This provides a numerical basis for the long-term stable operation of real-time closed-loop systems on conventional engineering computing platforms.

[0026] In one possible implementation, based on the aforementioned division into hatch opening / closing, strut retraction / extension, and chassis retraction / extension stages, the simulation model performs real-time calculations of the retraction / extension process based on driving conditions. Driving conditions include retraction drive conditions and retraction drive conditions. Retraction drive conditions include: receiving a retraction command, hatch component opening to the correct position, strut component not yet fully retracted, and the retraction command delay being released. Retraction drive conditions include: receiving a retraction command, hatch component opening to the correct position, strut component not yet fully retracted, and the retraction command delay being released. The release of the retraction command delay and the release of the retraction command delay mean that after receiving the corresponding command, a preset filtering time is allowed before the simulation model recognizes the command as valid, preventing command signal jitter. Through this implementation, since the command signal is only responded to by the simulation model after a stable and continuous preset filtering time, jitter near the command transition edge is absorbed by the filtering time. Therefore, jitter will not be recognized as a new command, and will not trigger erroneous stage switching, thereby avoiding abnormal interruptions or repetitive actions in the retraction / extension process caused by jitter, and improving the stability of simulation testing in a real test environment with electrical noise.

[0027] Secondly, a real-time simulation testing system for aircraft landing gear is provided. This system includes a motion control module, data interaction middleware, and a 3D animation engine module.

[0028] The motion control module runs the simulation model, performing real-time calculations on the aircraft landing gear retraction and extension process according to simulation steps. This yields the motion parameters of each landing gear component at each simulation step. The retraction and extension process consists of at least two sequentially executed stroke phases, each corresponding to the attitude changes of different landing gear components. A data interaction middleware connects the motion control module and the 3D animation engine module, sending the motion parameters calculated for each simulation step to the 3D animation engine module in real-time. Based on the received motion parameters, the 3D animation engine module drives the skeletal posture of the components corresponding to those motion parameters in the landing gear 3D model in real-time, presenting a retraction and extension animation synchronized with the real-time calculation results of the simulation model on the 3D interface.

[0029] The motion control module also generates a positioning signal when the simulation model detects that the positioning conditions corresponding to the current travel stage are met. This positioning signal is fed back to the 3D animation engine module via data interaction middleware to trigger the landing gear's extension / retraction process to switch from the current travel stage to the next travel stage. After switching to the next travel stage, the motion control module calculates the motion parameters of the components corresponding to the next travel stage. Based on these parameters, the 3D animation engine module drives the skeletal posture of the components corresponding to the next travel stage in the landing gear's 3D model. The 3D interface is also used to display the extension / retraction animation and data curves drawn based on the motion parameters in parallel to verify the extension / retraction process.

[0030] The signal flow between the three modules is as follows: motion parameters and positioning signals flow from the motion control module through the data interaction middleware to the 3D animation engine module; frame synchronization signals flow from the 3D animation engine module through the data interaction middleware to the motion control module. Details of the processing performed by each module can be found in the first aspect and any optional method described above, and will not be repeated here.

[0031] With this system, the three functions of calculation, transmission, and rendering are respectively handled by the motion control module, the data interaction middleware, and the 3D animation engine module. The modules exchange values ​​and signals only through the data interaction channel. The development, deployment, and replacement of each module are independent of each other. Therefore, the selection of simulation platform and rendering platform can be flexibly combined according to project requirements, thereby improving the engineering feasibility and maintainability of the system.

[0032] In one possible implementation, the system also includes a status monitoring and recording module. This module bypasses the data transmission of the data interaction middleware, records motion parameters and position signals throughout the process, and obtains a test record file. Each record in the test record file includes a timestamp and the corresponding motion parameters. Upon receiving a playback command, the status monitoring and recording module also reads the test record file in chronological order according to the timestamps and resends the read motion parameters to the 3D animation engine module to reproduce the release animation of the release process. Bypass monitoring means that the status monitoring and recording module obtains a copy of the data in the channel in read-only mode, without injecting data into the main link. Through this implementation, since the recording and playback capabilities are accessed in a bypass manner, they do not occupy the transmission and processing resources of the main link, and real-time test performance is not affected. Therefore, a fully traceable test recording capability is obtained without sacrificing real-time performance, thus supporting the requirements of type qualification testing for traceability and reproducibility of the test process.

[0033] Thirdly, a real-time simulation testing device for aircraft landing gear is provided. This device has the functionality provided by the first aspect or any optional method of the first aspect. The device includes at least one unit, which implements the method provided by the first aspect or any optional method of the first aspect. In one unit division method, the device includes a calculation unit, a transmission unit, a driving unit, a switching unit, and a display unit. These five units correspond one-to-one with the processing steps of real-time calculation, real-time transmission, skeleton posture driving, position feedback and stage switching, and parallel display verification in the first aspect. Under this division method, the transmission unit may optionally further include a loading subunit and a conversion subunit. The loading subunit is used to load the aircraft model parameter configuration file corresponding to the aircraft model, and the conversion subunit is used to convert the motion parameters into skeleton posture parameters according to the mapping rules and transmit them through the data interaction channel. The above unit division is only illustrative; in actual implementation, the units may be optionally merged or further split.

[0034] In some embodiments, the units in the device are implemented in software, and the units are program modules. In other embodiments, the units in the device are implemented in hardware or firmware. Specific details of the device provided in the third aspect can be found in the first aspect or any alternative to the first aspect described above, and will not be repeated here.

[0035] Fourthly, a computer device is provided. The computer device includes a processor coupled to a memory, the memory storing at least one computer program instruction, which is loaded and executed by the processor to cause the computer device to implement the method provided in the first aspect or any alternative embodiment of the first aspect. Specific details of the computer device provided in the fourth aspect can be found in the first aspect or any alternative embodiment of the first aspect, and will not be repeated here.

[0036] Fifthly, a computer-readable storage medium is provided. The storage medium stores at least one instruction that, when executed on a computer, causes the computer to perform the method provided in the first aspect or any alternative method of the first aspect.

[0037] Sixthly, a computer program product is provided. This computer program product includes one or more computer program instructions that, when loaded and executed by a computer, cause the computer to perform the method provided in the first aspect or any alternative method of the first aspect.

[0038] One of the above technical solutions has at least one of the following advantages or beneficial effects: each frame of the landing gear 3D animation is driven by the real-time calculation result of the current simulation step size of the simulation model, and the 3D screen and the state of the simulation model are always synchronized; the switching timing of each stroke stage in the retraction and extension process is determined by the positioning conditions detected by the simulation model, forming a real-time closed loop of "simulation calculation - animation driving - positioning feedback - stage switching", and the retraction and extension control logic and timing can be intuitively verified online during the simulation operation. Attached Figure Description

[0039] Figure 1 A schematic diagram of the composition of an aircraft landing gear real-time simulation test system 100 provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the entire retraction and extension stroke of a landing gear, provided for an embodiment of this application; Figure 3 A schematic diagram of a parameterized binding rule provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a code coverage testing device for model-driven code generation provided in an embodiment of this application; Figure 5 This application provides a schematic diagram of the structure of a computing device. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0041] In landing gear simulation testing scenarios on flight simulators and ground-based integrated test benches, motion control logic and 3D animation rendering typically run on different computing platforms. In related technologies, the 3D animation side often plays pre-produced animation clips, and there is a lack of real-time two-way data synchronization between the animation side and the control side, resulting in the 3D visuals failing to reflect the real-time results of the simulation calculations.

[0042] To address the above issues, this embodiment uses the motion parameters of each landing gear component calculated in real-time by the simulation model at each simulation step as the data source for animation driving. A data interaction channel is established between the simulation model and the 3D animation engine, sending the motion parameters to the 3D animation engine in real-time. Based on the received motion parameters, the 3D animation engine drives the skeletal posture of the corresponding components in the landing gear 3D model in real-time, ensuring that the retraction and extension animation presented on the 3D interface remains synchronized with the real-time calculation results of the simulation model. The landing gear retraction and extension process is divided into multiple stroke stages executed sequentially. When the simulation model detects that the positioning condition corresponding to the current stroke stage is met, it generates a positioning signal and feeds it back through the data interaction channel, triggering the retraction and extension process to switch from the current stroke stage to the next stroke stage, forming a real-time closed loop of "calculation—driving—feedback—switching". The retraction and extension animation and data curves drawn based on the motion parameters are displayed in parallel on the 3D interface to verify the retraction and extension process.

[0043] For ease of understanding, some terms used in the embodiments of this application are explained below.

[0044] Iron Bird Test Bench: A platform for comprehensive physical testing of aircraft systems such as hydraulics, landing gear, and flight control on the ground. The Iron Bird Test Bench is equipped with hydraulic lines, actuators, and control computers according to the system layout of a real aircraft, enabling it to simulate various operating conditions during flight from the ground.

[0045] Keyframe animation: a method of creating 3D animation. Artists pre-set several key pose frames in modeling software, and the 3D engine interpolates between adjacent keyframes to generate intermediate frames, forming a continuous animation clip. The playback trajectory of keyframe animation is fixed upon completion and does not respond to external real-time input values ​​during playback.

[0046] Bone: A hierarchical transformation node in a 3D model used to control mesh deformation. Each bone node has transformation attributes such as position, rotation, and scaling. The 3D engine drives the pose changes of the components to which the bone belongs by modifying the transformation attributes of the bone nodes. Bone pose refers to the collective position and rotation state of a bone node at a given moment.

[0047] User Datagram Protocol (UDP): A connectionless network transport protocol. UDP does not establish a connection or guarantee message order or reliable delivery. It has low transmission overhead and low latency, making it suitable for simulated data transmission scenarios with high real-time requirements and tolerance for a small amount of packet loss.

[0048] Shared memory: an inter-process communication mechanism. Multiple processes map to the same physical memory region, and data written by any process can be directly read by other processes. Data is not copied through the network protocol stack, and the transmission latency is lower than that of the network channel.

[0049] JavaScript Object Notation (JSON): A lightweight data-interchange format. JSON describes structured data in the form of key-value pairs and arrays of text, making it easy for humans to read and for programs to parse. It is often used in configuration files.

[0050] Differential braking: a ground taxiing control method for aircraft. Differential braking applies unequal braking torques to the left and right main wheels, using the difference in braking force between the two wheels to create an auxiliary yaw torque, helping the aircraft to turn on the ground.

[0051] Revolutions per minute (RPM): A unit of measurement for rotational speed, representing the number of revolutions a rotating body completes in one minute.

[0052] Comma-separated values ​​(CSV): A plain text table data format that separates fields with commas and records with newlines.

[0053] Software Development Kit (SDK): A collection of development interfaces, library files, and documentation provided by a software vendor for a specific platform. A 3D engine's SDK allows external programs to call the engine's internal model transformation interfaces.

[0054] Figure 1 This is a schematic diagram illustrating the composition of an aircraft landing gear real-time simulation testing system 100 provided in an embodiment of this application. Figure 1 As shown, the system 100 includes four parts: motion control module 101, animation engine module 102, data interaction middleware 103, and status monitoring and recording module 104.

[0055] The motion control module 101 runs on a Windows / Linux real-time simulation platform. The motion control module 101 executes the landing gear retraction and extension control logic and the turning kinematics model, calculating the target positions and angles of each landing gear component. The calculation programs in the motion control module 101, including the landing gear retraction and extension control logic and the turning kinematics model, are collectively referred to as the simulation model. The simulation model can be modeled and generate real-time code on the Simulink simulation platform, or it can be directly implemented using the C++ language.

[0056] Animation Engine Module 102 (i.e., the 3D Animation Engine Module) runs on the Windows 3D rendering platform. Animation Engine Module 102 constructs a 3D model of the landing gear based on a 3D engine and performs parametric rendering. The 3D engine includes, but is not limited to, Unreal Engine, Unity Engine, or a self-developed 3D rendering engine.

[0057] The data interaction middleware 103 operates across platforms. Deployed in an independent process or thread, it enables real-time data mapping, format conversion, and time synchronization between the motion control module 101 and the animation engine module 102. The logical link established between the two modules by the data interaction middleware 103 is called the data interaction channel.

[0058] The status monitoring and recording module 104 runs on the Windows platform. It bypasses the data transmission in the data interaction channel, collects and stores all motion parameters in real time, and supports data playback and animation reproduction. Bypass monitoring means that the status monitoring and recording module 104 obtains a copy of the data in the channel in read-only mode, without injecting data into the main link, thus not affecting the real-time performance of the main link.

[0059] In terms of deployment, the motion control module 101 and the animation engine module 102 can optionally run on two separate computers connected via a network; alternatively, they can run in different processes on the same computer. Figure 1 The number of modules and the operating platform shown are merely examples, and the embodiments of this application do not limit this.

[0060] One typical application scenario for the aforementioned system is an aircraft iron bird test bench. When the real or simulated landing gear on the iron bird test bench performs retraction and extension tests, the motion control module runs the simulation model to calculate the retraction and extension process in real time. The 3D animation on the control room screen reproduces the attitude changes of each component of the landing gear in real time. Engineers can judge whether the movement of the retraction and extension mechanism is in place and whether the timing is correct by observing the 3D screen. Another typical application scenario is a flight simulator. In the takeoff, landing, and ground taxiing subjects of the flight simulator, the landing gear retraction and extension animation and the nose wheel turning animation are presented in real time as the simulation progresses.

[0061] This embodiment describes the complete interaction process of contraction and expansion testing between the motion control module and the animation engine module under this architecture.

[0062] Example 1: Parameterized-driven multi-sided interaction implementation of the take-up and release process

[0063] Figure 2 This is a schematic diagram illustrating the entire retraction and extension process of a landing gear, as provided in an embodiment of this application. Figure 2 The process shown is as follows Figure 1 The following example illustrates the interaction between the motion control module, data interaction middleware, and animation engine module in the system shown. This embodiment involves three execution entities. The motion control module acts as the solution side, responsible for running the simulation model and generating motion parameters and positioning signals. The data interaction middleware acts as the transmission side, responsible for forwarding data between the two modules in real time. The animation engine module acts as the rendering side, responsible for driving the skeletal posture of the landing gear 3D model and presenting the 3D interface. The roles of the three parties are illustrative. When the motion control module and animation engine module are co-located on the same physical device, the steps performed by both sides are executed by the co-located device, and the function of the data interaction middleware is implemented through inter-process communication within the co-located device.

[0064] Step S201: The motion control module performs real-time calculations on the retraction and extension process of the aircraft landing gear according to the simulation step size through the simulation model, and obtains the motion parameters of each component of the landing gear at each simulation step size.

[0065] Motion parameters characterize the real-time attitude of the corresponding components during the landing gear's extension and retraction process. Taking angle-type parameters as an example, motion parameters are specific values ​​such as door angle, strut angle, and chassis angle; for example, the strut angle is equal to 35.7 degrees. Motion parameters are continuously changing values, not discrete segment indices like "playing a specific frame." Each time the simulation model advances by one simulation step, it solves the kinematic equations for each landing gear component, outputting the angle or position value of each component at that moment.

[0066] The retraction and extension process comprises at least two sequentially executed travel phases, each corresponding to the attitude changes of different components of the landing gear. A travel phase refers to a temporal division of the retraction and extension process, and the component experiencing attitude changes within each travel phase corresponds to the control objective of that phase. The method of dividing the travel phases is detailed in Embodiment 2.

[0067] Step S202: The motion control module sends the motion parameters calculated for each simulation step to the animation engine module in real time via the data interaction channel.

[0068] The data interaction channel connects the simulation model and the 3D animation engine, with motion parameters flowing from the simulation model to the 3D animation engine. Specifically, the motion control module encapsulates the calculated motion parameters along with timestamps into data packets, which are then forwarded by the data interaction middleware. The data interaction middleware performs format conversion on the data packets and writes them to the receiving interface on the 3D animation engine side. The specific form of the data interaction channel is described in Example 6, and the model mapping rules upon which the format conversion depends are described in Example 3.

[0069] Step S203: Based on the received motion parameters, the animation engine module drives the skeletal posture of the components in the landing gear 3D model corresponding to the motion parameters in real time, so as to present the extension and retraction animation synchronized with the real-time solution results of the simulation model on the 3D interface.

[0070] In the 3D model of the landing gear, the skeletons of each component are organized in a hierarchical structure. Taking the hierarchy of "fuselage → door / support → chassis → wheels" as an example, the fuselage is the root node, the door and support are attached to the fuselage node, the chassis is attached to the support node, and the wheels are attached to the chassis node. This hierarchical structure is consistent with the kinematic chain structure in the simulation model. Each time the animation engine module receives a set of motion parameters, it assigns the corresponding skeleton node's transformation attribute to that value in real time. For example, if the rotation angle of the support skeleton node is assigned to 35.7 degrees, the support component in the 3D interface will then exhibit the posture after rotating 35.7 degrees. The 3D model itself does not pre-store any extension or retraction animation clips; the posture of the 3D model is entirely determined by the motion parameters passed in each frame. This driving method is fundamentally different from keyframe animation: the playback trajectory of keyframe animation is fixed during production, while in this embodiment, the 3D model "obeys" every value calculated by the simulation model.

[0071] Step S204: When the simulation model detects that the positioning conditions corresponding to the current travel stage are met, the motion control module generates a positioning signal.

[0072] A positioning signal is a status indicator that a component has moved to the target state at the current stage of its journey. One way to realize the positioning condition is for the component to move to a preset positioning position. For example, the hatch opening positioning signal is set to true when the hatch angle reaches a preset opening angle.

[0073] Step S205: The motion control module feeds back the positioning signal to the animation engine module through the data interaction channel to trigger the extension and retraction process to switch from the current stroke stage to the next stroke stage.

[0074] The data interaction middleware forwards the arrival signal to the animation engine module. Upon receiving the arrival signal, the animation engine module displays the component corresponding to the current stage of the process as being in the "in position," for example, highlighting the hatch with a bright color. The state machine on the simulation model side then synchronously switches to the next stage of the process. For example... Figure 5 As shown, the deployment and recovery process proceeds in the following sequence: "receiving instructions → hatch operation → waiting for hatch arrival signal → support operation → waiting for support arrival signal → chassis operation → waiting for chassis arrival signal → hatch closing and locking". Each stage is triggered by the arrival signal of the previous stage.

[0075] Step S206: After switching to the next stroke stage, the motion control module calculates the motion parameters of the component corresponding to the next stroke stage. The calculated motion parameters are sent to the animation engine module in real time through the data interaction channel to drive the skeletal posture of the component corresponding to the next stroke stage in the landing gear 3D model.

[0076] After the phase switch, the simulation model's solution object changes to the component corresponding to the next stroke phase. The animation engine module's driving object changes synchronously to the skeletal nodes of that component. The solution, transmission, and driving processes described in steps S201 to S203 are repeated in the next stroke phase until all stroke phases of the expansion and contraction process are completed.

[0077] Step S207: The animation engine module displays the extension and retraction animation and the data curves drawn based on motion parameters in parallel on the 3D interface to verify the extension and retraction process.

[0078] The 3D interface is divided into an animation display area and a curve display area. The animation display area presents the attitude of each landing gear component in 3D space. The curve display area shows the changes in motion parameters such as door angle and strut angle over time in 2D curve form. Both display channels are driven by the same motion parameter data source and are synchronized with each other in time. Engineers can both intuitively judge the landing gear status by observing the 3D animation and confirm specific values ​​by interpreting the data curves; the two verification methods corroborate each other.

[0079] The beneficial effects of this embodiment will be analyzed below.

[0080] First, since the skeletal posture of each component of the 3D model is directly driven by the motion parameters calculated in real time for each simulation step of the simulation model, the posture of the 3D model completely follows the changes in the calculated values, without relying on any pre-recorded animation clips. Therefore, when the operating conditions such as the retraction speed and starting angle change, the position of each component of the landing gear in the animation remains consistent with the theoretical position calculated by the simulation model. This allows engineers to accurately judge the motion state of the actual retraction mechanism based on the 3D image, avoiding the disconnect between the image and the real state caused by the "fixed script" of keyframe animation.

[0081] Second, since the release and retraction process is divided into at least two sequentially executed stages, and the arrival signal of the current stage triggers the switch to the next stage after being fed back through the data interaction channel, the timing of the stage switch is determined by the arrival conditions detected by the simulation model, rather than by the preset playback duration. Therefore, the timing of the animation is precisely aligned with the physical timing of the simulation solution, thus ensuring the synchronization between the timing of the animation switch and the actual release and retraction process.

[0082] Third, since the 3D animation and data curves are driven in parallel by the same set of motion parameters, the 3D animation channel provides an intuitive means of judging spatial attitude, while the data curve channel provides an accurate means of interpreting numerical values. Therefore, the two channels are strictly synchronized in time and can verify each other, thereby improving the efficiency and accuracy of landing gear simulation testing and verification.

[0083] Example 2: Stroke Phase Division and Driving Conditions

[0084] In the interaction flow described in Embodiment 1, the arrival signal triggers the switching of the travel phase. However, the details of how the travel phases are divided, which components correspond to each phase, and how the driving conditions for phase switching are constituted directly affect the accuracy of the closed-loop switching. In order to implement the timing closed loop of the retraction and extension process, it is necessary to clarify the correspondence between phases and components. According to the embodiments of this application, the features related to the division of travel phases are as follows.

[0085] The release and take-off process consists of four stages.

[0086] Phase one involves unlocking and opening the hatch during the hatch opening and closing phase. The trigger condition is that the simulation model receives a command to raise or lower the hatch. The actions in this phase include energizing the hatch lock solenoid valve, extending the hatch actuator, and rotating the hatch to open. The end indicator is when the hatch is fully open signal is set to true.

[0087] Phase two is the strut retraction and extension phase. The trigger condition is that the hatch is fully open. In this phase, the actions are as follows: in the retraction direction, the strut actuator retracts and the strut rotates around the hinge point to retract; in the extension direction, the strut actuator extends and the strut rotates around the hinge point to lower. The phase ends when either the strut retraction complete signal or the strut extension complete signal is set to true.

[0088] Phase three is the frame retraction and extension phase. The trigger condition is the strut being in position. In this phase, the frame folds upwards and extends to a horizontal position downwards. The phase ends when the frame is in position signal is set to true.

[0089] Phase four involves closing and locking the hatch during the hatch opening and closing phase. The trigger condition is that the chassis is in position. The actions in this phase include retracting the hatch actuator, rotating the hatch to close, and locking the hatch lock. The phase ends when the hatch is closed and the lock signal is true.

[0090] In summary, the landing gear has at least two travel phases: a door opening / closing phase, a strut retraction / extension phase, and a chassis retraction / extension phase. The door opening / closing phase corresponds to the attitude change of the landing gear door components. The strut retraction / extension phase corresponds to the attitude change of the landing gear strut components. The chassis retraction / extension phase corresponds to the attitude change of the landing gear chassis components. The positioning condition for the current travel phase includes the component moving to a preset positioning position. For example, the positioning position for the strut retraction / extension phase is when the strut angle reaches 95 degrees (corresponding to fully retracted) or 0 degrees (corresponding to fully extended).

[0091] In actual testing, the inventors observed a phenomenon: when the take-up or put-down commands are issued by the physical switch on the control panel or by the host computer software, the command signal may exhibit millisecond-level jitter near the transition edge. If the simulation model directly responds to the jittered command, the take-up / put-down process will incorrectly switch between the two stages. Based on this observation, in one possible implementation, the simulation model performs real-time calculations of the take-up / put-down process based on driving conditions. These driving conditions include take-up driving conditions and put-down driving conditions.

[0092] The conditions for retracting / raising include: receiving a retracting / raising command, the hatch component being fully opened, the strut component not being fully retracted, and the retracting / raising command delay being released. The conditions for lowering / raising include: receiving a lowering command, the hatch component being fully opened, the strut component not being fully lowered, and the lowering command delay being released. The release of the retracting / raising command delay and the release of the lowering command delay mean that after receiving the corresponding command, a preset filtering time is allowed before the simulation model recognizes the command as valid. One possible value for the preset filtering time is 50 milliseconds. Logically, a valid retracting / raising drive is equal to the logical AND of "retracting command," "hatch component fully opened," "strut component not fully retracted," and "retracting command delay released." The retracting / raising calculation for the strut retraction / raising phase is only initiated when all four conditions are simultaneously met. The conditions for a valid lowering drive are similarly determined.

[0093] With this implementation, jitter in the command signal within the filtering time will not be recognized as a new command. For example, if a received command bounces back within 20 milliseconds after the transition, the 50-millisecond filtering time has not yet expired, and the simulation model remains unchanged.

[0094] The beneficial effects of this embodiment will be analyzed below.

[0095] Since the door opening / closing phase, strut retraction / extension phase, and chassis retraction / extension phase correspond one-to-one with the door component, strut component, and chassis component, respectively, the calculation object and animation driving object for each stroke phase are clearly defined as the component corresponding to that phase. Therefore, there is no object confusion between the calculation switching and screen switching between phases, thus ensuring that the timing of the landing gear retraction / extension animation is consistent with the mechanical action sequence of the actual retraction / extension mechanism. Furthermore, since the positioning condition is limited to the corresponding component moving to a preset positioning position, and the positioning judgment is based on continuously calculated angle values ​​rather than relying on timer estimation, the timing of the positioning signal generation is strictly aligned with the actual end point of the component's movement, thereby ensuring the accuracy of the phase switching timing.

[0096] Because both the take-up and take-down driving conditions incorporate a command delay cancellation anti-jitter condition, the simulation model only responds to the command after it has been stably and continuously filtered for a preset duration. Therefore, jitter on the command signal edge is absorbed by the filtering duration, preventing erroneous switching during the phase transition. This avoids abnormal interruptions or repetitive actions in the take-up and take-down process caused by jitter, thus improving the stability of the simulation test process. This anti-jitter mechanism ensures the reliable operation of the closed-loop process in Example 1 in a real test environment with electrical noise.

[0097] As an alternative implementation, the number of stroke stages is not limited to four. For example, for a front landing gear without an independent frame component, the retraction and extension process can optionally be divided into only two stroke stages: the door opening and closing stage and the strut retraction and extension stage. Alternatively, in aircraft models where the frame retraction and extension actions are mechanically linked to the strut retraction and extension actions, the frame retraction and extension stage can optionally be incorporated into the strut retraction and extension stage. This application does not limit the specific number or granularity of the stroke stages in its embodiments.

[0098] Example 3: Configurable Model Mapping Engine

[0099] In step S202 of Embodiment 1, motion parameters need to be format-converted to drive the skeletal nodes of the 3D model. A practical difficulty arises here: different aircraft models have different landing gear structures, resulting in variations in parameter names, angle definitions, and value ranges output by the simulation model; the default orientation, rotation axis, and initial attitude of skeletal nodes also differ between 3D models exported from different modeling software. If a fixed set of conversion code is written for each aircraft model, the middleware program needs to be modified and redeployed when adapting to new models. In related technologies, the mapping relationship between parameters and models is usually fixed in the program code. Unlike the above approach, this embodiment decouples the mapping relationship from the code and delegates it to an external configuration file for definition, forming a configurable aircraft mapping engine.

[0100] Figure 3 This is a schematic diagram of a parameterized binding rule provided in an embodiment of this application. Figure 3 Yes Figure 1This section further refines the parameter mapping rules executed by the data interaction middleware in the system shown. For example... Figure 3 As shown, the binding relationship between simulation model parameters and 3D model mapping objects includes: strut angle (a continuous value ranging from 0 to 90 degrees) mapped to the rotation transformation of the strut skeleton around the hinge point axis; door angle (a continuous value ranging from 0 to 60 degrees) mapped to the rotation transformation of the door skeleton around the hinge point axis; frame angle (a continuous value ranging from 0 to 90 degrees) mapped to the rotation transformation of the frame skeleton around the hinge point axis; front wheel yaw angle (a continuous value ranging from -60 degrees to +60 degrees) mapped to the rotation transformation of the front landing gear strut skeleton around the vertical axis; and wheel speed of each wheel (a continuous value ranging from 0 to 3000 revolutions per minute) mapped to the rotation transformation of the corresponding wheel skeleton around the wheel axis.

[0101] Based on the above binding concept, step S202 in Embodiment 1 is refined into the following two steps in a possible implementation.

[0102] Step 1: Load the aircraft model parameter configuration file corresponding to the aircraft model.

[0103] The aircraft parameter configuration file predefines the mapping rules between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model. These mapping rules include semantic mapping relationships between motion parameters and skeletal nodes, as well as coordinate system transformation rules. The semantic mapping relationship answers the question "which parameter drives which skeletal node," while the coordinate system transformation rules answer the question "how parameter values ​​are converted into attitude values ​​on that skeletal node." One format for the aircraft parameter configuration file is a JSON file. The data interaction middleware internally maintains the aircraft mapping engine, dynamically loading the configuration file corresponding to the current aircraft model at runtime, rather than executing a fixed transformation algorithm.

[0104] Below is a sample configuration file for a specific model. This example corresponds to the A320 model, and the file name is A320_gear_config.json (the field names in the JSON code block are kept in their original English form; the meanings of the fields will be explained later): { "aircraft_type": "A320", "coordinate_system": { "sim_model": { "up_axis": "Z", "angle_zero_reference": "vertical downward is 0°"}, "engine_model": { "up_axis": "Z", "angle_zero_reference": "Horizontal forward angle is 0°"} }, "mapping_rules": [ { "rule_id": "MAP_001", "sim_param_name": "Angle of the left main support", "sim_unit": "degree", "sim_value_range": { "min": 0, "max": 95}, "sim_angle_definition": "The angle between the angle and the vertical downward direction, 0° = fully lowered, 95° = fully tucked in", "target_model_path": "Gear_Left / Strut", "target_transform_type": "rotation", "target_rotation_axis": "X", "target_value_range_degrees": { "min": 0, "max": 95}, "coordinate_conversion": { "offset": 0, "scale": 1.0, "axis_remap": "X→X"} }, { "rule_id": "MAP_002", "sim_param_name": "Angle of the left main cabin door", "sim_unit": "degree", "sim_value_range": { "min": 0, "max": 60}, "sim_angle_definition": "The angle between the angle and the closed position, 0° = fully closed, 60° = fully open", "target_model_path": "Gear_Left / Door", "target_transform_type": "rotation", "target_rotation_axis": "Y", "target_value_range_degrees": { "min": 0, "max": 60}, "coordinate_conversion": { "offset": 0, "scale": 1.0, "axis_remap": "Y→Y"} }, { "rule_id": "MAP_003", "sim_param_name": "Front wheel steering angle", "sim_unit": "degree", "sim_value_range": { "min": -75, "max": 75}, "sim_angle_definition": "The angle between the angle and the direction directly ahead; negative values ​​indicate a left turn, and positive values ​​indicate a right turn." "target_model_path": "Gear_Nose / Steering", "target_transform_type": "rotation", "target_rotation_axis": "Z", "target_value_range_degrees": { "min": -60, "max": 60}, "coordinate_conversion": { "offset": 0, "scale": 0.8, "axis_remap": "Z→Z", "clamp_enabled": true, "clamp_min": -60, "clamp_max": 60 } } ], "timing_parameters": { "door_open_delay_ms": 200, "gear_transit_time_ms": 8000, "gear_retract_time_ms": 7000 } } The meanings of each field in the above configuration file are shown in Table 1 below.

[0105] Table 1

[0106] Step 2: According to the mapping rules, the motion parameters are converted into the corresponding skeletal pose parameters of the skeletal nodes, and the skeletal pose parameters are sent to the animation engine module in real time through the data interaction channel.

[0107] Skeletal pose parameters are numerical values ​​that can be directly written into the transformation properties of a bone node, such as the angle of rotation around a specified axis or the corresponding quaternion. The animation engine module drives the skeletal pose of the component to which the bone node belongs based on the skeletal pose parameters.

[0108] The coordinate system transformation rules are further refined below. These rules include scaling factors, offsets, and axial remapping relationships. The transformation process is as follows: the motion parameter values ​​are transformed according to the scaling factors and offsets, and the rotation axes on the skeletal nodes are determined according to the axial remapping relationships to obtain the skeletal attitude parameters. When adapting to a new aircraft model, the mapping rules in the aircraft parameter configuration file are updated to establish a mapping between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model corresponding to the new aircraft model, while the core middleware code remains unchanged.

[0109] The three transformation elements address the following three types of differences: Axial remapping addresses differences in default bone orientation: Models exported from different 3D modeling software (e.g., Maya, Blender) may have X-axis, Y-axis, or Z-axis rotation axes for support bones. The support angle output by the simulation model is always a scalar value. Axial remapping specifies which rotation axis of the 3D model this scalar value is applied to. Scaling factor addresses differences in scale and pivot point: Some 3D models are not strictly built to a 1:1 scale, or the position of the bone rotation pivot point differs from the definition in the simulation model. When the simulation outputs 1 degree, the 3D model needs to rotate 1.2 degrees to achieve the visually corresponding position. The scaling factor performs this correction function. Offset addresses differences in initial posture: In 3D models of different models, the initial bone angle corresponding to the "support fully retracted" posture may be 0 degrees, or it may be 5 degrees due to different modeling reference postures. Offset maps the zero point of the simulation value to the correct posture of the 3D model.

[0110] The following example illustrates the runtime conversion process using a specific numerical example. The scenario is: an A320 aircraft performs a landing gear retraction operation, and the simulation model calculates that the angle of the left main strut is 35.0 degrees at t = 5.2 seconds.

[0111] The first step is parameter reception and table lookup. The data interaction middleware receives a data packet carrying a timestamp t equal to 5.2 seconds, a parameter name "Left Main Column Angle", and a value of 35.0 degrees. The device mapping engine searches for the parameter name in the configuration file, matching rule MAP_001, and obtains the target skeleton path "Gear_Left / Strut", transformation type "rotation", rotation axis "X", scaling factor 1.0, offset 0, and target value range 0 to 95 degrees.

[0112] The second step is format conversion and range checking. The original value of 35.0 degrees is multiplied by a scaling factor of 1.0 to obtain a converted value of 35.0 degrees. This converted value is compared to the target value range. If 35.0 degrees falls within the range of 0 to 95 degrees, the original value is retained. If the converted value is less than the lower limit, the lower limit is used; if the converted value is greater than the upper limit, the upper limit is used. The pseudocode describes this checking logic as follows: `converted_value` equals `raw_value` multiplied by `scale`; if `converted_value` is less than 0, `clamped` is 0; if `converted_value` is greater than 95, `clamped` is 95; otherwise, `clamped` is `converted_value`. In the pseudocode, `converted_value` represents the scaled value, and `clamped` represents the clipped value.

[0113] The third step is coordinate system alignment. For this model, the simulation model uses vertical downward as 0 degrees, and the 3D model uses horizontal forward as 0 degrees, but rotation around the positive X-axis is defined in the configuration file and requires no additional offset; the value after limiting is directly used as the target angle. For other models with different zero-angle definitions, the configuration file can optionally define a conversion relationship such as "target angle equals 90 minus the limiting value".

[0114] The fourth step is to generate the skeleton pose parameters. The pose, rotated 35.0 degrees around the X-axis, is converted into a quaternion, resulting in a quaternion (x approximately equal to 0.296, y equal to 0, z equal to 0, w approximately equal to 0.955). Quaternions are a general data structure used internally by 3D engines to represent rotation, avoiding the gimbal lock problem of Euler angles.

[0115] The fifth step is to write the data to the 3D model. The data interaction middleware uses the external interface provided by the 3D engine SDK to call the bone transformation writing function, assigning the rotation attribute of the target bone path "Gear_Left / Strut" to the aforementioned quaternion. Taking Unreal Engine as an example, this can be optionally written via a UDP receiving plugin or a C++ SDK interface; taking Unity Engine as an example, this can be optionally written via the Transform interface in C# scripts.

[0116] The beneficial effects of this embodiment will be analyzed below.

[0117] Since the semantic mapping relationship between motion parameters and skeletal nodes and the coordinate system transformation rules are defined in the external model parameter configuration file, the middleware dynamically loads the mapping rules at runtime instead of executing a fixed algorithm. Therefore, the mapping relationship is decoupled from the program code. Thus, when adapting to a new model, only the configuration file needs to be updated to establish a new mapping. There is no need to modify, recompile, and redeploy the middleware program, which achieves the effect of "one middleware, adapting to multiple models" and reduces the adaptation cost and cycle of multi-model simulation testing.

[0118] Furthermore, since the coordinate system transformation rules are decomposed into three independent elements—scaling factor, offset, and axial remapping relationship—three common problems—bone orientation difference, proportional pivot difference, and initial pose difference—are each independently corrected by their respective elements. Therefore, model differences in any dimension can be resolved by adjusting the corresponding field without affecting the mapping results in other dimensions, thereby improving the flexibility and maintainability of the mapping rule configuration. The range checking and limiting mechanism also ensures that out-of-bounds values ​​are not written to bone nodes, avoiding abrupt changes in the 3D model pose caused by abnormal parameters.

[0119] Example 4: Integrated Coupling Kinematic Model of Turning-Wheel Speed-Differential Braking

[0120] The preceding embodiments focused on the landing gear retraction and extension process. During the ground taxiing phase, the landing gear also performs a turning function. In related technologies, nose wheel turning angle control, wheel speed signal generation, and differential braking torque distribution are typically implemented by three independent modules. During the integration process, the inventors observed that the arc length traversed by the outer main wheel during an aircraft turn is naturally greater than that of the inner main wheel. If the independently generated wheel speed signals do not take into account the turning radius, an inconsistency between the wheel speed and the fuselage turning motion will appear in the animation; for example, the fuselage may be turning at a large angle while the inner and outer wheels rotate at the same speed. Based on this observation, this embodiment integrates nose wheel turning control, wheel speed simulation, and differential braking into a unified turning-wheel speed coupled kinematic model, which is solved synchronously by the simulation model within the same computational framework.

[0121] Step 1: Determine the target deflection angle of the front wheels.

[0122] The simulation model receives turning commands. These commands originate from input via the control stick or pedals. Based on these commands, the simulation model calculates the target deflection angle of the landing gear's front wheels and limits this angle. One possible limit is within ±60 degrees, corresponding to the maximum design angle of the front wheel steering mechanism in the 3D model. The limited target deflection angle is denoted as δ.

[0123] Step 2: Calculate the turning radius.

[0124] The simulation model determines the turning radius R based on the target deflection angle δ and the aircraft's wheelbase L. The calculation formula is as follows: R = L / tan(δ) In the formula: R is the instantaneous turning radius of the aircraft's center of mass around the turning center, in meters, and its value ranges to a real number greater than 0. When δ approaches 0 degrees, R approaches infinity, corresponding to straight-line driving conditions; L is the aircraft's wheelbase, that is, the distance between the nose landing gear and the main landing gear along the longitudinal direction of the fuselage, in meters, and is given by the aircraft model parameters. For example, the wheelbase of a mainline passenger aircraft is on the order of tens of meters; δ is the nose wheel target deflection angle, in degrees or radians, and its value ranges within ±60 degrees. A negative value indicates a left turn, and a positive value indicates a right turn.

[0125] Step 3: Calculate the wheel speed parameters of each wheel.

[0126] The simulation model determines the wheel speed difference between the inner and outer main wheels based on the turning radius R, the aircraft's center of gravity velocity, and the main wheel track, thus obtaining the wheel speed parameters of each wheel. The calculation formula is as follows: V_inner = V_center × (R - T / 2) / R V_outer = V_center × (R + T / 2) / R In the formula: V_inner is the linear velocity of the inner main wheel, in meters per second; V_outer is the linear velocity of the outer main wheel, in meters per second; V_center is the instantaneous velocity of the aircraft's center of mass, given by the velocity model, in meters per second, with a typical range of 0 to 30 meters per second during ground taxiing; T is the wheelbase, i.e., the lateral distance between the left and right main wheels, in meters, given by the aircraft model parameters. The inner main wheel refers to the main wheel on the side of the turning center, and the outer main wheel refers to the main wheel on the side away from the turning center. When R approaches infinity, both V_inner and V_outer approach V_center, and the inner and outer wheel velocities are equal, consistent with the physical fact of straight-line travel. The wheel speed of the nose landing gear wheel is approximately taken as V_center, without considering the slight difference caused by the nose wheel's steering.

[0127] Wheel speed parameters can be output as linear velocity or converted to rotational speed. The conversion is as follows: rotational speed equals linear velocity divided by wheel circumference multiplied by 60, in revolutions per minute.

[0128] Step 4: Determine the differential braking torque distribution.

[0129] When braking is applied during a turn, the simulation model determines the braking torque distribution ratio between the inner and outer main wheels based on the target deflection angle. The distribution principle is: the braking torque of the outer main wheel is greater than that of the inner main wheel, and the difference in braking torque between the outer and inner main wheels increases with the increase of the target deflection angle, thus forming an auxiliary turning torque. A specific distribution formula is as follows: M_outer = M_total × (1 + k × |δ|) M_inner = M_total × (1 - k × |δ|) In the formula: M_outer is the braking torque allocated to the outer main wheel, in Newton-meters (Nm); M_inner is the braking torque allocated to the inner main wheel, in Newton-meters (Nm); M_total is the reference value of the total braking torque, given by the braking command, in Newton-meters (Nm); k is the turning braking gain coefficient, dimensionless, given by the flight control system parameter table, with a typical value range of 0 to 0.02 degrees per degree; δ is the target deflection angle of the front wheel, where |δ| represents the absolute value of the target deflection angle. When δ equals 0 degrees, M_outer and M_inner are equal, corresponding to symmetrical distribution of straight-line braking.

[0130] Step 5: Synchronize the output to the animation engine module.

[0131] The simulation model sends the target deflection angle and wheel speed parameters to the animation engine module in real time via a data interaction channel to drive the deflection attitude of the front wheel component and the rotation attitude of each wheel component in the landing gear 3D model. Braking parameters, representing the braking torque distribution ratio, are also sent to the animation engine module in real time via the data interaction channel. These braking parameters are presented synchronously with the deflection attitude of the front wheel component and the rotation attitude of each wheel component. One implementation of this synchronous presentation is as follows: the braking torque ratio of the left and right main wheels is displayed on the 3D interface using numerical gauges or varying shades of color. The display frames of the braking torque carry the same timestamp as the display frames of the front wheel deflection and wheel rotation.

[0132] Because the target deflection angle, turning radius, inner and outer wheel speed difference, and differential braking torque are derived sequentially from the same set of inputs (turning command, center of mass velocity, and aircraft geometric parameters) within the same kinematic model, the kinematic coupling relationship between each physical quantity is fully preserved during the calculation process. Therefore, the front wheel deflection, wheel rotation, and brake distribution are strictly synchronized at each simulation step, thus realistically reproducing the dynamic characteristics of an aircraft turning on the ground: "the sharper the turn, the more obvious the inner and outer wheel speed difference, and the greater the auxiliary turning torque," improving the realism of ground taxiing simulation. Simultaneously, since all turning-related parameters are synchronously sent to the animation engine module via the same data interaction channel and presented on the same 3D interface, engineers do not need to operate multiple interfaces to view different data, thereby improving the observation efficiency of turning tests. Unlike the effect of the retraction process in Example 1, the effect of this example is reflected in the real-time synchronous presentation of the coupling of multiple physical quantities.

[0133] As an alternative implementation, the turning radius can be calculated using an equivalent wheelbase model that considers the multi-wheel structure of the main landing gear, and the differential braking distribution can be achieved using a lookup table method instead of an analytical formula. This application does not limit the specific mathematical form of the coupled model.

[0134] Example 5: Clock Synchronization and Frame Skip Catching

[0135] In the interactive flow of Example 1, motion parameters carrying the simulation model's solution timestamps flow to the animation engine module. When the motion control module and animation engine module are located on different computing platforms, their clock references are independent. The simulation model progresses according to the simulation step size, while the animation engine renders frames according to the display refresh rate. After running for a long time, the time references on both sides will accumulate deviations. Once the animation lags behind the solution results, the image observed by the engineer will no longer reflect the landing gear state at the "current moment." To address this timing drift problem, this example provides a clock synchronization mechanism.

[0136] Specifically, the synchronization deviation is obtained by comparing the simulation model's solution timestamp with the 3D animation engine's frame counter. The solution timestamp is the time stamp used by the simulation model to write data packets at each simulation step. The frame counter is the cumulative number of rendered frames by the 3D animation engine; it increments by one for each rendered frame. The data interaction middleware or animation engine module calculates the display time on the animation side based on the frame counter and frame rate, and then subtracts the latest received solution timestamp from the display time; this difference is the synchronization deviation. A positive synchronization deviation indicates that the animation lags behind the solution, while a negative synchronization deviation indicates that the animation is ahead of the solution.

[0137] When the synchronization deviation exceeds a preset synchronization threshold, the animation engine module catches up by skipping frames or adjusting the playback speed of the animation to keep it synchronized with the real-time calculation results of the simulation model. One preset synchronization threshold is 50 milliseconds. 50 milliseconds corresponds to approximately 3 frames of display time at a normal refresh rate of 60 frames per second. This level of deviation is perceptible to the naked eye, and as a trigger threshold, it balances synchronization accuracy and adjustment frequency. There are two ways to catch up: Method 1: Frame skipping: When the synchronization deviation exceeds the preset synchronization threshold, the animation engine module discards the lagging intermediate pose and directly updates the skeletal pose to the pose corresponding to the latest received motion parameters. Method 2: Adjusting playback speed: When the synchronization deviation is a small positive amount, the animation engine module plays the animation at an interpolation speed higher than the normal rate; when the synchronization deviation is negative, the animation engine module reduces the playback speed and waits for the calculation side. Frame skipping is suitable for scenarios with sudden increases in deviation, while speed adjustment is suitable for scenarios with slow accumulation of deviation. The two methods can be used in combination.

[0138] Because the clock synchronization mechanism continuously compares the calculated timestamp with the frame counter and actively catches up when the deviation exceeds the limit, the cumulative drift of the clock references on both sides is periodically eliminated and will not increase indefinitely with the test duration. Therefore, the synchronization relationship between the animation and the real-time calculation results remains valid throughout long-term testing, thus ensuring the credibility of the animation display in continuous simulation tests lasting several hours (e.g., complete flight maneuvers). Unlike the drive synchronization within a single step in Example 1, this example addresses the problem of maintaining synchronization over a long timescale.

[0139] Example 6: UDP / Shared Memory Bidirectional Data Interaction Channel

[0140] The data interaction channel in Example 1 carries three types of data: motion parameters, arrival signals, and frame synchronization signals. The specific form of the channel directly affects transmission latency and deployment flexibility. This example elaborates on the form of the data interaction channel.

[0141] In one possible implementation, the data interaction channel is a UDP-based network channel. The computer hosting the motion control module and the computer hosting the animation engine module are connected via Ethernet. The data interaction middleware listens for data packets from the motion control module through a UDP port. The data packets use a custom structure format, which includes a timestamp, angle or position parameters for each component, and status flag fields. UDP does not require connection establishment, and packets do not undergo retransmission or reordering mechanisms. The single-packet transmission latency is lower than that of connection-oriented protocols, meeting the real-time delivery requirements of simulation step-level data. A small amount of packet loss in the simulation data stream only results in the loss of a few intermediate poses; the skeleton pose is immediately updated to the latest value upon the arrival of subsequent data packets, and packet loss will not cause state freeze.

[0142] In another possible implementation, the data interaction channel is a shared memory channel. When the motion control module and the animation engine module are deployed on the same computer, the data interaction middleware establishes a shared memory region between the processes of the two modules. The motion control module process writes motion parameters to the shared memory region, and the animation engine module process reads them from the shared memory region. Data does not pass through the network protocol stack, the transmission latency is on the order of microseconds, and there is no packet loss.

[0143] Regardless of the method used, the data interaction channel is bidirectional. Motion parameters and position signals are transmitted from the simulation model to the 3D animation engine. Frame synchronization signals are transmitted from the 3D animation engine to the simulation model. The frame synchronization signal is used by the simulation model to perform closed-loop verification of the display progress of the 3D animation engine. One aspect of the frame synchronization signal is that after each frame is rendered, the animation engine module sends back the current value of the frame counter and the timestamp of the corresponding displayed motion parameters. The simulation model compares the sent timestamp with its own calculation progress to determine whether the animation side has consumed the issued parameters as expected. If the feedback progress is continuously delayed, the simulation model generates a prompt message for engineers to troubleshoot rendering performance issues.

[0144] Because the data interaction channel transmits motion parameters and arrival signals in the downlink direction and sends back frame synchronization signals in the uplink direction, the display progress of the animation engine is included in the verification scope of the simulation model. The implicit assumption of "whether the animation keeps up with the test" becomes a quantifiable and verifiable state. Therefore, the control side can promptly detect lags or anomalies on the rendering side, thus achieving a two-way closed loop of "testing is animation, and animation is testing." The UDP channel supports cross-computer deployment with lower transmission overhead, while the shared memory channel supports intra-machine deployment with lower latency. Both forms provide adaptation methods for different hardware environments. Compared to the clock synchronization in Example 5, which addresses the comparison and catching up of clock references on both sides, this example addresses the low-latency transmission of the data path itself and the return of display progress; both work together to support the achievement of the synchronization goal.

[0145] Example 7: 3D Animation Feedback of Abnormal Operating Conditions

[0146] The preceding embodiments described retraction and turning tests under normal operating conditions. Another type of landing gear simulation testing is the abnormal operating condition injection test, such as actuator sticking, insufficient hydraulic pressure, or position sensor failure. In related technologies, abnormal operating conditions are usually indicated by alarm text or data exceeding limits, requiring engineers to manually associate the alarm information with the status of each component. This embodiment directly maps abnormal operating conditions to a differentiated presentation on a 3D animation, making abnormal components immediately apparent on the screen.

[0147] Specifically, in the event of a pre-set abnormal condition during the landing gear's retraction and extension process, a 3D animation engine will display the skeletal posture of the components experiencing the pre-set abnormal condition in the 3D model of the landing gear, using a display method distinct from the normal operating condition. Pre-set abnormal conditions include component jamming, abnormal retraction and extension speed, or failure to trigger the positioning signal.

[0148] The detection methods and animation feedback for the three types of abnormal operating conditions are shown in Table 2 below.

[0149] Table 2

[0150] Of the three types of feedback, the feedback method for abnormal retraction and extension speed is a natural result of parameter-driven processing. When the hydraulic pressure is low, the angle change rate calculated by the simulation model decreases synchronously, and the movement speed of the 3D model naturally slows down with the real-time parameters, requiring no additional abnormal rendering logic. Jamming and failure to trigger the positioning signal require differentiated processing on the rendering side: jammed parts are superimposed with a visual effect of slight reciprocating jitter or complete pause, indicating that the movement of the part is obstructed; when the positioning signal is not triggered, although the part moves to the target position, the positioning highlight or color switch that should occur under normal operating conditions does not occur, allowing engineers to identify the failure of the positioning sensor link.

[0151] Because abnormal operating conditions are mapped to a 3D animation display method distinct from normal operating conditions, abnormal posture, speed, or status of abnormal components are directly presented in the same frame as the engineer observes the extension / retraction animation. Engineers do not need to manually establish a correlation between the alarm list and component status, thus shortening the anomaly location time, thereby covering a more complete test scenario and improving the efficiency of anomaly injection testing. Simultaneously, the natural presentation of abnormal extension / retraction speed further confirms the advantages of parameterized driving over keyframe playback: keyframe animations still play at a preset speed when hydraulic pressure is low, while the animation speed in this embodiment changes synchronously with the solution results.

[0152] Example 8: Full Recording and Animation Playback

[0153] The model qualification test requires that the testing process be traceable and reproducible. In the previous embodiments, the interaction data was lost to memory after the test, making post-test analysis impossible. This embodiment supplements the system with the ability to record and replay the entire process.

[0154] The motion parameters and position signals transmitted via the data interaction channel are recorded throughout the entire process, resulting in a test log file. Each record in the test log file includes a timestamp and the corresponding motion parameters. Recording is performed by the state monitoring and recording module. The state monitoring and recording module bypasses the data interaction middleware to listen for all data forwarded and stores it in file format. One file format option is CSV, and the other is a binary file. Binary files have lower write overhead and are suitable for high-frequency recording at the millisecond level; CSV files facilitate manual review and analysis by third-party tools.

[0155] Table 3 below shows the field structure of a test record file provided in an embodiment of this application. As shown in Table 3, each record includes the following fields.

[0156] Table 3

[0157] Upon receiving a playback command, the test record file is read in chronological order according to the timestamps, and the read motion parameters are resent to the 3D animation engine to reproduce the extension and retraction animation. The playback data stream and the real-time test data stream enter the animation engine module through the same data interaction channel, and the skeletal driving logic during playback is completely consistent with that during real-time testing. Playback speed can be optionally set to normal speed, multiplied speed, or frame-by-frame increments, allowing engineers to pinpoint the precise moment when a problem occurs.

[0158] Because the test log file fully preserves motion parameters and arrival signals with millisecond-level timestamps, and the playback data stream reproduces the release and recovery animation through the same data interaction channel and the same skeletal drive logic, the playback screen is strictly consistent with the real-time screen during historical tests in principle. Therefore, engineers can accurately reproduce the problem occurrence process at any time afterward without repeating physical experiments, thus providing an intuitive and reliable visual verification method for fault location and fault resolution. The bypass monitoring recording method does not occupy the transmission and processing resources of the main link, and the introduction of the recording function does not reduce real-time test performance.

[0159] Example 9: Range of Simulation Step Size

[0160] In Example 1, the simulation model performs real-time calculations on the deployment and take-off process according to the simulation step size. The value of the simulation step size plays an adjusting role between calculation accuracy and computational cost. This example explains the range of values ​​for the simulation step size.

[0161] The simulation step size ranges from 1 millisecond to 10 milliseconds. Optionally, the simulation step size can further range from 1 millisecond to 5 milliseconds, for example, 1 millisecond, 2 milliseconds, 5 milliseconds, or 10 milliseconds.

[0162] The significance of a lower limit of 1 millisecond lies in the fact that the rate of change of the strut angle during landing gear retraction and extension is on the order of ten degrees per second. A simulation step size of 1 millisecond corresponds to an angle increment of approximately 0.01 degrees within a single step, providing sufficient accuracy to capture the dynamic details of the retraction and extension process, and matching the timer accuracy of the real-time simulation platform. The significance of an upper limit of 10 milliseconds lies in the fact that a 10-millisecond calculation cycle is still higher than the 16.7-millisecond frame interval corresponding to 60 frames per second in conventional 3D displays. This allows animation frames to obtain sufficient new calculation data, while the reduced calculation frequency frees up computational resources, enabling the same simulation platform to solve more system models in parallel. If the simulation step size is greater than 10 milliseconds, the angle increment within a single step increases, resulting in visually perceptible attitude jumps in the animation. If the simulation step size is less than 1 millisecond, the calculation overhead increases significantly, and the improvement in visual synchronization accuracy tends to saturate.

[0163] Because the simulation step size is limited to between 1 and 10 milliseconds, the frequency of solution updates is higher than the display refresh requirements, and the angle increment is less than a threshold perceptible to the naked eye. Therefore, the animation's expansion and contraction process is continuous and smooth, while the computational overhead of the solution task remains at a level that the real-time simulation platform can handle, thus achieving a balance between display effect and computing resources. This value range is the numerical basis for the long-term stable operation of the real-time closed loop described in Example 1 on a conventional engineering computing platform.

[0164] Example 10: Variations and Alternative Examples

[0165] The preceding embodiments provide specific implementations of the 3D animation engine, data interaction channels, and application objects. The related concepts in the claims are higher-level concepts; various lower-level implementations of these higher-level concepts are described below to demonstrate the diversity of implementation methods.

[0166] (1) Multiple lower-level implementations of the 3D animation engine.

[0167] Implementation Method 1: Unreal Engine. The animation engine module builds the landing gear 3D model based on Unreal Engine 5. The data interaction middleware receives bone pose parameters through Unreal Engine's UDP receiver plugin, or calls the bone transformation interface through the Unreal Engine C++ SDK to write quaternions into the corresponding bone nodes. Unreal Engine's physical rendering capabilities can render mechanical details such as hydraulic rod extension and contraction, and hatch hinge rotation.

[0168] Implementation Method Two: Unity Engine. The animation engine module builds the landing gear 3D model based on Unity. The data interaction middleware sends the bone pose parameters to a UDP listening script on the Unity side. After parsing the data packets, the listening script modifies the local rotation properties of the corresponding bone nodes through Unity's Transform interface. Unity's cross-platform deployment capabilities enable the 3D interface to be deployed on Windows workstations, Linux render nodes, or embedded display terminals.

[0169] Implementation Method 3: Self-developed 3D rendering engine. The animation engine module is based on an open-source graphics library (OpenGL) or DirectX graphics interface and uses a self-developed rendering program. The self-developed engine exposes a skeletal animation interface, and the data interaction middleware writes skeletal pose parameters through inter-process communication or dynamic link library calls. The self-developed engine is suitable for testbed projects that require independent control of the software.

[0170] In the three implementation methods described above, the processing logic of the motion control module and the data interaction middleware remains unchanged; only the interface for writing bone pose parameters adapts to the engine type. This application embodiment does not limit the specific type of 3D animation engine.

[0171] (2) Alternative implementation of data interaction channels.

[0172] In addition to the UDP network channel and shared memory channel in Example 6, the data interaction channel also includes the following alternative forms: Alternative Form 1: Reflective Memory Network. The computers hosting the motion control module and animation engine module each have a reflective memory card installed. Data written by any node is broadcast to all nodes in the network within microseconds, suitable for large-scale real-time interconnection of multiple simulation nodes in the Iron Bird Test Bench. Alternative Form 2: Network Channel Based on Transmission Control Protocol (TCP). TCP provides reliable and ordered byte stream transmission, suitable for recording and playback scenarios where data integrity requirements are higher than latency requirements. Alternative Form 3: Data Distribution Service (DDS) Middleware. DDS organizes data topics in a publish-subscribe model, with motion parameters, position signals, and frame synchronization signals corresponding to different topics, suitable for simulation systems with loosely coupled multi-module integration.

[0173] (3) Expand application scenarios.

[0174] The parametric 3D animation driving scheme of this application is not limited to landing gear retraction and turning objects. In one extended application, the simulation model performs real-time calculations on the opening and closing process of aircraft doors (e.g., cargo doors, boarding doors), and the door angle drives the skeletal posture of the door's 3D model via a data interaction channel for simulation testing of the door mechanism. In another extended application, the simulation model performs real-time calculations on the deflection process of control surfaces such as flaps, slats, and speed brakes, and the control surface deflection angle drives the skeletal posture of the corresponding control surface components for simulation testing of the aerodynamic control surface system. In the above extended applications, adaptation can be achieved by supplementing the corresponding mapping rules in the aircraft parameter configuration file, while the rest of the system remains unchanged.

[0175] Figure 4 This is a schematic diagram of the structure of an aircraft landing gear real-time simulation testing device 400 provided in an embodiment of this application. The device 400 includes: The calculation module 410 is used to perform real-time calculations on the retraction and extension process of the aircraft landing gear according to the simulation step size through the simulation model, and obtain the motion parameters of each component of the landing gear at each simulation step size. The motion parameters are used to characterize the real-time attitude of the corresponding component during the retraction and extension process. The retraction and extension process includes at least two stroke stages executed sequentially, and each stroke stage corresponds to the attitude change of different components of the landing gear. The sending module 420 is used to send the motion parameters calculated for each simulation step to the 3D animation engine in real time via a data interaction channel; wherein, the data interaction channel connects the simulation model and the 3D animation engine, and the motion parameters flow from the simulation model to the 3D animation engine in the data interaction channel; The driving module 430 is used to drive the skeletal posture of the component corresponding to the motion parameters in the landing gear 3D model in real time based on the received motion parameters through the 3D animation engine, so as to present the extension and retraction animation synchronized with the real-time solution results of the simulation model on the 3D interface. The switching module 440 is used to generate a positioning signal when the simulation model detects that the positioning condition corresponding to the current travel stage is met, and to feed the positioning signal back to the 3D animation engine through the data interaction channel to trigger the retraction and extension process to switch from the current travel stage to the next travel stage; wherein, after switching to the next travel stage, the calculation module 410 calculates the motion parameters of the component corresponding to the next travel stage, and the driving module 430 drives the skeletal posture of the component corresponding to the next travel stage in the landing gear 3D model based on the motion parameters of the component corresponding to the next travel stage; Display module 460 is used to display the extension and retraction animation and the data curve drawn based on the motion parameters in parallel on the three-dimensional interface to verify the extension and retraction process.

[0176] In some embodiments, the sending module 420 includes: The loading unit is used to load the aircraft model parameter configuration file corresponding to the aircraft model. The aircraft model parameter configuration file predefines the mapping rules between the motion parameters of the simulation model and the skeletal nodes of the landing gear three-dimensional model. The mapping rules include the semantic mapping relationship between the motion parameters and the skeletal nodes and the coordinate system transformation rules. The conversion unit is used to convert the motion parameters into the corresponding bone posture parameters of the bone nodes according to the mapping rules, and send the bone posture parameters to the 3D animation engine in real time through the data interaction channel, so that the 3D animation engine can drive the bone posture of the component to which the bone node belongs based on the bone posture parameters.

[0177] Appendix Figure 4 The described device embodiments are merely illustrative. For example, the division of the units described above is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0178] Figure 5 This application provides a schematic diagram of the structure of a computing device 500, which includes a processor 501 coupled to a memory 502. The memory 502 stores at least one computer program instruction, which is loaded and executed by the processor 501 to enable the computing device 500 to perform the aforementioned functions. Figure 1 The methods provided.

[0179] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps in any of the foregoing method embodiments. The computer-readable storage medium includes, but is not limited to, a read-only memory, a random access memory, a magnetic disk, an optical disk, or flash memory.

[0180] This application also provides a computer program product. The computer program product includes one or more computer program instructions. When the computer program instructions are loaded and run by a computer, the computer performs the steps in any of the foregoing method embodiments.

[0181] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0182] A references B, which means that A is the same as B or A is a simple variation of B.

[0183] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0184] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A real-time simulation testing method for aircraft landing gear, characterized in that, include: The retraction and extension process of the aircraft landing gear is calculated in real time by a simulation model according to the simulation step size, and the motion parameters of each component of the landing gear are obtained at each simulation step size. The motion parameters are used to characterize the real-time attitude of the corresponding component during the retraction and extension process. The retraction and extension process includes at least two stroke stages executed sequentially, and each stroke stage corresponds to the attitude change of different components of the landing gear. The motion parameters calculated for each simulation step are sent to the 3D animation engine in real time via a data interaction channel; wherein, the data interaction channel connects the simulation model and the 3D animation engine, and the motion parameters flow from the simulation model to the 3D animation engine in the data interaction channel; The 3D animation engine drives the skeletal posture of the components corresponding to the motion parameters in the 3D model of the landing gear in real time based on the received motion parameters, so as to present the extension and retraction animation synchronized with the real-time solution results of the simulation model on the 3D interface. When the simulation model detects that the positioning conditions corresponding to the current travel stage are met, a positioning signal is generated and fed back to the 3D animation engine via the data interaction channel to trigger the retraction and extension process to switch from the current travel stage to the next travel stage. After switching to the next travel stage, the simulation model calculates the motion parameters of the component corresponding to the next travel stage, and the calculated motion parameters are sent to the 3D animation engine in real time via the data interaction channel to drive the skeletal posture of the component corresponding to the next travel stage in the landing gear 3D model. The extension and retraction animation and the data curves drawn based on the motion parameters are displayed in parallel on the three-dimensional interface to verify the extension and retraction process.

2. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The at least two travel phases include a door opening / closing phase, a strut retraction / extension phase, and a chassis retraction / extension phase; wherein, the door opening / closing phase corresponds to the attitude change of the door component of the landing gear, the strut retraction / extension phase corresponds to the attitude change of the strut component of the landing gear, and the chassis retraction / extension phase corresponds to the attitude change of the chassis component of the landing gear; the positioning condition corresponding to the current travel phase includes the component corresponding to the current travel phase moving to a preset positioning position.

3. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The step of sending the motion parameters calculated for each simulation step size to the 3D animation engine in real time via a data interaction channel includes: Load the aircraft model parameter configuration file corresponding to the aircraft model. The aircraft model parameter configuration file predefines the mapping rules between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model. The mapping rules include the semantic mapping relationship between the motion parameters and the skeletal nodes and the coordinate system transformation rules. According to the mapping rules, the motion parameters are converted into the corresponding bone posture parameters of the bone nodes, and the bone posture parameters are sent to the 3D animation engine in real time through the data interaction channel, so that the 3D animation engine can drive the bone posture of the component to which the bone node belongs based on the bone posture parameters.

4. The real-time simulation test method for aircraft landing gear according to claim 3, characterized in that, The coordinate system transformation rules include scaling factors, offsets, and axial remapping relationships; The step of converting the motion parameters into the corresponding skeletal pose parameters of the skeletal nodes according to the mapping rule includes: The values ​​of the motion parameters are converted according to the scaling factor and the offset, and the rotation axis on the bone node is determined according to the axial remapping relationship to obtain the bone posture parameters. Specifically, when adapting to a new aircraft model, the mapping rules in the aircraft model parameter configuration file are updated to establish a mapping between the motion parameters of the simulation model and the skeletal nodes of the landing gear 3D model corresponding to the new aircraft model.

5. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The method further includes: The simulation model determines the target deflection angle of the front wheel of the landing gear based on the received turning command; The turning radius is determined based on the target deflection angle and the wheelbase of the aircraft, and the wheel speed difference between the inner and outer main wheels is determined based on the turning radius, the center of gravity velocity of the aircraft, and the main wheel track, thus obtaining the wheel speed parameters of each wheel. The target deflection angle and the wheel speed parameters are sent to the 3D animation engine in real time via the data interaction channel to drive the deflection attitude of the front wheel component and the rotation attitude of each wheel component in the 3D model of the landing gear.

6. The real-time simulation test method for aircraft landing gear according to claim 5, characterized in that, The method further includes: The braking torque distribution ratio between the inner main wheel and the outer main wheel is determined based on the target deflection angle; wherein the braking torque of the outer main wheel is greater than that of the inner main wheel, and the difference between the braking torques of the outer main wheel and the inner main wheel increases with the increase of the target deflection angle, so as to form an auxiliary turning torque; The braking parameters, which characterize the braking torque distribution ratio, are sent to the 3D animation engine in real time via the data interaction channel, so that the braking parameters are presented synchronously with the deflection attitude of the front wheel component and the rotation attitude of each wheel component.

7. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The method further includes: The synchronization deviation is obtained by comparing the solution timestamp of the simulation model with the frame counter of the 3D animation engine. If the synchronization deviation exceeds a preset synchronization threshold, the animation is caught up by skipping frames or adjusting the playback speed of the expansion and contraction animation, so that the expansion and contraction animation remains synchronized with the real-time solution results of the simulation model.

8. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The data interaction channel is a network channel or a shared memory channel based on the User Datagram Protocol (UDP); the data interaction channel is a bidirectional channel, wherein the motion parameters and the position signal are transmitted from the simulation model to the 3D animation engine, and a frame synchronization signal is transmitted from the 3D animation engine to the simulation model. The frame synchronization signal is used by the simulation model to perform closed-loop verification of the display progress of the 3D animation engine.

9. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The method further includes: If a preset abnormal condition occurs during the retraction and extension process, the 3D animation engine will display the skeletal posture of the component in the landing gear 3D model that is experiencing the preset abnormal condition in a display mode different from the normal condition; wherein, the preset abnormal condition includes component jamming, abnormal retraction and extension speed, or failure to trigger the positioning signal.

10. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The method further includes: The motion parameters and the arrival signal transmitted through the data interaction channel are recorded throughout the process to obtain a test record file. Each record in the test record file includes a timestamp and the motion parameter corresponding to the timestamp. Upon receiving a playback instruction, the test record file is read in chronological order according to the timestamps, and the read motion parameters are resent to the 3D animation engine to reproduce the release animation of the release process through the 3D animation engine.

11. The real-time simulation test method for aircraft landing gear according to claim 1, characterized in that, The simulation step size ranges from 1 millisecond to 10 milliseconds.

12. The real-time simulation test method for aircraft landing gear according to claim 2, characterized in that, The simulation model performs real-time calculations of the take-up and release process based on driving conditions. The driving conditions include the retraction driving condition and the release driving condition; The retraction drive conditions include: receiving a retraction command, the hatch component opening to the correct position, the support component not retracting to the correct position, and the retraction command delay being released. The lowering driving conditions include: receiving a lowering command, the hatch component opening to the correct position, the support component not being lowered to the correct position, and the lowering command delay being released; wherein, the release of the upper command delay and the release of the lowering command delay are performed after a preset filtering time after receiving the corresponding command, in order to prevent command signal jitter.

13. A real-time simulation testing system for aircraft landing gear, characterized in that, It includes a motion control module, a data interaction middleware, and a 3D animation engine module; The motion control module is used to run a simulation model, and to perform real-time calculations on the retraction and extension process of the aircraft landing gear according to the simulation step size, so as to obtain the motion parameters of each component of the landing gear at each simulation step size. The motion parameters are used to characterize the real-time attitude of the corresponding component during the retraction and extension process. The retraction and extension process includes at least two stroke stages executed sequentially, and each stroke stage corresponds to the attitude change of different components of the landing gear. The data interaction middleware connects the motion control module and the 3D animation engine module, and is used to send the motion parameters calculated for each simulation step to the 3D animation engine module in real time. The 3D animation engine module is used to drive the skeletal posture of the components in the landing gear 3D model corresponding to the motion parameters in real time based on the received motion parameters, so as to present the extension and retraction animation synchronized with the real-time solution results of the simulation model on the 3D interface. The motion control module is further configured to generate a positioning signal when the simulation model detects that the positioning condition corresponding to the current travel stage is met; the positioning signal is fed back to the 3D animation engine module via the data interaction middleware to trigger the retraction and extension process to switch from the current travel stage to the next travel stage; wherein, after switching to the next travel stage, the motion control module calculates the motion parameters of the component corresponding to the next travel stage, and the 3D animation engine module drives the skeletal posture of the component corresponding to the next travel stage in the landing gear 3D model based on the motion parameters of the component corresponding to the next travel stage; The 3D interface is also used to display the extension and retraction animation and the data curves drawn based on the motion parameters in parallel, so as to verify the extension and retraction process.

14. The real-time simulation test system for aircraft landing gear according to claim 13, characterized in that, The system also includes a status monitoring and recording module; the status monitoring and recording module is used to bypass and listen to the data transmitted by the data interaction middleware, record the motion parameters and the arrival signal throughout the process, and obtain a test record file. Each record in the test record file includes a timestamp and the motion parameter corresponding to the timestamp. The status monitoring and recording module is also used to read the test record file in the time order of the timestamps when a playback instruction is received, and resend the read motion parameters to the 3D animation engine module to reproduce the release animation of the release process.

15. A real-time simulation testing device for aircraft landing gear, characterized in that, include: The calculation module is used to perform real-time calculations on the retraction and extension process of the aircraft landing gear according to the simulation step size through the simulation model, and obtain the motion parameters of each component of the landing gear at each simulation step size. The motion parameters are used to characterize the real-time attitude of the corresponding component during the retraction and extension process. The retraction and extension process includes at least two stroke stages executed sequentially, and each stroke stage corresponds to the attitude change of different components of the landing gear. The sending module is used to send the motion parameters calculated for each simulation step to the 3D animation engine in real time via a data interaction channel; wherein, the data interaction channel connects the simulation model and the 3D animation engine, and the motion parameters flow from the simulation model to the 3D animation engine in the data interaction channel; The driving module is used to drive the skeletal posture of the component corresponding to the motion parameters in the landing gear 3D model in real time based on the received motion parameters through the 3D animation engine, so as to present the extension and retraction animation synchronized with the real-time solution results of the simulation model on the 3D interface. A switching module is used to generate a positioning signal when the simulation model detects that the positioning condition corresponding to the current travel stage is met, and to feed the positioning signal back to the 3D animation engine through the data interaction channel to trigger the retraction and extension process to switch from the current travel stage to the next travel stage; wherein, after switching to the next travel stage, the calculation module calculates the motion parameters of the component corresponding to the next travel stage, and the driving module drives the skeletal posture of the component corresponding to the next travel stage in the landing gear 3D model based on the motion parameters of the component corresponding to the next travel stage; The display module is used to display the extension and retraction animation and the data curve drawn based on the motion parameters in parallel on the three-dimensional interface to verify the extension and retraction process.

16. The real-time simulation testing device for aircraft landing gear according to claim 15, characterized in that, The sending module includes: The loading unit is used to load the aircraft model parameter configuration file corresponding to the aircraft model. The aircraft model parameter configuration file predefines the mapping rules between the motion parameters of the simulation model and the skeletal nodes of the landing gear three-dimensional model. The mapping rules include the semantic mapping relationship between the motion parameters and the skeletal nodes and the coordinate system transformation rules. The conversion unit is used to convert the motion parameters into the corresponding bone posture parameters of the bone node according to the mapping rules, and send the bone posture parameters to the 3D animation engine in real time through the data interaction channel, so that the 3D animation engine can drive the bone posture of the component to which the bone node belongs based on the bone posture parameters.

17. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the real-time simulation test method for aircraft landing gear as described in any one of claims 1 to 12.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the real-time simulation test method for aircraft landing gear as described in any one of claims 1 to 12.

Images