A change map-based flight simulator data backtracking method and system

Abstract

This application belongs to the field of data processing technology and relates to a method and system for data backtracking of flight simulators based on change maps. It aims to solve the problems of low efficiency, reliance on manual intervention, and inability to accurately locate the root causes of anomalies in existing technologies. The method includes: real-time monitoring of multi-source time-series data from a flight simulator to detect abnormal data periods; mapping the abnormal time periods to a data change map to locate the root cause change event leading to the anomaly; retrieving historical data versions recorded before the root cause change event occurred, and determining the target version through multi-objective quantitative scoring and ranking; comparing the target version with the current abnormal state to generate a minimum rollback package and performing incremental rollback; and verifying the rolled-back data based on the flight simulator's business rules to ensure the physical rationality and logical consistency of the state. This application achieves full-process automation from anomaly detection and root cause location to version selection, improving the efficiency, response speed, and reliability of data backtracking.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and relates to data backtracking technology for flight simulators or complex simulation systems, and particularly to a data backtracking method and system for flight simulators based on change maps. Background Technology

[0002] Flight simulators, as highly complex simulation systems, play a crucial role in pilot training, flight technology research, and accident analysis. During operation, they generate massive amounts of multi-source, heterogeneous time-series data, including flight attitude, control commands, system status, and visual environment. The accuracy, continuity, and consistency of this data are the cornerstones for ensuring the effectiveness and safety of simulation training. However, due to software defects, hardware failures, incorrect parameter configurations, or abnormal external data injection, simulator data states may deviate or become contaminated, potentially even leading to training interruptions in severe cases.

[0003] Currently, data recovery for flight simulators or similar complex systems primarily relies on traditional data rollback techniques. Common methods include: 1. Rollback based on periodic snapshots or full / incremental backups. While this method can restore the system to a specific backup point in time, its rollback granularity is coarse, potentially resulting in the loss of a large amount of normal data. Furthermore, the backup and recovery process consumes significant storage and computing resources, leading to prolonged system downtime. 2. Replay mechanisms based on operation logs. This method reconstructs the data state by replaying historical operation logs. However, it suffers from low retrieval efficiency when dealing with massive amounts of logs and struggles to handle state inconsistencies caused by non-idempotent operations. 3. Manual investigation by domain experts. This involves manually locating and executing rollbacks by analyzing system logs and data performance. This method heavily relies on personal experience, is time-consuming and labor-intensive, has a high error rate, and is ill-suited for handling sudden and complex anomalies. These methods fail to meet the urgent needs of modern flight simulators for high availability, rapid recovery, and intelligent data state management. Summary of the Invention

[0004] To address the aforementioned problems in the prior art, namely, the low efficiency of data backtracking, reliance on manual intervention, and inability to accurately pinpoint the root cause of anomalies, the first aspect of this application proposes a flight simulator data backtracking method based on change maps, the method comprising the following steps:

[0005] Monitor multi-source time-series data from flight simulators, perform anomaly detection, and determine abnormal time periods; The abnormal time period is mapped to the corresponding node of a pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between the nodes; Retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version; Perform a difference comparison between the target rollback version and the current abnormal data state, and generate a minimal rollback package containing only the difference data; Incremental rollback is performed based on the minimum rollback package to restore the data state to the target version; The rolled-back data is verified according to the flight simulator's business rules. If the verification passes, the status is fixed and an audit log is generated. If the verification fails, a rollback is executed or a new target rollback version is determined.

[0006] In some preferred embodiments, the location of the root cause change event leading to the anomaly specifically includes: The abnormal time period is mapped to a graph abnormal node according to the temporal proximity and dimensional matching degree. Multiple source tracing paths are generated by traversing in reverse along the edges from the graph abnormal node. A comprehensive score is calculated for each tracing path. The comprehensive score is determined based on the influence intensity of the edges in the path, the consistency of the delay between the change time and the abnormal time, the dimension matching degree, and the change execution status. The upstream change event node in the tracing path with the highest comprehensive score is identified as the root cause event; The node attributes of the data change graph include at least the change event identifier, change type, operation subject, timestamp, data dimension involved, and change content. The attributes of the edges include at least the impact type, impact intensity, and delay before the change takes effect.

[0007] In some preferred embodiments, the multi-objective quantitative score is obtained by dynamically weighting data integrity score, data availability score, and business continuity score; the dynamic weights are adjusted based on feedback from historical rollback results through an online learning mechanism.

[0008] In some preferred embodiments, the business continuity score is obtained by weighting time continuity, indicator smoothness, and change continuity; wherein, the time continuity is determined based on the proportion of continuous sampling duration without gaps in the timestamps of the backtracking data; the indicator smoothness is determined based on the proportion of key business indicators with no abnormal jumps in the rate of change under the first difference; and the change continuity is determined based on the completeness of the change event chain corresponding to the backtracking version.

[0009] In some preferred embodiments, the rolled-back data is validated according to the flight simulator's operational rules, including at least one of the following: Time continuity check is used to determine whether the timestamp of a data frame is monotonically increasing and the interval is within a preset sampling range; The physical rationality verification of flight attitude is used to determine whether the rate of change of pitch angle, roll angle and yaw angle is within the safe threshold. Control input continuity check is used to determine whether there are any unsmooth jumps in the control input of the control stick, rudder and throttle. Flight control system state consistency verification is used to determine whether there are any contradictions in the state logic of subsystems, including landing gear state and speed limit, hydraulic system state and servo response.

[0010] A second aspect of this application proposes a flight simulator data backtracking system based on change maps, comprising: The anomaly detection module is configured to monitor multi-source time-series data of the flight simulator, perform anomaly detection, and determine the abnormal time period. The root cause analysis module is configured to map the abnormal time period to the corresponding node of a pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between the nodes; The backtracking selection module is configured to retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and to sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version; The differential rollback module is configured to perform a difference comparison between the target rollback version and the current abnormal data state based on a joint identifier composed of the primary key and timestamp, and generate a minimum rollback package containing only the difference data; it is also configured to perform incremental rollback based on the minimum rollback package to restore the data state to the target version; The business rule verification module is configured to verify the rolled-back data based on the business rules of the flight simulator. If the verification passes, the status is fixed and an audit log is generated. If the verification fails, a rollback is executed or a new target rollback version is determined.

[0011] Compared with the prior art, the technical solutions in the embodiments provided in this application have at least the following beneficial effects: 1) By using deep learning models, unsupervised anomaly detection models, and multi-objective quantitative scoring mechanisms, the entire process from anomaly monitoring and root cause localization to version selection is automated and intelligent, reducing reliance on domain experts and significantly improving the efficiency and response speed of data backtracking.

[0012] 2) By constructing a data change map and performing reverse tracing, the accuracy of anomaly location is improved. It can accurately identify the root cause change events that cause anomalies from complex data dependencies, avoiding the problems of blind investigation or coarse-grained rollback in traditional methods.

[0013] 3) By conducting multi-objective quantitative scoring on candidate backtracking versions and introducing business continuity assessment, it is ensured that the selected target backtracking version data is complete and usable, and conforms to flight dynamics and system logic, avoiding recovery to an unstable intermediate state and ensuring business continuity after data recovery.

[0014] 4) By generating a minimum rollback package containing only the difference data and performing incremental rollback, the amount of data transmission and recovery time are reduced, system resource overhead is lowered, and interference with the normal operation of the flight simulator is minimized. Furthermore, a business rule verification step is added after the rollback is completed, which provides a guarantee for the correctness and physical rationality of data recovery, ensuring the stable operation of the flight simulator system in a high-availability state. Attached Figure Description

[0015] 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: Figure 1 This is a flowchart of a flight simulator data backtracking method based on a change map provided in one embodiment of this application; Figure 2 This is a schematic diagram of the structure of a computer system used to implement the methods, apparatus, and electronic devices of this application. Detailed Implementation

[0016] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] To address the problems of low efficiency, reliance on manual intervention, and inability to accurately pinpoint the root causes of anomalies in existing technologies, this application provides a flight simulator data backtracking method based on change maps. This method combines deep learning models, unsupervised anomaly detection models, and multi-objective quantitative scoring mechanisms to automate the entire process from anomaly monitoring and root cause localization to version optimization, thereby improving the efficiency, response speed, and reliability of data backtracking.

[0019] Before proceeding with the explanation, the technical terms used in this embodiment will be explained as follows: Data retrospective: Tracking, recording and restoring data to a historical point in time, with the core being to ensure that data is traceable, auditable and recoverable.

[0020] AI-driven: Using artificial intelligence to automatically trace data sources, locate problems, detect anomalies, and automatically roll back, eliminating the need for humans to check logs and flip through versions.

[0021] Version management: Attach a version identifier to each data change to enable data status traceability, version comparison, and historical status switching.

[0022] Differential restoration: It only stores and manipulates the changed parts of the data, and restores the complete data state at any point in time by combining the baseline data and the differential log.

[0023] Anomaly detection: Automatically detects abnormal patterns in data through algorithm models, such as null values, sudden increases or decreases, drift, duplication, errors, tampering, delays, etc., and performs real-time data checks.

[0024] Time series characteristics: Data patterns and attributes arranged in chronological order, including trends, periodicity, volatility, breakpoints, lag / lead relationships, and continuity.

[0025] To more clearly explain the flight simulator data backtracking method based on change maps in this application, the following will be combined with... Figure 1 The steps in the embodiments of this application are described in detail.

[0026] The first embodiment of this application provides a method for backtracking flight simulator data based on a change map, including steps S1 to S6, such as... Figure 1 As shown, each step is described in detail below: S1. Monitor multi-source time-series data of the flight simulator, perform anomaly detection, and determine the abnormal time period.

[0027] In some preferred embodiments, monitoring multi-source time-series data of the flight simulator for anomaly detection specifically includes: When a change in the time series data of the flight simulator is detected, multi-source time series data of the flight simulator within a preset time window before and after the data change event is collected and preprocessed. A hybrid neural network is used to extract features from the preprocessed multi-source time-series data to obtain time-series feature vectors, and the time-series feature vectors are associated with the corresponding graph nodes. The time-series feature vector is input into a pre-trained anomaly detection model to calculate a quantified anomaly score, and the anomaly time period is determined based on the anomaly score.

[0028] In this embodiment, the data generated by the flight simulator system is multi-source and time-series, including but not limited to the computer system logs controlling the flight simulator, flight attitude parameters (such as pitch angle, roll angle, and yaw angle), instrument readings, motion system status data, and visual system rendering data. This data is generated at a high frequency (e.g., 20-50 frames per second). When any change in this time-series data is detected, the system collects multi-source time-series data within a preset time window (e.g., 60 minutes) before and after the data change event.

[0029] Preferably, the hybrid neural network is a hybrid neural network of convolutional neural network and long short-term memory network; the hybrid neural network is used to extract features from the preprocessed multi-source time-series data, specifically as follows: A convolutional neural network is used to extract local spatial features (such as abrupt changes or fluctuations in flight parameters over a short period of time, e.g., three time steps) from multi-source time-series data. A long short-term memory network is used to extract long-range temporal dependence features (such as the temporal correlation between "voltage abrupt changes" and subsequent "temperature increases") from the same data. These local spatial features and long-range temporal dependence features are then fused to generate a fixed-dimensional time-series feature vector. This vector represents the "local anomaly features" and "temporal correlation features" of the data within the given time window and serves as the core input for subsequent anomaly detection.

[0030] More preferably, the method for collecting and preprocessing multi-source time-series data of the flight simulator within a preset time window before and after the data change event is as follows: 1) Collect raw data and remove invalid information from the raw data. For example, scan and delete data records that contain missing values ​​for one or more core fields (such as empty temperature or voltage); at the same time, records with outliers that exceed their physical constraints or business logic range (for example, the voltage reading of a sensor is far beyond its rated operating range) will also be removed to ensure the basic quality of the input data.

[0031] In this embodiment, the raw data is in CSV / JSON format, with core fields (i.e., raw features): device ID, acquisition time, temperature, voltage, current, operating speed, and fault code (a total of 6 valid features). The acquisition parameters can be set as needed, such as data volume: 10,000 acquisition records, acquisition frequency: 1 time / minute, i.e., a time span of 10,000 minutes (approximately 6.9 days).

[0032] In this embodiment, when removing invalid information from the original data, missing values ​​(such as records with empty temperature and voltage) and outliers (such as records with voltage exceeding the rated range of the equipment) are removed, and 8,000 valid records are retained. Then, non-numerical features (equipment ID, acquisition time) are removed, and only 6 numerical features (temperature, voltage, current, operating speed, fault code) are retained to form the original numerical matrix: the dimension is [8000, 6] (8,000 records, 6 features).

[0033] 2) Perform feature selection and data normalization to eliminate dimensional differences. In this embodiment, Min-Max normalization is preferred, mapping all feature values ​​to the [0,1] interval: );in, Features The normalized value, Features The minimum value, Features The maximum value.

[0034] Normalization yields a normalized matrix, ensuring that model training is not affected by differences in feature dimensions (such as temperature °C, voltage V) during convergence.

[0035] 3) Construct time series sequences using the "sliding window method," which divides continuous time series data into sequences of fixed length (i.e., the input sequences of the model), and sets the time window size and step size. For example, time window = 60 (meaning that time series data of every 60 minutes is an input sequence), step size = 1 (a new sequence is taken every 1 minute of sliding), and the final number of time series sequences generated is: 8000-60+1=7941, and the dimension of each sequence is [60,6] (60 time steps, each time step contains 6 features).

[0036] 4) Convert to model input tensor. Gather all the sequence samples generated in the previous step to construct a three-dimensional tensor that meets the input requirements of the subsequent neural network model. This tensor typically needs to conform to the format [batch_size, time_steps, input_dim], where batch_size is the number of samples input to the model in each batch during training (e.g., 32); time_steps is the size of the time window (e.g., 60); input_dim is the number of numerical features per time step (e.g., 6); and the final input tensor dimension is (e.g., [32, 60, 6]). During training, input samples to the model in batches. The validation and test sets are converted using the same process to ensure format consistency.

[0037] Preferably, if the original data is an image sequence (such as surveillance video frames), the conversion logic is similar: first, normalize the single frame image to [0,1] and uniform size (such as 64×64×3), and then convert it into an input tensor (such as [32, 10, 64, 64, 3]) by taking 10 consecutive frames as a sequence.

[0038] More preferably, as another example, the hybrid neural network can also be a convolutional neural network and a Transformer network.

[0039] Preferably, the anomaly detection model is an isolated forest model, and the calculation of the anomaly score of the time-series feature vector specifically includes: Within a time window consistent with the aforementioned time window, statistical features including change frequency, change type distribution, and the mean and variance of preset physical quantities, as well as the first-order difference peak value, are extracted as input to calculate the isolation degree index. Based on the isolation level index, combined with preset standardization rules, it is converted into a quantitative anomaly score.

[0040] More preferably, the preset standardization rule standardizes the isolation level index into an abnormal score of 0 to 100; when this score exceeds a preset threshold (e.g., 80 points), the corresponding change event or time point is marked as an abnormal time period.

[0041] S2. Map the abnormal time period to the corresponding node of the pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between nodes.

[0042] Preferably, the root cause change event that leads to the anomaly specifically includes: The abnormal time period is mapped to a graph abnormal node according to the temporal proximity and dimensional matching degree. The graph abnormal node is traversed in reverse along the edge to recursively obtain all upstream change event paths pointing to the abnormal node and generate multiple tracing paths. A comprehensive score is calculated for each tracing path. The comprehensive score is determined based on the influence intensity of the edges in the path, the consistency of the delay between the change time and the abnormal time, the dimension matching degree, and the change execution status. The upstream change event node in the tracing path with the highest comprehensive score is identified as the root cause event.

[0043] More preferably, the abnormal time periods are mapped to anomalous nodes in the graph based on temporal proximity and dimensional matching degree. The method is as follows: First, cluster the abnormal time periods, grouping those timestamps that differ by a preset threshold. Adjacent anomalies within the same time-series anomaly cluster are grouped together. Then, the parameter dimensions of outliers within a cluster are matched by temporal proximity and dimension matching. Those with high matching are retained, and those with low matching are split, ensuring that the parameter dimensions of outliers within each cluster are strongly correlated. Each qualified anomaly cluster is ultimately mapped to an anomaly node carrying a unique node identifier (bound to multimodal unified coding), anomaly time interval (start and end timestamps within the cluster), involved parameter dimensions (such as elevator, pitch angle, etc.), anomaly type and intensity (such as anomaly jump, jump magnitude 1.0% / 20ms), and the corresponding flight condition (such as cruise, climb, etc.).

[0044] Based on the original parameter influence relationships in the change map, determine whether there is a linkage effect between the parameter dimensions corresponding to different abnormal nodes. If there is a correlation (such as control surface jump and attitude parameter anomaly), establish a correlation edge between nodes, mark the correlation type (parameter transmission, coupling effect), and form an anomaly propagation path.

[0045] More preferably, time proximity is used to select the difference between the timestamp and the outlier timestamp. Within the event nodes, iterate through all valid abnormal time points and calculate the timestamp difference between adjacent abnormal time points. The smaller the intra-temporal difference, the greater the temporal proximity of outliers; in a specific embodiment... The setting matches the analog unit's 50Hz sampling frequency, such as the preset setting. That is, the interval between two sampling frames; if the difference is ≤40ms, they are classified into the same time-series anomaly cluster (corresponding to continuous anomaly intervals); if the difference is >40ms, a new anomaly cluster is created until all anomaly time points are clustered.

[0046] More preferably, the dimension matching degree is used to calculate the degree of matching between the data dimensions involved in the anomaly and the data dimensions recorded in the change event node attributes; the greater the intersection between the data dimensions involved in the anomaly and the data dimensions recorded in the change event node attributes, the higher the dimension matching degree. In a specific embodiment, the threshold for determining the dimension matching degree is preset to 0.8. If the matching degree is ≥0.8 (like source parameters or strongly coupled parameters), the cluster is retained and the anomaly features are merged; if the matching degree is <0.8 (irrelevant parameters), it is split into a new cluster to ensure that the anomaly parameters within each cluster are strongly correlated.

[0047] In a specific embodiment, the data change graph is a directed graph G=(V,E,W,A) used to describe the causal and dependency relationships between data change events. A node (V) represents a specific change event, such as parameter modification, data collection rule change, or algorithm version update. Node attributes (A(V)) record detailed information such as event ID, change type, operator, timestamp, involved data dimensions (e.g., velocity, attitude), and change content. Edges (E) represent the dependency or influence relationship between change events; for example, a "parameter modification" node pointing to a "data collection" node indicates that parameter modification affects the data collection results. Edge attributes (A(E)) record the influence type (direct / indirect), influence strength (a quantified value from 0 to 1), and the delay in the change taking effect. The weight (W) is the edge weight, quantifying the degree of influence; for example, direct influence weight = 0.9, indirect influence = 0.4.

[0048] S3. Retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version.

[0049] Preferably, after locating the root cause change event, the system retrieves all historical data versions recorded before the occurrence of the root cause change event, forming a candidate list. In order to select the best one from these candidate versions for recovery, this embodiment uses a multi-objective quantitative scoring model to perform multi-objective quantitative scoring, and selects the candidate version with the highest comprehensive score as the final target backtracking version.

[0050] More preferably, the multi-objective quantitative scoring is based on data integrity scoring. Data availability score and business continuity score The result is obtained through dynamic weighting: ； in, , , The weights are dynamic and adjusted based on feedback from historical rollback results through online learning mechanisms (such as reinforcement learning). Data integrity assesses whether the data is comprehensive and without missing data; data availability assesses whether the data format is compliant and can be parsed and loaded by the system; business continuity assesses whether the data can support business processes and whether key indicators exhibit abnormal jumps that violate physical laws.

[0051] In this embodiment, the initial weight value is set as follows (general backtracking scenario): =0.3 (integrity) =0.2 (availability) =0.5 (Business Continuity).

[0052] Specifically, the data integrity score It is obtained by weighting the normalized values ​​of multiple sub-indicators. The sub-indicators include: 1) Time coverage: The proportion of time series data corresponding to the candidate backtracking point that covers the target backtracking time period, to determine whether the backtracking data completely covers the target time period, with the highest priority.

[0053] Time coverage percentage = (Actual coverage duration of backtracking time series data / Target backtracking time period duration) The scoring mapping is as follows: if the coverage is 90% ≤ coverage ≤ 100%, it will score 9-10 points. If the coverage is < 60%, it means that the backtracking point cannot cover the core data of the target time period, and it will be directly judged as a non-optimal backtracking point, with a time coverage score ≤ 5 points.

[0054] 2) Field coverage: The proportion of core business fields (such as pitch angle, roll angle, and control surface position) in the time series data corresponding to the backtracking point that are not missing; among them, the missing rate of non-core fields is determined proportionally, and if it is higher than the preset threshold, it is also determined as a missing field; if a field has data, but the data is outside a reasonable range (such as pitch angle exceeding ±90°, sensor data jump exceeding the threshold), or the data is repeated without change, it is considered that the field is missing and is not included in the valid field statistics.

[0055] Scoring is based on percentage ranges; missing core fields will result in a direct deduction of high scores; if no core fields are missing, an extra 0.5 points will be added; if core fields are missing, 5 points will be deducted.

[0056] 3) Record completeness: The ratio of the number of valid sampled records in actual backtracking to the number of theoretical sampled records.

[0057] ; (The standard sampling frequency of the simulator is 50Hz), and a valid record refers to a sampling frame without any missing, abnormal, or invalid frames.

[0058] 4) Data tamper-proof: The data has not been illegally tampered with, as confirmed by hash verification or change graph tracing.

[0059] The risk of tampering is determined based on "data hash value consistency and change record integrity". No tampering is awarded full marks, and points are deducted according to the severity of the tampering risk. For example, if there are minor traces of tampering (such as modification of a single non-core field data with complete change records), 2 points will be deducted; if there is serious tampering (modification of core fields with no change records), 8-10 points will be deducted.

[0060] In one specific embodiment, the weights of each sub-indicator of the data integrity score can be set according to business needs. For example, time coverage and field coverage are each weighted at 0.3, and record integrity and data tamper-proofness are each weighted at 0.2.

[0061] Specifically, the data availability score The sub-metrics used to evaluate whether backtracking data can be parsed and loaded by the system include: 1) Format compliance rate: The proportion of records whose field types and data formats conform to business rules; Format compliance rate = (Number of format-compliant sampled records / Total number of sampled records) × 100%; The score is mapped to a percentage range.

[0062] 2) Parsable Rate: The percentage of records that can be successfully parsed without garbled characters or unreadable content; Parsable Rate Percentage = (Number of records that can be successfully parsed by the multimodal parsing engine / Total number of sampled records) × 100%; Parsable means that the parsing engine can normally extract core information such as timestamps, parameter values, and anomaly markers from the records, without parsing failures or parsing errors, and the score is mapped to a percentage range.

[0063] 3) Loadability: The success rate of simulating writing to the database or importing into the analysis tool; Loadability = Loading success rate - Deduction for exceeding the time limit, Loading success rate = (Number of successfully loaded sampled records / Total number of sampled records) × 100%, Loading time must be ≤ preset threshold (5 seconds / 100,000 records for simulator scenarios).

[0064] 4) No duplicate data rate: The proportion of data that does not contain duplicate records with completely identical content. No duplicate rate percentage = (Number of unique sampled records / Total number of sampled records) × 100%; Duplicate records refer to records with completely identical timestamps, parameter values, and field information. Only one record is retained as a valid record, and the rest are judged as duplicate records. The score is mapped to a percentage range.

[0065] In one specific embodiment, the weights of each sub-indicator of the data availability score can be set according to business needs. For example, the weights of parsable rate and loadable rate are each 0.3, and the weights of format compliance and no duplication rate are each 0.2.

[0066] Specifically, the business continuity score The results are obtained by weighting time continuity, indicator smoothness, and change continuity. The time continuity is determined by the proportion of continuous sampling duration where the timestamps of the backtracked data are uninterrupted (e.g., the data frame interval does not exceed twice the preset sampling period). The indicator smoothness is determined by the proportion of key business indicators whose rate of change under the first difference has no abnormal jumps. The change continuity is determined by the completeness of the change event chain corresponding to the backtracked version.

[0067] In one specific embodiment, the weights of each sub-indicator of the business continuity score can be set according to business needs. For example, the weights of time continuity and indicator smoothness are each 0.35, and the weight of change continuity is 0.3.

[0068] Specifically, the time continuity score is determined based on the proportion of uninterrupted timestamps in the backtracking data, and the specific solution is as follows: The temporal continuity ratio = (uninterrupted continuous sampling duration / target backtracking time duration) × 100%; uninterrupted continuous sampling means that the sampling frame interval conforms to the simulator's sampling frequency (no interval exceeding twice the sampling period), there is no obvious data interruption, and the score is mapped to a percentage interval, taking into account the continuity requirements of flight conditions. The time continuity score is 9-10. Continuity ratio = This indicates severe data gaps, failing to reflect complete flight conditions, and affecting the time series continuity score. 6 points, affecting the effectiveness of business retrospective analysis.

[0069] For example: The target backtracking time period is the flight simulator's climb phase from 08:30 to 08:45 (a total of 15 minutes). The simulator's sampling frequency is 50Hz (sampling period 20ms). The continuous sampling duration without gaps at candidate backtracking point I is 14.1 minutes, with a 0.9-minute data gap (caused by a temporary lag in the sampling equipment, with the interval exceeding 40ms). Therefore, the temporal continuity score of backtracking point I is 9.4.

[0070] Specifically, the smoothness of the indicator is determined by calculating the rate of change of key business indicators under first-order difference, evaluating the proportion of indicators without abnormal jumps (e.g., whether the rate of change of pitch angle and roll angle is within the safety threshold set by flight dynamics), and thus determining the indicator smoothness score. The specific calculation is as follows: Smoothness percentage = [1 - (number of sampling frames exceeding reasonable rate of change / total number of sampling frames)] × 100%; The scoring is based on the percentage of smoothness. In this embodiment, the specific scoring rule is as follows: 95% ≤ smoothness ≤ 100%, resulting in 9.5-10 points. If the smoothness is <85%, it indicates that the parameter fluctuations are too large and do not conform to the actual operating rules of the simulator; 0.3 points are deducted for every 1% below this level. The reasonable rate of change is set according to the various parameters of the simulator (e.g., the rate of change of pitch angle). Rate of change of rudder position The scores are mapped to percentage intervals, and are calculated after removing sudden anomalies (already marked abnormal time points). In this embodiment, the scores of the above dimensions are ultimately normalized to [0,1] to ensure data consistency.

[0071] For example: The total number of sampled frames for candidate backtracking point J is 20,000. After removing known outliers, 19,800 frames remain. Among them, 396 sampled frames exceed the reasonable rate of change (mainly instantaneous jumps in control surface position, not marked as outliers). Index smoothness percentage Therefore, the smoothness score of the backtracking point J is 9.8.

[0072] In a specific embodiment, the abnormal transition is further described as follows: The aforementioned abrupt changes are typical anomalies in multi-source time-series data from flight simulators (such as sudden changes in sensor data or abrupt parameter changes). Thresholds are set based on the characteristics of the simulator parameters. Using the parameter changes between adjacent sampling frames as the core judgment criterion, and considering the operational characteristics of each parameter of the flight simulator, three types of quantitative standards are defined: Jump amplitude standard: If the parameter change in adjacent sampling frames (based on the analog 50Hz sampling frequency, with an interval of 20ms) exceeds the preset "reasonable jump threshold" for that parameter, it is judged as an abnormal jump; Duration standard: Abnormal transitions must meet the requirement that "the duration of a single transition is ≤3 sampling frames" (≤60ms). If the duration is >3 sampling frames, it is determined to be parameter drift rather than abnormal transition. Consistency recovery criteria: If the parameters do not recover to the reasonable range of ±5% before the jump within 1-2 sampling frames after the jump, and there is no clear change of operating condition or operation command (such as control surface operation or throttle adjustment), it is further confirmed as an abnormal jump (excluding parameter changes caused by normal operating conditions).

[0073] For example, if the pitch rate of change of a certain version exceeds the safety threshold set by flight dynamics, its business continuity score will be reduced; the safety threshold is based on the aircraft manual, the dynamic limits of the simulation model, or historical normal data statistics, such as the pitch rate of change safety threshold can be set to [-25, +25] degrees / second.

[0074] Specifically, as an example, if the rate of change of flight attitude parameters (pitch angle, roll angle) between consecutive frames exceeds a preset safety threshold [e.g., 20 degrees / second], an abnormal jump is determined to have occurred, and the score for this indicator is 0; otherwise, the score is calculated linearly within 0-1 based on the smoothness of the rate of change.

[0075] Specifically, the change continuity is determined based on the completeness of the change event chain corresponding to the retrospective version. It checks the completeness of the change event chain based on the change graph, identifying any missing or broken change records. Change continuity score = 10 points - deduction for change breakage. Among them, change break refers to the lack of a complete link for the change event (such as parameter calibration, version update) corresponding to the backtracking point data, with missing change records or broken change nodes; points are deducted according to the severity of the break. If there is a minor change break (such as missing a single non-core parameter change record), 1.5 points are deducted; if there is a serious change break (broken core parameter change link, no change record), 7-10 points are deducted according to the severity of the break; no change break earns full marks.

[0076] Further preferably, in order to evaluate the reliability of each version score, a confidence score can also be calculated. The confidence score takes into account the stability of the version score (the volatility of multiple calculations, or the standard deviation of all versions if there are no multiple calculations) and the discriminability (the difference between the version score and the score of other candidate versions; the greater the difference between the version score and the mean, the higher the discriminability). The final output is sorted in descending order of the comprehensive score, and a Top-K optimal backtracking version list is filtered out for low-confidence versions, which is used for subsequent rollback operations.

[0077] S4. Perform a difference comparison between the target backtracking version and the current abnormal data state, and generate a minimal rollback package containing only the difference data.

[0078] Preferably, generating the minimum rollback package specifically involves: Using the primary key and timestamp as a combined identifier, a difference comparison is performed between the target backtracking version and the current abnormal data state to identify the difference records: newly added (e.g., records that exist in the target version but not in the current state), modified (e.g., records with the same combined identifier but different contents of one or more valid fields), and deleted (e.g., records that exist in the current state but not in the target version). The modified set contains the fields that have differed and their target values, and carries the target version identifier and difference statistics metadata. The difference record, along with metadata containing the target version identifier and difference statistics, is encapsulated into the minimum rollback package.

[0079] In this embodiment, the primary key can be a unique business identifier such as device ID or order ID. This combined identifier can accurately identify three types of differences: newly added records (existing in the target version, but not in the current state), modified records (with the same combined identifier, but different field contents), and deleted records (existing in the current state, but not in the target version).

[0080] Specifically, in this embodiment, the minimum rollback package includes: A metadata file records information such as the target version ID, difference statistics, primary key fields, and checksum; the difference data files store newly added complete records, modification records containing only the difference fields, and deletion records containing only the primary key. This structure ensures that the rollback package is as small as possible while still providing complete information.

[0081] S5. Perform incremental rollback based on the minimum rollback package to restore the data state to the target version.

[0082] Preferably, during the data recovery phase, the minimum rollback package is first decompressed, and the metadata is read. Before performing any modifications, all records in the current data that will be affected are backed up so that a quick rollback can be performed in case of failure. Then, incremental restoration is performed in the order of "add → modify → delete". The add operation directly appends the new record to the current database; the modify operation locates the specific record based on the primary key and timestamp, and only updates the specified difference fields in the rollback package, without touching other irrelevant fields; the delete operation deletes the corresponding record based on the primary key. The entire process only operates on the difference data and does not affect irrelevant data at all, thus achieving efficient and low-intrusion data recovery.

[0083] S6. Verify the rolled-back data according to the flight simulator's business rules. If the verification passes, solidify the status and generate an audit log. If the verification fails, execute a rollback or re-determine the target rollback version.

[0084] Preferably, the rolled-back data is verified according to the flight simulator's business rules, including at least one of the following: Time continuity check is used to determine whether the timestamp of the data frame is monotonically increasing and the interval is within the preset sampling interval (e.g., time gaps > 200ms are not allowed). Flight attitude physical rationality verification is used to determine whether the rate of change of pitch, roll, and yaw angles is within safe thresholds; (e.g., pitch angle) Civil aircraft Roll angle : Heading angle Single-frame change: <5°; Altitude change: <10 meters per frame; Airspeed change: <5 knots per frame; Vertical velocity: (This falls within the normal range) The continuity check of control inputs is used to determine whether there are any unsmooth jumps in the control inputs of the control stick, rudder, and throttle (e.g., single-frame change of control stick (Pitch / Roll) <10%; single-frame change of rudder <10%; single-frame change of throttle <5%; single-frame change of trim <1°). Flight control system state consistency verification is used to determine whether there are any contradictions in the state logic of subsystems, including landing gear state and speed limit, hydraulic system state and servo response.

[0085] If all validation items pass, the rollback is considered successful. The system will solidify the current data state and generate detailed audit logs, recording all information including anomaly detection, root cause analysis, version selection, and the rollback process. If any validation fails, the system will automatically perform a rollback operation, restoring the data to its pre-rollback state using the backup created in step S5. It can also trigger retry logic, such as returning to step S3, removing failed versions from the candidate versions, and selecting the next best version for a new round of rollback.

[0086] Furthermore, based on the change graph, a causal origination report is output, identifying the upstream change event node in the origination path with the highest comprehensive score as the root cause event. Related content is then compiled and output, including: Anomaly information: anomaly type, anomaly time, involved dimensions, anomaly score; Root cause location information: root cause event ID, change type, operator, change time, change content, tracing path, and cause confidence level; Root cause verification information: verification results and conclusions.

[0087] The second embodiment of this application provides a method for backtracking flight simulator data based on a change graph, which, based on the first embodiment, provides a detailed description of the specific implementation of the hybrid neural network described in step S1 of the first embodiment.

[0088] In this embodiment, the model input data is a preprocessed multidimensional time-series data tensor. For example, raw data containing six dimensions (temperature, voltage, current, speed, fault codes, etc.) collected by a flight simulator at a frequency of once per minute over 60 minutes is cleaned, normalized, and then constructed into a tensor with a dimension of [...]. The input tensor is [60,6], where 60 is the batch size (e.g., 32), 60 is the time step, and 6 is the feature dimension.

[0089] The input tensor first enters a 1DCNN spatial feature extraction module. This module consists of two sets of convolutional layers stacked with pooling layers, supplemented by a Dropout layer to prevent overfitting. The first convolutional layer (Conv1) uses 32 convolutional kernels of size 3 to capture local feature patterns within 3 time steps, such as short-term voltage spikes. After ReLU activation and MaxPooling pooling, the feature map size is compressed. The second convolutional layer (Conv2) uses 64 convolutional kernels to further extract more complex combined features. The final output of the CNN module is a feature map with dimensions [32, 15, 64], which condenses the local spatial features of the original sequence.

[0090] Subsequently, the feature map enters the feature reshaping module for sequence format verification. The output dimension conforms to the [batch_size, time_steps, feature_dim] format required by LSTM, without the need for additional dimension adjustment.

[0091] The data is fed into an LSTM temporal feature extraction module. This module consists of two LSTM layers and a fully connected layer. The first LSTM layer (LSTM layer 1) has 128 hidden units and is configured to return the output of all time steps (return_sequences=True) to capture the contextual information of each step in the sequence. The second LSTM layer (LSTM layer 2) has 64 hidden units and only returns the output of the last time step. This output can be regarded as an encoding of the global temporal features of the entire 15-time-step sequence, capturing long-range dependencies such as "changing trajectory associations".

[0092] Finally, the model fuses the local spatial features extracted by the CNN module with the global temporal features extracted by the LSTM module. In this preferred embodiment, the output feature map of the CNN is flattened, then concatenated with the output vector of the LSTM, and then subjected to dimensionality reduction and feature optimization through a fully connected layer. Ultimately, the model outputs a fixed-dimensional (e.g., 64-dimensional) feature vector. Each dimension of this vector represents an abstract feature of the original 60-minute time-series data at a certain level, providing high-quality input for subsequent anomaly detection, change relationship identification, and root cause localization.

[0093] The final output is a 64-dimensional feature vector, with each dimension having a specific business meaning, comprehensively representing the features of the input sequence (e.g., 60-minute time series data). A specific division example is shown below: Dimensions 1-20: Primarily correspond to the "local spatial features" extracted by CNN, representing feature patterns within a short time window, such as temperature fluctuation amplitude, voltage peak, and current stability, used to identify local anomalies in the data. Dimensions 21-45: Primarily correspond to the "temporal correlation features" extracted by LSTM, representing the dependencies between different time steps in the sequence, such as the correlation strength between "voltage changes in the first 10 minutes and temperature changes in the following 50 minutes," used to trace the temporal trajectory of data changes. Dimensions 46-64: Correspond to the fused "global comprehensive features," representing the overall state of the entire 60-minute sequence, such as the overall fluctuation level and the count of abnormal events, used for the node feature representation of the data change map and the comprehensive judgment of the root causes of anomalies.

[0094] More preferably, the feature reshaping module is used for dimensionality verification and reshapes the feature maps output by CNN modules that fail verification into a sequence format acceptable to subsequent LSTM modules. This layer plays a crucial role when processing other types of data (such as image sequences). For example, if the input is an image sequence, the output of a 2D CNN might be... At this point, the remodeling layer needs to be converted to The spatial dimensions are merged into time steps to adapt to the input of the LSTM.

[0095] The third embodiment of this application provides a flight simulator data backtracking method based on change maps, which, based on the first embodiment, provides a detailed description of the specific structure of the data change map used for root cause localization in step S2 of embodiment one.

[0096] The data change graph in this embodiment adopts a "four-layer architecture + temporal correlation" design.

[0097] The first layer is the foundation layer (data node layer), which contains all data entity nodes involved in the backtracking process, such as tables and fields in the database, as well as API outputs and model parameters. Each node has a unique identifier and rich attributes, such as data ID, data type (structured / unstructured), source system, initial generation time, sensitivity level, and associated business semantics.

[0098] The second layer is the change relationship layer, consisting of the edges connecting nodes. These edges are automatically identified and generated by a graph neural network algorithm. Edges are mainly divided into two categories: flow relationships, describing the transfer of data from one node to another; and change relationships, describing operations such as modification, deletion, and version updates of individual data nodes. The edge attributes record the change type, change time, operator, triggering conditions, and scope of change impact, forming the foundation of association analysis.

[0099] The third layer is the time-series version layer, which maintains a full-version snapshot history for each data node, recording every change in the data's state along the timeline. Each version snapshot is associated with a corresponding change relationship edge, forming a three-dimensional relationship of "node-version-time". This allows the system to accurately trace back to the state at any historical point in time and clearly track the complete source and evolution process of a particular version of data.

[0100] The fourth layer is the management layer. When the graph experiences breaks due to missing data nodes or broken connections, it automatically fills in the implicit connection links based on the knowledge graph and association rules to ensure the integrity of the graph. At the same time, it monitors changes in relationships in real time. When abnormal changes such as unauthorized modification of sensitive data are detected, it can quickly trigger an alert and link up with the root cause analysis module.

[0101] Through this structural design, the data change map not only records the lineage of data, but also forms a dynamic, intelligent, and self-healing causal relationship network, providing a strong data foundation for achieving accurate and efficient root cause localization.

[0102] Specifically, the construction process of the data change map is a dynamic and continuous process, which mainly includes the following steps: 1) Define the change event node.

[0103] The system monitors various change events in the flight simulator environment in real time, capturing events by parsing system logs, database binlogs, and configuration center change records. Whenever a change event occurs—such as a flight parameter modification, a data acquisition rule update, or an algorithm model version iteration—a corresponding change event node (V) is created in the graph. Simultaneously, information is extracted from the event's metadata to populate the node's attributes (A(V)), including: a unique event ID, change type (e.g., parameter modification, code release), operating entity (user or system process), precise timestamp, involved data dimensions (e.g., velocity, attitude), and a summary of the specific change content.

[0104] 2) Determine the influence relationships between nodes.

[0105] This is accomplished by a pre-trained Graph Neural Network (GNN) model, which learns from massive amounts of historical change data and system operation logs to grasp the potential causal relationships between different change events. When a new change event node is generated, edges are generated: Candidate nodes are initially screened based on rules and prior knowledge: Based on the preset rule base (such as "configuration changes within the same service will affect the data output of the service") and time proximity, candidate nodes that may be associated with the new node are screened from the graph.

[0106] Relationship prediction: Pair the new node with each candidate node, extract their attribute features (such as change type, involved dimension, time difference, etc.) as input, and feed them into the GNN model. The model will output a probability value representing the direct or indirect influence relationship between the two nodes.

[0107] Edge creation and attribute assignment: When the probability value exceeds a preset threshold (e.g., 0.8), the system creates a directed edge between the two nodes. The direction of the edge is determined by the temporal sequence and causal logic. At the same time, the edge's attributes (A(E)) are also assigned values, such as the type of impact (direct / indirect), the intensity of the impact (W, which can be quantified directly using the model's output probability value, such as 0.9), and the delay (the time difference before the change takes effect).

[0108] 3) Dynamic construction and maintenance of the map.

[0109] As the flight simulator system operates, new change event nodes and influencing relationship edges are continuously added to the graph, making it a knowledge base that can reflect the dynamic evolution of the system in real time.

[0110] More preferably, the graph is regularly inspected to automatically repair any broken links (e.g., by using knowledge graph reasoning to fill in missing indirect relationships), ensuring the integrity and accuracy of the graph.

[0111] The fourth embodiment of this application provides a method for backtracking flight simulator data based on change maps, which further explains the pre-training of the anomaly detection model in the first embodiment.

[0112] The anomaly detection model is an isolated forest model. The anomaly detection model is pre-trained using the following method: 1) Construct the training set; Data source: Extract historical normal simulator operating condition data (such as attitude parameters, control surface parameters, etc.) as a baseline, and mix in 5%-10% of simulated abnormal data (such as instantaneous false alarms of simulated sensors, high-frequency illegal changes, etc.).

[0113] Feature engineering: The continuous time series data is divided into sample windows of fixed length (e.g., 60 minutes) using the "sliding window method".

[0114] Feature extraction: For each window sample, extract two types of core features: Change-related characteristics: number of changes in the window, percentage of change types, and percentage of abnormal change markers; Numerical statistical characteristics: After performing Min-Max normalization on physical quantities such as temperature, voltage, current, and rotational speed, the mean, volatility, and extreme value characteristics within the calculation window are calculated.

[0115] Rule construction: Ensure that normal changes are reflected as low-temperature fluctuations and low-frequency changes; abnormal data are reflected as high-frequency changes or values ​​exceeding physical constraints, forming significant isolated characteristics.

[0116] 2) The training process is as follows: The constructed training dataset is input into the Isolation Forest model for training. The model's hyperparameters are optimized based on data change scenarios. In this embodiment, the preferred and validated parameter combinations are shown in Table 1: Table 1 Examples of hyperparameter configurations for the isolated forest model

[0117] An isolation tree is constructed by randomly partitioning the feature space, and the isolation path length of each time-series window sample in the tree is calculated. The shorter the path, the earlier the data in that window was "isolated" due to deviation from the normal distribution. 3) Abnormal reasoning and risk scoring A well-trained isolation forest model will output two types of information for a single sample: Unsupervised prediction label: value is 1 (classified as normal sample) or -1 (classified as abnormal sample).

[0118] Raw anomaly score: a continuous value in the range of [-1, 1]. The lower the score, the more abnormal the sample is.

[0119] To maintain consistency with the binary logic in the business system, a transformation rule is defined: the unsupervised label -1 output by the model is converted to the business anomaly label 1, and label 1 is converted to the business normal label 0. That is: , .

[0120] To obtain a more intuitive 0-100 risk score R, a linear transformation was performed on the original anomaly scores. The original scores of [-1,1] were converted to [0,100] (higher scores indicate greater anomalies). Subsequently, risk levels were determined based on the R values, as shown in Table 2.

[0121] Table 2

[0122] 4) Marking suspicious moments and abnormal operations Based on the abnormal score results, the following two-stage labeling is performed: A. Mark suspicious times (locate abnormal time periods): First, identify anomalous windows with scores higher than 50 (e.g., a 60-minute window). Then, calculate the "feature contribution within the window" and trace back the time range of that window in the original time series data. Calculate the instantaneous anomaly degree of each sampling point within the window (combining numerical deviation and change type weights), and select the specific sampling point with the highest anomaly degree (accurate to milliseconds) as the optimal suspicious moment.

[0123] B. Mark abnormal operations (identify specific changes): The marking of abnormal operations needs to combine the abnormal score with the specific characteristics of the change behavior, as follows: Preliminary assessment: If the standardized anomaly score R of the window to which a data change operation belongs is ≥50 (i.e., medium or high risk).

[0124] Rule combination marking: After meeting the above scoring conditions, the following rules are further combined for marking: (a) Abnormal scores ≥ 50 points; (b) The change type is "deletion" or belongs to "frequent modification"; (c) The operator belongs to the preset "high-risk user" list, or the field being changed belongs to the "core field"; (d) The change in value is greater than 80%.

[0125] If one or more of the rules (a), (b), (c), and (d) above are met, the operation will be marked as an "abnormal operation". The "abnormal operation record" generated by the mark shall contain at least the following fields: operation unique ID, timestamp, operation subject (account / IP), change type, fields or data dimensions involved, abnormal score, and risk level.

[0126] Based on the core logic that anomalous data is more easily isolated, this method randomly divides the feature space and calculates the length of the isolated path for each time series window. The shorter the path, the more likely it is to be considered an anomalous window. Without assuming data distribution, it directly scores anomalies within the time series window (the interval after aggregating consecutive anomalous points), focusing on quickly identifying anomalies with strong isolation (such as sudden jump windows). This embodiment fully discloses a closed-loop technical solution from constructing a dataset with verification labels, training and evaluating the model, to defining the model output interpretation and business application rules, enabling those skilled in the art to implement and verify the anomaly detection method.

[0127] As another example, and more preferably, the anomaly detection model can also be an autoencoder. The core logic for obtaining anomaly scores through the autoencoder is to "quantify the degree of anomaly based on the reconstruction error of the autoencoder," and then correct it by combining the confidence of the classification branch, ultimately obtaining a quantized score of 0-100 (the higher the score, the higher the degree of anomaly). Specifically, the steps are as follows: Step 1: Extract actual normal (e.g., compliant updates, routine additions and deletions) and abnormal (e.g., unauthorized tampering, unauthorized modifications) change records from database audit logs and business system logs. After sample screening and deduplication, extract core features, perform standardization processing, and obtain a standardized feature vector X. Construct a dataset containing normal and abnormal change samples, and define core labels (normal / abnormal) and auxiliary labels (specific abnormal types).

[0128] For each data change record, we extract the core dimensions that reflect the characteristics of the change (adapted to autoencoder input, balancing discriminability and practicality). The specific features are as follows: Change basic characteristics: Change type (e.g., Add=1, Modify=2, Delete=3, Format adjustment=4), Change duration (milliseconds from start to end of operation), Change data volume (number of data records / bytes involved in a single change); Operating entity characteristics: Operating account ID (encoded as a number), operating device IP (encoded as a number), operating permission level (e.g., no permission = 0, normal permission = 1, administrator permission = 2), operation frequency per unit time (number of changes made by this account within 1 hour); Data attribute characteristics: Importance level of the changed data (e.g., core data = 3, important data = 2, ordinary data = 1), differences between data before and after the change (value difference for numerical data, edit distance for text data, and 0 / 1 difference for Boolean data), and data format consistency (the degree of matching between the changed format and the standard format, between 0 and 1).

[0129] To address the scarcity of anomalous samples, various anomalous changes are simulated (such as simulating high-frequency batch deletion and core data tampering) to enhance the diversity of the dataset.

[0130] The standardization process specifically includes: The extracted features are standardized (using Min-Max standardization to map feature values ​​to the [0,1] interval) to eliminate the influence of units. Missing values ​​are filled with the mean of similar samples (e.g., the average operation frequency for the same operation permission), and outliers (e.g., change durations exceeding a reasonable range) are truncated. The preprocessed samples are divided into training, validation, and test sets in a 7:2:1 ratio to ensure consistent sample distribution across the three datasets (equal proportion of normal / outlier samples) and avoid data bias.

[0131] Define core tags and auxiliary tags, specifically including: Core tags: Used for reconstruction training of autoencoders, aiming to minimize the reconstruction error of normal samples, based on pre-defined business rules, and used for subsequent quantitative evaluation of model performance.

[0132] Auxiliary labels: Multi-class labels (such as illegal tampering, unauthorized operation, abnormal batch deletion, format disorder, high frequency change) are used to guide the model to learn the feature differences of different anomaly types.

[0133] The core tag definition rules are as follows: Normal label change (Label=0): Data changes and values ​​within the window are all within a reasonable range; Abnormal Change Label (Label=1): The data within the window meets any of the following preset abnormal rules: Abnormal Change Frequency Rules: Total number of changes within the window ≥ 5 (high-frequency changes); Numerical anomaly rule: The normalized value of a key physical quantity (such as temperature or voltage) is >0.8 (abnormally high).

[0134] In one specific embodiment, the autoencoder network structure adopts a symmetrical architecture, with the number of neurons in the encoder hidden layer decreasing layer by layer (e.g., 10→6→3) to generate low-dimensional latent vectors (3-5 dimensions); the decoder increases symmetrically (e.g., 3→6→10). The encoder output layer is connected to a Softmax classification branch to output the confidence scores of various anomalies. Its training parameters can be set as follows: initial learning rate 0.001 (with a decay strategy), and Dropout rate 0.2-0.3.

[0135] The trained model is evaluated using a validation set with basic validation labels (Label=0 / 1). The model's predictions are compared with the basic validation labels, and metrics such as accuracy and recall are calculated to quantify the model's ability to identify anomalous changes, ensuring that the model reaches a preset performance threshold (e.g., accuracy ≥ 95%).

[0136] Step 2, Reconstruction Error Calculation (Core Quantization Metric): Input the feature vector X into the trained autoencoder body, obtain the latent vector through the encoder, and then output the reconstructed feature vector through the decoder. Calculate X and The mean squared error (MSE), used as a basic anomaly indicator, is calculated as follows: ,in The number of feature dimensions. The eigenvector X is the first... Each dimension value To reconstruct the feature vector The Each dimension has a value; the larger the MSE, the further the data change characteristics deviate from the normal distribution learned by the model, and the higher the degree of anomaly.

[0137] Step 3, Classification Confidence Correction: Input the vector output by the encoder into the classification branch to obtain the confidence score of the data change belonging to each anomaly type (e.g., the confidence score for "illegal tampering" is 0.88, and the confidence score for "normal change" is 0.12). Take the highest confidence score. ; The correction rule used is as follows: like The corresponding label is "Normal Change" (label 0), then the corrected reconstruction error is... =MSE×0.8 (attenuation error, reducing outlier scores and avoiding misjudgments); like The corresponding label is "abnormal change" (labels 1-5), then the corrected reconstruction error is... =MSE×1.2 (Enhances error, improves anomaly scores, and avoids missed detections); Step 4: Standardize the scoring (quantified into 0-100 points): The corrected score... The score is mapped to 0-100 points, using segmented mapping and smoothing to ensure reasonable scoring and a natural transition. (1) Segmented mapping rules: when ≤ Normal reconstruction error threshold ( An abnormal score is 0-20 (judged as a normal change); when < <Abnormal reconstruction error threshold ( An abnormal score of 20-80 points (determined as a suspicious change); when ≥ An abnormal score of 80-100 points is considered a serious abnormal change. (2) Smoothing: The scoring results are smoothed using the Sigmoid function: ; in, The smoothing factor (set to 0.5) for and The average value is used to avoid abrupt changes in scoring and ensure a smooth transition between adjacent changes in scoring.

[0138] Step 5: Final score output: Output a smoothed score of 0-100, retaining one decimal place, as the final outlier score for this data change.

[0139] Autoencoders are unsupervised deep learning models that compress temporal window data into low-dimensional features through an encoder, and then reconstruct the original data through a decoder. The larger the reconstruction error, the more likely it is to be considered an abnormal window. Relying on the latent distribution of the data, they can capture abnormal coupling and correlation of parameters within the temporal window (such as the multi-parameter linkage drift window in a simulator).

[0140] More preferably, the threshold is divided into "normal reconstruction error threshold (...)" ")" and "Abnormal reconstruction error threshold ( The thresholds were determined using test set data during the model calibration phase to ensure their rationality and universality. The specific steps are as follows: The trained model is used to reconstruct all samples (normal samples + abnormal samples) in the test set. The MSE of each sample is calculated, and the MSE distributions of normal samples and abnormal samples are statistically analyzed separately. The 95th percentile of the MSE of all normal samples in the test set is taken as... The quintile of the MSE of all anomalous samples in the test set is taken as... .

[0141] In this embodiment, the two determined thresholds can be further validated using validation set samples to calculate the false positive rate (the proportion of normal samples misclassified as abnormal, and the proportion of abnormal samples misclassified as normal); if the false positive rate > 5%, the thresholds are fine-tuned (e.g., ...). Increase by 5% Lower the threshold by 5% until the false positive rate is ≤5%. As business scenarios change and data change patterns are updated, recalibrate the threshold periodically (e.g., monthly) with new historical change samples to ensure that the threshold always adapts to the current data change scenario and avoids abnormal score deviations due to scenario changes.

[0142] Step 6: Based on the anomaly score results, model classification output, and data change logs, accurately mark suspicious moments and abnormal operations. The marking logic aligns with actual business needs, facilitating subsequent investigation. The specific method is as follows: 1) Mark suspicious times, specifically including: Single change suspicious marker: If the abnormal score of a certain data change is between 20 and 80, the operation time is directly marked as "suspicious time", and the score result and change type are marked; Suspicious Continuous Changes: If there are 3 or more consecutive data changes within 10 minutes, and the abnormal score shows a gradual upward trend (e.g., 15 points → 30 points → 55 points), even if the score of a single change does not reach 20 points, all changes within that time period will be marked as "suspicious moments" and labeled "continuous abnormal increase". Archive the marked suspicious times, corresponding change records, abnormal scores, and operating entities, and sort them in chronological order to facilitate subsequent tracing and investigation.

[0143] 2) Abnormal operation flags, specifically including: Preliminary marking of abnormal operations: Data changes with an abnormal score ≥ 80 are initially marked as "abnormal operations". Based on the output of the classification branch, the specific abnormal type is marked (such as "illegal tampering" or "unauthorized operation"). Suspicious Time Review: For the marked suspicious time (20-80 minutes), extract the corresponding change records (data before and after the change, operation subject, operation permissions, etc.) and review them to confirm whether they are abnormal operations; if they are confirmed to be abnormal, upgrade the mark to "abnormal operation" and add review comments; if they are confirmed to be normal, remove the suspicious mark and mark it "review normal". Abnormal operation warning and archiving: For marked abnormal operations, warnings are triggered in real time (such as push notifications and log annotations), and archived according to the abnormality type, recording the processing results (such as "intercepted", "rectified", "source traced"), forming a complete closed loop for abnormal operation handling.

[0144] For confirmed abnormal operations, mark the following core information to ensure that the investigation can be implemented: Basic information: operation time, operation subject (account ID, device IP), operation permissions, change type; Abnormal information: abnormal score, specific abnormal type, reconstruction error value, classification confidence level; Data information: Data content before and after the change, amount of data changed, and data importance level.

[0145] Further preferably, to improve the recognition accuracy, an isolated forest is first used for coarse detection across the entire region to quickly locate all discrete suspicious abnormal time periods, and then an autoencoder is used for fine detection of time-series windows to identify continuous drift and coupled abnormal time periods. The scores of the two types of abnormalities are weighted, fused, and normalized to obtain a comprehensive abnormal score.

[0146] The fifth embodiment of this application proposes a flight simulator data backtracking system based on change maps, comprising: The anomaly detection module is configured to monitor multi-source time-series data of the flight simulator, perform anomaly detection, and determine the abnormal time period. The root cause analysis module is configured to map the abnormal time period to the corresponding node of a pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between the nodes; The backtracking selection module is configured to retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and to sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version; The differential rollback module is configured to perform a difference comparison between the target rollback version and the current abnormal data state based on a joint identifier composed of the primary key and timestamp, and generate a minimum rollback package containing only the difference data; it is also configured to perform incremental rollback based on the minimum rollback package to restore the data state to the target version; The business rule verification module is configured to verify the rolled-back data based on the business rules of the flight simulator. If the verification passes, the status is fixed and an audit log is generated. If the verification fails, a rollback is executed or a new target rollback version is determined.

[0147] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the system described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0148] It should be noted that the flight simulator data backtracking system based on change maps provided in the above embodiments is only an example of the division of the above functional units. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of this application can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of this application are only for distinguishing the various modules or steps and are not considered as an improper limitation of this application.

[0149] A device according to the sixth embodiment of this application includes: At least one processor; and a memory communicatively connected to at least one of the processors; The memory stores instructions that can be executed by the processor to implement the aforementioned method for backtracking flight simulator data based on change maps.

[0150] A computer-readable storage medium according to a seventh embodiment of this application stores computer instructions that are executed by a computer to implement the above-described method for backtracking flight simulator data based on a change map.

[0151] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0152] The following is for reference. Figure 2 It shows a schematic diagram of the structure of a computer system for implementing the methods, apparatus, and electronic devices of this application. Figure 2 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0153] like Figure 2As shown, the computer system includes a Central Processing Unit (CPU) 201, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 202 or programs loaded from storage into Random Access Memory (RAM) 203. The RAM 203 also stores various programs and data required for system operation. The CPU 201, ROM 202, and RAM 203 are interconnected via a bus 204. An Input / Output (I / O) interface 205 is also connected to the bus 204.

[0154] The following components are connected to I / O interface 205: an input section 206 including a keyboard, mouse, etc.; an output section 207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 208 including a hard disk, etc.; and a communication section 209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 209 performs communication processing via a network such as the Internet. A drive 210 is also connected to I / O interface 205 as needed. Removable media 211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 210 as needed so that computer programs read from them can be installed into storage section 208 as needed.

[0155] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 209, and / or installed from removable medium 211. When the computer program is executed by central processing unit (CPU) 201, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but 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 may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, 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 devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0156] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0158] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0159] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0160] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. Without departing from the principles of this application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of this application.

Claims

1. A change map based flight simulator data backtracking method, characterized in that, Includes the following steps: Monitor multi-source time-series data from flight simulators, perform anomaly detection, and determine abnormal time periods; The abnormal time period is mapped to the corresponding node of a pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between the nodes; Retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version; Perform a difference comparison between the target rollback version and the current abnormal data state, and generate a minimal rollback package containing only the difference data; Incremental rollback is performed based on the minimum rollback package to restore the data state to the target version; The rolled-back data is verified according to the flight simulator's business rules. If the verification passes, the status is fixed and an audit log is generated. If the verification fails, a rollback is executed or a new target rollback version is determined.

2. The flight simulator data regression method based on change map according to claim 1, characterized in that, The method for monitoring multi-source time-series data from flight simulators and detecting anomalies is as follows: When a change in the time series data of the flight simulator is detected, multi-source time series data of the flight simulator within a preset time window before and after the data change event is collected and preprocessed. A hybrid neural network is used to extract features from the preprocessed multi-source time-series data to obtain time-series feature vectors, and the time-series feature vectors are associated with the corresponding graph nodes. The time-series feature vector is input into a pre-trained anomaly detection model to calculate a quantified anomaly score, and the anomaly time period is determined based on the anomaly score.

3. The method for backtracking flight simulator data based on change maps according to claim 2, characterized in that, The hybrid neural network is a hybrid neural network of convolutional neural network and long short-term memory network; the hybrid neural network is used to extract features from the preprocessed multi-source time series data, specifically as follows: Local spatial features are extracted from multi-source time-series data using convolutional neural networks, and long short-term memory networks are used to extract long-range time-dependent features from multi-source time-series data. The local spatial features and the long-range time-dependent features are then fused to generate a fixed-dimensional time-series feature vector.

4. The method for backtracking flight simulator data based on change maps according to claim 2, characterized in that, The anomaly detection model is an isolated forest model, which calculates the anomaly score of the temporal feature vector, specifically including: Within a time window consistent with the aforementioned time window, statistical features including change frequency, change type distribution, and the mean and variance of preset physical quantities, as well as the first-order difference peak value, are extracted as input to calculate the isolation degree index. Based on the isolation level index, combined with preset standardization rules, it is converted into a quantitative anomaly score.

5. The method for backtracking flight simulator data based on change maps according to claim 1, characterized in that, The root cause change event that leads to the anomaly specifically includes: The abnormal time period is mapped to a graph abnormal node according to the temporal proximity and dimensional matching degree. Multiple source tracing paths are generated by traversing in reverse along the edges from the graph abnormal node. A comprehensive score is calculated for each tracing path. The comprehensive score is determined based on the influence intensity of the edges in the path, the consistency of the delay between the change time and the abnormal time, the dimension matching degree, and the change execution status. The upstream change event node in the tracing path with the highest comprehensive score is identified as the root cause event; The node attributes of the data change graph include at least the change event identifier, change type, operation subject, timestamp, data dimension involved, and change content. The attributes of the edges include at least the impact type, impact intensity, and delay before the change takes effect.

6. The method for backtracking flight simulator data based on change maps according to claim 1, characterized in that, The multi-objective quantitative score is obtained by dynamically weighting data integrity score, data availability score, and business continuity score; the dynamic weights are adjusted based on feedback from historical rollback results through an online learning mechanism.

7. The method for backtracking flight simulator data based on change maps according to claim 6, characterized in that, The business continuity score is obtained by weighting time continuity, indicator smoothness, and change continuity; wherein, time continuity is determined based on the proportion of continuous sampling duration without gaps in the timestamps of the backtracking data; indicator smoothness is determined based on the proportion of key business indicators with no abnormal jumps in the rate of change under the first difference; and change continuity is determined based on the completeness of the change event chain corresponding to the backtracking version.

8. The method for backtracking flight simulator data based on change maps according to claim 1, characterized in that, The minimum rollback package is generated as follows: Using primary key and timestamp as a combined identifier, a difference comparison is performed between the target retrospective version and the current abnormal data state to identify newly added, modified, and deleted difference records; wherein, the modification set contains the fields that have differences and their target values, and carries the target version identifier and difference statistical metadata; The difference record, along with metadata containing the target version identifier and difference statistics, is encapsulated into the minimum rollback package.

9. The method for backtracking flight simulator data based on change maps according to claim 1, characterized in that, The rolled-back data is validated according to the flight simulator's business rules, including at least one of the following: Time continuity check is used to determine whether the timestamp of a data frame is monotonically increasing and the interval is within a preset sampling range; The physical rationality verification of flight attitude is used to determine whether the rate of change of pitch angle, roll angle and yaw angle is within the safe threshold. Control input continuity check is used to determine whether there are any unsmooth jumps in the control input of the control stick, rudder and throttle. Flight control system state consistency verification is used to determine whether there are any contradictions in the state logic of subsystems, including landing gear state and speed limit, hydraulic system state and servo response.

10. A flight simulator data backtracking system based on change maps, characterized in that, include: The anomaly detection module is configured to monitor multi-source time-series data of the flight simulator, perform anomaly detection, and determine the abnormal time period. The root cause analysis module is configured to map the abnormal time period to the corresponding node of a pre-constructed data change graph to locate the root cause change event that caused the abnormality; wherein, the data change graph is constructed based on historical data, the node represents historical data change events, and the edge represents the dependency or influence relationship between the nodes; The backtracking selection module is configured to retrieve multiple candidate historical data versions recorded before the root cause change event occurred, and to sort the candidate historical data versions by multi-objective quantitative scoring to determine the target backtracking version; The differential rollback module is configured to perform a difference comparison between the target rollback version and the current abnormal data state based on a joint identifier composed of the primary key and timestamp, and generate a minimum rollback package containing only the difference data; it is also configured to perform incremental rollback based on the minimum rollback package to restore the data state to the target version; The business rule verification module is configured to verify the rolled-back data based on the business rules of the flight simulator. If the verification passes, the status is fixed and an audit log is generated. If the verification fails, a rollback is executed or a new target rollback version is determined.

Images