Engine maintenance method, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an engine maintenance method, electronic equipment and a storage medium, and relates to the technical field of computers, and the method comprises the following steps: displaying health index data of each engine through a plurality of digital twin bodies, the health index data of any engine at least comprises a fault prediction result generated by the corresponding client based on the global fault prediction model; global model parameters of the global fault prediction model are obtained by the central server aggregating local model parameters obtained by a plurality of clients in local training; performing risk scoring based on a fault prediction result contained in the health index data of each engine to obtain a risk score of each engine; and generating a maintenance suggestion for each engine based on the risk score of each engine. According to the method, the data privacy of model training collaboratively performed by multiple clients can be protected, and the intelligence and efficiency of engine cluster maintenance are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to an engine maintenance method, electronic equipment, and storage medium. Background Technology

[0002] With the widespread application of industrial diesel engines in critical scenarios such as power generation, transportation, and heavy equipment, their operational safety and maintenance efficiency are receiving increasing attention. Traditional periodic maintenance methods suffer from problems such as high randomness and significant resource waste, necessitating the use of intelligent technologies to achieve predictive maintenance of equipment.

[0003] In related technologies, single-machine prediction systems based on machine learning models are used for fault trend prediction or remaining life estimation. However, these solutions often rely on centralized data collection from multiple devices, resulting in poor data privacy and failing to meet data privacy requirements in a distributed industrial environment. Furthermore, most systems focus only on modeling and displaying a single engine, making it difficult to support intelligent maintenance of large-scale engine groups. Summary of the Invention

[0004] This application provides an engine maintenance method, electronic device, and storage medium to alleviate or solve one or more technical problems existing in the prior art.

[0005] In a first aspect, embodiments of this application provide an engine maintenance method, comprising: displaying health indicator data of each engine through multiple digital twins, wherein the health indicator data of any engine includes at least a fault prediction result generated by a corresponding client based on a global fault prediction model; the global model parameters of the global fault prediction model are obtained by the central server aggregating local model parameters trained locally by multiple clients; performing risk scoring based on the fault prediction results contained in the health indicator data of each engine to obtain a risk score for each engine; and generating maintenance recommendations for each engine based on the risk scores of each engine.

[0006] Secondly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the methods of embodiments of this application when executing the computer program.

[0007] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method of any one of the embodiments of this application.

[0008] Fourthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any of the methods described in the embodiments of this application.

[0009] According to the method in this application embodiment, the central server displays the health indicator data of each corresponding engine through multiple digital twins. The health indicator data of each engine includes a fault prediction result for that engine. This fault prediction result is obtained by the client corresponding to that engine based on a global fault prediction model. The global fault prediction model is obtained by the central server aggregating local model parameters trained locally by multiple clients and uploaded by the central server. The central server performs risk scoring based on the fault prediction results contained in the health indicator data of each engine, obtaining a risk score for each engine. Based on these risk scores, maintenance recommendations are generated for each engine.

[0010] According to this method, a federated learning architecture enables multiple clients to collaboratively train a model without sharing training data. Each client trains its local model based on the engine's local model, obtains local model parameters, and reports these parameters to the central server. The central server then aggregates the local model parameters reported by multiple clients into a global model, achieving collaborative model training among multiple clients without sharing training data, effectively protecting data privacy. Furthermore, the central server can receive and display corresponding engine health indicator data through multiple digital twins. This data includes fault prediction results for the corresponding engines inferred by each client based on the global fault prediction model. The central server can perform risk scoring and generate maintenance suggestions based on the fault prediction results of multiple engines, realizing horizontal collaborative analysis of multiple engines and group maintenance based on the results of horizontal collaborative analysis. In this embodiment, predictive engine maintenance can be achieved through federated learning and multi-twin collaborative analysis, which is beneficial for improving the intelligence and efficiency of engine cluster maintenance.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0012] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0013] Figure 1 A flowchart of an engine maintenance method according to an embodiment of this application is shown; Figure 2 A flowchart of an engine maintenance method according to an embodiment of this application is shown; Figure 3 A flowchart illustrating an exemplary embodiment of the engine maintenance method of this application is shown; Figure 4 A schematic diagram of the structure of an engine maintenance system according to an exemplary embodiment of this application is shown; Figure 5 This application shows a schematic diagram of the modules of an engine maintenance device according to an embodiment of the present application; Figure 6 This application shows a schematic diagram of the modules of an engine maintenance device according to an embodiment of the present application; Figure 7 A block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0014] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0015] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0016] In related technologies, single-machine prediction systems based on machine learning models are employed, such as those using Long Short-Term Memory (LSTM) networks for fault trend prediction or remaining lifetime estimation. These solutions often rely on centralized data collection, which does not meet the data privacy requirements of distributed industrial environments. Specifically, traditional centralized machine learning models depend on aggregating data from various devices to a central server. Engines are deployed across multiple edge nodes, resulting in widely distributed operational data that is difficult to collect centrally, and it involves confidential and privacy-sensitive data (such as in military, leasing, and critical infrastructure scenarios). Centralized modeling faces data security risks and compliance obstacles. However, data from different devices also contains common knowledge; sharing model experience could improve overall prediction accuracy.

[0017] In practical applications, the maintenance target is often not a single engine, but a group of machines, such as mines, power plants, and transport fleets. Most systems only focus on modeling and displaying individual engine equipment, which can only perform "local optimization" and cannot formulate maintenance priorities and resource allocation from an overall perspective. They also lack the ability to perform horizontal analysis between digital twins, making it difficult to support intelligent maintenance scheduling for large-scale diesel engine groups.

[0018] It should be noted that the application scenarios or examples provided in the embodiments of this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the technical solutions. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0019] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0020] Figure 1 A flowchart illustrating an engine maintenance method according to an embodiment of this application is shown. In some embodiments, the method is applied to a central server. Figure 1 As shown, the method may include steps S101, S102 and S103.

[0021] S101 displays the health index data of each engine through multiple digital twins. The health index data of any engine includes at least the fault prediction result generated by the corresponding client based on the global fault prediction model. The global model parameters of the global fault prediction model are obtained by the central server aggregating the local model parameters trained locally by multiple clients.

[0022] S102, risk scoring is performed based on the fault prediction results contained in the health index data of each engine to obtain the risk score of each engine.

[0023] S103 generates maintenance recommendations for each engine based on its risk score.

[0024] According to the method in this application embodiment, the central server displays the health indicator data of each corresponding engine through multiple digital twins. The health indicator data of each engine includes a fault prediction result for that engine. This fault prediction result is obtained by the client corresponding to that engine based on a global fault prediction model. The global fault prediction model is obtained by the central server aggregating local model parameters trained locally by multiple clients and uploaded by the central server. The central server performs risk scoring based on the fault prediction results contained in the health indicator data of each engine, obtaining a risk score for each engine. Based on these risk scores, maintenance recommendations are generated for each engine.

[0025] According to this method, a federated learning architecture enables multiple clients to collaboratively train a model without sharing training data. Each client trains its local model based on the engine's local model, obtains local model parameters, and reports these parameters to the central server. The central server then aggregates the local model parameters reported by multiple clients into a global model, achieving collaborative model training among multiple clients without sharing training data, effectively protecting data privacy. Furthermore, the central server can receive and display corresponding engine health indicator data through multiple digital twins. This data includes fault prediction results for the corresponding engines inferred by each client based on the global fault prediction model. The central server can perform risk scoring and generate maintenance suggestions based on the fault prediction results of multiple engines, realizing horizontal collaborative analysis of multiple engines and group maintenance based on the results of horizontal collaborative analysis. In this embodiment, predictive engine maintenance can be achieved through federated learning and multi-twin collaborative analysis, which is beneficial for improving the intelligence and efficiency of engine cluster maintenance.

[0026] In this embodiment, Federated Learning (FL) is a distributed machine learning method that allows multiple devices or nodes to collaboratively train a global machine learning model without exchanging data. Each device (such as a diesel engine sensor node) trains locally and generates a local model, then sends the model update information to a central server, which then merges these updates to obtain the global model.

[0027] The central server in this application embodiment can be a single server, a server cluster, or a cloud server. A single server can be a physical server or a virtual server. A server cluster is a cluster composed of multiple servers. A cloud server may include components such as processors, memory, and cloud disks to provide cloud computing. It should be understood that the specific type of server can be selected according to actual needs in this application embodiment, and this application embodiment does not impose specific limitations.

[0028] In step S101, a digital twin is a digital representation of a physical entity. It maps real-time data collected by sensors and reported by the client into a virtual model, enabling real-time monitoring and simulation of the physical system. The digital twin accurately reflects the state, behavior, and performance of the actual equipment and can perform predictive analysis.

[0029] As an example, the client is deployed on the engine side, with each client corresponding to one or more engines. An engine is a device that converts the chemical energy of fuel into mechanical energy and is widely used in various mechanical equipment. Different types of engines are suitable for different application scenarios and needs.

[0030] For example, the engine may include, but is not limited to, at least one of the following: diesel engine, gasoline engine, and hybrid engine. For the sake of simplicity, the following embodiments use a diesel engine as an example to illustrate the specific implementation of the engine maintenance method. However, this description should not be construed as limiting the scope or feasibility of this solution; the maintenance methods for other types of engines besides diesel engines are consistent with the methods used for diesel engines.

[0031] As an example, the health index data for each engine includes not only the fault prediction results obtained by the client on the engine side based on the global fault prediction model to predict the faults in the local operating status data of the engine collected in real time, but also other quantitative indicators.

[0032] For example, Key Performance Indicators (KPIs) data may include at least one of the following engine information items: equipment ID, equipment model, geographical location, current load, and fault prediction results. Fault prediction results include, but are not limited to, at least one of the following: predicted Remaining Useful Life (RUL), identified potential fault modes, and operating efficiency. Here, current load refers, for example, to the engine's energy output demand at the current moment, characterizing the load on the engine during operation. Operating efficiency refers to the efficiency with which the engine converts fuel into mechanical energy, used to measure engine performance.

[0033] In this step, the health indicator data of the corresponding engine received and displayed by any digital twin can be called twin information. The central server can aggregate information from multiple twins and perform subsequent cross-sectional analysis.

[0034] In some embodiments, before step S101, the method further includes: sending an initial fault prediction model to each client during the current model training cycle; receiving local model parameters uploaded by each client, wherein the local model parameters uploaded by any client are obtained by training the initial fault prediction model based on the historical operating status data of the corresponding engine; aggregating the local model parameters uploaded by each client to obtain global model parameters; generating a global fault prediction model based on the global model parameters; and sending the global fault prediction model to each client.

[0035] As an example, the initial fault prediction model can be a time-series data prediction model. As another example, it can be a Long Short-Term Memory (LSTM) model. Taking LSTM as an example, the initial model structure includes: an input layer, a first LSTM layer (LSTM layer 1), a dropout layer, a second LSTM layer (LSTM layer 2), a fully connected layer, and an output layer.

[0036] The input layer has a shape of (Time_Steps, Num_Features). The time step represents the number of time points in the sequence data, which is the length of the sequence. The number of features represents the number of features in each time step; a feature is any quantifiable attribute. For example, an input layer with a shape of (50, 14) indicates 50 time steps, with 14 features per step. If each time step represents one hour, 50 time steps mean that the input data contains 50 hours of sequence data.

[0037] The first long short-term memory layer contains, for example, 128 neurons. `return_sequences=True` is set to pass sequence information to the next layer. `return_sequences=True` means that the model will output a prediction at each time step of the sequence.

[0038] Random deactivation layers are a type of regularization technique used to prevent overfitting in neural networks during training. By randomly "dropping out" (i.e., temporarily ignoring) some neurons in the network during training, the generalization ability of the model is increased. For example, randomly deactivating a certain percentage (e.g., 20%) of neurons can prevent overfitting.

[0039] The second long short-term memory layer, for example, contains 64 neurons. `return_sequences=False` because this is the last sequential processing layer, and it only needs to output the final state.

[0040] Fully connected layers are used to integrate features and perform non-linear transformations. For example, a fully connected layer contains 32 neurons and uses the ReLU activation function. The ReLU function increases the non-linearity of the network, helping the model learn more complex patterns.

[0041] The output layer, for example, contains one neuron and uses a linear activation function to directly output the predicted value of the engine's remaining service life (hereinafter referred to as the predicted remaining service life value).

[0042] In some scenarios, during the local prediction modeling and federated learning collaborative modeling phases, the Long Short-Term Memory (LSTM) model used to build the time-series prediction model can be flexibly replaced to improve model performance, prediction accuracy, or adapt to specific application scenarios. The time-series prediction model can be other types of network models. For example, a Gated Recurrent Unit (GRU) can be used to achieve efficient training at the edge with fewer parameters; or a Transformer model based on self-attention and a Temporal Convolutional Network (TCN) can be used to capture long-term dependencies more accurately through parallel computation, which is particularly suitable for long-term lifetime prediction. Another example is a hybrid model combining a Convolutional Neural Network (CNN) and a LSTM model (CNN-LSTM), where a Convolutional Neural Network (CNN) is first used to extract spatial features from multi-dimensional sensor data, and then the LSTM model performs time-series analysis.

[0043] In some embodiments, the network model can output failure modes and predicted remaining useful life values. This multi-task learning approach improves the model's generalization ability, allowing the model to learn multiple related tasks simultaneously within a joint framework. As an example, the model can contain multiple output layers, one for predicting remaining useful life values ​​and another for fault classification to identify potential failure modes.

[0044] Taking LSTM as an example, the first few layers of this network model can be set to be shared by two output layers, such as: an input layer, a first long short-term memory layer (LSTM layer 1), a random deactivation layer (Dropout layer), and a second long short-term memory layer (LSTM layer 2). After feature extraction, the model can be divided into different branches, each corresponding to a feature prediction task. For example, one branch can contain one or more fully connected layers, followed by an output layer (e.g., a linear activation function) to output the predicted remaining lifetime value. Another branch can contain one or more fully connected layers, followed by an output layer (e.g., a softmax activation function) to output the fault type.

[0045] In this embodiment, the prediction of remaining useful life is a regression problem, and Mean Squared Error (MSE) or Mean Absolute Error (MAE) can be used as the loss function. An Adaptive Moment Estimator (Adam) optimizer is employed to adaptively adjust the learning rate, resulting in fast and stable convergence, thereby improving the efficiency and effectiveness of model training. Each client trains on its local dataset for several epochs, updating the weights and biases of its local model through backpropagation. This process is entirely local, ensuring data privacy. Fault type prediction is typically treated as a classification problem; for example, the Cross-Entropy Loss function can be used to measure the difference between the probability distribution predicted by the model and the true label.

[0046] In a multi-task learning framework, a model can be trained simultaneously to perform predictions of remaining useful life and failure types, allowing the model to focus on different prediction tasks.

[0047] As an example, after the central server collects all the local model parameters uploaded by clients, it can execute an aggregation algorithm to generate a new, higher-performing global model. Aggregation algorithms could include, for example, Federated Averaging (FedAvg), Federated Proximal (FedProx), or Federated Asynchronous (FedAsync).

[0048] As a concrete example, suppose that in a federated learning round t, there are K clients participating in model training, where K is an integer greater than or equal to 2. The server holds the current global model parameters. The server will Distributed to K clients; each client k has its local dataset (size is) Train the model on the local machine to obtain updated local model parameters. Each client will transfer local model parameters. Uploaded to the central server; the central server performs a weighted average of multiple local model parameters to calculate the new global model parameters. .

[0049] Specifically, the new global model parameters can be expressed as the following formula (1): (1) In the above formula (1), This represents the total number of samples participating in this round of model training. The significance of this weighting strategy is that clients with more sample data contribute more to the global model, and their model update direction may be more universal.

[0050] As an example, the central server can distribute the newly generated global model parameters to all clients, and the clients can obtain the new global model based on the new global model parameters. Alternatively, the central server can also generate a new global model based on the newly generated global model parameters and then send the new global model to all clients. Specifically, depending on the actual application scenario, the central server may choose to distribute global model parameters or directly distribute the global model; this embodiment does not impose specific limitations.

[0051] In this embodiment, the client performs local training and uploads the trained local model parameters to the central server. The central server aggregates the local model parameters uploaded by multiple clients to obtain global model parameters. The process of distributing the global model parameters to each client is repeated multiple times until the performance of the global model, such as the loss on a certain validation set, converges or a preset number of training rounds is reached. In this way, the global model gradually incorporates the data characteristics of all engines, such as diesel engines, becoming more robust and accurate than any single local model.

[0052] In some embodiments, step S102 may specifically include: for any engine, obtaining the predicted remaining service life and the predicted fault mode from the engine fault prediction results, wherein the fault mode is used to characterize the type of engine fault; determining the risk coefficient corresponding to the remaining service life based on the remaining service life and the preset correspondence between the engine's remaining service life and the engine fault risk; obtaining the severity level value corresponding to the fault mode from a preset expert knowledge base; obtaining the engine's downtime impact level value, wherein the downtime impact level value is preset according to the engine's usage scenario; and determining the engine's risk score based on the risk coefficient, the severity level value, and the downtime impact level value.

[0053] As an example, taking a diesel engine as an example, in order to effectively allocate limited maintenance resources, all diesel engines in the fleet need to be sorted according to the urgency of maintenance. This application embodiment calculates the risk score of the diesel engine using a Credit Risk Score (CRS) model, which can be specifically expressed as the following formula (2): (2) In the above formula (2), i represents the i-th diesel engine; It is a risk function related to the remaining useful life. For example, the smaller the remaining useful life, the larger the value of this term; the larger the remaining useful life, the smaller the value of this term. It is the severity level of the predicted failure mode, such as level 1-5, which is predefined by the expert knowledge base. For example, the severity of bearing wear is 4 and the severity of sensor drift is 2. This refers to the downtime impact level of the diesel engine, i.e., the level of business impact caused by the downtime, such as level 1-5. For example, the impact of the main generator set is level 5, and the impact of the standby fire pump is level 2. , and These are user-configurable weights used to balance the importance of different risk factors.

[0054] It should be understood that the severity level and business impact level of the above-mentioned failure modes are merely illustrative and can be customized according to actual needs. This application does not impose any specific limitations on the embodiments.

[0055] In some embodiments, step S103 may specifically include: sorting the risk scores of each engine to obtain a risk score sorting result; sequentially obtaining at least one risk score in descending order of the risk score sorting result; for each obtained risk score, obtaining the fault mode and remaining service life of the engine to which the risk score belongs; querying specific maintenance measures corresponding to the fault mode and remaining service life from a preset maintenance knowledge base; and generating maintenance recommendations containing specific maintenance measures.

[0056] For example, the central server calculates the risk score for each engine and sorts them from highest to lowest score. For at least one engine with a high CRS ranking, the system automatically queries the built-in maintenance knowledge base to generate specific maintenance recommendations. For example: IF (Predicted Fault = "Turbocharger Bearing Wear" AND RUL < 50 hours) THEN {Recommended Actions: "Schedule turbocharger disassembly and inspection, replace bearing kit"; Required Spare Parts: ["Spare Part A", "Spare Part B"]; Required Labor Hours: "8 hours"; Skill Requirement: "Senior Technician"}.

[0057] For example, the maintenance recommendation is a group maintenance recommendation list for a fleet of engines. The list includes at least one of the following information items: engine identifier, risk ranking, risk score, specific location, predicted fault, maintenance recommendation, and estimated downtime. The engine identifier uniquely identifies an engine. The predicted fault includes the fault prediction result. The specific location includes the engine's specific geographical location reported by the client. The estimated downtime can be determined based on the predicted remaining service life. For example, the estimated downtime is the duration of the predicted remaining service life after the current time.

[0058] In this embodiment, by sorting by risk score and querying the predictive maintenance knowledge base, accurate maintenance suggestions for the engine can be generated. This effectively integrates fault prediction and remaining service life data, automatically generates maintenance measures, and improves the efficiency and accuracy of maintenance work.

[0059] In some embodiments, after step S103, the method further includes: displaying the results of multi-twin collaborative analysis through a twin collaborative analysis display platform, wherein the multi-twin collaborative analysis results include a group maintenance recommendation list, which includes: maintenance recommendations, remaining service life, and failure modes for each engine; determining the target engine that needs maintenance based on the group maintenance recommendation list, generating corresponding control commands according to the maintenance recommendations for the target engine, and sending the control commands to the client corresponding to the target engine; receiving feedback on the actual maintenance results for the group maintenance recommendation list, wherein the feedback on the actual maintenance results is at least used to indicate whether the corresponding fault prediction result is a false alarm; determining the label correction instruction for the corresponding client based on the feedback on the actual maintenance results; and sending the label correction instruction to the corresponding client for model training in the next model training cycle.

[0060] As an example, the central server displays group maintenance suggestions through a twin collaborative analysis and display platform. The display page for group maintenance suggestions includes a first page element, which triggers the receipt of operation instructions for the maintenance list. For instance, in response to the operation instruction for this first page element, operations personnel can perform actions on each suggestion in the group maintenance suggestion list.

[0061] As an example, the action taken for each suggestion could include any of the following: accept, postpone, or ignore. Accepting actions include: automatically generating a work order and notifying relevant personnel, and reserving spare parts. Reserving spare parts includes, for example, notifying relevant personnel to prepare and retain spare parts or components for upcoming maintenance or repair work. Postponing actions include: entering the reason for postponement and a new scheduled time. Ignoring actions are used to indicate: in cases determined to be false alarms, inputting feedback.

[0062] As an example, the group maintenance suggestion display page also includes a second page element. This second page element is used to receive the maintenance results, i.e., the actual maintenance results after accepting the suggestion. For example, maintenance results include: repair confirmation, fault confirmation, and discrepancy discovery. Taking a diesel engine as an example, repair confirmation might include: the turbocharger of diesel engine A was replaced. Fault confirmation might include: after disassembly, it was found that the bearing did indeed have severe wear, consistent with the system prediction. Discrepancy discovery might include: after disassembly, it was found that the problem was not with the bearing, but with cracked blades. This information will be recorded as a false alarm.

[0063] In this embodiment, for any suggestion in the group maintenance suggestion list, the actual maintenance result feedback includes: false alarm identification, fault confirmation, discrepancy detection, and actual fault time. False alarm identification refers to receiving an operation indicating that the suggestion is a false alarm. Fault confirmation refers to receiving both an operation indicating acceptance of the suggestion and an operation indicating fault confirmation. Discrepancy detection refers to receiving both an operation indicating acceptance of the suggestion and an operation indicating discrepancy detection. Actual fault time refers to the actual fault time reported by maintenance personnel based on the engine failing before the predicted remaining service life is reached. Any of the following—false alarm identification, discrepancy detection, and actual fault time—is considered a false alarm. Fault confirmation is considered a valid false alarm.

[0064] As an example, the first page element and the second page element can be page controls for information input, such as at least one of buttons, text boxes, checkboxes, and drop-down menus. Specific settings can be customized according to actual needs, and this application embodiment does not impose specific limitations.

[0065] As an example, actual maintenance result feedback also includes the received actual failure time of the corresponding engine. When the corresponding engine equipment fails before the predicted remaining service life is reached, this actual failure point will be recorded.

[0066] As an example, feedback from actual maintenance results can serve as input for subsequent iterative learning, optimizing the fault prediction model for the next training cycle. This constitutes a closed-loop learning mechanism for the system, enabling it to self-evolve and continuously optimize. When a maintenance work order is executed and closed, maintenance personnel need to record the actual findings in the system.

[0067] In this embodiment, feedback data is used to optimize the entire predictive maintenance system. For example, for cases of false alarms or inaccurate predictions, historical data can be reviewed to correct the remaining useful life labels and / or fault type labels, making the labels closer to the actual degradation process and / or the actual fault type. Newly confirmed and corrected data samples can be added to the corresponding client's local dataset. In the next cycle of federated learning, the model will be trained on the new dataset containing this valuable feedback. This allows the global model to learn the reasons for past prediction errors, gradually improving the accuracy and reliability of predictions, forming a continuously spiraling intelligent optimization loop.

[0068] In this embodiment, a digital twin platform enables collaborative analysis of multiple twins, automatically generating a group maintenance recommendation list, including maintenance recommendations, remaining service life, and failure modes. Based on the maintenance recommendations, the system identifies the target engine, generates and sends control commands, receives maintenance feedback to verify prediction accuracy, and corrects labels and optimizes model training based on the feedback. This improves the intelligence and accuracy of maintenance work for the corresponding engine group, reduces false alarm rates, and enhances equipment operational reliability.

[0069] Figure 2 A flowchart illustrating an engine maintenance method according to an embodiment of this application is provided. In some embodiments, the method is applied to a client and includes the following steps.

[0070] S201, based on the global fault prediction model, perform fault prediction on the local operating status data of the engine corresponding to the client, and obtain the fault prediction result; the global fault prediction model is generated using global model parameters from the central server, which are obtained by the central server by aggregating the local model parameters trained locally by multiple clients.

[0071] S202, the fault prediction results are sent to the central server. The digital twin of the engine deployed on the central server is used to display health indicator data containing the fault prediction results. The central server is used to perform risk scoring based on the fault prediction results of each engine to obtain a risk score and generate corresponding engine maintenance recommendations.

[0072] According to the method in this application embodiment, the client can perform fault prediction based on a global prediction model, which is a model determined by the client based on global model parameters issued by the central server. The global model parameters are obtained by the central server aggregating local model parameters from multiple clients. The fault prediction results from each client are sent to the central server for risk scoring and maintenance recommendation generation. This helps improve the intelligence level of engine maintenance, reduce false alarm rates, and enhance the reliability and safety of equipment operation.

[0073] In some embodiments, before step S201, the following steps are further included: during the current model training cycle, receiving an initial fault prediction model issued by the central server; training the initial fault prediction model based on the historical operating status data of the corresponding engine to obtain local model parameters; sending the local model parameters to the central server so that the central server aggregates the local model parameters sent by multiple clients to obtain global model parameters and generates a global fault prediction model based on the global model parameters.

[0074] As an example, the local prediction model is sent from the central server to each client. Each client can collect sensor data on the engine's performance parameters, temperature, pressure, fuel consumption, vibration, and speed, and perform standardization to construct time-series samples. The constructed time-series data is used to train the local prediction model to predict the remaining service life of key engine components, or to predict abnormal trends determined based on the remaining service life. Abnormal trends, for example, indicate that the engine is expected to shut down after the predicted remaining service life has elapsed since the current moment.

[0075] In this embodiment, each client trains an initial model using local data and uploads its local model parameters. The central server aggregates these parameters to generate global model parameters. This process, through federated learning, enables the training and optimization of a distributed fault prediction model, ensuring data privacy while improving the model's generalization ability and prediction accuracy.

[0076] In some embodiments, after sending the fault prediction result to the central server in step S202, the method further includes: receiving a control command from the central server, the control command including maintenance recommendations, remaining service life, and fault mode for the engine; receiving a label correction instruction, the label correction instruction being used to indicate whether the engine fault prediction result is a false alarm; updating the historical operating state data to which the fault prediction result belongs as training data according to the label correction instruction; and in the next training cycle, performing model training based on the updated historical operating state data to obtain new local model parameters, and sending the new model parameters to the central server.

[0077] As an example, for any fault prediction result, the label correction indication received by the client may include, for example, either a false alarm or a valid fault prediction result. A false alarm further includes: the predicted fault type did not occur, for example: the engine did not fail or the fault type that occurred was inconsistent with the prediction, or the fault occurred before the predicted remaining service life was reached.

[0078] In this embodiment, the client can receive maintenance instructions from the central server, including maintenance suggestions, remaining service life, and failure modes. It can also correct historical operational data used as training data using received label correction instructions, and in the next training cycle, train the model locally based on the updated training data to obtain new local model parameters. By uploading the new local model parameters to the central server, continuous optimization of the global model can be promoted, improving the accuracy of the global model's prediction results.

[0079] Figure 3 A flowchart illustrating an exemplary embodiment of the present application is provided. Taking a diesel engine as an example, in some embodiments, the method includes the following steps.

[0080] S301: Data is collected from each diesel engine node and preprocessed to construct training samples for the model.

[0081] Specifically, each diesel engine client node executes this locally, aiming to transform raw, messy sensor data into structured time-series samples suitable for training time-series prediction models. The specific steps are as follows: As an example, each diesel engine is equipped with multiple sensors to collect local operating status data in real time as training data, i.e., a local private dataset. This data constitutes a multidimensional time series. Status data includes, but is not limited to, performance parameters, temperature parameters, pressure parameters, vibration parameters, and at least one of other parameters. Performance parameters include, but are not limited to, at least one of engine speed, output torque, and fuel consumption rate. Temperature parameters include, but are not limited to, at least one of coolant temperature, lubricating oil temperature, and exhaust temperature. Pressure parameters include, but are not limited to, at least one of intake pressure, oil pressure, and fuel pressure. Vibration parameters include, but are not limited to, triaxial vibration signals of critical components such as bearings and housings. Other parameters include, but are not limited to, at least one of the following: load percentage and operating time.

[0082] Considering the presence of noise, missing data, and inconsistent units in the raw data, fine-grained processing is required. This can be achieved by preprocessing the real-time collected runtime data before model training. Data preprocessing includes any one of the following: data cleaning, feature selection, and feature normalization.

[0083] As an example, data cleaning includes missing value handling, outlier detection, and noise filtering. In missing value handling, for a small number of random missing values, forward / backward imputation or time-series-based linear interpolation can be used. For a large number of consecutive missing values, which may indicate sensor malfunction, the data for that time period should be flagged or removed. In outlier detection, the 3-sigma criterion (3σ) or box plot method can be used to identify and remove / smooth outliers caused by electrical interference or instantaneous shocks. For example, if a pressure value suddenly jumps to 10 times the normal range, it is considered an anomaly. In noise filtering, for high-frequency vibrations and other signals, low-pass filters (such as Butterworth filters) or moving averages can be used for smoothing to remove environmental noise and retain low-frequency trends that characterize equipment degradation.

[0084] As an example, feature selection specifically includes choosing a subset of features most relevant to the health status of the diesel engine based on mechanistic analysis and expert experience. For instance, combined changes in lubricating oil pressure and temperature can effectively indicate the health status of the lubrication system.

[0085] As an example, feature normalization specifically includes: Since the units and numerical ranges of different features in state data vary greatly—for example, revolutions per minute (RPM) are in the thousands, and pressure is in the tens of Pascals—normalization is necessary to prevent large-valued features from dominating the gradient descent direction during model training. Min-Max Scaling is commonly used to scale all feature values ​​to the [0, 1] interval.

[0086] As an example, when constructing model training samples, supervised learning samples are needed by adding target labels (input sequence, target label) to the input sequence. Specifically, a sliding window method can be used to construct these samples. Take the remaining service life of a critical component as an example. During the training phase, historical data needs to be labeled with the true remaining service life. It is typically assumed that device degradation is linear, from a brand-new state (RUL_max) to failure (RUL=0). For a device with a total lifespan of (T_total) cycles, its remaining service life in the t-th cycle is the difference between T_total and t, where T_total is an integer greater than or equal to 1, and t is an integer greater than or equal to 1 and less than or equal to the total lifespan.

[0087] S302 is a locally trained time series prediction model that predicts remaining lifetime or future state sequences.

[0088] Each diesel engine, acting as an independent node, can independently train a time series prediction model using the local private dataset generated in step S301 above.

[0089] S303 uploads the local model parameters to the server and performs federated aggregation to generate a global model.

[0090] Specifically, this step is the core of federated learning, aiming to pool the wisdom of all nodes without sharing the original data. Each client node uploads the parameters (including weights and biases) of its trained local time-series prediction model, rather than the data itself, to the central server after encryption. Once the central server has collected all the model parameters uploaded by the clients, it decrypts the data and executes an aggregation algorithm to generate a new, higher-performing global model—the global fault prediction model. The central server then redistributes the newly generated global model parameters to all clients to replace their existing local models.

[0091] S304, the twin receives the prediction results and maps them to the current state to form a visual display.

[0092] Specifically, abstract predictive data can be transformed into information that maintenance personnel can intuitively understand. The twin collaborative analysis platform can display a high-fidelity 3D model that perfectly matches the structure, dimensions, and components of a real diesel engine. Predicted remaining service life or predicted health status can be mapped to color codes.

[0093] As an example, critical components (such as turbochargers and piston connecting rods) can be color-coded based on the predicted health of their subsystems. Green indicates: the predicted remaining service life is greater than a first time threshold, indicating good health; yellow indicates: the predicted remaining service life is greater than a second time threshold but less than or equal to the first time threshold, indicating a health warning requiring attention; red indicates: the predicted remaining service life is less than or equal to the second time threshold, indicating a dangerous health condition requiring urgent maintenance. The first time threshold is greater than the second time threshold. For example, the first time threshold is 200 hours, and the second time threshold is 50 hours. It should be understood that the specific values ​​of the first and second time thresholds can be customized according to actual needs, and this application embodiment does not impose specific limitations.

[0094] As an example, clicking on a component on a twin of a diesel engine will bring up a detailed information panel displaying the engine's real-time data, predictive information, and historical data. Real-time data includes, for example, the component's current real-time temperature, pressure, and vibration values. Predictive information includes a defined remaining service life prediction, such as "148.5 hours remaining," and a future degradation curve. For instance, the health status can be defined as a linear function from 100% (new) to 0% (failure). Assume a diesel engine's turbocharger has a total lifespan T_total = 1200 operating hours. According to the health status formula HS(t) = (1000-t) / 1000*100%, where t is the operating time, HS(t) represents the linear relationship between health status and operating time. Based on the health status formula, the health status at any point in time can be calculated, and a degradation curve, i.e., the future degradation curve, can be plotted. Historical data can be represented as a graph of the component's historical operating parameters for comparative analysis.

[0095] In this embodiment, the data mapping between the digital twin and the physical diesel engine is not only one-way but also bidirectional. Specifically, this includes uplink synchronization and downlink feedback. Uplink synchronization includes synchronizing real-time sensor data to the digital twin. Downlink feedback includes automatically or semi-automatically triggering control commands to the physical device based on the digital twin's status assessment results, such as switching operating modes, issuing warnings, and generating maintenance requests.

[0096] S305, the central server aggregates information from multiple twins and performs horizontal analysis and sorting.

[0097] Specifically, the central server moves from the perspective of maintaining individual devices to macro-level management of the entire diesel engine fleet. The central server collects key health indicators (KPIs) from all digital twins, such as: each diesel engine's equipment identification, model, geographical location, current load, predicted RUL (Rating Under Utility), identified potential failure modes, and operating efficiency.

[0098] In order to effectively allocate limited maintenance resources, the risk score of the diesel engine can be calculated according to the above formula (2) model, and all diesel engines in the group can be sorted according to the urgency of maintenance based on the risk score.

[0099] S306 outputs a list of group maintenance recommendations and instructs users to provide feedback for confirmation.

[0100] Specifically, the central server can convert the risk score ranking results into executable maintenance work orders. For diesel engines with high risk scores, the system automatically queries the built-in maintenance knowledge base to generate specific maintenance recommendations. The content of the maintenance recommendations can be referred to the description in the above embodiments, and will not be repeated here.

[0101] S307 uses the maintenance results as input for subsequent iterations to optimize the model in the next cycle.

[0102] Specifically, once a maintenance work order is executed and closed, the maintenance personnel need to record the actual findings in the system. An example is shown below: Repair confirmation, fault confirmation, discrepancy found, and actual fault time.

[0103] Through steps S301-S307 above, combining the federated learning framework with a time-series prediction model helps address the challenges of data silos and privacy protection in predictive maintenance of diesel engines. Furthermore, utilizing multiple digital twin technology facilitates an intuitive mapping from data to information, and through group collaborative analysis and closed-loop feedback mechanisms, enables adaptive and highly efficient predictive maintenance of diesel engine groups, covering the entire process from individual equipment monitoring to intelligent operation and maintenance decision-making for the entire fleet.

[0104] Figure 4 A schematic diagram illustrating the structure of an engine maintenance system according to an exemplary embodiment of this application is shown. Figure 4 The system includes: multiple client nodes 410 deployed on the diesel engine side, a central server 420, and a twin collaborative analysis and display platform 430.

[0105] Each client node 410 can correspond to a physical diesel engine (diesel engine #1) for data acquisition, preprocessing, and local model training for its corresponding diesel engine. The central server 420 is used to execute the aggregation process of federated learning, generate a global model, and perform cross-sectional analysis of multiple twins. The twin collaborative analysis and display platform 430 is responsible for visualizing the analysis results and enabling user interaction.

[0106] like Figure 4 As shown, any client node 410 includes: an edge data acquisition and preprocessing module 411 and a local prediction model modeling module 412. The central server 420 includes a federated learning collaborative training module 421, a digital twin modeling and synchronization module 422, a multi-twin collaborative analysis module 423, and a predictive maintenance strategy generation module 424.

[0107] The edge data acquisition and preprocessing module 411 is deployed at each diesel engine node to collect sensor data such as temperature, pressure, fuel consumption, and speed, and performs standardized processing to construct time-series samples. The local prediction model modeling module 412 is used to train a local prediction model using the constructed time-series data to predict the remaining lifespan or abnormal trends of key components.

[0108] The Federated Learning Collaborative Training Module 421 is used by each edge node (client) to upload local model parameters to the central server. An aggregation algorithm is used to aggregate the local model parameters of each edge node into global model parameters and distribute updates accordingly. The Digital Twin Modeling and Synchronization Module 422 is used to construct a virtual model corresponding to each diesel engine, mapping the equipment's operating status and prediction results in real time, and supporting interactive visualization. The digital twins not only provide one-way data mapping between physical diesel engines but also have bidirectional data interaction capabilities, including uplink synchronization and downlink feedback. The Multi-Twin Collaborative Analysis Module 423 is used to perform horizontal standardization processing on the status of all equipment twins, outputting a health ranking chart, a fault heatmap, and a group maintenance plan, realizing the transformation from single-machine optimization to group maintenance optimization. The Predictive Maintenance Strategy Generation Module 424 is used to generate a priority maintenance list and scheduling suggestions based on the results of the multi-twin collaborative analysis, and supports user confirmation or adjustment.

[0109] According to the method and system of this application, a time-series prediction model can be deployed locally at each engine node. A global prediction model can be trained using federated learning without transmitting the original data. This cross-node collaborative training mechanism of the federated prediction model effectively avoids the risks of centralized storage and transmission of privacy data. While ensuring data security, it facilitates knowledge integration and shared modeling of distributed diesel engine operating data, significantly improving the model's generalization ability and robustness. Furthermore, the central server can map each engine to a corresponding digital twin model. The twin not only synchronously displays the physical state but also issues feedback commands, forming a "digital-physical" two-way control closed loop. This two-way closed-loop interaction mechanism of the digital twin enhances the interpretability and practicality of the prediction model, enabling the system to have a higher level of intelligent operation and maintenance decision-making, and can assist in functions such as early warning prompts, operating mode adjustments, and automatic maintenance request generation.

[0110] Furthermore, the central server can standardize and compare the predicted states of multiple engine twins, outputting health ranking, risk heatmaps, and global maintenance scheduling strategies. Based on the collaborative analysis results, the system can output maintenance priority ranking and batch maintenance suggestions, realizing the transformation from isolated maintenance to group maintenance optimization. Through this multi-twin group-level collaborative analysis and optimization, the overall efficiency of maintenance plans and the rationality of resource scheduling can be effectively improved.

[0111] In this embodiment, when the client performs federated learning-based model training, local training behavior occurs, with training metrics such as the number of local training epochs, batch count, and sample count (n_i) being visible. The number of local training epochs refers to the number of times the entire training dataset is traversed during training; the batch count refers to the number of batches the data is divided into within each training epoch; and the sample count refers to the number of samples contained in each batch. During the training period, the client device exhibits a "short-cycle high usage—idle—re-usage" round rhythm for its CPU / GPU / memory / IO devices.

[0112] Regarding the data type and format of client-side uploads, each client can periodically upload parameter tensors, such as at least one of weights, gradients, and optimizer states, with a size consistent with or proportional to the number of model parameters. Raw sensor fields, such as temperature, pressure, fuel consumption, and RPM, are not uploaded. For the parameter aggregation mode on the central server: the central server can execute aggregation algorithms, such as using n_i weighting in federated averaging algorithms, or introducing a proximal regularization term in federated approximation algorithms. The output of the aggregation algorithm is the global model parameters, which can be published and distributed according to training rounds. For training timing and auditability, model training is done in rounds, with a list of clients participating in model training (e.g., device identifiers of multiple clients), the proportion of training samples for each client, and aggregation weights. The model version number / hash increments with the training round. If a client undergoes the following processing flow: maintenance feedback, label correction, changes in local dataset version and sample count, the number of local samples participating in the next round of model training increases, and the corresponding task metrics will improve on adjacent global model versions. Improvements may include a decrease in the mean remaining lifetime error (RUL MAE) and an increase in the area under the failure curve (AUC).

[0113] In the embodiments of this application, the above features are useful for identifying whether federated learning or centralized training has been used based on training behavior features.

[0114] In practical applications, on the end-to-end network side, network packet capture (tcpdump / pcap) can be enabled at both the client and server. If Transport Layer Security (TLS) encryption is used, the pre-serialized payload data can be exported via the client's Software Development Kit (SDK) logs or through a valid debug switch. Data items during model training can be verified as follows: uplink payload data is a tensor (e.g., a float32 / float16 / int8 array), its size matches the number of model parameters, and it does not contain original sensor fields. Typical batch size and total number of parameters can also be recorded on the client or central server. Furthermore, it can be verified that downlink payload data represents new model parameters or model differences; the round identifier (round_id) and model version number increment over time. Uplink payload data is data sent from the client to the central server, and downlink payload data is data sent from the central server to the client.

[0115] On the training side, the client logs include at least one of the following fields: client identifier (client_id), round identifier, number of local training epochs, number of samples (n_samples), loss before / after (loss_before / after), and upload size (upload_size). Loss before / after refers to the model's loss function value before and after a specific training step (e.g., parameter update) during model training. Upload size refers to the size of the data uploaded by the client to the central server in the federated learning environment. The server aggregation logs include at least one of the following information items: list of participating clients, aggregation weight α_i (aggregation algorithm, where i represents the ID of any client), aggregation algorithm used, and global model hash (global_model_hash). The global model hash is the hash value of the global model.

[0116] In practical applications, after any client executes the "maintenance feedback, label correction, and dataset version change" process, the change timestamp and dataset hash can be recorded. By comparing the first round participated in after the change, the client is counted in the participation list, and the global model improves in the relevant task metrics.

[0117] In this embodiment, the uplink synchronization data flow is from the sensor to the twin, and the downlink feedback data flow is from the twin / platform to the device control. Uplink synchronization and downlink feedback form a two-way closed loop. Specifically, uplink synchronization includes the continuous push of high-frequency time-series data (such as engine temperature, pressure, fuel consumption, and speed data) to the twin. The twin's status panel is refreshed in real time and carries the model inference results (remaining service life and failure probability). Downlink feedback refers to the platform sending control commands and maintenance requests to the client (device control side) based on inference or rules, such as switching modes, limiting power, issuing warnings, and automatically generating maintenance work orders. When the maintenance work order is closed and feedback is written back, the twin status or device control suggestion is marked as "label corrected" or "dataset updated," and subsequently, the control suggestion threshold or sorting of the new model changes.

[0118] In practical applications, if the sensor input is manually changed or a "switch operation mode / generate maintenance request" is initiated on the twin platform, the device side can confirm receipt and execute it; by recording the uplink / downlink end-to-end delay, the "real-time / near real-time" bidirectional link can be proved; after the work order is closed and the twin status or device control suggestion is written back, it can be verified that the tag status of the twin panel and the source model version of the subsequent control suggestion have changed.

[0119] In practical applications, for multi-twin horizontal comparative analysis, the central server's system platform has a "fleet / machinery" level interface, which can be used to display at least one of the following: twin status diagrams, comparison trends, health ranking, and fault heatmaps for multiple diesel engines. It can generate group maintenance plans, handle priorities, maintenance windows, and resource scheduling, and support user confirmation / adjustment. A maintenance window refers to a predetermined time range or period set on the central server, within which specific maintenance activities or tasks are completed. When the labels of single or multiple devices are corrected and they enter the next round of federated training, the group health ranking and the priority of the maintenance list undergo version-based changes.

[0120] When switching model versions, such as from model V1 to V2, two separate "Group Ranking + Maintenance Plan" reports can be generated. The group ranking indicates the priority of maintenance based on risk scoring. The maintenance plan is a maintenance recommendation for each client, generated based on the group ranking. Comparing the newly generated reports with the previous version identifies which devices are affected by the maintenance plan update, enabling differential comparison and labeling of affected devices. When making model changes or updates, the versions of business rules can be temporarily frozen or fixed to ensure accurate assessment of the impact of model changes on the maintenance plan, unaffected by changes in other business rules. By freezing the business rule versions, comparisons can be made of ranking / threshold changes caused only by model changes.

[0121] In this embodiment, the closed-loop feedback path includes the following processing flow: feedback maintenance, label correction, local dataset modification, the next round of federated learning, and performance and policy improvement. Offline / online metrics related to this feedback are improved, such as a decrease in remaining lifetime error, improved alarm lead time, and a decrease in false positive / false negative rates. Policy-related thresholds and ranking results are adjusted with the new model version. This demonstrates the actual operation of the closed loop of "feedback maintenance → label correction → local dataset modification → next round of federated learning → performance and policy improvement".

[0122] Furthermore, in this embodiment, the following key interfaces—maintenance feedback entry, tag editing, dataset version list, federated monitoring, model registration, and group reports—can be screen-recorded or have their entire process recorded and electronically notarized to generate an evidence chain mapping table. A identifiable tag correction event is generated for a single device, tracking its entry into the next training round and observing changes in inferences / recommendations related to that device. The training pipeline is frozen or the model version is rolled back to verify that relevant metrics / recommendations no longer change after the closed loop is broken, thus ruling out the scenario of only recording without training. Related PCAP (Programmable Packet Access Point), logs, model artifacts, reports / screen recordings are hashed and electronically notarized to ensure relevance, authenticity, and legality.

[0123] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide an engine maintenance device.

[0124] Figure 5 This diagram illustrates a module schematic of an engine maintenance apparatus according to an embodiment of this application. The apparatus is used to perform the engine maintenance method applied to a central server as described in the above embodiments. In some embodiments, the apparatus includes the following modules.

[0125] The data display module 510 displays the health index data of each engine through multiple digital twins. The health index data of any engine includes at least the fault prediction result generated by the corresponding client based on the global fault prediction model. The global model parameters of the global fault prediction model are obtained by the central server aggregating the local model parameters trained locally by multiple clients.

[0126] The risk assessment module 520 scores the risk based on the fault prediction results contained in the health index data of each engine, and obtains the risk score of each engine.

[0127] It is recommended that module 530 generate maintenance recommendations for each engine based on the risk score of each engine.

[0128] In some embodiments, the apparatus further includes: a global model parameter generation module, configured to send an initial fault prediction model to each client during the current model training cycle before receiving and displaying the corresponding engine health index data through multiple digital twins; receive local model parameters uploaded by each client, wherein the local model parameters uploaded by any client are obtained by training the initial fault prediction model based on the historical operating status data of the corresponding engine; aggregate the local model parameters uploaded by each client to obtain global model parameters; and send the global model parameters to each client so that each client generates a global fault prediction model based on the global model parameters.

[0129] In some embodiments, the risk assessment module 520 is specifically used to: for any engine, obtain the predicted remaining service life and the predicted fault mode from the engine fault prediction results, wherein the fault mode is used to characterize the type of engine fault; determine the risk coefficient corresponding to the remaining service life based on the remaining service life and the preset correspondence between the engine's remaining service life and the engine fault risk; obtain the severity level value corresponding to the fault mode from a preset expert knowledge base; obtain the engine's downtime impact level value, wherein the downtime impact level value is preset according to the engine's usage scenario; and determine the engine's risk score based on the risk coefficient, the severity level value, and the downtime impact level value.

[0130] In some embodiments, it is suggested that the generation module 530 is specifically used to: sort the risk scores of each engine to obtain a risk score sorting result; sequentially obtain at least one risk score in descending order of the risk score sorting result; for each obtained risk score, obtain the failure mode and remaining service life of the engine to which the risk score belongs; query the specific maintenance measures corresponding to the failure mode and remaining service life from the preset maintenance knowledge base; and generate maintenance suggestions containing specific maintenance measures.

[0131] In some embodiments, the feedback module is configured to, after generating maintenance recommendations for each engine, display the results of multi-twin collaborative analysis through a twin collaborative analysis display platform. The multi-twin collaborative analysis results include a group maintenance recommendation list, which includes: maintenance recommendations, remaining service life, and failure modes for each engine; determine the target engine requiring maintenance based on the group maintenance recommendation list; generate corresponding control commands according to the maintenance recommendations for the target engine; send the control commands to the client corresponding to the target engine; receive feedback on the actual maintenance results for the group maintenance recommendation list, which at least indicates whether the corresponding fault prediction result is a false alarm; determine the label correction instruction for the corresponding client based on the actual maintenance result feedback; and send the label correction instruction to the corresponding client for model training in the next model training cycle.

[0132] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0133] Figure 6 This diagram illustrates a module schematic of an engine maintenance apparatus according to an embodiment of this application. The apparatus is used to perform the engine maintenance method applied to a client in the above embodiments. In some embodiments, the apparatus includes the following modules.

[0134] The prediction module 610 performs fault prediction on the local operating status data of the engine corresponding to the client based on the global fault prediction model, and obtains the fault prediction result. The global fault prediction model is generated using global model parameters from the central server. The global model parameters are obtained by the central server aggregating the local model parameters trained locally by multiple clients.

[0135] The sending module 620 sends the fault prediction results to the central server. The digital twin of the engine deployed on the central server is used to display health indicator data containing the fault prediction results. The central server is used to perform risk scoring based on the fault prediction results of each engine to obtain a risk score and generate corresponding engine maintenance recommendations.

[0136] In some embodiments, the apparatus further includes: a local training module, configured to receive an initial fault prediction model from the central server during the current model training cycle before performing fault prediction on the local operating status data of the engine corresponding to the client based on the global fault prediction model issued by the central server; perform model training on the initial fault prediction model based on the historical operating status data of the corresponding engine to obtain local model parameters; and send the local model parameters to the central server so that the central server aggregates the local model parameters sent by multiple clients to obtain global model parameters and generates a global fault prediction model based on the global model parameters.

[0137] In some embodiments, the apparatus further includes: a correction module, configured to, after sending the fault prediction result to the central server, receive control instructions from the central server, the control instructions including maintenance recommendations for the engine, remaining service life, and fault mode; receive a label correction instruction, the label correction instruction being used to indicate whether the fault prediction result of the engine is a false alarm; update the historical operating state data to which the fault prediction result belongs as training data according to the label correction instruction; and, in the next training cycle, perform model training based on the updated historical operating state data to obtain new local model parameters, and send the new model parameters to the central server.

[0138] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0139] Figure 7 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 7 As shown, the electronic device includes a memory 701 and a processor 702. The memory 701 stores a computer program that can run on the processor 702. When the processor 702 executes the computer program, it implements the method described in the above embodiments. The number of memories 701 and processors 702 can be one or more. In a specific implementation, the electronic device may also include a communication interface 703 for communicating with external devices and performing data exchange and transmission.

[0140] In practical implementation, if the memory 701, processor 702, and communication interface 703 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0141] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0142] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0143] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0144] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0145] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0146] It should be understood that the aforementioned processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0147] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0148] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0149] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0150] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0151] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0152] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0153] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0155] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An engine maintenance method, characterized in that, Applied to a central server, the method includes: The health index data of each engine is displayed through multiple digital twins. The health index data of any engine includes at least the fault prediction result generated by the corresponding client based on the global fault prediction model. The global model parameters of the global fault prediction model are obtained by the central server aggregating the local model parameters trained locally by multiple clients. Risk scores are obtained by performing risk assessments based on the fault prediction results contained in the health index data of each engine. Based on the risk scores of each engine, maintenance recommendations are generated for each engine.

2. The method according to claim 1, characterized in that, Before receiving and displaying the corresponding engine health indicator data through multiple digital twins, the process also includes: During the current model training cycle, send the initial fault prediction model to each client; The system receives local model parameters uploaded by each client. The local model parameters uploaded by any client are obtained by training the initial fault prediction model based on the historical operating status data of the corresponding engine. The local model parameters uploaded by each client are aggregated to obtain global model parameters; The global model parameters are sent to each client so that each client can generate a global fault prediction model based on the global model parameters.

3. The method according to claim 1, characterized in that, The risk score for each engine is obtained by performing a risk assessment based on the fault prediction results contained in the health indicator data of each engine, including: For any engine, the predicted remaining service life and the predicted failure mode are obtained from the failure prediction results of the engine, and the failure mode is used to characterize the failure type of the engine. Based on the remaining service life and the preset correspondence between the engine's remaining service life and the engine failure risk, the risk coefficient corresponding to the remaining service life is determined. Obtain the severity level value corresponding to the fault mode from the preset expert knowledge base; Obtain the downtime impact level value of the engine, which is preset according to the engine's usage scenario; The risk score of the engine is determined based on the risk coefficient, the severity level value, and the downtime impact level value.

4. The method according to claim 3, characterized in that, The process of generating maintenance recommendations for each engine based on its risk score includes: The risk scores of each engine are sorted to obtain the risk score sorting result; Based on the descending order of the risk scores, obtain the first at least one risk score in sequence; For each risk score obtained, the fault mode and remaining service life of the engine to which the risk score belongs are obtained; From the preset maintenance knowledge base, query the specific maintenance measures corresponding to the fault mode and the remaining service life; Generate maintenance recommendations that include the specific maintenance measures described above.

5. The method according to claim 3, characterized in that, After generating maintenance recommendations for each of the engines, the process further includes: The results of multi-twin collaborative analysis are displayed through a twin collaborative analysis display platform. The results of multi-twin collaborative analysis include a group maintenance recommendation list, which includes: maintenance recommendations for each engine, the remaining service life, and the failure mode. Based on the group maintenance suggestion list, the target engine that needs maintenance is determined, the corresponding control command is generated according to the maintenance suggestion of the target engine, and the control command is sent to the client corresponding to the target engine; Receive actual maintenance result feedback for the group maintenance suggestion list, wherein the actual maintenance result feedback is at least used to indicate whether the corresponding fault prediction result is a false alarm; Based on the feedback of the actual maintenance results, the label correction instruction for the corresponding client is determined; The label correction instruction is sent to the corresponding client for model training in the next model training cycle.

6. An engine maintenance method, characterized in that, Applied to a client, the method includes: The fault prediction result is obtained by performing fault prediction on the local operating status data of the engine corresponding to the client based on the global fault prediction model; the global fault prediction model is generated using global model parameters from the central server, and the global model parameters are obtained by the central server by aggregating the local model parameters trained locally by multiple clients. The fault prediction results are sent to the central server. The digital twin of the engine deployed on the central server is used to display health indicator data containing the fault prediction results. The central server is used to perform risk scoring based on the fault prediction results of each engine to obtain a risk score and generate corresponding engine maintenance recommendations.

7. The method according to claim 6, characterized in that, Before performing fault prediction on the local operating status data of the engine corresponding to the client based on the global fault prediction model, the method further includes: During the current model training cycle, the initial fault prediction model is received from the central server. Based on the historical operating status data of the corresponding engine, the initial fault prediction model is trained to obtain local model parameters; The local model parameters are sent to the central server, so that the central server can aggregate the local model parameters sent by multiple clients to obtain global model parameters, and generate a global fault prediction model based on the global model parameters.

8. The method according to claim 7, characterized in that, After sending the fault prediction result to the central server, the process further includes: Receive control commands from the central server, the control commands containing maintenance recommendations, remaining service life, and fault modes for the engine; Receive a tag correction instruction, the tag correction instruction being used to indicate whether the fault prediction result of the engine is a false alarm; According to the label correction instruction, update the historical running state data, which is used as training data, to which the fault prediction result belongs; In the next training cycle, the model is trained based on the updated historical running status data to obtain new local model parameters, and the new model parameters are sent to the central server.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1 to 5 or any one of claims 6 to 8.

10. A computer-readable storage medium storing a computer program therein, which, when executed by a processor, implements the method of any one of claims 1 to 5 or any one of claims 6 to 8.

Images