Civil aviation database inspection data intelligent maintenance method and system

Abstract

This invention discloses a method and system for intelligent maintenance of civil aviation database inspection data, belonging to the field of computer technology. The method includes: collecting database operation status data and processing it into standardized time-series data blocks; calculating the hash value of the data blocks and concatenating them into a hash chain, writing it to the blockchain for trusted storage; establishing a dynamic health assessment model based on business calendars and historical data and calculating real-time scores; when the score is below a threshold, automatically issuing an early warning through a smart contract and linking it to the emergency command system; using graph neural networks and knowledge graphs to locate root causes and generate personalized solutions; verifying the effectiveness of the solutions and accumulating the processing experience in the blockchain and knowledge graph; training a prediction model based on historical data to achieve predictive maintenance. The system includes collaborative functional modules for implementing the above steps. This invention achieves data storage and tamper-proofing, real-time anomaly detection, intelligent fault diagnosis, and predictive maintenance, improving the automation and reliability of civil aviation database operation and maintenance.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a method and system for intelligent maintenance of civil aviation database inspection data. Background Technology

[0002] In the digital operation system of civil aviation, the database serves as the data support platform for core businesses such as flight scheduling, passenger services, and security control. Its stable operation is directly related to airport operating efficiency and passenger travel experience. With the expansion of business scale and the surge in data volume, higher requirements are placed on the real-time performance, reliability, and security of the database. Traditional inspection methods usually rely on manually setting thresholds for monitoring and storing data in a centralized system, which lacks an effective anti-tampering mechanism and is insufficient in terms of data credibility and sharing traceability.

[0003] The current civil aviation database inspection technology mainly suffers from the following problems: First, the inspection data storage is centralized, making it susceptible to human or system factors, which makes it difficult to guarantee the authenticity and integrity of the data, and hinders cross-departmental sharing and fault tracing; second, anomaly warnings rely on fixed thresholds and manual notifications, resulting in large response delays and failing to meet the real-time requirements of civil aviation scenarios; third, health assessment models mostly use general indicators and fail to combine civil aviation business characteristics and time-based load changes, leading to high false alarm rates and inaccurate root cause identification; fourth, there is a lack of systematic accumulation and intelligent reuse of historical fault experience, resulting in the recurrence of similar problems and low operation and maintenance efficiency.

[0004] Therefore, there is an urgent need for a closed-loop maintenance solution that can achieve reliable data storage, real-time early warning of anomalies, accurate health assessment, and intelligent prediction and handling of faults, so as to improve the automation and intelligence level of civil aviation database operation and maintenance. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method and system for intelligent maintenance of civil aviation database inspection data, employing the following technical solution.

[0006] Firstly, a method for intelligent maintenance of civil aviation database inspection data includes the following steps: Collect general performance indicators and civil aviation-specific business indicators from database nodes as operational status data; The runtime status data is time-series aligned, cleaned, and standardized, and then cut into continuous data blocks according to a fixed time window; The hash value of each data block is calculated and cascaded to build a hash chain. The transaction data containing the hash chain is written into a consortium blockchain network composed of nodes from multiple parties in the civil aviation industry to achieve tamper-proof evidence storage. A dynamic health assessment model is built based on civil aviation business calendar and historical data. The dynamic health assessment model dynamically adjusts the indicator thresholds according to the current business period, and performs weighted fusion calculation on multiple indicators to output a real-time health score. When the score falls below the threshold, the blockchain smart contract is triggered to automatically generate and push an early warning message, while the early warning event is stored as evidence and cross-system emergency response is initiated. By using graph neural networks to analyze the causal relationships between abnormal indicators to locate the core root cause, and by combining fault handling knowledge graphs with historical cases, personalized solutions can be generated. Implement personalized solutions and verify their effectiveness. Encapsulate successful processing procedures as fault handling knowledge units, store them in the blockchain, and update them to the knowledge graph. The predictive model is trained based on historical data and fault handling knowledge units to predict future trends of key indicators and generate predictive maintenance recommendations.

[0007] Preferably, the operational status data undergoes time-series alignment, cleaning, and standardization processing, specifically including: The system clock of the server where the database performance view acquisition module is located is used as a unified time reference; Linear interpolation is used to align the data timestamps of the operating system resource acquisition module to the unified time base. The nearest neighbor interpolation method is used to align the data timestamps of the business log parsing module to the whole second of the unified time base; Forward filling is performed to complete missing values ​​in the data stream; A sliding window method based on statistical distribution is used to identify and remove outliers; Convert all indicator values ​​into a floating-point number format with a preset precision. The processed indicators are merged into a standardized data stream according to time sequence, and then cut into two-dimensional data blocks according to a preset duration.

[0008] Preferably, the process of calculating hash values ​​and constructing hash chains by cascading them includes: Serialize the two-dimensional data matrix of the current data block into a string; Calculate the hash value of the string as the hash of the current data block; The hash of the current data block is concatenated with the hash of the previous data block, and the hash is calculated again to obtain the chained hash value. The chained hash value, the time window information corresponding to the data block, and the digital signature are encapsulated into transaction data; The transaction data is submitted to a consortium blockchain network composed of nodes from multiple parties in the civil aviation industry, and stored as evidence after consensus is reached.

[0009] Preferably, a dynamic health assessment model is constructed, specifically including: The day is divided into several standard time periods based on flight schedules; For each monitoring indicator, the 95th percentile value of its historical data in each standard time period is calculated and used as the dynamic anomaly threshold for that time period. Identify special event days and increase the dynamic anomaly threshold by a preset ratio; Allocate a total weight to civil aviation-specific business indicators that is no less than that to general performance indicators; The normalized health contribution value is calculated based on the current value, dynamic threshold and historical mean of each indicator; The contribution values ​​of each indicator are weighted and summed to obtain a health score in the range of 0-100.

[0010] Preferably, triggering automatic alerts from smart contracts includes: The smart contract sorts the health scores based on the contribution of each indicator to the health score and identifies the main abnormal indicators. Query the predefined business-metric mapping table to identify the core business systems affected; Generate structured early warning messages that include an anomaly list, measured values, scores, and the scope of impact; Early warning messages are pushed to the operation and maintenance terminal via message queue; Calculate the hash value of the warning message and store it in the blockchain; The system calls the emergency command system interface to report event information, triggering a business status update.

[0011] Preferably, the core root cause is located using a graph neural network, specifically including: The nodes of the graph neural network correspond to various database metrics, and the edges between nodes are established based on statistical correlation and predefined business dependency rules. Abnormal index values ​​are used as node features and input into the graph neural network; The node status is updated iteratively through multi-layer message passing, and the anomaly contribution score of each node is calculated. The node with the highest abnormal contribution score is identified as the core root cause indicator node.

[0012] Preferred solutions that combine knowledge graph generation include: The fault handling knowledge graph stores fault entities and relationships extracted from historical documents in the form of triples. Map the core root cause indicator nodes and the historical root cause indicator entities in the knowledge graph to the same vector space; Calculate the similarity between vectors and match the historical case with the highest similarity; A customized solution is generated by referencing solutions from historical cases and combining them with the current database configuration parameters.

[0013] Preferably, knowledge is encapsulated and preserved, specifically including: After verifying the effectiveness of the solution, a fault handling knowledge unit is constructed, which includes early warning event identifiers, root cause indicators, implementation plans, remediation effects, and implementation information. The fault handling knowledge unit is serialized and hashed, and then submitted to the consortium blockchain network for storage. The root cause and solution relationships in the fault handling knowledge unit are converted into triples and injected into the fault handling knowledge graph.

[0014] Preferably, predictive maintenance recommendations are generated, specifically including: The time series prediction model is trained by taking the historical index sequence before fault repair as input and the stable data after repair as labels. Use models to predict key performance indicators ahead of future business peaks; Dynamically adjust the predicted alarm thresholds based on the business calendar; When the predicted value exceeds the threshold, maintenance suggestions including expansion, preloading, or rate limiting operations are automatically generated. Integrate maintenance recommendations into the pending tasks of the operation and maintenance plan system.

[0015] Secondly, a civil aviation database inspection data intelligent maintenance system includes: The multi-source data acquisition module is used to collect general performance indicators and civil aviation-specific business indicators from database nodes; The time-series data preprocessing module is used to perform time-series alignment, cleaning, standardization, and window segmentation on the collected data; The blockchain hash chain notarization module is used to construct a data block hash chain and write transaction data into the consortium blockchain network for notarization. The dynamic health assessment module is used to dynamically calculate thresholds based on the business calendar and integrate multiple indicators to output a health score. The smart contract early warning module is used to trigger automatic contract early warning, evidence storage, and emergency response when the score is abnormal; The root cause localization and solution generation module is used to locate the core root cause through graph neural networks and generate personalized solutions by combining knowledge graphs. The fault handling knowledge accumulation module is used to encapsulate successful handling experience and update the blockchain and knowledge graph; The predictive maintenance module is used to train the predictive model and generate predictive maintenance suggestions. Each module interacts with other modules and works collaboratively through a message bus.

[0016] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention calculates the hash value of the inspection data blocks after time-series processing, concatenates them into a chain, and writes them into a blockchain distributed ledger, thereby achieving the immutability and full traceability of data records. It effectively solves the problems of traditional centralized storage being easily tampered with and the lack of credible evidence for cross-departmental sharing, and provides reliable technical evidence for fault backtracking and responsibility determination.

[0017] 2. This invention relies on a dynamic health assessment model that integrates the characteristics of civil aviation business and an automatic early warning mechanism based on smart contracts. It can trigger an alarm and link the emergency system within seconds when the score is lower than the threshold. Furthermore, by analyzing the causal relationship between indicators through graph neural networks and combining historical knowledge graphs for case matching, it can accurately locate the root cause and generate personalized handling solutions, which can significantly improve the efficiency of fault response and diagnosis.

[0018] 3. This invention can encapsulate the complete process into a structured fault handling knowledge unit after each successful handling, and simultaneously store it on the blockchain and update the knowledge graph, realizing the continuous accumulation and intelligent reuse of operation and maintenance experience; at the same time, based on historical data, the predictive model can be trained to identify potential performance bottlenecks in advance and generate predictive maintenance suggestions, thereby reducing the recurrence rate of faults and realizing the transformation of operation and maintenance mode from passive response to proactive prevention. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the intelligent maintenance method for civil aviation database inspection data according to the present invention. Figure 2 This is a detailed flowchart of step S2 of the present invention; Figure 3 This is a detailed flowchart of step S3 of the present invention; Figure 4 This is a detailed flowchart of step S4 of the present invention; Figure 5 This is a detailed flowchart of step S5 of the present invention; Figure 6 This is a detailed flowchart of step S6 of the present invention; Figure 7 This is a detailed flowchart of step S7 of the present invention; Figure 8 This is a detailed flowchart of step S8 of the present invention. Detailed Implementation

[0020] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following detailed description of specific embodiments based on the present invention is provided in conjunction with the accompanying drawings and preferred embodiments.

[0021] This invention provides a method and system for intelligent maintenance of civil aviation database inspection data, aiming to solve the core problems existing in the current civil aviation database health inspection technology, such as low reliability of inspection data, delayed response to abnormal warnings, health assessment models being out of touch with civil aviation business scenarios, lack of intelligent decision support, and low efficiency in handling repetitive faults.

[0022] Reference Figures 1 to 8 As shown, a method for intelligent maintenance of civil aviation database inspection data includes the following steps: S1 collects database operation status data in real time through a multi-source data acquisition module deployed at the civil aviation database node.

[0023] S101 clarifies that the database operation status data to be collected includes two main categories: the first category is general performance indicators, and the second category is civil aviation-specific business indicators.

[0024] S102 collects the first type of general performance indicators, including CPU utilization, memory usage, disk I / O latency, transaction response time, and connection pool utilization.

[0025] S103 collects the second category of civil aviation-specific business indicators, including check-in transaction throughput, baggage tracking data packet loss rate, flight scheduling transaction rollback rate, and security check verification transaction failure rate.

[0026] S104, constructs the overall architecture of the multi-source data acquisition module, which integrates three dedicated data acquisition sub-modules: The database performance view acquisition submodule reads core performance metrics such as transaction response time and connection pool utilization once per second from Oracle's V$SYSSTAT view or MySQL's performance_schema database table by sending customized SQL queries to the database management system.

[0027] The operating system resource acquisition submodule obtains CPU usage, memory usage, and disk I / O latency data by calling or parsing the host operating system's standard performance monitoring interfaces, such as reading the contents of the / proc / stat file or executing the iostat command in a Linux environment.

[0028] The business log parsing and collection submodule analyzes application log files generated by business systems such as check-in, baggage tracking, and security check in real time based on predefined regular expressions or parsing rules, and extracts and calculates civil aviation-specific business indicators such as check-in transaction throughput and baggage data packet loss rate.

[0029] S105 configures the operating characteristics of the multi-source data acquisition module, ensuring that the three data acquisition sub-modules run with independent system threads, so that the data acquisition process is isolated from each other and does not interfere with each other.

[0030] Meanwhile, a breakpoint resume mechanism is designed and implemented for each submodule. This mechanism persists the timestamp of the last successfully acquired data point locally. When a submodule is interrupted due to network fluctuations or system restart, it can automatically read the timestamp upon restart and continue the data acquisition task from that moment onward. This ensures the continuity of the final uploaded data stream in the time dimension and avoids data interruption or overlap.

[0031] S2 performs time-series alignment and cleaning on the database operation status data collected by the multi-source data acquisition module, forming a standardized time-series data stream, and then cuts it into continuous data blocks according to fixed time windows. See details below. Figure 2 As shown.

[0032] S201, Determine the reference time source for timestamp alignment. Select the system clock of the server where the database performance view acquisition submodule is located as the unified time reference. The timestamps of all other acquisition submodules must be calibrated with reference to this reference.

[0033] S202, timestamp correction is performed on the data of the operating system resource acquisition submodule. The timestamp of the data of this submodule may have a microsecond-level deviation from the reference time source.

[0034] The system uses linear interpolation for correction. Specifically, for each data point to be corrected, a new, accurate timestamp aligned to the reference time line is calculated linearly according to the time ratio between the original timestamp and two known reference points before and after it on the reference time line.

[0035] S203, timestamp alignment is performed on the data of the business log parsing and collection submodule. The data sampling interval of this submodule is five seconds. The system uses the nearest neighbor interpolation method to align the timestamp of each log data point to the nearest whole second on the reference time source, thereby incorporating it into a unified time sequence framework in seconds.

[0036] S204 performs missing value processing in data cleaning, and detects in real time whether there are missing data points in the time series data stream of each indicator. Once a missing value is found, a forward filling strategy is immediately adopted to fill the current missing value with the value of the previous valid data point in the indicator sequence, so as to ensure the continuity of data in the time dimension.

[0037] S205, perform outlier filtering in data cleaning, and use the three-standard-deviation principle based on statistical distribution to identify and remove outlier data.

[0038] In practice, a sliding time window with a length of 300 sampling points is maintained for each indicator. The window slides forward once per second. Within each window, the mean and standard deviation of the data in that window are calculated. If the value of a data point in the window deviates from the mean of the window by more than three times the standard deviation, the point is determined to be an outlier and removed from the sequence.

[0039] S206 performs data format standardization processing, converting raw indicator values ​​from different data sources and with varying formats into double-precision floating-point numbers.

[0040] To ensure computational consistency and balance accuracy with storage efficiency, all values ​​are uniformly formatted to retain six decimal places, eliminating differences in the type and precision of the original data and forming a regular and uniform standardized index sequence.

[0041] S207 takes the data of each indicator that has undergone the above alignment, cleaning and standardization processes, and merges and splices them in strict chronological order to finally generate a continuous and regular standardized time-series data stream containing all monitoring indicators.

[0042] S208 divides the generated standardized time-series data stream into time-window blocks. The preset fixed time window length is sixty seconds, which means that the system will divide the continuous standardized time-series data stream into a series of continuous data blocks in units of sixty seconds. Each data block is a two-dimensional data matrix in structure. The rows of the matrix correspond to sixty consecutive time points, and the columns of the matrix correspond to all monitored indicators, thereby completely encapsulating the full-dimensional state information within a time window.

[0043] S3: For each standardized data block generated in step S2, calculate its global hash value, and concatenate this hash value with the hash value of the previous data block to construct a hash chain. Finally, write the transaction data representing this hash chain into the designated blockchain network distributed ledger. See details below. Figure 3 As shown.

[0044] S301, prepare the basic data for hash calculation of the data block to be processed.

[0045] First, the two-dimensional data block (i.e., the two-dimensional data matrix) representing the data block needs to be converted into a string that can be processed by the hash function. Using row-major order, all rows of the matrix are concatenated from beginning to end. Each floating-point index value is converted into a string according to the six decimal places defined in step S206. The values ​​are separated by commas, and the rows are separated by semicolons to ensure that the same data content always generates a completely consistent string representation.

[0046] S302, the secure hash algorithm 256 is used to calculate the string obtained after serialization to generate a fixed-length hash digest, which is the global hash value of the current data block.

[0047] S303, construct the hash chain structure.

[0048] For the first data block, its hash value is directly used as the starting node of the hash chain; for the subsequent nth data block, its hash value... It needs to be calculated using a specific formula that reflects the chain relationship with the preceding data block.

[0049] The specific calculation formula is as follows:

[0050] in, This represents the hash value of the (n-1)th data block. This represents the original string after the nth data block is serialized through step S301, and the symbol || represents the string concatenation operation.

[0051] S304 encapsulates the calculated hash chain structure into a blockchain transaction data entry. The encapsulated content includes not only the core hash value of the current data block, but also other related information. Furthermore, necessary metadata must be attached to complete the transaction information.

[0052] The metadata specifically includes the start and end timestamps of the time window corresponding to the data block, the total number of indicators contained in the data block, and the digital signature information of the submitter. The digital signature uses the submitter's private key to sign the core content of the transaction, which is used to verify the authenticity of the data submission source and the integrity of the transaction content.

[0053] S305 configures the specific architecture and operating parameters of the target blockchain network, using a consortium blockchain as the underlying evidence storage network to adapt to the characteristics of multi-party collaboration and access control required in the civil aviation industry.

[0054] The participating nodes in the consortium blockchain mainly include the Civil Aviation Information Technology Center, information centers of major airports, and airline data centers. The network consensus mechanism employs a practical Byzantine fault-tolerant algorithm, achieving a good balance between efficiency and fault tolerance while ensuring the identities of participating nodes are known. Furthermore, based on the estimated size and frequency of inspection data blocks, the maximum size of a single block is set at 4 megabytes, and the average time interval for network block generation is configured to approximately 5 seconds to ensure that inspection data can be promptly confirmed and stored.

[0055] S306. The packaged transaction data is submitted to the configured consortium blockchain network. The consensus nodes in the network verify the validity of the transaction according to the practical Byzantine fault tolerance algorithm mechanism. After the verification is passed, it is packaged into a new block and finally recorded sequentially in the distributed ledger of all nodes, thereby completing the immutable evidence storage of the current inspection data block.

[0056] S4, based on civil aviation business calendar information and historical operational data, constructs a dynamic health assessment model, as detailed in [reference needed]. Figure 4 As shown.

[0057] S401, the time-period adaptive threshold module for building the model, first divides the day into three standard time periods with different load characteristics based on a typical civil aviation flight schedule: The morning peak hours are set from 6:00 to 10:00, the evening peak hours are set from 16:00 to 22:00, and the rest of the time is uniformly defined as off-peak hours.

[0058] S402 handles threshold adjustments for special event periods. For major holidays such as National Day and Spring Festival, or during specific large-scale conferences, the system supports two ways to enter special event mode.

[0059] One method is for maintenance personnel to manually mark the time period; the other is for the system to automatically identify it based on the built-in statutory holiday calendar and major event schedule.

[0060] During special event periods, the system will temporarily adjust the dynamic thresholds of all indicators to 1.2 times the original value, that is, increase the threshold tolerance by 20%, in order to match the expected increase in business pressure.

[0061] S403, calculate the dynamic abnormal threshold of each indicator in the corresponding time period, retrieve the historical operation data of the past 90 days, and for each monitored indicator, calculate the 95th percentile value of all sample data in the three time periods of morning peak, evening peak and off-peak.

[0062] The calculated 95th percentile value is determined as the initial abnormal threshold for the indicator in the corresponding period. For example, the dynamic threshold for transaction response time during the morning peak period is the 95th percentile of the indicator value in all morning peak periods over the past 90 days.

[0063] S404, the multi-indicator fusion scoring module for building the model, first determines the set of all indicators involved in the health scoring and formulates a weight allocation strategy. The core principle of this strategy is to highlight the health of civil aviation business and require that the total weight allocated to civil aviation-specific business indicators is not lower than the total weight of general performance indicators.

[0064] S405 executes the specific weight allocation.

[0065] Based on business importance, key civil aviation business indicators are assigned higher weights: baggage tracking data packet loss rate is weighted at 0.25, flight scheduling transaction rollback rate is weighted at 0.20, and check-in transaction throughput is weighted at 0.15.

[0066] At the same time, weights were assigned to key performance indicators: transaction response time was weighted at 0.15, and connection pool utilization was weighted at 0.10.

[0067] The remaining four metrics—CPU utilization, memory usage, disk I / O latency, and security check transaction failure rate—are each weighted equally by 0.15, meaning each metric has a weight of 0.0375.

[0068] S406, based on the currently collected real-time indicator data and dynamic thresholds, calculates the database health score. The score calculation formula is:

[0069] Where S represents the final health score, The weight represents the i-th indicator. This represents the current measured value of the indicator. This represents the dynamic threshold of the indicator in the current time period.

[0070] S407, Define the normalization function in the formula. The function maps the deviation between the measured value and the threshold of each indicator to a health contribution value between 0 and 1, where 1 represents the best state.

[0071] The function is specifically defined as follows:

[0072] in, This represents the long-term historical average of the i-th indicator in the current period, which is obtained by calculating the arithmetic mean of all data for the indicator in the same period over the past 90 days.

[0073] Finally, the health score S, calculated by weighting and summing all indicators, has a theoretical range of 0 to 100. The higher the actual score, the better the overall health status of the database.

[0074] S5: When the database health score falls below a preset health threshold, an automated early warning mechanism is triggered, which executes smart contracts deployed on the blockchain. See details... Figure 5 As shown.

[0075] S501 sets clear health score warning trigger conditions, defines the preset health threshold as 70 points, continuously monitors the database health score calculated by the dynamic health assessment model, and immediately triggers the smart contract's warning execution logic once the score is detected to be below 70 points.

[0076] S502, determine and encapsulate the core content of the warning message.

[0077] First, the smart contract needs to reverse-engineer the main anomaly indicators based on the scoring formulas of S406 and S407. The specific method is as follows: Calculate the individual health contribution value for each monitoring indicator. The indicators were sorted from lowest to highest contribution value, and the three lowest-ranked indicators were selected as the main abnormal indicators that caused the low health score.

[0078] S503, the scope of business that may be affected by the associated early warning event is determined based on the business-metric mapping relationship table that is pre-configured in the smart contract or accessible.

[0079] This business-metric mapping table explicitly predefines the names of the core business systems that each monitoring metric directly affects. For example, the table defines baggage tracking data packet loss rate as mapped to the baggage tracking system, and flight scheduling transaction rollback rate as mapped to the flight scheduling system.

[0080] Based on the abnormal indicators identified by S502, the smart contract queries this mapping table to quickly obtain a list of associated business systems.

[0081] S504 generates and sends an early warning message.

[0082] The smart contract automatically encapsulates the warning message into a structured data object, which contains the following fields: a list of abnormal indicators and their current measured values, the current health score, the precise timestamp of the event, and a list of related business impacts.

[0083] Subsequently, the smart contract calls the message queue service interface provided by the deployment environment to push the structured warning message in real time to the mobile and desktop terminals of the operations and maintenance personnel who have pre-subscribed to the alarm topic, ensuring that it is available within seconds.

[0084] S505 provides credible evidence of the warning event itself.

[0085] While sending the warning message, the smart contract uses the structured warning message content generated in S504 as input data to calculate its SHA-256 hash value; then the smart contract initiates a new blockchain transaction, the main payload of which is the hash value of this warning event.

[0086] After the transaction is reached through network consensus, it is permanently recorded in the blockchain distributed ledger, thereby ensuring that the warning event record is immutable and fully traceable.

[0087] S506, initiate cross-system emergency response.

[0088] After completing internal alerts and evidence storage, the smart contract early warning mechanism automatically calls the event reporting service of the civil aviation emergency command system through a predefined application programming interface.

[0089] When invoked, the smart contract will transmit a standardized data packet containing key information such as event number, event type, health score, anomaly indicators, associated business systems, and blockchain-based notarized transaction ID.

[0090] After receiving the data, the emergency command system will officially enter the abnormal event into the unified emergency event management database, and automatically update the collaborative status identifier of the relevant flight support tasks based on the information of the associated business systems, thereby realizing information synchronization and automated linkage between the operation and maintenance alarm system and the production command system.

[0091] S6, in response to an early warning event, initiates the root cause analysis and solution generation module. See details... Figure 6 As shown.

[0092] S601, constructs a causal dependency graph between anomaly indicators based on a pre-trained graph neural network model.

[0093] Each node of the graph neural network model corresponds to a specific database operation metric. The training data of the graph neural network model comes from snapshots of metric data collected when historical early warning events are triggered and their final confirmed root cause metric labels.

[0094] The training objective is to enable the graph neural network model to learn to output anomaly contribution distributions that match manually labeled root causes based on the correlation patterns between indicators. The loss function is designed as a cross-entropy loss that combines the ranking priority of root cause nodes.

[0095] S602 establishes edge connections between nodes in a graph neural network model, and the establishment of edges is based on two types.

[0096] The first type is the statistical correlation edge, which is established by calculating the Pearson correlation coefficient between any two indicator sequences in the past 30 days. When the absolute value of the correlation coefficient is greater than 0.7, an undirected edge is established between the two indicator nodes.

[0097] The second type is business logic dependency edges, whose connection relationships are obtained from a predefined expert knowledge base. This expert knowledge base is stored in the form of a list of rules. Each rule explicitly declares that one indicator has a direct impact on another indicator. For example, high connection pool utilization may lead to an increase in transaction response time. Directed edges are established between the corresponding indicator nodes based on such rules.

[0098] S603, run the graph neural network model to perform root cause analysis.

[0099] The abnormal indicator values ​​corresponding to the current warning event are used as the initial features of the corresponding node and input into the graph neural network model. The graph neural network model adopts a multi-layer message passing mechanism, which allows each node to aggregate the state information of all its neighboring nodes.

[0100] After multiple rounds of iterative calculations, the graph neural network model outputs an anomaly contribution score for each indicator node in the graph. This score quantitatively reflects the degree of influence of the indicator corresponding to that node on the current overall health score decline.

[0101] S604. Based on the output of the graph neural network model, identify the core root cause node, select the indicator node with the highest abnormal contribution score, and determine it as the core root cause of this health abnormality.

[0102] S605, retrieve historical fault handling knowledge graphs to find reference solutions.

[0103] The knowledge graph is automatically constructed using natural language processing technology. The specific process is as follows: Named entity recognition technology is used to extract entities such as fault phenomena, operation steps, and configuration parameters from historical work orders and operation and maintenance manuals; relation extraction technology is used to identify the relationships between entities, such as adopting a certain solution to solve a certain fault; and finally, the entities and relations are stored as structured triples in the form of "entity-relationship-entity".

[0104] The entity types related to root cause localization in the graph include fault type, root cause indicators, solutions, and repair effects.

[0105] S606 performs similarity matching retrieval in a knowledge graph by using graph embedding technology to map entities in the knowledge graph to a unified low-dimensional vector space, where root cause indicator entities and indicator nodes in the graph neural network model share the same set of vector representations.

[0106] Calculate the cosine similarity between the currently identified core root cause node vector and the entity vectors of all historical root cause indicators in the knowledge graph. Select the top 3 historical fault cases with the highest similarity. The solutions and repair effects associated with these cases will serve as the core reference for this fault handling.

[0107] S607 generates a personalized solution based on the matched historical reference cases. This solution integrates the operation steps in the reference cases and combines them with the specific configuration environment of the current database, replacing the variable parameters (such as connection pool size and memory allocation value) with suggested values ​​calculated based on the current load.

[0108] The plan concludes with the expected range of improvement in health scores and the expected improvement targets for key indicators, based on statistical analysis of the effects of similar historical cases.

[0109] S7 pushes the generated personalized solution to the operations and maintenance personnel's terminals. After the solution is executed, it collects the database operation status data after the repair, verifies the repair effect, and accumulates successful experiences into the knowledge base. See details below. Figure 7 As shown.

[0110] The S701 pushes the generated personalized solutions to the designated maintenance personnel's terminals, including the maintenance personnel's mobile terminals and desktop terminals, to ensure that critical information can be delivered in a timely manner.

[0111] The S702 provides maintenance personnel with two solution execution modes.

[0112] The first mode is manual execution, where operations and maintenance personnel manually log into the database management system to make configuration adjustments and execute operations, following the detailed operation steps and parameter suggestions listed in the solution documentation.

[0113] The second type is the one-click execution mode. In this mode, the system calls the command-line interface or dedicated management API provided by the database management system through pre-configured database connection parameters and authentication credentials. The system encapsulates the configuration item names, target values ​​and operation instructions parsed from the solution according to the format required by the interface and sends them. The database management system automatically performs parameter modification and configuration update, and records a complete operation log at the same time.

[0114] S703: After the solution is completed, regardless of the mode used, a new round of database operation status data collection is immediately started. This collection process lasts for 10 minutes, and the range of collected indicators is completely consistent with that in step S1.

[0115] S704, based on the newly collected 10 minutes of data, recalculate the average database health score for this period, in the same way as steps S406 and S407.

[0116] At the same time, the average values ​​of key indicators expected to be improved in the solution (such as transaction response time and connection pool utilization) before and after the repair are extracted and compared, and the calculated average health score is compared with the preset repair success threshold of 80 points.

[0117] S705, after determining that the repair was successful, the complete fault handling process is structured and encapsulated to form a new fault handling knowledge unit. This fault handling knowledge unit specifically includes the following information items: The original warning event is recorded in the blockchain along with the corresponding transaction hash, the identified core root cause indicator nodes, the complete content of the implemented solution, the key effect indicators observed after the repair and their comparative data, the specific timestamp of the solution execution, and the identity of the executor.

[0118] S706 submits the encapsulated fault handling knowledge unit as a new transaction and stores it in the blockchain distributed ledger.

[0119] The transaction content includes the serialized data and hash value of the fault handling knowledge unit, realizing the immutability and permanent proof of the knowledge record.

[0120] S707 simultaneously and automatically converts the key information in the fault handling knowledge unit into structured triples that can be accepted by the knowledge graph. The conversion rules are as follows: The core root cause indicator node is treated as entity one, and the implemented solution is treated as entity two. A relationship of being resolved is established between the two, forming a core triplet that includes the root cause indicator, the resolved solution, and the solution. At the same time, attributes such as the repair effect and the time period of occurrence are added to this triplet.

[0121] The system calls the knowledge graph management interface to inject the newly generated triples into the historical fault handling knowledge graph, thereby enriching and updating the knowledge base and providing more accurate case support for future intelligent decision-making.

[0122] S8, based on historical operational data and successfully accumulated fault handling knowledge units, constructs and runs a predictive maintenance model. See details... Figure 8 As shown.

[0123] S801 uses a long short-term memory neural network model as the core for prediction.

[0124] First, clarify the data required for model training and inference. The training input of the model is the time series data of historical database operation indicators. Specifically, it is the full monitoring indicator data extracted from the historical fault handling knowledge unit, which is the data of all indicators defined in S1, within 2 hours before the start of the peak period of 7 consecutive flights before each successful repair.

[0125] The training labels for the model are the actual observed index data during the next stable peak period after the corresponding successful repair.

[0126] The model's prediction output is: for the current time point, predict the values ​​of three key performance indicators one hour before the start of the next upcoming peak flight period, including connection pool utilization, transaction response time, and check-in transaction throughput.

[0127] S802 preprocesses the input and output data to adapt it for model training.

[0128] The input historical indicator sequence needs to be normalized. The minimum-maximum normalization method is used to scale the values ​​of each indicator to the range of 0 to 1 based on their historical range.

[0129] After calculation, the predicted sequence output by the model needs to be restored to a value with actual physical meaning through the corresponding inverse normalization process.

[0130] S803 configures the specific parameters and optimization strategies for model training.

[0131] The loss function used in model training is mean squared error, which measures the difference between the predicted value and the actual observed value. The optimizer is the Adam optimizer, and its learning rate parameter is set to 0.001. Through multiple iterations of training, the model can learn the mapping relationship from the historical sequence before and after the failure to the trend of the future steady state.

[0132] S804 defines the dynamic judgment threshold and triggering mechanism for prediction results.

[0133] A dynamic anomaly prediction threshold is set for each prediction indicator. This dynamic threshold is based on the dynamic anomaly threshold of the indicator during the target peak period calculated in step S4. When the predicted target date is identified by the system as a special event day, this basic threshold is multiplied by a coefficient greater than 1, such as 1.3, as the final dynamic prediction alarm threshold to match the higher performance tolerance requirements of special periods.

[0134] S805 generates and pushes predictive maintenance recommendations.

[0135] When the model's predicted value exceeds its corresponding dynamic prediction alarm threshold, the predictive maintenance process is automatically triggered.

[0136] The generated recommendations not only include specific operations such as expanding the connection pool before peak hours, preloading critical database indexes, and temporarily limiting non-core business requests, but also reference historical failure case knowledge units that lead to similar predictive patterns, providing operation and maintenance personnel with decision-making background references.

[0137] S806 integrates the generated maintenance recommendations into the operation and maintenance workflow.

[0138] Predictive maintenance recommendations are automatically added to the on-call engineer's task list through the standard application programming interface provided by the operation and maintenance planning system. At the same time, clear reminders and execution time requirements are set for each task to ensure that all recommended measures can be prepared and executed before the peak business hours.

[0139] S807 performs prediction performance verification and model update.

[0140] After the predicted peak period, the actual database operation index data for that period is collected, and the actual observed values ​​are compared with the model's previous predicted values. Indicators such as the mean absolute percentage error are calculated to evaluate the accuracy of this prediction.

[0141] If the prediction error exceeds the set standard multiple times in a row, or if the business model changes significantly, the prediction model will be automatically trained or retrained using newly added historical fault handling knowledge units and operational data to ensure the continued effectiveness of the prediction capability.

[0142] This embodiment also provides a civil aviation database inspection data intelligent maintenance system. This system implements the aforementioned civil aviation database inspection data intelligent maintenance method through multiple collaborative functional modules. The core modules of the system include: The multi-source data acquisition module is deployed on each civil aviation database node to synchronously collect database operation status data from three data sources: querying the database's built-in performance view, calling the operating system monitoring interface, and parsing business application logs to achieve real-time data acquisition.

[0143] The time-series data preprocessing module receives the raw data stream from the acquisition module and is responsible for performing timestamp alignment of multi-source data, data cleaning of missing and outlier values, and standardization of numerical formats. It also cuts the processed continuous data stream into standardized data blocks according to a fixed 60-second time window.

[0144] The blockchain hash chain notarization module calculates the SHA-256 global hash value for each standard data block obtained after preprocessing. By concatenating this hash value with the hash value of the previous data block to construct a hash chain, the transaction data containing this hash chain information is finally submitted to a pre-set consortium blockchain network to complete the immutable notarization of the inspection data in the distributed ledger.

[0145] The dynamic health assessment module integrates civil aviation business calendar and historical operation data. It has two core sub-modules: time-adaptive threshold calculation and multi-indicator fusion scoring. It can dynamically adjust the anomaly judgment threshold of each indicator according to the current business time period, and perform weighted fusion calculation on general performance indicators and civil aviation-specific business indicators, and finally output a real-time database health score between 0 and 100.

[0146] The smart contract early warning module continuously monitors the scoring results output by the health assessment module. When the score is lower than the preset threshold of 70 points, it automatically triggers the smart contract deployed on the blockchain. The logic of the smart contract automatically generates an early warning message containing detailed abnormal indicators, the scope of business impact, and other information. This message is pushed to the operations and maintenance personnel's terminal through the message queue service. At the same time, the key information hash value of this early warning event is stored in the blockchain for evidence preservation, and the standard interface of the external emergency command system is called to initiate a cross-system linkage response.

[0147] The root cause localization and solution generation module is automatically activated after an early warning event is triggered. The core of this module is to call a pre-trained graph neural network model to analyze the causal dependencies between various abnormal indicators, identify the core root cause indicator nodes that lead to the deterioration of health status, and then combine it with the fault handling knowledge graph built from historical operation and maintenance documents to match similar cases. Finally, a personalized solution containing specific operation steps, parameter adjustment suggestions and expected results is generated.

[0148] The fault handling knowledge accumulation module is responsible for pushing the generated solutions to the operations and maintenance terminal, and initiating a repair effect verification process after the solution is executed. This process collects post-repair operational data and recalculates the health score. If the repair is verified to be successful, the entire process information of this fault handling, including the core root cause, execution plan, repair effect, and its correlation with the original warning, is encapsulated into a structured fault handling knowledge unit. This fault handling knowledge unit is simultaneously stored in the blockchain ledger for permanent evidence preservation and injected into the historical fault handling knowledge graph to solidify and reuse experience.

[0149] The predictive maintenance module utilizes historical fault handling knowledge units and database performance metrics data accumulated by the system to train a long short-term memory neural network model. This model analyzes the trend of metric changes before historical peak flight periods and predicts potential performance bottlenecks in specific future periods. When the model's predicted value exceeds a threshold dynamically adjusted according to the business calendar, the module automatically generates and pushes maintenance suggestions such as preventative capacity expansion and index preloading to the operations and maintenance planning system.

[0150] All the above functional modules communicate and collaborate loosely through an internal message bus, ensuring that data flow and control commands can be transmitted efficiently and reliably between modules.

[0151] The entire system is preferably deployed on a private cloud infrastructure in the civil aviation sector, and is integrated with existing ITSM systems, emergency command systems, and operation and maintenance planning systems through predefined standard application programming interfaces, thereby achieving seamless connection and data interoperability with the existing operation and maintenance technology stack.

[0152] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0153] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment includes only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for intelligent maintenance of civil aviation database inspection data, characterized in that, Includes the following steps: Collect general performance indicators and civil aviation-specific business indicators from database nodes as operational status data; The runtime status data is time-series aligned, cleaned, and standardized, and then cut into continuous data blocks according to a fixed time window; The hash value of each data block is calculated and cascaded to build a hash chain. The transaction data containing the hash chain is written into a consortium blockchain network composed of nodes from multiple parties in the civil aviation industry to achieve tamper-proof evidence storage. A dynamic health assessment model is built based on civil aviation business calendar and historical data. The dynamic health assessment model dynamically adjusts the indicator thresholds according to the current business period, and performs weighted fusion calculation on multiple indicators to output a real-time health score. When the score falls below the threshold, the blockchain smart contract is triggered to automatically generate and push an early warning message, while the early warning event is stored as evidence and cross-system emergency response is initiated. By using graph neural networks to analyze the causal relationships between abnormal indicators to locate the core root cause, and by combining fault handling knowledge graphs with historical cases, personalized solutions can be generated. Implement personalized solutions and verify their effectiveness. Encapsulate successful processing procedures as fault handling knowledge units, store them in the blockchain, and update them to the knowledge graph. The predictive model is trained based on historical data and fault handling knowledge units to predict future trends of key indicators and generate predictive maintenance recommendations.

2. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, The runtime status data undergoes time-series alignment, cleaning, and standardization, specifically including: The system clock of the server where the database performance view acquisition module is located is used as a unified time reference; Linear interpolation is used to align the data timestamps of the operating system resource acquisition module to the unified time base. The nearest neighbor interpolation method is used to align the data timestamps of the business log parsing module to the whole second of the unified time base; Forward filling is performed to complete missing values ​​in the data stream; A sliding window method based on statistical distribution is used to identify and remove outliers; Convert all indicator values ​​into a floating-point number format with a preset precision. The processed indicators are merged into a standardized data stream according to time sequence, and then cut into two-dimensional data blocks according to a preset duration.

3. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Calculating hash values ​​and constructing hash chains by cascading them specifically includes: Serialize the two-dimensional data matrix of the current data block into a string; Calculate the hash value of the string as the hash of the current data block; The hash of the current data block is concatenated with the hash of the previous data block, and the hash is calculated again to obtain the chained hash value. The chained hash value, the time window information corresponding to the data block, and the digital signature are encapsulated into transaction data; The transaction data is submitted to a consortium blockchain network composed of nodes from multiple parties in the civil aviation industry, and stored as evidence after consensus is reached.

4. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Constructing a dynamic health assessment model specifically includes: The day is divided into several standard time periods based on flight schedules; For each monitoring indicator, the 95th percentile value of its historical data in each standard time period is calculated and used as the dynamic anomaly threshold for that time period. Identify special event days and increase the dynamic anomaly threshold by a preset ratio; Allocate a total weight to civil aviation-specific business indicators that is no less than that to general performance indicators; The normalized health contribution value is calculated based on the current value, dynamic threshold and historical mean of each indicator; The contribution values ​​of each indicator are weighted and summed to obtain a health score in the range of 0-100.

5. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Triggering automatic alerts from smart contracts includes: The smart contract sorts the health scores based on the contribution of each indicator to the health score and identifies the main abnormal indicators. Query the predefined business-metric mapping table to identify the core business systems affected; Generate structured early warning messages that include an anomaly list, measured values, scores, and the scope of impact; Early warning messages are pushed to the operation and maintenance terminal via message queue; Calculate the hash value of the warning message and store it in the blockchain; The system calls the emergency command system interface to report event information, triggering a business status update.

6. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Using graph neural networks to locate the root cause, specifically including: The nodes of the graph neural network correspond to various database metrics, and the edges between nodes are established based on statistical correlation and predefined business dependency rules. Abnormal index values ​​are used as node features and input into the graph neural network; The node status is updated iteratively through multi-layer message passing, and the anomaly contribution score of each node is calculated. The node with the highest abnormal contribution score is identified as the core root cause indicator node.

7. The intelligent maintenance method for civil aviation database inspection data according to claim 6, characterized in that, The knowledge graph generation solution specifically includes: The fault handling knowledge graph stores fault entities and relationships extracted from historical documents in the form of triples. Map the core root cause indicator nodes and the historical root cause indicator entities in the knowledge graph to the same vector space; Calculate the similarity between vectors and match the historical case with the highest similarity; A customized solution is generated by referencing solutions from historical cases and combining them with the current database configuration parameters.

8. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Encapsulating and solidifying knowledge, specifically including: After verifying the effectiveness of the solution, a fault handling knowledge unit is constructed, which includes early warning event identifiers, root cause indicators, implementation plans, remediation effects, and implementation information. The fault handling knowledge unit is serialized and hashed, and then submitted to the consortium blockchain network for storage. The root cause and solution relationships in the fault handling knowledge unit are converted into triples and injected into the fault handling knowledge graph.

9. The intelligent maintenance method for civil aviation database inspection data according to claim 1, characterized in that, Generate predictive maintenance recommendations, specifically including: The time series prediction model is trained by taking the historical index sequence before fault repair as input and the stable data after repair as labels. Use models to predict key performance indicators ahead of future business peaks; Dynamically adjust the predicted alarm thresholds based on the business calendar; When the predicted value exceeds the threshold, maintenance suggestions including expansion, preloading, or rate limiting operations are automatically generated. Integrate maintenance recommendations into the pending tasks of the operation and maintenance plan system.

10. A civil aviation database inspection data intelligent maintenance system, used to implement the civil aviation database inspection data intelligent maintenance method according to any one of claims 1-9, characterized in that, include: The multi-source data acquisition module is used to collect general performance indicators and civil aviation-specific business indicators from database nodes; The time-series data preprocessing module is used to perform time-series alignment, cleaning, standardization, and window segmentation on the collected data; The blockchain hash chain notarization module is used to construct a data block hash chain and write transaction data into the consortium blockchain network for notarization. The dynamic health assessment module is used to dynamically calculate thresholds based on the business calendar and integrate multiple indicators to output a health score. The smart contract early warning module is used to trigger automatic contract early warning, evidence storage, and emergency response when the score is abnormal; The root cause localization and solution generation module is used to locate the core root cause through graph neural networks and generate personalized solutions by combining knowledge graphs. The fault handling knowledge accumulation module is used to encapsulate successful handling experience and update the blockchain and knowledge graph; The predictive maintenance module is used to train the predictive model and generate predictive maintenance suggestions. Each module interacts with other modules and works collaboratively through a message bus.

Images