A full-movement simulator fault self-recovery optimization method, system, electronic device and storage medium

Abstract

The application relates to the technical field of computers and discloses a full-movement simulator fault self-recovery optimization method and system, an electronic device and a storage medium. The method comprises the following steps: collecting multi-dimensional state data, identifying a fault type and locating a root cause, performing cross verification and confirmation through remote display picture and local rendering data comparison, performing hierarchical self-recovery according to the fault type and the severity, backing up configuration, cache and log to support rollback, performing bidirectional connectivity test and link health degree evaluation on network faults, executing adapter reset, driver reload and master / standby link / network port switching and outputting deterioration early warning, grading and caching terrain data according to distance, preloading tiles in combination with flight situation to predict a path range, regularly cleaning the cache and synchronizing with a data source, controlling a start timing based on a node dependency relationship and adjusting parameters in a maintenance mode, training a time sequence feature model based on historical fault data to realize trend early warning and preventive maintenance, and archiving disposal data to update a diagnosis rule and a self-recovery strategy.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a self-healing optimization method, system, electronic device, and storage medium for a full-motion simulator. Background Technology

[0002] Currently, fault detection technology in the field of flight simulators can only achieve simple detection of faults related to 3D maps and can identify fault phenomena, but it does not involve automatic fault self-healing, network redundancy fault tolerance, and data loading optimization. It cannot achieve closed-loop fault handling and relies on manual follow-up repairs.

[0003] The terrain data loading optimization technology only optimizes the single stage of terrain data loading and does not work in conjunction with fault diagnosis and automatic self-healing mechanisms. It cannot solve loading anomalies caused by faults and does not adopt hierarchical caching and flight status preloading strategies, making it difficult to fundamentally solve the problems of missing close-range terrain and loading lag.

[0004] While network redundancy technology in general industrial control fields can achieve dual-link switching, it does not meet the millisecond-level real-time requirements of 3Dmap loading for XR series full-motion simulators, nor does it integrate adaptive repair of network ports and cables and link health warning functions. Therefore, it cannot adapt to the special application scenarios of simulators and is not linked with fault diagnosis and self-healing mechanisms.

[0005] Existing technologies have not yet formed a complete closed-loop control system encompassing "diagnosis—self-healing—optimization—prevention," and their core shortcomings are as follows:

[0006] The system lacks intelligent fault diagnosis and graded self-healing capabilities, relying excessively on manual operation; it also lacks a network redundancy and fault tolerance mechanism adapted to simulator scenarios, resulting in insufficient communication stability.

[0007] The terrain data loading strategy was not optimized for flight scenarios, resulting in poor loading quality and smoothness.

[0008] Without establishing a startup timing coordination and fault prediction mechanism, it is impossible to suppress the occurrence of faults at the source;

[0009] The lack of a self-learning system based on fault knowledge leads to repeated occurrences of similar faults, resulting in high maintenance costs.

[0010] Therefore, this application provides a self-healing optimization method for faults in a full-motion simulator to solve the above-mentioned technical problems. Summary of the Invention

[0011] The purpose of this invention is to provide a self-healing optimization method, system, electronic device, and storage medium for full-motion simulators, in order to solve the comprehensive technical problems in the prior art caused by the lack of intelligent fault diagnosis and hierarchical self-healing mechanism, poor adaptability of network redundancy fault tolerance scheme, coarse terrain data loading strategy, disordered start-up timing of the whole machine, and lack of fault prediction and knowledge base self-learning system. These problems result in the simulator's 3D map faults relying on manual handling, insufficient communication stability, missing close-range terrain and loading lag, high start-up loading failure rate, and repeated occurrence of similar faults.

[0012] To address the aforementioned technical problems, this invention provides a self-healing optimization method for faults in a full-motion simulator, comprising:

[0013] Real-time acquisition of multi-dimensional status data related to 3D map operation; identification of fault types and location of root causes based on preset rules; and confirmation of diagnostic results through cross-validation.

[0014] Based on the fault type and severity, a graded self-healing operation is performed, and rollback protection is implemented during the process.

[0015] When the diagnostic result is a network-related fault, perform dynamic verification and redundancy fault tolerance repair of the network link;

[0016] Terrain data is cached in a hierarchical manner, and terrain tiles are preloaded based on flight status information. At the same time, the cached data is cleaned up regularly and the latest terrain data version is synchronized with the data source.

[0017] The startup sequence is preset based on the dependencies between each startup node. Each node is started sequentially according to the preset startup sequence, and the startup sequence parameters are adjusted when a maintenance mode trigger command is detected.

[0018] A time-series feature model is built based on historical fault data to monitor the changing trends of operating parameters in real time and output early warning signals based on the monitoring results. At the same time, preventive maintenance operations are performed, and fault handling data is archived to update diagnostic rules and self-healing strategies.

[0019] In some specific embodiments, multi-dimensional status data related to 3D map operation are collected in real time, fault types are identified and root causes are located based on preset rules, and the diagnostic results are confirmed through cross-validation. Further steps include:

[0020] Process status data, network status data, and rendering status data are collected at a preset frequency. The process status data includes process running status, loading log, crash flag, and cache usage. The network status data includes connectivity, transmission latency, packet loss rate, and network port light status. The rendering status data includes loading progress, near-field terrain tile loading flag, and rendering frame rate.

[0021] The collected data is matched with preset fault features, and it is determined whether each parameter exceeds the corresponding threshold. When the feature matching degree reaches the preset matching threshold and the parameter deviation does not exceed the preset deviation range, the fault type identifier and root cause location information are output.

[0022] The remote display screen is obtained through a remote display protocol. The rendering status in the remote display screen is compared with the rendering status data collected locally. If they match, the diagnostic result is confirmed. If they do not match, the data is collected again and the diagnosis is performed again.

[0023] The confirmed fault type identifier and root cause location information are used as input data for the graded self-healing operation.

[0024] In some specific embodiments, a graded self-healing operation is performed based on the fault type and severity, and rollback protection is implemented during the execution process, further including:

[0025] In response to process freezes or cache anomalies, a first-level self-healing operation is performed, including terminating the abnormal process, clearing the abnormal cache and rendering context, restarting the process and initiating a map loading request, and checking the fault recovery status. If the fault has not been recovered, a second-level self-healing operation is performed.

[0026] For failures such as ineffective process restart or abnormal configuration, perform a level 2 self-healing operation, including uninstalling relevant components and configuration files, reinstalling components and performing version verification, triggering the re-pushing of terrain index and core terrain tiles, restarting the node and checking the failure recovery status. If the failure is not recovered, perform a level 3 self-healing operation.

[0027] For system-level failures, a three-level self-healing operation is performed, including shutting down the visual system and related computers, resetting the communication link and performing a full-process re-inspection of the link. If the failure is still not resolved after the full-process re-inspection, a unified reset is performed on the basic support node, IOS node and DBW visual computer, and the entire system is restarted according to the preset startup sequence.

[0028] Before performing Level 2 or Level 3 self-healing, the current configuration file, cached data, and fault logs are backed up. If a new fault occurs during the self-healing process, a rollback operation is triggered.

[0029] In some specific embodiments, when the diagnostic result is a network-related fault, dynamic verification and redundancy fault-tolerant repair of the network link are performed, further including:

[0030] Perform a bidirectional connectivity test from the local node to the peer node, record the latency and packet loss rate for each test, and calculate the link health score. The link health score is negatively correlated with the packet loss rate and negatively correlated with the ratio of latency to a preset latency threshold.

[0031] When the link health score is lower than the first preset threshold, a basic link repair operation is performed, including resetting the network adapter, reloading the network card driver, and automatically switching to the backup link. The backup link includes a preset backup network cable, and the link health score is re-detected after the repair.

[0032] When the link health score is still lower than the first preset threshold after the basic link is repaired, the main link network interface is shut down, the backup network interface is enabled, the network parameters of the backup network interface are configured to be consistent with the main link, the route switching is realized, and the switching time is recorded.

[0033] The link health score is monitored in real time. If the score drops more than a second preset threshold within a preset time window, a link degradation warning signal is output.

[0034] In some specific embodiments, terrain data is hierarchically cached, and terrain tiles are preloaded based on flight situation information. Simultaneously, the hierarchically cached data is periodically cleaned and the latest terrain data version is synchronized with the data source. Further steps include:

[0035] The terrain data is classified into different levels according to distance range. Core terrain data within the closest distance range is cached in memory, secondary terrain data within the middle distance range is cached on disk and updated at a preset period, and remote terrain data within the farthest distance range is loaded on demand.

[0036] The system acquires the current flight position, heading, and speed in real time, calculates the predicted flight path range within a preset time period, determines the terrain tiles that need to be preloaded based on the predicted flight path range, and performs preloading in the order of loading core terrain data first and then loading secondary terrain data.

[0037] Terrain tile preloading is performed in the background, and the tiles are prioritized according to their importance to control the rendering frame rate fluctuation during the preloading process to not exceed the preset fluctuation range.

[0038] Clean up unused secondary terrain cache data and remote terrain cache data that have exceeded the preset time period at preset intervals, synchronize the latest terrain data version with the data source, compare the differences between the local cache and the data source, and perform update operations on the data with differences.

[0039] In some specific embodiments, a startup sequence is preset based on the dependencies between startup nodes, and each node is started sequentially according to the preset startup sequence. The startup sequence parameters are adjusted when a maintenance mode trigger command is detected. Further steps include:

[0040] The dependencies between each startup node are preset, and the startup order is determined according to the dependencies. The startup order is as follows: first, the basic support node is started; after the basic support node completes self-check and sends a ready signal, the intermediate node that depends on the basic support node is started; after the intermediate node completes initialization and sends a ready signal, the final dependent node is started.

[0041] During startup, the self-test status and ready signal transmission status of each node are monitored in real time. If any node fails to send a ready signal within the preset node startup time limit, the startup process of all subsequent nodes will be blocked, and a node abnormality warning will be output.

[0042] After all nodes have sent ready signals, send map loading commands to each node.

[0043] When a maintenance mode trigger command is detected, the startup timing parameters are adjusted, including extending the self-test time limit and skipping unnecessary initialization steps.

[0044] In some specific embodiments, a time-series feature model is constructed based on historical fault data to monitor the changing trends of operating parameters in real time and output early warning signals according to the monitoring results. Simultaneously, preventative maintenance operations are performed, and fault handling data is archived to update diagnostic rules and self-healing strategies. Further embodiments include:

[0045] The fault phenomenon, fault type, root cause, handling steps, repair results, occurrence time and operating environment parameters of each fault are continuously recorded to construct a fault feature dataset containing time sequence information. The fault feature dataset is trained using a long short-term memory network algorithm to extract feature parameters of fault occurrence patterns.

[0046] Real-time monitoring of process resource usage fluctuations, network latency jitter, and loading latency trends; inputting the monitoring data into a trained time-series feature model; when the output of the time-series feature model matches the fault characteristics and the parameter changes reach the warning threshold, outputting a warning signal and corresponding handling suggestions.

[0047] Based on the training schedule information, identify the non-training time window, and within the non-training time window, sequentially perform system self-check, cache clearing, link re-verification and data update operations;

[0048] After each fault is resolved, the fault-related data is archived as standardized fault cases. Based on the archived fault cases, the priority of fault diagnosis rules and self-healing strategies is updated using a decision tree algorithm. In addition, externally inputted expert experience data is integrated, and the knowledge base is sorted out and invalid cases are deleted at preset intervals.

[0049] Based on the same concept, the present invention also provides a fault self-healing optimization system for a full-motion simulator, comprising:

[0050] The multidimensional status data acquisition and fault confirmation module is configured to collect multidimensional status data related to 3Dmap operation in real time, identify fault types and locate root causes based on preset rules, and confirm the diagnosis results through cross-validation.

[0051] The graded self-healing operation execution module is configured to perform graded self-healing operations based on the fault type and severity, and to perform rollback protection during the execution process;

[0052] The dynamic verification and redundancy fault tolerance repair module is configured to perform dynamic verification and redundancy fault tolerance repair of the network link when the diagnostic result is a network-related fault.

[0053] The terrain loading and data synchronization module is configured to perform hierarchical caching of terrain data, preload terrain tiles based on flight status information, and periodically clean up the hierarchically cached data and synchronize the latest terrain data version with the data source.

[0054] The node startup and parameter adjustment module is configured to preset a startup sequence based on the dependency relationship between each startup node, start each node sequentially according to the preset startup sequence, and adjust the startup sequence parameters when a maintenance mode trigger command is detected.

[0055] The early warning output and maintenance operation module is configured to build a time-series feature model based on historical fault data, monitor the changing trends of operating parameters in real time, output early warning signals according to the monitoring results, perform preventive maintenance operations, and archive fault handling data to update diagnostic rules and self-healing strategies.

[0056] Based on the same concept, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a full-motion simulator fault self-healing optimization method.

[0057] Based on the same concept, the present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a full-motion simulator fault self-healing optimization method.

[0058] Compared with existing technologies, its advantages are as follows:

[0059] This invention discloses a fault self-healing optimization method, system, electronic device, and storage medium for a full-motion simulator. Through a dual diagnostic algorithm combining multi-dimensional state acquisition, feature matching, and threshold judgment, as well as a cross-validation mechanism, it achieves intelligent fault diagnosis and accurate root cause location. Combined with a three-level hierarchical self-healing strategy and rollback protection, it forms an automatic fault repair closed loop, eliminating reliance on human experience, improving fault handling efficiency, and reducing manual maintenance costs.

[0060] By constructing a primary and backup dual-link redundancy mechanism, real-time verification and dynamic evaluation of link health are achieved. When the primary link is abnormal, it automatically switches to the backup link with a switching time within milliseconds, ensuring uninterrupted communication between the IOS node and the DBW visual computer, thus solving the vulnerability problem of traditional single-link communication.

[0061] By employing a hierarchical caching strategy for terrain data, core terrain data is cached in memory while secondary terrain data is cached on disk and updated periodically. Combined with a pre-loading mechanism based on flight status, this effectively solves the problems of missing close-range terrain data and loading lag, ensuring the realism of simulated flight training.

[0062] By establishing a startup timing collaborative control mechanism based on node dependencies, the system starts up in the order of basic support nodes, intermediate nodes, and final dependent nodes, and monitors the readiness signals of each node in real time. This suppresses 3D map loading failures caused by disordered startup order from the source, thereby improving the startup reliability of the simulator.

[0063] By training historical fault data with a time-series feature model based on the LSTM algorithm, real-time monitoring of operating parameter change trends and early warning of potential faults can be achieved. Combined with preventive maintenance operations within the non-training window, the transformation from "post-fault troubleshooting" to "pre-fault prevention" can be realized, reducing the risk of downtime caused by sudden faults.

[0064] By archiving fault data, updating diagnostic rules and self-healing strategies through decision tree algorithms, and supporting the integration of expert experience and regular iterative optimization, a closed-loop control system of "diagnosis-self-healing-learning-optimization" is formed, which effectively reduces the recurrence rate of similar faults and continuously improves the operational stability of the simulator. Attached Figure Description

[0065] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0066] Figure 1 This is a flowchart illustrating some specific embodiments of the self-healing optimization method for faults in a full-motion simulator according to the present invention;

[0067] Figure 2This is a schematic diagram of the structure of a self-healing optimization system for a full-motion simulator according to some specific embodiments of the present invention;

[0068] Figure 3 This is a schematic diagram of the structure of an electronic device according to some specific embodiments of the present invention;

[0069] In the diagram, 710 is the processor; 720 is the memory; 730 is the input device; and 740 is the output device. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0071] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0072] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0073] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0074] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0075] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0076] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0077] Reference Figure 1 A fault self-healing optimization method for a full-motion simulator, comprising:

[0078] S101 collects multi-dimensional status data related to 3Dmap operation in real time, identifies fault types and locates root causes based on preset rules, and confirms diagnostic results through cross-validation.

[0079] S102, perform graded self-healing operation according to the fault type and severity, and perform rollback protection during the execution process;

[0080] S103, when the diagnostic result is a network-related fault, perform dynamic verification and redundancy fault tolerance repair of the network link;

[0081] S104 performs hierarchical caching of terrain data, preloads terrain tiles based on flight status information, and periodically cleans up the hierarchically cached data and synchronizes the latest terrain data version with the data source.

[0082] S105, based on the dependency relationship between each startup node, a startup sequence is preset, each node is started sequentially according to the preset startup sequence, and the startup sequence parameters are adjusted when a maintenance mode trigger command is detected;

[0083] S106 constructs a time-series characteristic model based on historical fault data, monitors the changing trends of operating parameters in real time, outputs early warning signals based on the monitoring results, performs preventive maintenance operations, and archives fault handling data to update diagnostic rules and self-healing strategies.

[0084] Specifically, in this embodiment of the invention, multi-dimensional status data related to the operation of the 3D map is collected in real time at preset time intervals, including process status data, network status data, and rendering status data. The process status data covers the running status of the 3D map process, exception markers and crash markers in the loading log, and cache usage; the network status data covers the connectivity, transmission latency, packet loss rate, and network port status of the communication link between the IOS node and the DBW visual computer; and the rendering status data covers the 3D map loading progress, loading markers of nearby terrain tiles, and rendering frame rate. After collection, the collected multi-dimensional data is input into a preset rule engine. This rule engine employs a dual diagnostic algorithm combining feature matching and threshold judgment. It matches the real-time collected data features with preset fault feature models and simultaneously determines whether each parameter exceeds the corresponding preset threshold. When the feature matching degree reaches the preset matching threshold and the parameter deviation does not exceed the preset deviation range, the fault type is automatically identified and the root cause is located. To avoid misdiagnosis due to display delay or acquisition errors, the remote display screen of the iOS node is further obtained through a remote display protocol. The rendering status in this remote display screen is compared with the locally acquired rendering status data. If they match, the diagnostic result is confirmed; otherwise, data is re-acquired and the diagnosis is repeated. After confirming the diagnostic result, a graded self-healing operation is performed based on the diagnosed fault type and its severity. The tiered self-healing system comprises three levels: Level 1 self-healing is suitable for minor faults such as process freezes, minor loading anomalies, and dirty cached data. It achieves rapid recovery by terminating the abnormal process, clearing the abnormal cache and rendering context, restarting the process, and initiating a map loading request. If the fault is not recovered, it automatically upgrades to Level 2 self-healing. Level 2 self-healing is suitable for moderate faults such as ineffective process restarts and configuration anomalies. It achieves recovery by uninstalling relevant components and configuration files, reinstalling components and performing version verification, triggering the data source to re-push terrain indexes and core terrain tiles, and restarting nodes. If the fault is not recovered, it automatically upgrades to Level 3 self-healing. Level 3 self-healing is suitable for severe system-level faults. It achieves recovery by shutting down the visual system and related computers, resetting communication links and performing a full link re-check. If necessary, it performs a unified reset of all system nodes and restarts the entire system according to a preset startup sequence. Before performing Level 2 or Level 3 self-healing, the system automatically backs up the current configuration files, cached data, and fault logs. If a new fault occurs during the self-healing process, a rollback operation is triggered to restore the system to the state at the time of backup.When the diagnosis result is a network-related fault, dynamic verification and redundancy fault-tolerant repair of the network link are performed. Specifically, this includes performing bidirectional connectivity tests from the local node to the peer node, recording the latency and packet loss rate for each test, and calculating the link health score based on the deviation of the packet loss rate and latency from the preset latency threshold. When the link health score is lower than the first preset threshold, basic repair operations such as resetting the network adapter, reloading the network card driver, and automatically switching to the backup link are performed. After the repair, the link health score is rechecked. If it is still lower than the first preset threshold, the primary link network port is automatically shut down and the backup network port is enabled. The network parameters of the backup network port are configured to be consistent with the primary link to achieve route switching. At the same time, the continuous changes in the link health score are monitored in real time. If the score drops more than the second preset threshold within a preset time window, a link degradation warning signal is output. Regarding data loading, terrain data is cached in a tiered manner. Terrain data within the closest range to the aircraft is used as core terrain data and cached in memory. Terrain data within the intermediate range is used as secondary terrain data and cached on disk, updated at a preset period. Terrain data within the furthest range is used as remote terrain data and loaded on demand. Simultaneously, the aircraft's current flight position, heading, and speed are acquired in real time to calculate the predicted flight path range within a preset time period. Based on this range, the terrain tiles that need to be preloaded are determined. Preloading is performed in the background in the order of loading core terrain data first, followed by secondary terrain data, and the tiles are prioritized according to their importance to control the rendering frame rate fluctuation during the preloading process to not exceed a preset fluctuation range. Furthermore, secondary terrain cache data and remote terrain cache data that have not been used for a preset time period are cleaned up at preset periods, and the latest terrain data version is synchronized with the data source. The differences between the local cache and the data source are compared, and update operations are performed on the data with discrepancies. In terms of startup control, a startup sequence is preset based on the dependencies between startup nodes. The basic support node is started first. After the basic support node completes its self-check and sends a ready signal, the intermediate nodes that depend on the basic support node are started. After the intermediate nodes complete their initialization and send a ready signal, the final dependent node is started. Throughout the startup process, the self-check status and ready signal sending status of each node are monitored in real time. If any node fails to send a ready signal within the preset node startup time limit, the startup process of all subsequent nodes is blocked and a node anomaly warning is output. After all nodes have sent ready signals, a map loading command is sent to all nodes in a unified manner. When a maintenance mode trigger command is detected, the startup sequence parameters are adjusted, including extending the self-check time limit and skipping unnecessary initialization steps.In terms of fault prediction and knowledge management, the system continuously records the fault phenomenon, fault type, root cause, handling steps, repair results, occurrence time, and operating environment parameters for each fault, constructing a fault feature dataset containing time-series information. This dataset is then trained using a Long Short-Term Memory (LSTM) network algorithm to extract feature parameters indicating fault occurrence patterns. Real-time monitoring of process resource usage fluctuations, network latency jitter, and loading latency trends is conducted. This monitoring data is input into the trained time-series feature model. When the model output matches the fault features and parameter changes reach the warning threshold, a warning signal and corresponding handling suggestions are output. Non-training time windows are identified based on training schedule information. Within these windows, system self-checks, cache clearing, link re-verification, and data update operations are performed sequentially. After each fault handling is completed, fault-related data is archived as standardized fault cases. Based on these archived cases, a decision tree algorithm is used to update the priority of fault diagnosis rules and self-healing strategies. Externally inputted expert experience data is also integrated, and the knowledge base is periodically reviewed and invalid cases are deleted.

[0085] In some applications, multi-dimensional status data related to 3D map operation are collected in real time. Fault types are identified and root causes are located based on preset rules, and diagnostic results are confirmed through cross-validation. This includes collecting process status data, network status data, and rendering status data at preset frequencies. The process status data includes process running status, loading logs, crash markers, and cache usage. The network status data includes connectivity, transmission latency, packet loss rate, and network port status. The rendering status data includes loading progress, near-field terrain tile loading markers, and rendering frame rate. The collected data is matched with preset fault features, and it is determined whether each parameter exceeds a corresponding threshold. When the feature matching degree reaches the preset matching threshold and the parameter deviation does not exceed the preset deviation range, a fault type identifier and root cause location information are output. A remote display screen is obtained through a remote display protocol, and the rendering status in the remote display screen is compared with the locally collected rendering status data. If they match, the diagnostic result is confirmed; if they do not match, data is collected again and the diagnosis is repeated. The confirmed fault type identifier and root cause location information are used as input data for a tiered self-healing operation.

[0086] Understandably, multi-dimensional status data related to the 3Dmap operation is collected in real time at preset time intervals, specifically including process status data, network status data, and rendering status data. Process status data covers the running status of the 3Dmap process, exception markers and crash markers in the loading log, and cache usage; network status data covers the connectivity, transmission latency, packet loss rate, and network port status of the communication link between the IOS node and the DBW visual computer; rendering status data covers the 3Dmap loading progress, loading markers of nearby terrain tiles, and rendering frame rate. After collection, the collected multi-dimensional data is input into a preset rule engine. This rule engine employs a dual diagnostic algorithm combining feature matching and threshold judgment. It matches the real-time collected data features with preset fault feature models and simultaneously determines whether each parameter exceeds the corresponding preset threshold. When the feature matching degree reaches the preset matching threshold and the deviation of each parameter does not exceed the preset deviation range, the corresponding fault type identifier and root cause location information are automatically output. To avoid misjudgments due to display delays or acquisition errors, a remote display screen of the iOS node is obtained via a remote display protocol. The rendering status in this remote display screen is compared with the locally acquired rendering status data. If they match, the diagnostic result is confirmed; otherwise, data is re-acquired and the above diagnostic process is repeated. The confirmed fault type identifier and root cause location information serve as input data for subsequent graded self-healing operations, triggering the corresponding self-healing strategy.

[0087] In some applications, tiered self-healing operations are performed based on the type and severity of the fault, with rollback protection implemented during the process. These include: Level 1 self-healing for process freezes or cache anomalies, which involves terminating the abnormal process, clearing the abnormal cache and rendering context, restarting the process and initiating a map loading request, and checking the fault recovery status; if the fault is not recovered, Level 2 self-healing is performed. Level 2 self-healing for ineffective process restarts or configuration anomalies, which involves uninstalling relevant components and configuration files, reinstalling components and performing version verification, triggering a re-push of terrain indexes and core terrain tiles, restarting nodes and checking the fault recovery status; if the fault is not recovered, Level 3 self-healing is performed. Level 3 self-healing for system-level faults, which involves shutting down the visual system and related computers, resetting communication links and performing a full-process re-inspection of the links; if the fault is still not recovered after the full-process re-inspection, a unified reset is performed on the basic support nodes, IOS nodes, and DBW visual computers, and the entire system is restarted according to a preset startup sequence. Before performing Level 2 or Level 3 self-healing, the current configuration files, cached data, and fault logs are backed up; if a new fault occurs during the self-healing process, a rollback operation is triggered.

[0088] Understandably, based on the fault type identifier and root cause location information output by the fault diagnosis steps, the severity level of the fault is determined, and corresponding graded self-healing operations are performed. For minor faults such as process freezes, minor loading anomalies, or dirty cached data, a Level 1 self-healing operation is performed: the process management interface is called to forcibly terminate the abnormal process and release the system resources occupied by the abnormal process; the abnormal cache and rendering context are cleaned up to prevent dirty data from affecting subsequent loading; the process is restarted and a map loading request is initiated, and terrain data loading instructions from the data source are obtained synchronously; after completing the above operations, the fault recovery status is checked. If all operating indicators return to normal, self-healing is complete; if the fault is still not recovered, it is automatically upgraded to Level 2 self-healing. For moderate faults such as ineffective process restart, corrupted map resources, or abnormal node configuration, a Level 2 self-healing operation is performed: the relevant components and configuration files are uninstalled, and abnormal data and corrupted resources inside the node are cleaned up; the relevant components are reinstalled, and the latest configuration files are obtained from the data source to perform version verification to ensure version consistency; the data source is triggered to re-push terrain index data and core terrain tiles to ensure data integrity; the node is restarted and the fault recovery status is checked. If the recovery is normal, self-healing is complete; if the fault is still not recovered, it is automatically upgraded to Level 3 self-healing. For severe system-level failures such as visual computer malfunctions, complete communication link interruptions, or multi-node collaborative failures, a three-level self-healing operation is performed: The visual system and related computers are shut down; the communication link is reset and a full-process re-inspection is performed, checking for potential faults in network ports, network cables, and network card drivers; if the fault is still not resolved after the full-process re-inspection, a unified reset is performed on all system nodes, including basic support nodes, IOS nodes, and DBW visual computers, restoring them to their initial state; the entire system is then restarted according to the preset startup sequence to complete self-healing. Before performing level two or level three self-healing, the current configuration files, cached data, and fault logs are automatically backed up. If new faults occur during the self-healing process, causing nodes to fail to start or data loss, the fault escalates, and a rollback operation is automatically triggered to restore the system to the state at the time of backup, preventing further deterioration of the fault.

[0089] In some applications, when the diagnostic result is a network-related fault, dynamic verification and redundancy fault-tolerant repair of the network link are performed. This includes performing bidirectional connectivity tests from the local node to the peer node, recording the latency and packet loss rate for each test, and calculating a link health score. The link health score is negatively correlated with the packet loss rate and negatively correlated with the ratio of latency to a preset latency threshold. When the link health score is lower than a first preset threshold, basic link repair operations are performed, including resetting the network adapter, reloading the network card driver, and automatically switching to a backup link. The backup link includes a preset backup network cable, and the link health score is re-checked after repair. If the link health score is still lower than the first preset threshold after basic link repair, the primary link network port is shut down, the backup network port is enabled, the network parameters of the backup network port are configured to be consistent with the primary link, route switching is achieved, and the switching time is recorded. The continuous change of the link health score is monitored in real time. If the score decreases by more than a second preset threshold within a preset time window, a link degradation warning signal is output.

[0090] Understandably, when the fault diagnosis steps output network-related faults, dynamic verification and redundancy fault-tolerance repair of the network links are performed. A bidirectional connectivity test is performed from the local node to the peer node, recording the transmission latency and packet loss rate for each test, and calculating a link health score based on the test results. This link health score is calculated as follows: the link health score is negatively correlated with the packet loss rate and negatively correlated with the ratio of transmission latency to a preset latency threshold; that is, the higher the packet loss rate or the larger the ratio of transmission latency to the preset latency threshold, the lower the link health score. The calculated link health score is compared with a first preset threshold. When the link health score is lower than the first preset threshold, basic link repair operations are performed. Basic link repair operations include resetting the network adapter to release the resources occupied by the network adapter, reloading the network card driver to repair link problems caused by driver anomalies, and automatically switching to a backup link. This backup link includes a preset backup network cable to ensure that no manual replacement of the network cable is required during link switching. After the basic link repair is completed, the bidirectional connectivity test is re-executed and the link health score is recalculated. If the link health score remains below the first preset threshold after repair, it indicates that the primary link is still abnormal. The primary link's network interface is automatically shut down, and the backup network interface is activated. The backup interface's network parameters are configured to match those of the primary link, including IP address, subnet mask, and gateway, ensuring it is on the same local area network as the peer node and achieving seamless route switching. The switching time is recorded. Throughout the operation, the continuous trend of the link health score is monitored in real time. If the link health score drops more than the second preset threshold within a preset time window, it indicates a link degradation trend, and a link degradation warning signal is output to remind maintenance personnel to promptly investigate potential link faults.

[0091] In some applications, terrain data is hierarchically cached, and terrain tiles are preloaded based on flight status information. Simultaneously, the hierarchically cached data is periodically cleaned up, and the latest terrain data version is synchronized with the data source. This includes classifying terrain data by distance range, using a persistent memory cache for core terrain data within the closest distance range, a disk cache for secondary terrain data within the intermediate distance range updated at a preset period, and an on-demand loading mode for distant terrain data within the farthest distance range. The current flight position, heading, and speed are acquired in real-time, and the predicted flight path range within a preset time period is calculated. Based on the predicted flight path range, the terrain tiles to be preloaded are determined, and preloading is performed in the order of loading core terrain data first, followed by secondary terrain data. Terrain tile preloading is performed in the background, prioritizing tiles according to their importance, and controlling the rendering frame rate fluctuation during preloading to not exceed a preset fluctuation range. Secondary terrain cache data and distant terrain cache data that have not been used for a preset period are cleaned up at preset periods, and the latest terrain data version is synchronized with the data source. Differences between the local cache and the data source are compared, and updates are performed on data with discrepancies.

[0092] Understandably, terrain data is processed using a tiered caching system, dividing it into three levels based on its distance from the aircraft: For terrain data within the closest range, it is treated as core terrain data and cached in memory to ensure its constant availability in real-time; for terrain data within the intermediate range, it is treated as secondary terrain data and cached on disk, updated at preset intervals to guarantee fast loading; for terrain data within the farthest range, it is treated as remote terrain data and loaded on demand, only initiating loading just before the aircraft enters the area to avoid excessive system resource consumption. Based on this tiered caching, the aircraft's current flight position, heading, and speed are acquired in real-time. The predicted flight path range within a preset timeframe is calculated using this data, obtained by multiplying the flight speed by the preset timeframe and combining it with an altitude correction factor. The terrain tiles to be pre-loaded are determined based on the predicted flight path range, and pre-loading is performed in the order of loading core terrain data first, followed by secondary terrain data. The preloading process runs in the background, prioritizing terrain tiles based on their importance and loading the core terrain tiles that have the greatest impact on the current flight training first. Simultaneously, resource consumption during preloading is controlled to ensure that rendering frame rate fluctuations do not exceed a preset range, preventing stuttering during the normal rendering of the current 3D map. Cache optimization and data synchronization operations are performed at preset intervals. Specifically, this includes cleaning up unused secondary terrain cache data and remote terrain cache data that have exceeded a preset time to free up cache space; simultaneously, synchronizing the latest terrain data version with the data source; comparing the differences between local cache data and data from the data source; and updating any dirty or missing data to prevent loading anomalies caused by data inconsistency.

[0093] In some applications, a startup sequence is preset based on the dependencies between startup nodes. Each node is started sequentially according to this preset sequence, and the startup sequence parameters are adjusted when a maintenance mode trigger command is detected. This includes pre-setting the dependencies between startup nodes and determining the startup order according to these dependencies. The startup order is as follows: first, the basic support node is started; after the basic support node completes its self-check and sends a ready signal, the intermediate nodes that depend on the basic support node are started; after the intermediate nodes complete initialization and send a ready signal, the final dependent node is started. During startup, the self-check status and ready signal sending status of each node are monitored in real time. If any node fails to send a ready signal within a preset node startup time limit, the startup process of all subsequent nodes is blocked, and a node anomaly warning is output. After all nodes have sent ready signals, a map loading command is sent to each node. When a maintenance mode trigger command is detected, the startup sequence parameters are adjusted, including extending the self-check time limit and skipping unnecessary initialization steps.

[0094] Understandably, the dependencies between nodes are predefined, and the preconditions for each node's startup are clearly defined. Basic support nodes provide fundamental support to other nodes and do not depend on any other nodes; intermediate nodes can only start after the basic support nodes have completed their startup; and final dependent nodes can only start after the intermediate nodes have completed their startup. Based on these dependencies, the startup order is determined as follows: start the basic support nodes; after the basic support nodes complete their self-check and send a ready signal, start the intermediate nodes that depend on the basic support nodes; after the intermediate nodes complete their initialization and send a ready signal, start the final dependent nodes. Throughout the startup process, the self-check status and ready signal sending status of each node are monitored in real time. If any node fails to send a ready signal within the preset node startup time limit, the startup process of all subsequent nodes is blocked, and a node anomaly warning is output, prompting maintenance personnel to investigate the node's anomaly. After all nodes have sent ready signals, a map loading command is sent to all nodes to ensure that there are no missing dependencies during the loading process. In addition, it supports maintenance mode adaptation. When a maintenance mode trigger command is detected, the startup timing parameters are automatically adjusted. Specifically, this includes extending the self-test time limit of each node and skipping some unnecessary initialization steps to adapt to the needs of maintenance and repair scenarios and reduce startup failures caused by human error.

[0095] In some applications, a time-series feature model is built based on historical fault data to monitor the changing trends of operating parameters in real time and output early warning signals based on the monitoring results. Preventive maintenance operations are performed simultaneously, and fault handling data is archived to update diagnostic rules and self-healing strategies. This includes continuously recording the fault phenomenon, fault type, root cause, handling steps, repair results, occurrence time, and operating environment parameters for each fault. A fault feature dataset containing time-series information is constructed, and a Long Short-Term Memory (LSTM) network algorithm is used to train the fault feature dataset to extract feature parameters indicating fault occurrence patterns. Real-time monitoring of process resource usage fluctuations, network latency jitter, and loading latency trends is also conducted. The monitoring data is input into the trained time-series feature model. When the output of the time-series feature model matches the fault characteristics and the parameter change reaches the warning threshold, a warning signal and corresponding handling suggestions are output. Non-training time windows are identified according to the training schedule information. During the non-training time windows, system self-check, cache clearing, link re-verification, and data update operations are performed sequentially. After each fault handling is completed, the fault-related data is archived as standardized fault cases. Based on the archived fault cases, the priority of fault diagnosis rules and self-healing strategies is updated using a decision tree algorithm. Externally inputted expert experience data is also integrated, and the knowledge base is sorted out and invalid cases are deleted at a preset period.

[0096] Understandably, a fault prediction model is constructed by continuously recording complete information for each fault occurrence, including fault phenomena, fault type, root cause analysis results, handling steps, repair results, fault occurrence time, and operating environment parameters. All recorded data is then used to build a fault feature dataset containing time-series information. Based on this, a Long Short-Term Memory (LSTM) network algorithm is used to train this fault feature dataset. This algorithm, through a recurrent neural network structure with multiple hidden layers, learns the patterns of change in various operating parameters over time before a fault occurs, extracts feature parameters closely related to the fault occurrence, and forms a time-series feature model capable of identifying fault precursors. During real-time operation, key operating parameters such as process resource usage fluctuations, network latency jitter, and loading latency trends are continuously monitored. The monitored real-time data is input into the trained time-series feature model. The model performs feature extraction and pattern matching on the input data. When the model output matches known fault characteristics and the change in monitored parameters reaches a preset warning threshold, a warning signal is output, along with the corresponding potential fault type and preliminary handling suggestions. In terms of preventative maintenance, the system automatically identifies non-training time windows based on the simulator's training schedule information, such as nighttime or weekend periods without training tasks. Within these identified non-training windows, preventative maintenance operations such as system self-checks, cache clearing, link re-verification, and data updates are performed sequentially to proactively identify and eliminate potential faults. Regarding knowledge base self-learning, after each fault handling process, whether through automatic self-healing or manual intervention, the relevant data is archived as standardized fault cases, forming a unified fault case library. Based on these archived fault cases, a decision tree algorithm is used to update fault diagnosis rules. By analyzing the correlation between different fault characteristics and diagnostic results, diagnostic rule branches are automatically generated or optimized. Simultaneously, the execution priority of self-healing strategies is dynamically adjusted based on the frequency of occurrence and self-healing success rate of various fault types. Furthermore, maintenance personnel can input expert experience data through maintenance terminals, integrating diagnostic methods for new faults, optimized self-healing steps, or handling techniques for special scenarios into the fault knowledge base, merging them with the automatically learned content. The knowledge base is reviewed at preset intervals, invalid cases are deleted, and the diagnostic rules and self-healing steps of valid cases are updated to continuously improve the accuracy of fault diagnosis and self-healing.

[0097] The following describes another embodiment of the fault self-healing optimization method for a full-motion simulator according to the present invention:

[0098] This embodiment includes:

[0099] Multi-dimensional real-time status acquisition and intelligent fault diagnosis:

[0100] Data Acquisition: The system deploys an embedded data acquisition module to collect three types of key data related to 3D map operation between the IOS node and the DBW visual computer in real time. The acquisition frequency is set to 1 time / second to build a unified fault characteristic model. The acquired data specifically includes:

[0101] Process status data includes the running status of the iOS 3Dmap process (running / stopped / unresponsive), loading logs (loading progress, error codes, exception markers), crash markers (whether the process crash was triggered, crash timestamp), and cache usage (current cache usage, cache threshold, preset to 30% of iOS node memory).

[0102] Network status data includes connectivity of the ETH3 network interface between the IOS node and the DBW visual computer, ping latency (threshold set to 50ms, exceeding the threshold is considered a network anomaly), packet loss rate (threshold set to 1%, exceeding the threshold is considered a network anomaly), and network port light status (normal flashing / constant on / off).

[0103] Rendering status data includes 3D map loading progress (0%-100%), terrain tile loading markers within 5 nautical miles (loaded / not loaded / loading error), and rendering frame rate (threshold set to 30fps, below which is considered a rendering error).

[0104] Fault Diagnosis: Based on the collected multi-dimensional data, the fault type and root cause are automatically identified through a preset rule engine. The rule engine adopts a dual diagnostic algorithm of "feature matching + threshold judgment". The algorithm parameters are set as follows: feature matching threshold ≥ 95%, threshold judgment deviation ≤ 5%. The specific diagnostic logic is as follows:

[0105] If the iOS 3Dmap process is found to be unresponsive, has no output, and has a rendering frame rate of 0fps, and there are no valid loading records in the loading log, it is determined to be a 3Dmap black screen failure, the root cause of which is a process freeze or crash.

[0106] If the 3Dmap loading progress is detected to remain in the "MAP is loading" state for a long time (more than 30 seconds), and the process status is running, the network ping latency is normal, and the packet loss rate is 0, it is determined to be a loading blocking failure. The root cause is abnormal terrain data loading request or dirty cached data.

[0107] If the 3D map is detected to be loaded (loading progress 100%), but the terrain tiles within 5 nautical miles are marked as not loaded or loading abnormally, and the network ping latency exceeds 50ms or the packet loss rate exceeds 1%, it is determined to be a terrain data distribution / network jitter failure, the root cause of which is abnormal network link or terrain data push failure.

[0108] If the network ping latency is detected to be more than 100ms, the packet loss rate is more than 5%, or the network port light is constantly on / off, it is determined to be a network link failure. The root cause is network port failure, loose network cable, or abnormal network card driver.

[0109] Cross-validation: To avoid misjudgments caused by display delays and data acquisition errors, the system supports cross-validation between VNC remote status and local status. That is, the 3D map display screen of the IOS node is obtained remotely via VNC and compared with the rendering status data collected locally. If the two are consistent, the fault diagnosis result is confirmed. If they are inconsistent, the data is re-collected and the diagnosis is repeated to ensure the accuracy of fault diagnosis.

[0110] Automatic self-healing based on fault severity level:

[0111] Level 1 self-healing (lightweight, second-level self-healing): Suitable for minor faults such as process freezes, minor loading anomalies, and dirty cached data. Self-healing response time is ≤5 seconds. Specific steps:

[0112] The system automatically calls the process management interface to forcibly terminate the abnormal IOS 3Dmap process and release the system resources occupied by the process;

[0113] Automatically clean up abnormal 3Dmap caches (including temporary caches and expired caches) and rendering contexts on iOS nodes to prevent dirty data from affecting reloading;

[0114] Restart the IOS 3Dmap process, initiate a map loading request, synchronously obtain terrain data loading instructions from the DBW visual computer, and complete the 3Dmap reloading;

[0115] After loading is complete, the rendering frame rate and the loading status of nearby terrain are checked. If they return to normal, the self-healing is complete. If they are still abnormal, the self-healing is automatically upgraded to level two.

[0116] Level 2 self-healing (node-level, minute-level self-healing): Applicable to moderate faults such as ineffective process restart, corrupted map resources, and abnormal iOS node configuration. Self-healing response time is ≤3 minutes. Specific steps:

[0117] The system automatically uninstalls 3Dmap-related components and configuration files from the iOS node, and cleans up abnormal data and corrupted resources within the node.

[0118] Reinstall the 3Dmap component on the IOS node, synchronously obtain the latest visual configuration file from the DBW visual computer, and perform version verification (verification algorithm: MD5 verification, verification deviation ≤ 0.01%) to ensure that the 3Dmap version of the IOS node and the DBW visual computer are consistent.

[0119] Trigger the DBW visual computer to re-push terrain index data and core terrain tiles to ensure data integrity;

[0120] Restart the iOS node, reload 3Dmap, and check various operating metrics. If the self-healing process returns to normal, it is complete. If it is still abnormal, it will automatically upgrade to Level 3 self-healing.

[0121] Level 3 self-healing (system-level self-healing): Applicable to system-level faults, such as severe faults like DBW visual computer malfunctions, complete communication link interruptions, and multi-node collaborative failures. Self-healing response time is ≤10 minutes. Specific steps:

[0122] The system automatically shuts down the visual system and DBW visual computer, resets the communication link between the IOS node and the DBW visual computer, and releases system-level resources;

[0123] The linkage network module performs a full-process re-inspection of the link to check for potential faults in network ports, network cables, network card drivers, etc.

[0124] If necessary, perform a unified reset on all system nodes (including S1 rack computers, IOS nodes, and DBW vision computers) to restore the system to its initial state;

[0125] The entire system restarts according to the preset startup sequence, reloads 3Dmap, and completes self-healing.

[0126] Self-healing rollback protection: During the level 2 and level 3 self-healing processes, the system automatically backs up the configuration files, cached data and fault logs of the current IOS node. If the fault escalates during the self-healing process (such as the node failing to start or data loss), a rollback operation is automatically triggered to restore the state before self-healing, thus preventing the fault from worsening further.

[0127] IOS-DBW Network Link Dynamic Verification and Redundancy Fault Tolerance Repair:

[0128] Link status verification: Automatically perform bidirectional connectivity test by pinging the DBW visual computer on the IOS node. The test packet size is set to 1024 bytes, and the number of tests is 10. Record the latency and packet loss rate of each test, and calculate the link health score (score = (1 - packet loss rate) × (1 - latency / threshold) × 100, threshold is 50ms). A score ≥80 indicates a normal link, 60-79 indicates a degraded link, and <60 indicates an abnormal link.

[0129] Basic link repair: If the link health score is <60 (link abnormal), the system will automatically perform basic repair operations:

[0130] Reset the network adapters of the IOS node and the DBW visual computer to release the resources occupied by the network adapters;

[0131] Reload the network card driver to fix the link problem caused by driver abnormality;

[0132] Automatically switch to backup network cables (the system has two backup network cables pre-set). The two backup network cables correspond to the ETH3 main link and the ETH4 backup link respectively, ensuring that the network cables do not need to be manually replaced when switching links. The link health is re-checked, and if the score is ≥80, the repair is complete.

[0133] Redundant link switching: If the link health score is still <60 points after the basic link is repaired (the main link ETH3 is still abnormal), the system will automatically switch to the backup ETH network interface (such as ETH4) and perform the following operations:

[0134] Automatically shut down the primary ETH3 network interface and enable the backup ETH4 network interface;

[0135] Automatically configure the IP address, subnet mask, and gateway of the backup network port to ensure consistency with the main link network parameters. The IP address can be flexibly configured according to the actual network environment of the simulator and must be on the same local area network as the DBW visual computer to achieve seamless routing switching.

[0136] After the switch is complete, re-execute the link connectivity test to confirm that the link is normal and ensure uninterrupted communication between the IOS node and the DBW visual computer, with a switch time of ≤100ms.

[0137] Link health warning: The system monitors the link health status in real time. If the link health score continues to decline (e.g., a drop of more than 20 points within 10 minutes), an early warning signal will be issued (via a pop-up window and sound prompt on the simulator maintenance terminal, with a prompt volume of 80dB) to remind maintenance personnel to promptly investigate potential link faults and avoid complete link interruption.

[0138] 3D terrain data intelligent caching and preloading optimization:

[0139] Tiered terrain data caching: The system categorizes 3D terrain data according to the flight scene range and employs different caching strategies to ensure fast loading of core terrain data.

[0140] Core terrain data: Terrain data within a range of 0–5 nautical miles, using a high-speed cache (memory cache) resident mode, with the cache capacity set to 30% of the iOS node's memory, to ensure that close-range terrain data is available in real time and to avoid missing close-range terrain data;

[0141] Secondary terrain data: Terrain data within a range of 5–20 nautical miles, using a hard disk cache mode with a cache capacity of 100GB, updated regularly (once per hour) to ensure fast loading of mid-range terrain data;

[0142] Remote terrain data: Terrain data beyond 20 nautical miles is loaded on demand, only starting to load 10 minutes before the simulator flies to the area, to avoid consuming too many system resources.

[0143] Terrain data preloading: The system acquires real-time flight status data such as the simulator's current flight position (latitude, longitude, altitude), heading, and flight speed. A preloading algorithm is used to preload terrain tiles along the flight path. The preloading algorithm employs an improved greedy algorithm with the following parameters: iteration count = 100, learning rate = 0.01. The specific algorithm logic is as follows:

[0144] Based on the simulator's current flight speed and altitude, calculate the flight path range within the next 5 minutes (predicted flight distance = flight speed × 5 minutes, altitude correction factor = 0.8).

[0145] Based on the predicted flight path range, determine the range of terrain tiles that need to be preloaded, prioritize preloading core terrain data (0–5 nautical miles), and then preload secondary terrain data (5–20 nautical miles).

[0146] During the preloading process, a "background loading + priority sorting" mechanism is adopted to ensure that the normal rendering of the current 3D map is not affected and that the loading process is smooth (rendering frame rate fluctuation ≤ 5fps).

[0147] Cache optimization and data synchronization: The system regularly (every 30 minutes) cleans up expired cache (secondary and remote terrain cache data that has not been used for more than 24 hours) to free up cache space; at the same time, it automatically synchronizes the latest terrain data version of the DBW visual computer, compares the differences between local cache data and DBW data, and updates dirty and missing data in a timely manner to prevent loading anomalies caused by data inconsistency.

[0148] Overall startup timing coordination control and preventive optimization:

[0149] Startup Sequence Planning: The system presets startup sequence rules. Based on the dependencies between nodes (the S1 rack computer provides basic support for the IOS node and the DBW visual computer; the IOS node depends on the S1 rack computer; and the DBW visual computer depends on the IOS node), the optimal startup order is determined as follows:

[0150] Phase 1: Power on and start all S1 rack computers, and perform self-test operations on the S1 rack computers (including hardware self-test, software self-test, and network connectivity self-test). After the self-test is completed, the S1 rack computers send a "ready signal" to the system.

[0151] Phase 2: After the system receives the "ready signal" from all S1 rack computers, it starts the IOS node computer and performs the IOS node's self-test and initialization operations (including 3Dmap component initialization, network configuration initialization, and cache initialization). After initialization is complete, the IOS node sends a "ready signal" to the system.

[0152] Phase 3: After receiving the "ready signal" from the IOS node, the system finally starts the DBW visual computer, performs the DBW visual computer's self-test and terrain data loading initialization operation, and after initialization is completed, the DBW visual computer sends a "ready signal" to the system.

[0153] Phase 4: After receiving the "ready signal" from all nodes (S1 rack, IOS, DBW), the system sends a 3Dmap loading command to the IOS node and the DBW visual computer to execute the unified 3Dmap loading, ensuring that there are no dependencies or missing components during the loading process.

[0154] Startup Status Monitoring: Throughout the startup process, the system monitors the startup status and self-test results of each node in real time. If a node fails to complete its self-test and send a "ready signal" within the preset time (S1 rack ≤ 5 minutes, IOS node ≤ 3 minutes, DBW visual computer ≤ 5 minutes), the system will block the startup process of subsequent nodes and issue an early warning signal to remind maintenance personnel to check for abnormalities in that node, thus avoiding subsequent loading failures due to a node not being ready.

[0155] Maintenance mode adaptation: The system supports automatic triggering of the optimal startup process in maintenance mode. When the simulator enters maintenance mode (such as weekly or monthly inspection), the system automatically identifies the maintenance scenario (triggered by inputting commands through the maintenance terminal) and adjusts the startup timing parameters (such as extending the self-test time to 10 minutes and skipping some unnecessary initialization steps) to reduce startup failures caused by human error and improve maintenance efficiency.

[0156] Fault prediction and preventive maintenance:

[0157] Historical data acquisition and modeling: The system continuously records all fault data (including fault phenomena, fault types, root causes, handling steps, repair results, fault occurrence time, and operating environment parameters), constructs a fault time-series feature model, and uses the LSTM (Long Short-Term Memory) algorithm to train the historical data. The LSTM algorithm parameters are set as follows: number of hidden layers = 3 layers, number of hidden units = 128, number of iterations = 500, learning rate = 0.001, batch size = 32, to mine the patterns and characteristics of fault occurrence (such as the correlation between process fluctuations, network jitter, and loading latency trends and fault occurrence).

[0158] Early warning of faults: Based on a trained time-series feature model, the system monitors the changing trends of process fluctuations (such as fluctuations in process CPU and memory usage), network jitter (such as fluctuations in ping latency and packet loss rate), and loading latency (such as 3D map loading latency and terrain tile loading latency) in real time. When the changing trend of a certain parameter is found to be consistent with the characteristics of a fault occurrence (such as a continuous increase in process memory usage and a continuous increase in network latency) and reaches the warning threshold, an early warning signal is issued in advance. At the same time, the system pushes the potential fault type and preliminary handling suggestions to remind maintenance personnel to intervene in a timely manner.

[0159] Preventative maintenance: The system, in conjunction with the simulator's training schedule, automatically identifies non-training windows (such as nights and weekends) and automatically performs preventative maintenance operations during these windows. Specifically, this includes:

[0160] System self-check: Perform a comprehensive self-check on IOS nodes, DBW visual computer, and network links to identify potential faults;

[0161] Cache cleanup: Cleans up expired cache and dirty data to free up system resources;

[0162] Link re-verification: Perform connectivity tests and health assessments on the primary and backup links, and repair minor link anomalies;

[0163] Data Update: Synchronize the latest terrain data and configuration files from the DBW visual computer to ensure data integrity and consistency.

[0164] Fault knowledge base self-learning and iterative optimization:

[0165] Fault Data Archiving: After each fault is handled (whether it is automatic self-healing or manual intervention repair), the system automatically archives the fault-related data. The archived content includes: fault phenomenon, fault type, root cause analysis results, self-healing / handling steps, repair results, fault occurrence time, operating environment parameters, and maintenance personnel operation records (if any), forming standardized fault cases.

[0166] Knowledge base self-learning: Based on archived fault cases, the system automatically updates fault diagnosis rules and optimizes the priority of self-healing strategies by using machine learning algorithms (such as decision tree algorithm, algorithm parameters: depth=10, number of leaf nodes=50) to optimize the execution order of self-healing steps (such as adjusting the execution order of self-healing steps for a certain type of high-frequency fault to improve self-healing efficiency). At the same time, it optimizes the parameters of the fault feature model to improve the accuracy of fault diagnosis and early warning.

[0167] Expert experience integration: The system supports maintenance personnel in inputting expert experience (such as diagnostic methods for new types of faults, optimized self-healing procedures, and handling techniques for special scenarios). Maintenance personnel can upload expert experience through the maintenance terminal, and the system integrates it into the fault knowledge base, combining it with automatically learned content to further improve fault diagnosis and self-healing strategies.

[0168] Iterative optimization: The system regularly (monthly) reviews and optimizes the fault knowledge base, deletes invalid cases, updates the diagnostic rules and self-healing steps of valid cases, and counts the recurrence rate of similar faults. Based on the statistical results, the optimization direction is adjusted to ensure that the recurrence rate of similar faults continues to decrease as the system is used.

[0169] For the purpose of simplicity, the method steps disclosed in the above embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0170] like Figure 2 As shown, the present invention also provides a fault self-healing optimization system for a full-motion simulator, comprising:

[0171] The multidimensional status data acquisition and fault confirmation module 201 is configured to collect multidimensional status data related to 3Dmap operation in real time, identify fault types and locate root causes based on preset rules, and confirm the diagnostic results through cross-validation.

[0172] The graded self-healing operation execution module 202 is configured to perform graded self-healing operations according to the fault type and severity, and to perform rollback protection during the execution process;

[0173] The dynamic verification and redundancy fault tolerance repair module 203 is configured to perform dynamic verification and redundancy fault tolerance repair of the network link when the diagnostic result is a network-related fault.

[0174] The terrain loading and data synchronization module 204 is configured to perform hierarchical caching of terrain data, preload terrain tiles according to flight status information, and periodically clean up the hierarchically cached data and synchronize the latest terrain data version with the data source.

[0175] The node startup and parameter adjustment module 205 is configured to preset a startup sequence based on the dependency relationship between each startup node, start each node sequentially according to the preset startup sequence, and adjust the startup sequence parameters when a maintenance mode trigger command is detected.

[0176] The early warning output and maintenance operation module 206 is configured to build a time-series feature model based on historical fault data, monitor the changing trend of operating parameters in real time and output early warning signals according to the monitoring results, perform preventive maintenance operations, and archive fault handling data to update diagnostic rules and self-healing strategies.

[0177] It is worth noting that although only some basic functional modules are disclosed in the embodiments of this invention, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not be considered as the scope of protection of the claims of this invention being limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0178] like Figure 3 As shown, the present invention also provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of a full-motion simulator fault self-healing optimization method.

[0179] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. For example... Figure 3 The structure shown in this embodiment of the invention includes an electronic device comprising one or more processors 710 and a memory 720; the processors 710 in this electronic device may be one or more. Figure 3 Taking a processor 710 as an example; a memory 720 is used to store one or more programs; the one or more programs are executed by the one or more processors 710, so that the one or more processors 710 implement a full-motion simulator fault self-healing optimization method as described in any one of the embodiments of the present invention.

[0180] The electronic device may also include an input device 730 and an output device 740.

[0181] The processor 710, memory 720, input device 730, and output device 740 in this electronic device can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0182] The memory 720 in this electronic device serves as a computer-readable storage medium, capable of storing one or more programs. These programs can be software programs, computer-executable programs, or modules, such as the program instructions / modules corresponding to the self-healing optimization method for a full-motion simulator provided in this embodiment of the invention. The processor 710 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 720, thereby implementing the self-healing optimization method for a full-motion simulator as described in the above embodiment.

[0183] The memory 720 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 720 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 720 may further include memory remotely located relative to the processor 710, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0184] Input device 730 can be used to receive input digital or character information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 740 may include display devices such as a display screen.

[0185] The present invention also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a full-motion simulator fault self-healing optimization method.

[0186] Specifically, the computer storage medium in this embodiment of the invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be—but is not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0187] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention 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 or all of the technical features therein. 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 the present invention.

Claims

1. A self-healing optimization method for faults in a full-motion simulator, characterized in that, include: Real-time acquisition of multi-dimensional status data related to 3D map operation; identification of fault types and location of root causes based on preset rules; and confirmation of diagnostic results through cross-validation. Based on the fault type and severity, a graded self-healing operation is performed, and rollback protection is implemented during the process. When the diagnostic result is a network-related fault, perform dynamic verification and redundancy fault tolerance repair of the network link; The terrain data is cached hierarchically, and terrain tiles are preloaded according to flight status information. At the same time, the hierarchically cached terrain data is cleaned up regularly. The hierarchically cached terrain data includes secondary terrain cache data and remote terrain cache data, and the latest terrain data version is synchronized with the data source. The startup sequence is preset based on the dependencies between each startup node. Each node is started sequentially according to the preset startup sequence, and the startup sequence parameters are adjusted when a maintenance mode trigger command is detected. A time-series feature model is built based on historical fault data to monitor the changing trends of operating parameters in real time and output early warning signals based on the monitoring results. At the same time, preventive maintenance operations are performed, and fault handling data is archived to update diagnostic rules and self-healing strategies. Among them, the terrain data is classified according to distance range. The core terrain data in the closest distance range is cached in memory, the secondary terrain data in the middle distance range is cached on disk and updated at a preset period, and the remote terrain data in the farthest distance range is loaded on demand. The system acquires the current flight position, heading, and speed in real time, calculates the predicted flight path range within a preset time period, determines the terrain tiles that need to be preloaded based on the predicted flight path range, and performs preloading in the order of loading core terrain data first and then loading secondary terrain data. Terrain tile preloading is performed in the background, and the tiles are prioritized according to their importance to control the rendering frame rate fluctuation during the preloading process to not exceed the preset fluctuation range. Clean up unused secondary terrain cache data and remote terrain cache data that have exceeded the preset time period at preset intervals, synchronize the latest terrain data version with the data source, compare the differences between the local cache and the data source, and perform update operations on the data with differences.

2. The self-healing optimization method for faults in a full-motion simulator according to claim 1, characterized in that, Real-time acquisition of multi-dimensional status data related to 3D map operation; identification of fault types and root causes based on preset rules; and confirmation of diagnostic results through cross-validation. Further aspects include: Process status data, network status data, and rendering status data are collected at a preset frequency. The process status data includes process running status, loading log, crash flag, and cache usage. The network status data includes connectivity, transmission latency, packet loss rate, and network port light status. The rendering status data includes loading progress, near-field terrain tile loading flag, and rendering frame rate. The collected data is matched with preset fault features, and it is determined whether each parameter exceeds the corresponding threshold. When the feature matching degree reaches the preset matching threshold and the parameter deviation does not exceed the preset deviation range, the fault type identifier and root cause location information are output. The remote display screen is obtained through a remote display protocol. The rendering status in the remote display screen is compared with the rendering status data collected locally. If they match, the diagnostic result is confirmed. If they do not match, the data is collected again and the diagnosis is performed again. The confirmed fault type identifier and root cause location information are used as input data for the graded self-healing operation.

3. The self-healing optimization method for faults in a full-motion simulator according to claim 1, characterized in that, Based on the fault type and severity, a graded self-healing operation is performed, and rollback protection is implemented during the operation, further including: In response to process freezes or cache anomalies, a first-level self-healing operation is performed, including terminating the abnormal process, clearing the abnormal cache and rendering context, restarting the process and initiating a map loading request, and checking the fault recovery status. If the fault has not been recovered, a second-level self-healing operation is performed. For failures such as ineffective process restart or abnormal configuration, perform a level 2 self-healing operation, including uninstalling relevant components and configuration files, reinstalling components and performing version verification, triggering the re-pushing of terrain index and core terrain tiles, restarting the node and checking the failure recovery status. If the failure is not recovered, perform a level 3 self-healing operation. For system-level failures, a three-level self-healing operation is performed, including shutting down the visual system and related computers, resetting the communication link and performing a full-process re-inspection of the link. If the failure is still not resolved after the full-process re-inspection, a unified reset is performed on the basic support node, IOS node and DBW visual computer, and the entire system is restarted according to the preset startup sequence. Before performing Level 2 or Level 3 self-healing, the current configuration file, cached data, and fault logs are backed up. If a new fault occurs during the self-healing process, a rollback operation is triggered.

4. The self-healing optimization method for faults in a full-motion simulator according to claim 1, characterized in that, When the diagnostic result is a network-related fault, dynamic verification and redundancy fault-tolerant repair of the network link are performed, further including: Perform a bidirectional connectivity test from the local node to the peer node, record the latency and packet loss rate for each test, and calculate the link health score. The link health score is negatively correlated with the packet loss rate and negatively correlated with the ratio of latency to a preset latency threshold. When the link health score is lower than the first preset threshold, a basic link repair operation is performed, including resetting the network adapter, reloading the network card driver, and automatically switching to the backup link. The backup link includes a preset backup network cable, and the link health score is re-detected after the repair. When the link health score is still lower than the first preset threshold after the basic link is repaired, the main link network interface is shut down, the backup network interface is enabled, the network parameters of the backup network interface are configured to be consistent with the main link, the route switching is realized, and the switching time is recorded. The link health score is monitored in real time. If the score drops more than a second preset threshold within a preset time window, a link degradation warning signal is output.

5. The self-healing optimization method for faults in a full-motion simulator according to claim 1, characterized in that, Based on the dependencies between each startup node, a startup sequence is preset, and each node is started sequentially according to the preset startup sequence. Upon detecting a maintenance mode trigger command, the startup sequence parameters are adjusted. This further includes: The dependencies between each startup node are preset, and the startup order is determined according to the dependencies. The startup order is as follows: first, the basic support node is started; after the basic support node completes self-check and sends a ready signal, the intermediate node that depends on the basic support node is started; after the intermediate node completes initialization and sends a ready signal, the final dependent node is started. During startup, the self-test status and ready signal transmission status of each node are monitored in real time. If any node fails to send a ready signal within the preset node startup time limit, the startup process of all subsequent nodes will be blocked, and a node abnormality warning will be output. After all nodes have sent ready signals, send map loading commands to each node. When a maintenance mode trigger command is detected, the startup timing parameters are adjusted, including extending the self-test time limit and skipping unnecessary initialization steps.

6. The self-healing optimization method for faults in a full-motion simulator according to claim 1, characterized in that, A time-series feature model is constructed based on historical fault data to monitor the changing trends of operating parameters in real time and output early warning signals based on the monitoring results. Preventive maintenance operations are performed simultaneously, and fault handling data is archived to update diagnostic rules and self-healing strategies. Further features include: The fault phenomenon, fault type, root cause, handling steps, repair results, occurrence time and operating environment parameters of each fault are continuously recorded to construct a fault feature dataset containing time sequence information. The fault feature dataset is trained using a long short-term memory network algorithm to extract feature parameters of fault occurrence patterns. Real-time monitoring of process resource usage fluctuations, network latency jitter, and loading latency trends; inputting the monitoring data into a trained time-series feature model; when the output of the time-series feature model matches the fault characteristics and the parameter changes reach the warning threshold, outputting a warning signal and corresponding handling suggestions. Based on the training schedule information, identify the non-training time window, and within the non-training time window, sequentially perform system self-check, cache clearing, link re-verification and data update operations; After each fault is resolved, the fault-related data is archived as standardized fault cases. Based on the archived fault cases, the priority of fault diagnosis rules and self-healing strategies is updated using a decision tree algorithm. In addition, externally inputted expert experience data is integrated, and the knowledge base is sorted out and invalid cases are deleted at preset intervals.

7. A fault self-healing optimization system for a full-motion simulator, characterized in that, include: The multidimensional status data acquisition and fault confirmation module is configured to collect multidimensional status data related to 3Dmap operation in real time, identify fault types and locate root causes based on preset rules, and confirm the diagnosis results through cross-validation. The graded self-healing operation execution module is configured to perform graded self-healing operations based on the fault type and severity, and to perform rollback protection during the execution process; The dynamic verification and redundancy fault tolerance repair module is configured to perform dynamic verification and redundancy fault tolerance repair of the network link when the diagnostic result is a network-related fault. The terrain loading and data synchronization module is configured to perform hierarchical caching of terrain data, preload terrain tiles according to flight status information, and periodically clean up the hierarchically cached terrain data. The hierarchically cached terrain data includes secondary terrain cache data and remote terrain cache data, and synchronizes the latest terrain data version with the data source. The node startup and parameter adjustment module is configured to preset a startup sequence based on the dependency relationship between each startup node, start each node sequentially according to the preset startup sequence, and adjust the startup sequence parameters when a maintenance mode trigger command is detected. The early warning output and maintenance operation module is configured to build a time-series feature model based on historical fault data, monitor the changing trend of operating parameters in real time and output early warning signals according to the monitoring results, perform preventive maintenance operations, and archive fault handling data to update diagnostic rules and self-healing strategies. Among them, the terrain data is classified according to distance range. The core terrain data in the closest distance range is cached in memory, the secondary terrain data in the middle distance range is cached on disk and updated at a preset period, and the remote terrain data in the farthest distance range is loaded on demand. The system acquires the current flight position, heading, and speed in real time, calculates the predicted flight path range within a preset time period, determines the terrain tiles that need to be preloaded based on the predicted flight path range, and performs preloading in the order of loading core terrain data first and then loading secondary terrain data. Terrain tile preloading is performed in the background, and the tiles are prioritized according to their importance to control the rendering frame rate fluctuation during the preloading process to not exceed the preset fluctuation range. Clean up unused secondary terrain cache data and remote terrain cache data that have exceeded the preset time period at preset intervals, synchronize the latest terrain data version with the data source, compare the differences between the local cache and the data source, and perform update operations on the data with differences.

8. An electronic device, characterized in that, include: The system includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus; the memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the method according to any one of claims 1 to 6.

Images