Method, device and cloud server for processing diagnostic logs

Abstract

The application discloses a diagnosis log processing method and device and a cloud server, and relates to the technical field of vehicle diagnosis. The method comprises the following steps: receiving a diagnosis request and determining a corresponding target analysis model; acquiring state information of each computing node, and selecting a target computing node from the plurality of computing nodes based on the state information; loading model parameters of the target analysis model to the target computing node to obtain an analysis model instance; and inputting diagnosis data into the analysis model instance to obtain a diagnosis conclusion. The application dynamically schedules computing resources and matches diagnosis models on demand, improves resource utilization and diagnosis response timeliness, and guarantees consistency of diagnosis model versions and reliability of diagnosis results.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a method for processing diagnostic logs and a cloud server. Background Technology

[0002] Automotive fault diagnosis is a crucial part of vehicle after-sales maintenance. Currently, the common diagnostic method involves repair personnel using diagnostic equipment to read vehicle fault codes and then combining this information with their repair experience to diagnose the problem. Some diagnostic equipment has a built-in fixed diagnostic rule library, which can match collected vehicle data with the rule library and output reference conclusions. This local diagnostic method is limited by the device's own computing power and storage space, resulting in a limited number and complexity of diagnostic rules that it can support, and insufficient ability to identify complex faults.

[0003] With the development of cloud computing technology, solutions have emerged that deploy diagnostic models on cloud servers, perform data analysis in the cloud, and return results to diagnostic terminals. In existing cloud-based diagnostic solutions, cloud servers are typically pre-configured with a fixed number of computing resources, processing all diagnostic requests using the same diagnostic model. When the concurrency of diagnostic requests is high, the fixed computing resources cannot be scaled up as needed, causing some requests to queue and significantly increasing diagnostic response latency. Conversely, when the concurrency of diagnostic requests is low, a large amount of computing resources remain idle, resulting in resource waste. Therefore, existing cloud-based diagnostic solutions still have room for improvement in terms of computing resource utilization efficiency and the timeliness of diagnostic responses. Summary of the Invention

[0004] This application provides a method for processing diagnostic logs and a cloud server, which can solve the technical problems of low resource utilization and unstable response latency caused by fixed computing resources and a single model in the prior art. The technical solution is as follows: In a first aspect, embodiments of this application provide a method for processing diagnostic logs, the method comprising: Receive diagnostic log data packets sent by the diagnostic terminal, the diagnostic log data packets being collected by the diagnostic terminal on the vehicle; Obtain the analysis task type; the analysis task type is either a fault prediction task or a diagnostic classification task. The diagnostic log data packet is preprocessed to obtain standardized diagnostic data; Features are extracted from the standardized diagnostic data to generate a feature vector; According to the analysis task type, a corresponding target analysis model is obtained from multiple pre-trained analysis models; the multiple analysis models include a fault prediction model and a diagnostic classification model, wherein the fault prediction model corresponds to the fault prediction task and the diagnostic classification model corresponds to the diagnostic classification task. The complexity of the analysis task is determined based on the feature vector and the analysis task type. Based on the complexity of the analysis task, a corresponding target computing node is obtained from the computing resource pool, which includes multiple hardware computing nodes. The model parameters of the target analysis model are loaded onto the target computing node to obtain an analysis model instance; The feature vector is input into the analysis model instance, and the analysis model instance outputs a diagnostic conclusion. A diagnostic response is generated based on the diagnostic conclusion, and the diagnostic response is sent to the diagnostic terminal.

[0005] Secondly, embodiments of this application provide a diagnostic log processing apparatus, the apparatus comprising: The transceiver module is used to receive diagnostic log data packets sent by the diagnostic terminal and obtain the analysis task type; the diagnostic log data packets are collected by the diagnostic terminal on the vehicle; the analysis task type is either a fault prediction task or a diagnostic classification task. The generation module is used to preprocess the diagnostic log data packet to obtain standardized diagnostic data, and extract features from the standardized diagnostic data to generate a feature vector; The acquisition module is used to acquire the corresponding target analysis model from a plurality of pre-trained analysis models according to the analysis task type; the plurality of analysis models include a fault prediction model and a diagnostic classification model, wherein the fault prediction model corresponds to the fault prediction task and the diagnostic classification model corresponds to the diagnostic classification task. The determination module is used to determine the complexity of the analysis task based on the feature vector and the analysis task type, and to obtain the corresponding target computing node in the computing resource pool based on the complexity of the analysis task, wherein the computing resource pool includes multiple hardware computing nodes; The output module is used to load the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance, and input the feature vector into the analysis model instance, and output the diagnostic conclusion from the analysis model instance; The transceiver module is also used to generate a diagnostic response based on the diagnostic conclusion and send the diagnostic response to the diagnostic terminal.

[0006] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0007] Fourthly, embodiments of this application provide a cloud server, which may include: a processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded by the processor and to execute the above-described method steps.

[0008] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: The solution obtains diagnostic requests from a cloud server and determines the corresponding target analysis model. Simultaneously, it acquires the current status information of each computing node, identifies the target computing node from multiple nodes based on this information, loads the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance, and finally, this analysis model instance performs analysis on the diagnostic data and outputs a diagnostic conclusion. The beneficial effects of this solution are: First, the cloud server selects the target computing node based on the status information of each computing node, realizing dynamic scheduling of computing resources. When the concurrency of diagnostic requests is high, tasks can be assigned to computing nodes with lighter loads, avoiding some nodes being overloaded while others are idle, effectively improving the overall utilization of computing resources, shortening the queuing time of diagnostic requests, and reducing the latency of diagnostic responses.

[0009] Secondly, the cloud server determines the corresponding target analysis model based on the fault type indicated by the diagnostic request, enabling different diagnostic requests to be matched with suitable diagnostic models, rather than all requests sharing the same model. This on-demand model matching approach allows for sufficient model complexity and analytical accuracy in the diagnosis of complex faults, while lightweight models can be used to achieve a rapid response in the diagnosis of simple faults, achieving a better balance between diagnostic accuracy and response speed.

[0010] Furthermore, the model parameters of the target analysis model are centrally managed by the cloud server and loaded onto the target computing nodes as needed. The updates and version management of the model parameters are all completed uniformly in the cloud. The diagnostic terminal does not need to be upgraded locally. Each computing node runs the latest version of the diagnostic model, ensuring the consistency and timeliness of the diagnostic results. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the architecture of the diagnostic log processing system provided in the embodiments of this application; Figure 2This is a flowchart illustrating a diagnostic log processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the process for determining the complexity of the analysis task provided in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of a diagnostic log processing device provided in this application; Figure 5 This is a schematic diagram of a computer storage medium provided in this application; Figure 6 This is a schematic diagram of the structure of a cloud server provided in this application. Detailed Implementation

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

[0014] It should be noted that the diagnostic log processing method provided in this application is generally executed by the diagnostic terminal, and correspondingly, the diagnostic log processing device is generally set in the target vehicle 102.

[0015] Figure 1 This is a schematic diagram of the architecture of a diagnostic log processing system provided in an embodiment of this application. The system is used to implement the diagnostic log processing method described in this application and is composed of a diagnostic terminal 100, a cloud server 101, and a target vehicle 102.

[0016] The target vehicle 102 serves as the data source for diagnostic logs. It contains multiple on-board electronic control units and sensor units. The original diagnostic logs generated during vehicle operation, such as operating status parameters, fault code information, and operating condition record data, are all stored in the corresponding on-board units, providing the original data foundation for subsequent diagnostic analysis.

[0017] The diagnostic terminal 100 establishes a communication connection with the target vehicle 102 and can access the vehicle's electronic control system through the vehicle's standard diagnostic interface. It reads and collects the original diagnostic logs of the target vehicle 102, encapsulates them into diagnostic log data packets, and uploads them to the cloud server 101 through a wired or wireless communication network. At the same time, the diagnostic terminal 100 has the ability to receive and display data, and is used to receive the diagnostic responses sent by the cloud server 101 and present the final diagnostic analysis results to the operator.

[0018] The cloud server 101 is the executing entity of the method described in this application. Internally, it is configured with a computing resource pool containing multiple hardware computing nodes and multiple pre-trained analysis models. After receiving the diagnostic log data packet uploaded by the diagnostic terminal 100, the cloud server 101 preprocesses the data packet according to the obtained analysis task type to obtain standardized diagnostic data. Feature vectors are generated through feature extraction and matched with the corresponding target analysis model. The cloud server 101 further determines the complexity of the analysis task based on the feature vectors and the analysis task type, schedules the corresponding target computing node from the computing resource pool to load the parameters of the target analysis model to generate an analysis model instance, outputs diagnostic conclusions through the analysis model instance calculation, and finally encapsulates the diagnostic conclusions into a diagnostic response and sends it to the corresponding diagnostic terminal 100.

[0019] It should be understood that Figure 1 The number of diagnostic terminals, networks, and servers shown is for illustrative purposes only. The number of diagnostic terminals, networks, and servers can be any number, depending on the implementation requirements.

[0020] The following will be combined with the appendix Figure 2 This application provides a detailed description of a diagnostic log processing method according to embodiments of the present application. The diagnostic log processing device in these embodiments may be... Figure 1 The cloud server shown.

[0021] Please see Figure 2 This is a flowchart illustrating a diagnostic log processing method provided in an embodiment of this application. Figure 2 As shown, the method described in this application embodiment may include the following steps: S1. Receive the diagnostic log data packet sent by the diagnostic terminal. The diagnostic log data packet is collected by the diagnostic terminal on the vehicle.

[0022] The cloud server receives diagnostic log data packets sent by the diagnostic terminal, which are collected by the diagnostic terminal on the vehicle. During vehicle operation, the diagnostic terminal continuously collects operating status data, fault codes, and sensor readings from various electronic control units in the vehicle through the on-board diagnostic interface. This data is then encapsulated into diagnostic log data packets according to a preset communication protocol and uploaded to the cloud server. Upon receiving the data packets, the cloud server first performs a data integrity check. If the check passes, the data packet is stored in a receive queue for further processing. If the check fails, a retransmission request is sent back to the diagnostic terminal.

[0023] S2. Obtain the analysis task type; the analysis task type is either a fault prediction task or a diagnostic classification task.

[0024] The cloud server obtains the analysis task type, which can be either a fault prediction task or a diagnostic classification task. The task type can be obtained by parsing diagnostic requests sent from diagnostic terminals, or it can be determined automatically by the cloud server based on preset business rules. The diagnostic request may carry task instruction information, which the cloud server parses to determine whether fault prediction or diagnostic classification needs to be performed. Fault prediction tasks aim to predict potential vehicle faults within a certain period based on historical operating data and current status data, while diagnostic classification tasks aim to locate and classify the root causes of existing faults.

[0025] S3. Preprocess the diagnostic log data packet to obtain standardized diagnostic data.

[0026] The cloud server preprocesses the diagnostic log data packets to obtain standardized diagnostic data. The purpose of preprocessing is to convert raw diagnostic logs from different vehicle models, communication protocols, and data formats into standardized data in a unified format, ensuring consistent processing by subsequent feature extraction and analysis models. Preprocessing operations may include sub-steps such as data unpacking, protocol parsing, data cleaning, missing value imputation, outlier removal, and data format conversion. The data cleaning stage filters out duplicate records, invalid fields, and values ​​outside the reasonable range. The missing value imputation stage can use methods such as mean imputation, forward imputation, or prediction imputation based on regression models. The outlier removal stage marks and removes data points that deviate significantly from the physical constraints of each signal.

[0027] S4. Extract features from standardized diagnostic data and generate feature vectors.

[0028] The cloud server extracts features from standardized diagnostic data, generating a feature vector. Feature extraction is the process of converting standardized diagnostic data into a numerical vector representation that can be used by the analysis model. Extracted features can include time-domain statistical features, frequency-domain features, and domain-knowledge-based expert features. Time-domain statistical features include mean, variance, maximum, minimum, peak-to-peak value, skewness, and kurtosis; frequency-domain features include the amplitude of each frequency component obtained through Fast Fourier Transform; and expert features include the ratio of engine load to speed, and the deviation between long-term and short-term fuel corrections. The cloud server arranges the extracted features in a preset order to form a multi-dimensional feature vector, which serves as the input to the subsequent analysis model.

[0029] S5. Based on the analysis task type, obtain the corresponding target analysis model from multiple pre-trained analysis models.

[0030] The cloud server selects the corresponding target analysis model from multiple pre-trained analysis models based on the analysis task type. These models include fault prediction models and diagnostic classification models. The fault prediction model corresponds to the fault prediction task, and the diagnostic classification model corresponds to the diagnostic classification task. Both models are pre-trained machine learning models, but their model structures, training data, and output formats differ. The fault prediction model can be built based on a Long Short-Term Memory (LSTM) network, taking a time-series feature vector as input and outputting the probability of each fault type occurring within a preset future time period. The diagnostic classification model can be built based on a gradient boosting tree or random forest, taking the feature vector at the current moment as input and outputting a specific fault category label and its corresponding confidence score. After determining the analysis task type, the cloud server retrieves a model matching that task type from the model library and uses it as the target analysis model.

[0031] In one embodiment, the fault prediction model is constructed using a neural network architecture based on a Long Short-Term Memory (LSTM) network. This model comprises an input layer, two LSTM hidden layers, a fully connected layer, and an output layer. The number of neurons in the input layer is consistent with the dimension of the feature vector, and it receives the feature vector generated in step S4. The first LSTM hidden layer contains 128 hidden units, and the second LSTM hidden layer contains 64 hidden units. The two LSTM layers are connected via a fully connected mechanism to pass the hidden state. Stacking LSTM layers enhances the model's ability to capture long-distance dependencies in time-series data. Each LSTM hidden unit contains three gating structures: a forget gate, an input gate, and an output gate, which control the degree of discarding historical information, the degree of writing new information, and the degree of outputting the current hidden state, respectively. The fully connected layer, located after the second LSTM hidden layer, contains 32 neurons and uses ReLU (Rectified Luminous Interval) as the activation function to perform nonlinear mapping and dimensionality reduction on the time-series features extracted by the LSTM layers. The number of neurons in the output layer is equal to the total number of preset fault types. The output layer uses the softmax activation function to map the output value of each neuron to a probability value between 0 and 1. The sum of the probability values ​​corresponding to all fault types is 1. Each probability value represents the probability of the corresponding fault type occurring in a preset time period in the future.

[0032] For example, in a fault prediction model capable of predicting eight types of faults, the input layer receives a feature vector with a dimension of 32. The first LSTM hidden layer contains 128 hidden units, the second LSTM hidden layer contains 64 hidden units, the fully connected layer contains 32 neurons, and the output layer contains 8 neurons, corresponding to the eight fault types: engine misfire, catalytic converter efficiency degradation, slow oxygen sensor response, ignition coil failure, injector blockage, abnormal turbocharger pressure, exhaust gas recirculation valve sticking, and lean fuel system. When a feature sequence containing 500 sampling points is input, the output layer outputs eight probability values, with the third neuron outputting 0.78, indicating a 78% probability of catalytic converter efficiency degradation.

[0033] The diagnostic classification model is constructed using an ensemble learning algorithm based on gradient boosting trees. This model consists of multiple decision trees combined in an additive manner. Each decision tree fits the residuals of the previous tree, and the final classification result is obtained by weighted summation of the predictions from all decision trees. The diagnostic classification model contains 200 decision trees, each with a maximum depth of 6 and a learning rate of 0.1 to control the contribution of each tree to the final prediction result and prevent overfitting. The model employs a feature subsampling strategy when splitting nodes, randomly selecting 80% of the total number of features as candidate split features at each split to enhance the model's generalization ability. The model's objective function is a multi-class softmax loss function, which can simultaneously output the probability distributions of multiple fault categories and select the fault category with the highest probability value as the diagnostic classification result.

[0034] For example, in a diagnostic classification model, 200 decision trees are constructed sequentially, each with a maximum depth of 6 layers and a learning rate of 0.1. When a 24-dimensional feature vector is input, it passes through each of the 200 decision trees. Each tree provides an initial classification score, and all scores are accumulated and converted into a probability distribution using a softmax function. The final output is the category of "ignition coil secondary winding fault," with a confidence score of 0.92. This confidence score indicates the model's certainty regarding the diagnostic result; the closer the value is to 1, the more reliable the diagnosis.

[0035] The training process for the fault prediction model first requires constructing a training dataset. This dataset is built by retrieving diagnostic log data collected within a preset time period from a historical diagnostic log database on a cloud server. Each log entry undergoes preprocessing and feature extraction to generate a feature vector, which serves as a training sample. Simultaneously, each log entry is labeled with a fault tag based on the subsequent actual fault record; the fault tag encodes the type of fault that actually occurred. If a vehicle corresponding to a particular log entry did not experience a fault within the preset time period, its fault tag is marked as "no fault." The training dataset is randomly divided into a training set and a validation set in an 8:2 ratio. The training set is used to update model parameters, while the validation set is used to monitor overfitting during training.

[0036] The model was trained using the Adam optimizer for parameter updates, with an initial learning rate of 0.001, a batch size of 32, and 100 training epochs. The cross-entropy loss function was used, which measures the difference between the model's predicted probability distribution and the true fault labels; a smaller loss value indicates more accurate predictions. After each training epoch, a validation loss value was calculated using the validation set. If the validation loss value did not decrease for 10 consecutive epochs, an early stopping mechanism was triggered, terminating training prematurely, and the optimal model parameters on the validation set were saved as the final parameters for the fault prediction model. After training, the model was evaluated using an independent test set, with evaluation metrics including accuracy, precision, recall, and F1 score.

[0037] For example, when constructing the training dataset for the fault prediction model, 150,000 diagnostic log data collected over the past 12 months were retrieved from the historical diagnostic log database. Each data point was preprocessed and feature extracted according to steps S3 and S4, generating a corresponding feature vector. Fault labels were assigned to the feature vectors based on the vehicle's actual maintenance records within 30 days of data collection: engine misfire was labeled as label 1, catalytic converter efficiency degradation as label 3, and no fault as label 0. The 150,000 samples were divided into a 120,000-sample training set and a 30,000-sample validation set at an 8:2 ratio. The Adam optimizer was used for training with a learning rate of 0.001 and a batch size of 32. At the 47th epoch, the validation loss value failed to decrease for 10 consecutive epochs, triggering an early stop mechanism. The model parameters from the 37th epoch were saved as the final model. The evaluation results on 10,000 test samples showed an accuracy of 94.3% and a macro-average F1 score of 0.91.

[0038] The training process for the diagnostic classification model also requires the construction of a training dataset. The training dataset is constructed by retrieving confirmed fault type diagnostic log data from a historical diagnostic log database on a cloud server. Each log entry is preprocessed and its features are extracted to generate a feature vector, which serves as the training sample. The confirmed fault type corresponding to that log entry is used as the fault label. The training dataset is randomly divided into a training set and a validation set in an 8:2 ratio.

[0039] The diagnostic classification model is trained using an iterative gradient boosting tree approach. In each iteration, the model calculates the residual between the current model prediction and the true fault label, constructs a new decision tree to fit this residual, and then adds the new decision tree to the model with a learning rate of 0.1. This iterative process continues for 200 iterations. After each iteration, the model's multi-class log loss is evaluated using a validation set. If the validation loss does not decrease after 10 consecutive iterations, an early stopping mechanism is triggered, and the number of decision trees in the final model is determined as the iteration number at which early stopping is triggered. Among the hyperparameters used in model training, the maximum depth of each decision tree is 6, the feature subsampling ratio when splitting nodes is 80%, and the minimum leaf node sample weight sum is 1, used to control the complexity of a single decision tree. After training, the model is evaluated using an independent test set, with evaluation metrics including accuracy, precision, recall, and F1 score.

[0040] For example, when constructing the training dataset for the diagnostic classification model, 80,000 diagnostic log entries whose fault types had been confirmed by maintenance technicians were retrieved from the historical diagnostic log database. Preprocessing and feature extraction were performed according to steps S3 and S4 to generate feature vectors and label them with the corresponding fault type tags. The 80,000 samples were divided into a training set of 64,000 entries and a validation set of 16,000 entries in an 8:2 ratio. 200 decision trees were trained, each with a maximum depth of 6, a learning rate of 0.1, and a feature subsampling ratio of 80%. After 135 rounds of training, the validation loss value failed to decrease for 10 consecutive rounds, triggering an early stopping mechanism. The final model retained 125 decision trees. The evaluation results on 5,000 test samples showed an accuracy of 96.1% and a macro-average F1 score of 0.94.

[0041] S6. Determine the complexity of the analysis task based on the feature vector and the analysis task type.

[0042] The cloud server determines the complexity of the analysis task based on the feature vector and the analysis task type. The analysis task complexity quantifies the computational resource requirements of the current analysis task, and its determination can comprehensively consider the attribute information of the feature vector and the inherent characteristics of the analysis task type. The cloud server can obtain the attribute information of the feature vector, including the feature dimension and the data volume. The feature dimension is the number of features contained in the feature vector, and the data volume is the total number of data sampling points participating in this analysis. The cloud server queries a preset task complexity mapping table based on the analysis task type to obtain the baseline complexity coefficient corresponding to the analysis task type. Fault prediction tasks, due to their involvement in time series modeling and future state prediction, typically have a higher baseline complexity coefficient than diagnostic classification tasks. The cloud server calculates the analysis task complexity based on the feature dimension, data volume, and baseline complexity coefficient. Optionally, the analysis task complexity can be calculated using the formula C = α × (d × n), where C is the analysis task complexity, α is the baseline complexity coefficient, d is the feature dimension, and n is the data volume.

[0043] S7. Based on the complexity of the analysis task, obtain the corresponding target computing node from the computing resource pool, which includes multiple hardware computing nodes.

[0044] The cloud server selects a target computing node from the computing resource pool based on the complexity of the analysis task. The computing resource pool is a collection of multiple hardware computing nodes managed by the cloud server, each with independent computing resources such as CPU, memory, and GPU. The cloud server selects a hardware computing node from the pool as the target computing node based on the complexity of the analysis task. This target computing node will be used to handle subsequent model loading and inference calculations. The selection process may include obtaining the current load status of each hardware computing node, which includes at least one of CPU utilization, memory usage, and GPU utilization; determining the minimum resource configuration requirements for executing the analysis task based on its complexity; and then filtering hardware computing nodes that meet the filtering criteria from the computing resource pool based on the current load status and the minimum resource configuration requirements. The filtering criteria can be set to ensure that the current load status of the hardware computing node is below a preset load threshold and that the available resources meet the minimum resource configuration requirements.

[0045] S8. Load the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance.

[0046] The cloud server loads the model parameters of the target analysis model onto the target computing node, resulting in an analysis model instance. Model parameter loading refers to transferring the target analysis model's structure definition file and trained weight file to the target computing node, whereby the target computing node initializes and prepares the model. The cloud server first sends a model deployment request to the target computing node, carrying the model identifier of the target analysis model. Upon receiving the request, the target computing node allocates memory and GPU resources, and then the cloud server transfers the model parameter file to the target computing node. The model parameter file includes a model structure description file and a model weight file. The model structure description file defines the model's architecture information, such as the number of layers, the number of neurons per layer, and the type of activation functions. The model weight file stores the connection weights and bias terms between neurons in each layer. After the transfer is complete, the cloud server controls the target computing node to complete the model loading and initialization based on the model parameter file, enabling the target computing node to run the target analysis model and obtain a callable analysis model instance.

[0047] S9. Input the feature vector into the analysis model instance, and the analysis model instance will output the diagnostic conclusion.

[0048] The cloud server inputs feature vectors into the analysis model instance, which then outputs diagnostic conclusions. Upon receiving the feature vectors, the analysis model instance performs forward inference calculations, passing and calculating layer by layer, ultimately obtaining the prediction result at the output layer. The specific form of the diagnostic conclusion depends on the analysis task type. When the analysis task is a fault prediction task, the diagnostic conclusion may include the predicted fault type, the probability of occurrence for each fault type, and the predicted fault occurrence time window. When the analysis task is a diagnostic classification task, the diagnostic conclusion may include the diagnosed fault category, the confidence score corresponding to that fault category, and a description of possible fault causes. After completing the inference, the analysis model instance returns the diagnostic conclusions to the cloud server.

[0049] S10. Generate a diagnostic response based on the diagnostic conclusion and send the diagnostic response to the diagnostic terminal.

[0050] The cloud server generates a diagnostic response based on the diagnostic conclusions and sends it to the diagnostic terminal. The diagnostic response is readable information for the end user. The cloud server semantically processes the diagnostic conclusions output by the analysis model instance and supplements them with relevant maintenance suggestions and risk warnings to form a complete diagnostic response. The cloud server obtains the fault type and confidence level information from the diagnostic conclusions. Based on the fault type information, it matches the corresponding maintenance suggestions and risk level information in a pre-defined diagnostic knowledge base. The diagnostic knowledge base maintains the mapping relationship between fault types, maintenance plans, and risk levels. The cloud server generates a diagnostic response based on the fault type information, confidence level information, maintenance suggestions, and risk level information, and then sends the diagnostic response to the diagnostic terminal.

[0051] In one possible embodiment, the acquisition of the analysis task type includes: S21. Receive a diagnostic request sent by the diagnostic terminal, wherein the diagnostic request carries task instruction information.

[0052] The cloud server receives a diagnostic request from the diagnostic terminal, which carries task instruction information. The diagnostic request is a service call initiated by the diagnostic terminal to the cloud server after or during the collection of diagnostic log data packets, informing the cloud server of the specific requirements for this diagnostic analysis. The diagnostic request and the diagnostic log data packets can be encapsulated in the same communication message and sent together, or they can be sent separately and bound together by an association identifier. The task instruction information carried in the diagnostic request identifies the type of analysis task. This task instruction information can be automatically generated by the diagnostic terminal based on user operations, or it can be sent to the diagnostic terminal by the remote control platform and then forwarded to the cloud server by the diagnostic terminal. After receiving the diagnostic request, the cloud server associates it with the corresponding diagnostic log data packet and stores the diagnostic request in a request parsing queue for further processing.

[0053] For example, after a commercial vehicle completes a long-distance transport trip, it pulls into a service station. The mechanic selects the "Full Vehicle Fault Prediction" function on the diagnostic terminal. The terminal automatically generates a diagnostic request, which includes the task instruction information "Fault Prediction." The diagnostic terminal then uploads this request, along with previously collected diagnostic log data packets from various control units such as the engine, transmission, and braking system, to a cloud server. Upon receiving the data, the cloud server establishes a mapping between the request identifier and the data packet identifier.

[0054] S22. Parse the diagnostic request and extract the task instruction information.

[0055] The cloud server parses the diagnostic request and extracts task indication information. The specific parsing method depends on the encoding format of the diagnostic request. Diagnostic requests can use key-value pairs, JSON structures, or custom binary protocols, among other encoding methods. The cloud server decodes the diagnostic request according to a preset communication protocol specification, locating and extracting the task indication information from the decoded request fields. The task indication information can be an enumerated value, a string identifier, or a preset encoded number, used to uniquely identify the type of analysis task expected in this request. During the extraction process, the cloud server verifies the format validity of the task indication information. If the task indication information format is invalid or unrecognizable, it returns a format error message to the diagnostic terminal, requesting it to re-initiate the diagnostic request.

[0056] For example, the diagnostic request might be encoded as a key-value pair structure, containing a task type field with a value of "predict" or "classify". When parsing the request, the cloud server extracts the value "predict" from the task type field, confirms it belongs to the preset set of valid values, and uses it as the task indication information for this analysis. If the cloud server extracts "unknown" or other content not in the preset set of values ​​from the task type field, it determines the format is invalid, returns an error code and description to the diagnostic terminal, and prompts the user to reselect the diagnostic function.

[0057] S23. Based on the task instruction information, determine that the analysis task type is the fault prediction task or the diagnostic classification task.

[0058] The cloud server determines the analysis task type as either a fault prediction task or a diagnostic classification task based on the task indication information. The cloud server maintains an internal task type mapping table, which records the correspondence between each task indication and the analysis task type. The cloud server matches the task indication information extracted in step S22 against the task type mapping table. If a match is successful, the corresponding analysis task type is taken as the target type for this analysis task. If the task indication information explicitly points to fault prediction, the analysis task type is determined to be a fault prediction task; if the task indication information explicitly points to diagnostic classification, the analysis task type is determined to be a diagnostic classification task. In the case of missing or ambiguous task indication information, the cloud server can enable a default strategy, automatically determining the analysis task type based on whether the diagnostic log data packet contains triggered fault codes. If fault codes are present, the default is a diagnostic classification task; otherwise, the default is a fault prediction task.

[0059] For example, the task type mapping table records two mapping relationships: the task indication information "fault prediction" corresponds to the fault prediction task, and the task indication information "diagnosis classification" corresponds to the diagnosis classification task. The task indication information "fault prediction" extracted by the cloud server in step S22 matches successfully in the mapping table, thus determining the analysis task type as a fault prediction task. Subsequent steps S3 to S10 will then revolve around this fault prediction task. In another scenario, the diagnostic terminal does not explicitly carry task indication information in the diagnostic request. The cloud server detects fault code P0171 in the diagnostic log data packet, triggering the default policy and automatically determining the analysis task type as a diagnosis classification task.

[0060] In one possible embodiment, see Figure 3 , Figure 3 This is a schematic diagram of the process for determining the complexity of an analysis task provided in an embodiment of this application, specifically including the following steps: S61. Obtain the attribute information of the feature vector, including the feature dimension and the amount of data.

[0061] The cloud server acquires the attribute information of the feature vector, including feature dimension and data volume. Feature dimension refers to the number of features contained in the feature vector generated in step S4, and data volume refers to the total number of data sampling points participating in this analysis. After feature extraction is completed in step S4, the cloud server stores the feature vector and related metadata in memory. The cloud server can obtain the feature dimension and data volume by reading the metadata record of the feature vector. Feature dimension directly reflects the breadth of input information and the number of input neurons the model needs to process, while data volume reflects the length of the time series or the sample size involved in the analysis. Both together determine the computational complexity of the analysis task. The larger the feature dimension, the more multiply-accumulate operations the analysis model needs to perform in a single forward propagation; the larger the data volume, the longer the feature vector sequence. For fault prediction models based on recurrent neural network structures, the number of time step unfoldings also increases. Therefore, feature dimension and data volume are two core indicators for evaluating the computational complexity of the analysis task, and the cloud server uses these two indicators as the basic parameters for subsequent complexity calculations.

[0062] For example, in step S4, the cloud server extracts 32 features from standardized diagnostic data for a specific fault prediction task, including the mean engine speed, standard deviation of engine speed, mean coolant temperature, maximum coolant temperature, and fuel correction deviation, with a feature dimension of 32. Simultaneously, the data sampling points for this analysis are 500, meaning 500 consecutive sampling times are extracted from the diagnostic log, resulting in a data volume of 500. The cloud server reads the feature dimension of 32 and the data volume of 500 from the metadata of this feature vector and passes these two attribute information to steps S62 and S63.

[0063] S62. Based on the analysis task type, query the preset task complexity mapping table to obtain the baseline complexity coefficient corresponding to the analysis task type.

[0064] The cloud server queries a pre-defined task complexity mapping table based on the analysis task type to obtain the baseline complexity coefficient corresponding to that task type. The task complexity mapping table is a pre-built and stored table on the cloud server that records the mapping relationship between each analysis task type and its corresponding baseline complexity coefficient. The baseline complexity coefficient is a value greater than 0, used to characterize the relative computational resource requirements of different analysis task types under the same feature dimensions and data volume conditions. The baseline complexity coefficient is set based on the model structure complexity and inference computation volume corresponding to the analysis task type. For example, the model corresponding to fault prediction tasks is usually an LSTM-based recurrent neural network, whose inference process involves multiple time steps of loop unrolling and gating operations, resulting in a large computational load per inference step; therefore, fault prediction tasks are assigned a high baseline complexity coefficient. The model corresponding to diagnostic classification tasks is usually a gradient boosting tree model, whose inference process involves traversing multiple decision trees one by one and accumulating scores; the computational load per inference step is relatively small, therefore, diagnostic classification tasks are assigned a low baseline complexity coefficient.

[0065] In one embodiment, the task complexity mapping table contains two records: a baseline complexity coefficient of 1.5 for the fault prediction task and a baseline complexity coefficient of 1.0 for the diagnostic classification task. The cloud server, having determined the analysis task type to be a fault prediction task in step S2, retrieves the task complexity mapping table using the fault prediction task as the query key in step S62, matching a baseline complexity coefficient of 1.5. If the analysis task type is a diagnostic classification task, the matched baseline complexity coefficient is 1.0. The specific value of the baseline complexity coefficient can be adjusted based on the actual computational load test results of the model. After model training, the cloud server measures the inference time of each model on standard test data, using the inference time of the diagnostic classification model as the baseline unit of 1.0, and the ratio of the inference time of the fault prediction model to the baseline unit as the baseline complexity coefficient of the fault prediction task.

[0066] S63. Based on the feature dimension and data volume, combined with the baseline complexity coefficient, the complexity of the analysis task is calculated.

[0067] Analysis task complexity is a quantitative numerical metric used to comprehensively measure the computational resource requirements of the current analysis task.

[0068] In one possible embodiment, the complexity of the analysis task is calculated based on the feature dimension and the amount of data, combined with the baseline complexity coefficient, including: S631. Calculate the basic complexity value based on the feature dimension and the amount of data.

[0069] In step S631, the cloud server calculates the basic complexity value based on the feature dimension and data volume obtained in step S61. The basic complexity value quantifies the original computational scale of the analysis task at the data level, without considering differences caused by the type of analysis task and model structure. The cloud server denotes the feature dimension as 'd' and the data volume as 'n', calculating the basic complexity value B according to the formula B = d × n. Here, the feature dimension 'd' determines the number of features processed by the analysis model in a single operation, and the data volume 'n' determines the total number of data sampling points that need to be processed. Their product reflects the total computational load of the analysis task from the perspective of data scale. The physical meaning of this calculation method is that the product of the feature dimension 'd' and the data volume 'n', d × n, represents the total number of data units that the analysis model needs to process during a complete inference operation. For fault prediction tasks, the larger the feature dimension 'd', the higher the dimension of the input vector at each time step, and the greater the matrix multiplication operation within the LSTM layer. The larger the data volume 'n', the more steps the LSTM expands along the time dimension, resulting in a linear increase in the total computational load. For diagnostic classification tasks, gradient boosting tree models require feature traversal and decision path search for each data sampling point. The feature dimension d and the data volume n directly affect the total computational cost. Therefore, using ×d×n as the basic complexity value can objectively reflect the differences in computational cost under different data scales.

[0070] For example, in step S61, the feature dimension d is 32, the data volume n is 500, and the basic complexity B of the cloud server computation is 32 multiplied by 500, resulting in 16000. In another diagnostic classification task scenario, the feature dimension d is 24, the data volume n is 200, and the basic complexity B is 24 multiplied by 200, resulting in 4800. The former's basic complexity of 16000 is significantly higher than the latter's 4800, indicating that the former involves a larger data computation scale and requires more computing resources.

[0071] S632. Perform a weighted operation on the basic complexity value and the baseline complexity coefficient to obtain the intermediate complexity value.

[0072] The cloud server performs a weighted average of the base complexity value calculated in step S631 and the baseline complexity coefficient obtained in step S62 to obtain the intermediate complexity value. The purpose of this weighted average is to take into account the differences in computational complexity of models corresponding to different analysis task types, ensuring that the complexity value can distinguish the inference computation volume of different models under the same data scale. The cloud server denotes the base complexity value as B, the baseline complexity coefficient as α, and calculates the intermediate complexity value M according to the formula M = α × B.

[0073] The baseline complexity coefficient α is a weighting factor greater than 0, and its value is determined based on the computational load of the model corresponding to the analysis task type during the inference phase. The LSTM model for the fault prediction task requires multiple time-step iterations during inference, involving matrix multiplications and element-wise operations for forget gates, input gates, and output gates within each time step, resulting in high computational density; therefore, its baseline complexity coefficient α is set to 1.5. The gradient boosting tree model for the diagnostic classification task only requires traversing 200 decision trees and accumulating scores during inference, with each tree's decision path depth not exceeding 6 levels, resulting in relatively low computational load; therefore, its baseline complexity coefficient α is set to 1.0. Through weighted calculations, the intermediate complexity value M comprehensively reflects the computational resource requirements of both the data scale and the analysis task type.

[0074] For example, the basic complexity value B calculated in step S631 is 16000, and the baseline complexity coefficient α corresponding to the fault prediction task obtained in step S62 is 1.5. The cloud server calculates the intermediate complexity value M according to the formula M=α×B, which equals 1.5 multiplied by 16000, resulting in 24000. In another diagnostic classification task scenario, the basic complexity value B is 4800, the baseline complexity coefficient α is 1.0, and the intermediate complexity value M equals 1.0 multiplied by 4800, resulting in 4800. Through weighted calculation, although the ratio of the basic complexity values ​​of the two tasks is approximately 3.33 to 1, the ratio of the intermediate complexity values ​​expands to 5 to 1, more accurately reflecting the high computational cost characteristic of the LSTM model compared to the gradient boosting tree model in the inference stage.

[0075] S633. Based on the model parameter scale of the target analysis model, the intermediate complexity value is corrected to obtain the complexity of the analysis task.

[0076] The cloud server adjusts the intermediate complexity value based on the model parameter size of the target analysis model to obtain the final analysis task complexity. Model parameter size refers to the total number of learnable parameters in the target analysis model after training, usually measured by the number of parameters. Model parameter size directly affects the model's memory usage and computational overhead during the inference phase; a larger parameter size requires more memory and GPU memory during model loading, and also increases the data transfer and computational overhead during inference. After determining the target analysis model in step S5, the cloud server can obtain the model parameter size, denoted as P, from the model library, in millions of parameters.

[0077] The cloud server queries a pre-defined parameter size correction table based on the model parameter size P to obtain the correction coefficient β corresponding to the model parameter size. The parameter size correction table is a pre-built mapping table on the cloud server, recording the mapping relationship between different model parameter size ranges and correction coefficients. The correction coefficient β is a value greater than or equal to 1; the larger the model parameter size, the higher the correction coefficient β, reflecting the additional computational resource requirements of large models. In one embodiment, the parameter size correction table contains three records: a correction coefficient β of 1.0 for models with no more than 1 million parameters, a correction coefficient β of 1.2 for models with 1 million to 5 million parameters, and a correction coefficient β of 1.5 for models with more than 5 million parameters.

[0078] The cloud server denotes the intermediate complexity value as M and the correction factor as β, and calculates the final analysis task complexity C according to the formula C=M×β. The physical meaning of this formula is that the intermediate complexity value M already reflects the impact of data scale and model computation on resource requirements, while the correction factor β further incorporates the memory usage and data transfer overhead caused by the model parameter scale. This allows the final analysis task complexity C to comprehensively and accurately assess the overall computational resource requirements of the analysis task, providing a more refined quantitative basis for the selection of computing nodes in step S7.

[0079] For example, in step S632, the intermediate complexity value M is calculated to be 24000. The target analysis model is an LSTM fault prediction model with a parameter size P of 3.2 million parameters, falling within the range of 1 million to 5 million parameters, and the corresponding correction coefficient β is 1.2. The cloud server calculates the analysis task complexity C according to the formula C=M×β, which equals 24000 multiplied by 1.2, resulting in 28800. In another diagnostic classification task scenario, the intermediate complexity value M is 4800, the target analysis model is an XGBoost diagnostic classification model with a parameter size P of 0.5 million parameters, and the corresponding correction coefficient β is 1.0. The analysis task complexity C equals 4800 multiplied by 1.0, resulting in 4800.

[0080] By introducing model parameter size adjustment, this step effectively distinguishes the differentiated computational resource requirements of different versions of the same type of task. For example, there are two versions of a fault prediction model on the cloud server: the first version is a lightweight version with 0.8 million parameters and a correction factor of 1.0, while the second version is a standard version with 3.2 million parameters and a correction factor of 1.2. Under the same data size and baseline complexity coefficient, the standard version model has a 20% higher analysis task complexity than the lightweight version, and is therefore more likely to be allocated to a higher-configuration computing node in step S7, ensuring that the inference task can be completed efficiently.

[0081] In one possible embodiment, obtaining the corresponding target computing node from the computing resource pool based on the complexity of the analysis task includes: S71. Obtain the current load status of each hardware computing node in the computing resource pool. The current load status includes at least one of CPU utilization, memory usage, and GPU utilization.

[0082] The cloud server obtains the current load status of each hardware computing node in the computing resource pool. This current load status includes at least one of CPU utilization, memory usage, and GPU utilization. The computing resource pool is a collection of hardware computing nodes managed by the cloud server. Each hardware computing node has independent hardware resources such as CPU, memory, and GPU, and maintains a communication connection with the cloud server through an internal high-speed network. The cloud server maintains a computing node status table, which records the node identifier, hardware configuration information, and current load status of each hardware computing node. The current load status is periodically collected and reported to the cloud server by monitoring agents deployed on each hardware computing node. The collection period is set to 5 seconds to ensure the real-time and accuracy of the load status data.

[0083] CPU utilization, expressed as a percentage, reflects the current activity level of the CPU cores on the hardware computing node; it is the arithmetic mean of the utilization rates of all CPU cores. Memory utilization, expressed as a percentage, reflects the proportion of physical memory used on the hardware computing node relative to the total physical memory. GPU utilization, expressed as a percentage, reflects the current activity level of the GPU computing cores on the hardware computing node; in the case of multiple GPUs, it is the arithmetic mean of the utilization rates of each GPU. When the analysis task is a fault prediction task, the fault prediction model involves a large number of matrix multiplications and parallel operations during the inference phase, which places high demands on GPU resources; therefore, GPU utilization is an important indicator for assessing the node's load status. When the analysis task is a diagnostic classification task, the diagnostic classification model is based on gradient boosting trees, and its inference process is mainly based on CPU serial computation. In this case, GPU utilization is not a necessary indicator; only CPU utilization and memory utilization need to be considered.

[0084] For example, in a computing resource pool containing 5 hardware computing nodes, nodes A through E have different hardware configurations. Node A is configured with an 8-core CPU, 32GB of memory, and 1 GPU; node B is configured with a 16-core CPU, 64GB of memory, and 2 GPUs; node C is configured with a 4-core CPU, 16GB of memory, and no GPU; node D is configured with a 32-core CPU, 128GB of memory, and 4 GPUs; and node E is configured with an 8-core CPU, 32GB of memory, and 1 GPU. At a certain moment, the monitoring agents deployed on each node report their current load status: node A has a CPU utilization of 35%, memory utilization of 42%, and GPU utilization of 28%; node B has a CPU utilization of 78%, memory utilization of 65%, and GPU utilization of 92%; node C has a CPU utilization of 12% and memory utilization of 30%; node D has a CPU utilization of 55%, memory utilization of 70%, and GPU utilization of 45%; and node E has a CPU utilization of 90%, memory utilization of 88%, and GPU utilization of 85%. The cloud server updates the above load status data to the compute node status table for use in subsequent step S73 for filtering.

[0085] S72. Based on the complexity of the analysis task, determine the minimum resource configuration requirements required to execute the analysis task.

[0086] The cloud server determines the minimum resource configuration requirements for executing the analysis task based on its complexity. These minimum resource configuration requirements refer to the minimum hardware resources required by the computing nodes to ensure the analysis task can be completed within a preset time threshold. These requirements include at least one of the following: minimum number of CPU cores, minimum memory capacity, and minimum GPU memory capacity. The cloud server has pre-defined resource requirement mapping rules that define the correspondence between the analysis task complexity and the minimum resource configuration requirements. These rules can be represented as a resource requirement mapping table or a piecewise function.

[0087] The resource requirement mapping table is constructed as follows: during the offline phase, the cloud server uses hardware computing nodes with different resource configurations as the test environment to benchmark the inference time of various analysis tasks under different complexity conditions. The minimum resource configuration required to meet a preset time threshold is recorded, forming a mapping relationship between the complexity of the analysis task and the minimum resource configuration requirements. The preset time threshold is set according to the real-time requirements of the business scenario. For example, for online diagnostic scenarios, the preset time threshold is set to 3 seconds, meaning the analysis task must complete inference and return results within 3 seconds. For batch analysis scenarios, the preset time threshold can be appropriately relaxed to 30 seconds. By querying this resource requirement mapping table, the cloud server can quickly determine the required minimum resource configuration based on the complexity of the current analysis task.

[0088] In one embodiment, the resource requirement mapping table divides the complexity of the analysis task into multiple intervals, each interval corresponding to a set of minimum resource configuration requirements. For tasks with a complexity between 0 and 5000, the minimum resource configuration requirements are: at least 2 CPU cores, at least 4GB of memory, and no GPU required. For tasks with a complexity between 5000 and 20000, the minimum resource configuration requirements are: at least 4 CPU cores, at least 8GB of memory, and at least 2GB of GPU memory. For tasks with a complexity between 20000 and 50000, the minimum resource configuration requirements are: at least 8 CPU cores, at least 16GB of memory, and at least 4GB of GPU memory. For tasks with a complexity exceeding 50000, the minimum resource configuration requirements are: at least 16 CPU cores, at least 32GB of memory, and at least 8GB of GPU memory.

[0089] S73. Based on the current load status and the minimum resource configuration requirements, select hardware computing nodes that meet the selection criteria from the computing resource pool as the target computing nodes.

[0090] The cloud server selects hardware computing nodes that meet the selection criteria from the computing resource pool as target computing nodes based on the current load status and minimum resource configuration requirements. The selection criteria include two levels: hardware configuration conditions and load status conditions. Hardware configuration conditions refer to the basic hardware configuration of the node needing to meet the minimum resource configuration requirements determined in step S72. Load status conditions refer to the fact that after deducting the resources expected to be consumed by this analysis task, the remaining resources of the node are still sufficient to maintain the normal operation of existing tasks on the node, avoiding quality degradation or interruption of existing tasks due to resource overload.

[0091] In one possible embodiment, the step of selecting hardware computing nodes that meet the selection criteria from the computing resource pool as the target computing nodes based on the current load status and the minimum resource configuration requirements includes: S731. Compare the current load status of each hardware computing node with a preset load threshold, and remove hardware computing nodes whose load status exceeds the load threshold to obtain a candidate node set.

[0092] The cloud server compares the current load status of each hardware computing node with preset load thresholds, eliminating those exceeding the thresholds to obtain a candidate node set. The preset load thresholds are upper limits set by the cloud server based on the hardware computing node's design specifications and historical operating experience, used to determine whether a hardware computing node is at risk of overload. The load thresholds include CPU utilization thresholds, memory usage thresholds, and GPU utilization thresholds. Each threshold is set separately and judged independently. If any one of these indicators exceeds its corresponding load threshold, the hardware computing node is determined to be overloaded and eliminated.

[0093] In one embodiment, the CPU utilization threshold is set to 85%, the memory utilization threshold to 90%, and the GPU utilization threshold to 90%. These thresholds comprehensively consider the performance margin and operational stability of the hardware computing nodes, leaving a certain margin to cope with sudden load fluctuations. When the CPU utilization exceeds 85%, the node's CPU scheduling latency will increase significantly, which may lead to longer response times for ongoing tasks and affect user experience. When the memory utilization exceeds 90%, the node's available memory space is minimal, and the operating system may trigger memory reclamation or swapping operations, resulting in a significant drop in system performance. When the GPU utilization exceeds 90%, GPU computing resources tend to be saturated, and newly submitted tasks will face queuing and waiting, extending the total execution time of tasks. Therefore, using these thresholds as criteria for removing overloaded nodes can effectively avoid assigning analysis tasks to nodes whose performance is already close to their bottleneck, ensuring the quality and efficiency of task execution.

[0094] Specifically, the cloud server reads the current load status data of each hardware computing node from the computing node status table obtained in step S71, and compares the CPU utilization, memory usage, and GPU utilization of each node with the corresponding load thresholds. For the analysis task type being fault prediction, since this task has a high dependence on GPU resources, the GPU utilization threshold is a mandatory check; if the current GPU utilization exceeds 90%, the node is directly removed. For the analysis task type being diagnostic classification, this task does not rely primarily on GPUs for computing resources, so GPU utilization is not used as a removal criterion; only CPU utilization and memory usage are used as the basis for judgment. If the current CPU utilization exceeds 85% or the memory usage exceeds 90%, the node is removed.

[0095] S732. Match the available resources of each hardware computing node in the candidate node set with the minimum resource configuration requirements, and filter out the hardware computing nodes whose available resources meet the minimum resource configuration requirements to obtain the available node set.

[0096] The cloud server matches the available resources of each hardware computing node in the candidate node set with the minimum resource configuration requirements, filtering out hardware computing nodes whose available resources meet the minimum resource configuration requirements, thus obtaining the available node set. Available resources refer to the amount of resources a hardware computing node actually has available for new tasks under its current load state, after deducting resources already occupied. This remaining resource amount reflects the node's capacity to handle new tasks. The minimum resource configuration requirements are the minimum hardware resource conditions required to execute the task, determined in step S72 based on the analysis of task complexity, including the minimum number of CPU cores, minimum memory capacity, and minimum GPU memory capacity.

[0097] The cloud server calculates the available resources for each candidate node in the candidate node set and matches these resources against the minimum resource configuration requirements. Available resources are calculated as follows: Available CPU cores equal the total number of CPU cores on the hardware computing node minus the number of CPU cores currently in use, where the number of CPU cores currently in use can be estimated by multiplying CPU utilization by the total number of CPU cores. Available memory capacity equals the total memory capacity of the hardware computing node minus the amount of memory currently used, where the amount of memory currently used can be calculated by multiplying memory utilization by the total memory capacity. Available GPU memory capacity equals the total GPU memory capacity of the hardware computing node minus the amount of GPU memory currently used, where the amount of GPU memory currently used can be estimated by multiplying GPU utilization by the total GPU memory capacity. If a hardware computing node does not have a GPU, its available GPU memory capacity is zero.

[0098] The matching rules are as follows: the number of available CPU cores of a candidate node must be greater than or equal to the minimum CPU core requirement, the available memory capacity must be greater than or equal to the minimum memory capacity requirement, and the available GPU memory capacity must be greater than or equal to the minimum GPU memory capacity requirement. For analysis tasks of diagnostic classification type where GPU requirements are not included in the minimum resource configuration requirements, the GPU memory capacity matching item can be skipped. If a candidate node's available resources do not meet the minimum resource configuration requirements in any of these aspects, the candidate node is not capable of undertaking this analysis task and will be excluded.

[0099] S733. Select a hardware computing node from the available node set as the target computing node.

[0100] The cloud server selects a hardware computing node from the available node set as the target computing node. The selection strategy employs different processing methods depending on the number of nodes in the available node set.

[0101] When the available node set contains only one hardware computing node, the cloud server directly identifies that single hardware computing node as the target computing node. In the example of step S732, the available node set contains only node D, and the cloud server directly identifies node D as the target computing node.

[0102] When the available node set contains multiple hardware computing nodes, the cloud server selects the node with the best overall evaluation from among these available nodes as the target computing node. The overall evaluation can employ a weighted scoring method, quantifying and scoring multiple indicators such as the remaining resources, load balancing, and network latency of each available node, and selecting the node with the highest overall score. In one optimal strategy, the cloud server prioritizes load balancing, selecting the available node with the lightest current load as the target computing node to achieve a balanced load distribution among nodes in the computing resource pool, avoiding an imbalance where some nodes are idle while others are overloaded. The criterion for determining the lightest load is a weighted average of the CPU utilization, memory usage, and GPU utilization of each available node; the node with the lowest weighted average is considered the lightest load node.

[0103] In another preferred strategy, the cloud server can also consider network latency, selecting the available node with the lowest network latency between itself and the diagnostic terminal that initiated the diagnostic request as the target computing node. Network latency data can be obtained by the cloud server periodically probing and recording the network latency between each hardware computing node and each diagnostic terminal. Selecting the node with the lowest network latency can shorten the end-to-end response time of diagnostic requests and improve user experience. If there is a conflict between the load balancing strategy and the network latency priority strategy, the cloud server can make a comprehensive decision based on preset strategy priority weights.

[0104] After identifying the target computing node, the cloud server records its node identifier, IP address, port number, and other information in the task scheduling table, associating it with the task identifier of this analysis task. Simultaneously, the cloud server pre-allocates the available resources of the target computing node in the computing node status table, temporarily deducting the estimated resource consumption of this analysis task from the node's available resources. This prevents the node from being repeatedly allocated resources by other concurrent analysis tasks within a short time window after the task is completed, thus preventing resource overload. The pre-allocation mark is valid for the task timeout period. If the task is successfully delivered to the target computing node and begins execution within the validity period, the pre-allocation mark is converted to full occupancy. If the task fails to deliver or times out within the validity period, the pre-allocation mark is automatically released, and the node's available resources return to their pre-allocation level, ensuring resource consistency.

[0105] In one possible embodiment, loading the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance includes: S81. Send a model deployment request to the target computing node, wherein the model deployment request carries the model identifier of the target analysis model.

[0106] S82. The model parameter file corresponding to the target analysis model is transmitted to the target computing node. The model parameter file includes a model structure description file and a model weight file.

[0107] S83. Control the target computing node to complete the model loading and initialization based on the model parameter file, so that the target computing node runs the target analysis model and obtains the analysis model instance.

[0108] In step S81, the cloud server sends a model deployment request to the target computing node. This model deployment request is a remote procedure call between the cloud server and the target computing node, used to notify the target computing node to prepare to receive and load the specified target analysis model. The model deployment request carries the model identifier of the target analysis model. The model identifier is a unique identifier assigned to the target analysis model by the cloud server during the model management phase, used to uniquely identify the target analysis model in the cloud server's model library. The model identifier can be in the form of a universally unique identifier or a combination of the model name and version number.

[0109] After determining the target computing node in step S73, the cloud server retrieves the node identifier, IP address, and port number of the target computing node from the task scheduling table, and establishes a communication session with the target computing node based on this network connection information. The communication session uses a secure transmission protocol, and the cloud server sends a model deployment request to the target computing node through this communication session. The data structure of the model deployment request includes a request type field, a model identifier field, a task identifier field, and a timestamp field. The request type field identifies this request as a model deployment request; the model identifier field carries the model identifier of the target analysis model; the task identifier field carries the task identifier of this analysis task; and the timestamp field records the request initiation time for subsequent timeout judgment and log tracking.

[0110] Upon receiving a model deployment request, the target compute node parses the model identifier in the request data and checks if it has already cached the corresponding model parameter file locally. The target compute node maintains a local model cache table, which records the model identifiers and cache times of cached models. If the target compute node finds the model identifier in its local model cache table, and the cached model parameter file matches the current version in the cloud server's model library, the target compute node returns a "Model is cached" response to the cloud server, informing the cloud server that the model parameter file does not need to be retransmitted. If the target compute node does not find the model identifier in its local model cache table, or the cached model parameter file version has expired, the target compute node returns a "Model is not cached" response to the cloud server, requesting the cloud server to transmit the model parameter file. This caching mechanism effectively reduces the repeated transmission of model parameter files, lowers network bandwidth usage, and shortens the overall model deployment time.

[0111] In step S82, the cloud server transmits the model parameter file corresponding to the target analysis model to the target computing node. The model parameter file is the complete model description data saved after the target analysis model has completed training and optimization, comprising two parts: a model structure description file and a model weight file. The model structure description file defines the network topology of the target analysis model, including information such as the layer type, number of layers, input / output dimensions of each layer, activation function type, and connection relationships. The model structure description file can be serialized and stored in JSON or Protobuf format. The model weight file stores the weight and bias parameters obtained after training each layer of the target analysis model. These parameters are organized layer by layer in floating-point form, and the model weight file is stored in binary format to ensure parameter accuracy and storage efficiency. The model structure description file and the model weight file together constitute the complete expression of the target analysis model. After obtaining these two files, the target computing node can completely reconstruct the target analysis model.

[0112] After receiving a "model not cached" response from the target compute node, the cloud server retrieves the model parameter file corresponding to the model identifier from the model library. The model library is a centralized storage system on the cloud server that stores all trained model parameter files. Each model parameter file in the library is organized and indexed according to its model identifier. Once the cloud server obtains the model parameter file, it transmits it in chunks to the target compute node through an established communication session. The chunked transmission method involves the cloud server dividing the model parameter file into multiple data blocks according to a preset block size, attaching a block number and checksum to each data block, and sending them to the target compute node one block at a time. Each time the target compute node receives a data block, it verifies its integrity. If it confirms that the block is intact, it returns an acknowledgment to the cloud server. Upon receiving the acknowledgment, the cloud server continues sending the next data block until all data blocks of the model parameter file have been transmitted. This chunked transmission mechanism can adapt to the instability of the network environment. When the transmission of a data block fails, the cloud server only needs to retransmit the failed data block, rather than retransmitting the entire model parameter file, thus improving transmission efficiency.

[0113] After receiving the complete model parameter file, the target compute node stores the model structure description file and model weight file in its local model cache directory. It also adds a cache record with the model identifier to the local model cache table, recording the cache time and file storage path. This ensures that subsequent deployment requests for the same model can directly access the local cache, reducing redundant transmissions. Simultaneously, the target compute node sends a model transmission completion response to the cloud server, notifying it that the model parameter file is ready and the model loading and initialization phase can begin.

[0114] In step S83, the cloud server controls the target computing node to complete model loading and initialization based on the model parameter file. Model loading refers to the process by which the target computing node reads the model structure description file and model weight file from the model parameter file and constructs the runtime data structure of the target analysis model in memory. Model initialization refers to the initial state setting of the constructed model runtime data structure by the target computing node, including allocating computing devices to the model, setting the inference mode, and initializing internal state variables. After the model loading and initialization are completed, the target analysis model running on the target computing node becomes an analysis model instance, which has the ability to receive input data and perform inference calculations.

[0115] After receiving the model transfer completion response from the target computing node, the cloud server sends a model loading instruction to the target computing node. This instruction carries the storage path of the model parameter file and the computing device specification information. The computing device specification information indicates which computing device the target computing node should load and run the target analysis model on. For fault prediction tasks, since LSTM models involve numerous matrix operations, a GPU is typically specified as the computing device; for diagnostic classification tasks, a CPU is typically specified. Upon receiving the model loading instruction, the target computing node first parses the model structure description file. Based on the layer types, number of layers, and connection relationships defined in the model structure description file, it constructs the model's network topology in memory. The construction process proceeds sequentially according to the layer order defined in the model structure description file. For each layer, a corresponding runtime object is created based on its layer type, the input / output dimensions and activation function type are set, and it is associated with the preceding and following layers according to the connection relationships.

[0116] After constructing the network topology, the target compute node parses the model weight file and loads the weight and bias parameters from the file into the corresponding runtime objects one by one, layer by layer. The loading of weight parameters must ensure that the data type and dimensions are consistent with the definitions in the model structure description file. If a dimension mismatch is found, the target compute node returns a model loading failure response to the cloud server along with error information. After the weight parameters are loaded, the target compute node migrates the entire model to the designated computing device, copying the model parameters and runtime data structures from host memory to GPU memory or keeping them in CPU memory. Subsequently, the target compute node sets the model's inference mode, disabling the Dropout and Batch Normalization layers specific to the training mode, ensuring deterministic output during inference. Finally, the target compute node initializes the model's internal state variables; for LSTM models, the hidden state vector and cell state vector are initialized to zero, completing model initialization.

[0117] After the target computing node completes all model loading and initialization, it returns a model loading completion response to the cloud server, informing the cloud server that the analysis model instance is ready to receive the analysis task. The cloud server marks the analysis model instance as ready and associates it with the current analysis task, preparing to input standardized diagnostic data into the analysis model instance for inference execution in step S9.

[0118] In one possible embodiment, generating a diagnostic response based on the diagnostic conclusion and sending the diagnostic response to the diagnostic terminal includes: S101. Obtain the fault type information and confidence level information from the diagnostic conclusion.

[0119] In step S101, the cloud server obtains the fault type information and confidence level information from the diagnostic conclusion. The diagnostic conclusion is the result data output by the analysis model instance after performing inference calculations on the standardized diagnostic data in step S9. This result data is sent to the cloud server by the target computing node after completing the inference. The diagnostic conclusion is organized in a structured data format, which includes fields such as fault type information, confidence level information, analysis timestamp, and analysis model identifier. The fault type information indicates the specific fault category identified in this diagnosis and can be a set of one or more fault types. The confidence level information indicates the degree of confidence of the analysis model in the fault type judgment result, expressed as a percentage, with a value range of 0% to 100%. When the diagnostic conclusion contains multiple fault types, each fault type corresponds to an independent confidence level value.

[0120] After receiving the diagnostic conclusion returned by the target computing node, the cloud server first verifies the data format of the diagnostic conclusion, confirming that the fault type field and confidence level field exist and that the data type conforms to the specifications. The value of the fault type field comes from a preset fault type coding table, which defines all fault types supported by the system and their corresponding coding values. For example, in the fault type coding table, code 001 represents engine misfire fault, code 002 represents oxygen sensor fault, code 003 represents catalytic converter fault, code 004 represents fuel system fault, and code 005 represents ignition system fault. The confidence level field must be a value between 0 and 100; if it exceeds this range, it is considered abnormal data, triggering the exception handling process. After the cloud server verifies the diagnostic conclusion, it extracts the coding value of the fault type field and converts it into a readable fault type name according to the fault type coding table. At the same time, it extracts the value of the confidence level field, which serves as input data for the subsequent repair suggestion matching in step S102 and the diagnostic response generation in step S103.

[0121] For example, in step S9, the target computing node runs an analysis model instance to infer the standardized diagnostic data, obtaining a diagnostic conclusion of fault type code 001 and confidence level of 93.5%. After receiving this diagnostic conclusion, the cloud server verifies the data format, confirming that the fault type field is 001, which is a valid code value defined in the fault type coding table, and the confidence level field is 93.5%, falling within the valid range of 0% to 100%, thus passing the verification. The cloud server converts code 001 into the fault type name "engine misfire fault" according to the fault type coding table, extracts the confidence level value of 93.5%, and completes the acquisition of fault type information and confidence level information. In another example, the diagnostic conclusion contains two fault types: code 001 with a confidence level of 78.2% and code 003 with a confidence level of 65.8%. The cloud server extracts the correspondence between the two fault types and their confidence levels, forming a complete set of fault type information and confidence level information.

[0122] S102. Based on the fault type information, match the corresponding maintenance suggestion information and risk level information in the preset diagnostic knowledge base.

[0123] In step S102, the cloud server matches the corresponding maintenance suggestion information and risk level information in the preset diagnostic knowledge base based on the fault type information. The preset diagnostic knowledge base is a structured knowledge storage system maintained on the cloud server, storing the mapping relationship between fault types, maintenance suggestions, and risk levels. The content of the diagnostic knowledge base is organized and entered by domain experts during the system construction phase and supports continuous updates and expansion based on accumulated maintenance experience during system operation. Each knowledge record in the diagnostic knowledge base includes fields such as fault type code, fault type name, maintenance suggestion list, risk level, and estimated maintenance time. The maintenance suggestion list contains one or more maintenance suggestions, each detailing the detection steps, maintenance operations, and precautions for that fault type. The risk level indicates the degree of impact of the fault type on equipment operational safety, and risk levels are divided into low risk, medium risk, and high risk. Low risk indicates that the fault does not affect the normal operation of the equipment and can be handled within the planned maintenance cycle; medium risk indicates that the fault may cause a decline in equipment performance and it is recommended to repair it as soon as possible in the short term; high risk indicates that the fault poses a safety hazard and may trigger a chain of faults or safety accidents, and the machine must be shut down for inspection and repair immediately.

[0124] The cloud server uses the fault type information obtained in step S101 as a query condition to perform an exact match query in the diagnostic knowledge base. If the fault type information contains multiple fault types, the cloud server matches each fault type separately to obtain the corresponding maintenance suggestion information and risk level information. When multiple fault types correspond to different risk levels, the cloud server takes the highest risk level as the comprehensive risk level for this diagnosis to reflect full attention to safety risks. After matching is completed, the cloud server associates and integrates the fault type information and confidence information obtained in step S101 with the maintenance suggestion information and risk level information obtained in step S102 to form a complete diagnostic result data set, which serves as the material for generating the diagnostic response in step S103.

[0125] For example, in step S101, the fault type information is engine misfire, corresponding to fault type code 001. The cloud server matches the code 001 in the diagnostic knowledge base and retrieves the corresponding knowledge record. This knowledge record contains three repair suggestions: the first is to check for carbon buildup or electrode erosion on the spark plugs and replace them if necessary; the second is to check if the resistance values ​​of the primary and secondary coils of the ignition coil are within the specified range, and replace the ignition coil if they are outside the range; the third is to check for blockages or leaks in the fuel injectors and clean or replace them. The risk level is high because engine misfire may cause unburned fuel to enter the exhaust system, damaging the catalytic converter and potentially causing power interruption while driving, posing a safety hazard. The estimated repair time is 2 hours. The cloud server integrates the engine misfire fault, the 93.5% confidence level, the three repair suggestions, the high risk level, and the estimated repair time of 2 hours to form a complete diagnostic result data set.

[0126] In an example where the fault type information includes multiple fault types, code 001 (engine misfire) corresponds to a high-risk level, while code 003 (catalytic converter fault) corresponds to a medium-risk level. The cloud server takes the highest risk level, i.e., high risk, as the overall risk level for this diagnosis and records this overall risk level in the diagnostic results dataset. At the same time, it retains the individual risk level for each fault type so that maintenance personnel can understand the independent risk status of each fault.

[0127] S103. Based on the fault type information, the confidence level information, the maintenance suggestion information, and the risk level information, generate the diagnostic response and send the diagnostic response to the diagnostic terminal.

[0128] In step S103, the cloud server generates a diagnostic response based on fault type information, confidence level information, maintenance suggestion information, and risk level information, and sends the diagnostic response to the diagnostic terminal. The diagnostic response is the final diagnostic result notification returned by the cloud server to the diagnostic terminal. Its content integrates diagnostic conclusions and maintenance guidance information, enabling users of the diagnostic terminal to intuitively understand the diagnostic results and take corresponding maintenance measures. The data structure of the diagnostic response includes two parts: diagnostic response header information and diagnostic response body information. The diagnostic response header information includes metadata fields such as diagnostic task identifier, diagnostic timestamp, diagnostic terminal identifier, and response type. The diagnostic response body information includes diagnostic result fields such as fault type information, confidence level information, maintenance suggestion information, risk level information, and estimated maintenance time.

[0129] The cloud server determines the formatted template for the diagnostic response based on the risk level information. There is a pre-defined correspondence between risk levels and formatted templates: low risk corresponds to a standard notification template, medium risk to a warning notification template, and high risk to an emergency notification template. Different templates are visually distinguishable; for example, a standard notification template uses blue, a warning notification template uses orange, and an emergency notification template uses red, allowing users to intuitively perceive the urgency of the fault. The cloud server fills the fault type information, confidence level information, repair suggestion information, and risk level information into the corresponding formatted template to generate a complete diagnostic response. Regarding the presentation of confidence level information, when the value is greater than or equal to 90%, the template includes the text "High confidence level of diagnostic result"; when the confidence level is between 70% and 90%, the template includes the text "Medium confidence level of diagnostic result, it is recommended to combine with other testing methods for confirmation"; and when the confidence level is less than 70%, the template includes the text "Low confidence level of diagnostic result, it is recommended to conduct further testing".

[0130] After generating a diagnostic response, the cloud server retrieves the current network connection information of the diagnostic terminal, including its IP address and port number, from the terminal management table based on the diagnostic terminal identifier recorded in the diagnostic task. The cloud server then sends the diagnostic response to the diagnostic terminal via an existing or newly established communication session. Upon receiving the response, the diagnostic terminal parses the fields in the response body and presents them to the user in a structured format on its display interface. Simultaneously, it triggers corresponding audio-visual prompts based on the risk level: an emergency alarm sound and screen flashing in high-risk situations, a warning sound in medium-risk situations, and only a normal alarm sound in low-risk situations.

[0131] For example, in step S102, the diagnostic result dataset includes a fault type of engine misfire, a confidence level of 93.5%, three specific repair recommendations, a high-risk level, and an estimated repair time of two hours. The cloud server selects an emergency notification template based on the high-risk level, which is marked in red. The cloud server fills in the fault type "engine misfire" in the template's fault type display area, the confidence level "93.5%" in the template's confidence level display area, and adds the description "high confidence level of diagnostic results." It also fills in the three repair recommendations by number in the template's repair recommendation display area, the risk level "high-risk" in the template's risk level display area, and the estimated repair time "2 hours" in the template's estimated time display area. After completion, a complete diagnostic response is generated. The diagnostic task identifier in the response header is TASK-20260703-0015, the diagnostic timestamp is July 3, 2026, 15:30:25, the diagnostic terminal identifier is TERMINAL-09, and the response type is diagnostic result notification. The cloud server queries the terminal management table for the IP address of diagnostic terminal TERMINAL-09, which is 192.168.20.109, and the port number is 5050. It then sends the diagnostic response to the diagnostic terminal through the established communication session. Upon receiving the diagnostic response, the diagnostic terminal displays the engine misfire fault diagnosis result in red on the display interface, showing a confidence level of 93.5% with a high confidence note. It lists three repair suggestions, marks them as high risk, and triggers an emergency alarm sound and screen flashing to remind the user to pay immediate attention and take repair measures.

[0132] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0133] Please see Figure 4 This illustration shows a schematic diagram of a diagnostic log processing apparatus provided in an exemplary embodiment of this application, hereinafter referred to as apparatus 4. Apparatus 4 can be implemented as all or part of a cloud server through software, hardware, or a combination of both. Apparatus 4 includes: The transceiver module 401 is used to receive diagnostic log data packets sent by the diagnostic terminal and obtain the analysis task type; the diagnostic log data packets are collected by the diagnostic terminal on the vehicle; the analysis task type is a fault prediction task or a diagnostic classification task. The generation module 402 is used to preprocess the diagnostic log data packet to obtain standardized diagnostic data, and extract features from the standardized diagnostic data to generate a feature vector; The acquisition module 403 is used to acquire the corresponding target analysis model from a plurality of pre-trained analysis models according to the analysis task type; the plurality of analysis models include a fault prediction model and a diagnostic classification model, wherein the fault prediction model corresponds to the fault prediction task and the diagnostic classification model corresponds to the diagnostic classification task. The determination module 404 is used to determine the complexity of the analysis task based on the feature vector and the analysis task type, and to obtain the corresponding target computing node in the computing resource pool based on the complexity of the analysis task. The computing resource pool includes multiple hardware computing nodes. The output module 405 is used to load the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance, and input the feature vector into the analysis model instance, and output the diagnostic conclusion from the analysis model instance. The transceiver module 401 is further configured to generate a diagnostic response based on the diagnostic conclusion and send the diagnostic response to the diagnostic terminal.

[0134] For further details regarding the implementation of the above technical solutions by each module in the diagnostic log processing device, please refer to the description of a diagnostic log processing method provided in the above-described embodiments of the invention, which will not be repeated here.

[0135] It should be noted that the device 4 provided in the above embodiments, when executing a diagnostic log processing method, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. In addition, the diagnostic log processing device and the diagnostic log processing method embodiment provided in the above embodiments belong to the same concept, and the implementation process is detailed in the method embodiment, which will not be repeated here.

[0136] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0137] See Figure 5 The diagram shown is a schematic of a computer storage medium provided in an embodiment of this application. The computer storage medium can store multiple instructions (i.e., ... Figure 5 The computer program shown above), the instructions are adapted to be loaded and executed as described above. Figure 2 The method steps of the illustrated embodiment can be found in the following documentation for detailed execution. Figure 2 The specific details of the illustrated embodiments will not be elaborated here.

[0138] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by a processor to implement a diagnostic log processing method as described in the above embodiments.

[0139] Please see Figure 6 This document provides a schematic diagram of the structure of a cloud server as an embodiment of this application. Figure 6 As shown, the cloud server 600 may include: at least one 601, at least one network interface 604, a user interface 603, a memory 605, and at least one communication bus 602.

[0140] The communication bus 602 is used to enable communication between these components.

[0141] The user interface 603 may include input units such as a mouse and keyboard.

[0142] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0143] 601 may include one or more processing cores. 601 connects to various parts of the cloud server 600 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 605, and by calling data stored in memory 605. Optionally, 601 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). 601 may integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into 601 and may be implemented as a separate chip.

[0144] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and application programs.

[0145] exist Figure 6 In the cloud server 600 shown, the user interface 603 is mainly used to provide an input interface for the user and obtain the user's input data; while 601 can be used to call the application stored in the memory 605 and specifically execute, such as Figure 2 The method shown can be referred to for details. Figure 2 As shown, it will not be elaborated further here.

[0146] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0147] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for processing diagnostic logs, characterized in that, Includes the following steps: ‌ The diagnostic log data packet sent by the diagnostic terminal is received, and the analysis task type is obtained; the diagnostic log data packet is collected by the diagnostic terminal on the vehicle; the analysis task type is either a fault prediction task or a diagnostic classification task. The diagnostic log data packet is preprocessed to obtain standardized diagnostic data, and features are extracted from the standardized diagnostic data to generate a feature vector. According to the analysis task type, a corresponding target analysis model is obtained from multiple pre-trained analysis models; the multiple analysis models include a fault prediction model and a diagnostic classification model, wherein the fault prediction model corresponds to the fault prediction task and the diagnostic classification model corresponds to the diagnostic classification task. Based on the feature vector and the analysis task type, the complexity of the analysis task is determined, and the corresponding target computing node is obtained from the computing resource pool according to the complexity of the analysis task. The computing resource pool includes multiple hardware computing nodes. The model parameters of the target analysis model are loaded onto the target computing node to obtain an analysis model instance, and the feature vector is input into the analysis model instance, from which the analysis model instance outputs a diagnostic conclusion; A diagnostic response is generated based on the diagnostic conclusion, and the diagnostic response is sent to the diagnostic terminal.

2. The method according to claim 1, characterized in that, The types of acquisition and analysis tasks include: Receive a diagnostic request sent by a diagnostic terminal, the diagnostic request carrying task instruction information; The diagnostic request is parsed to extract the task instruction information; Based on the task instruction information, the analysis task type is determined to be either the fault prediction task or the diagnostic classification task.

3. The method according to claim 1, characterized in that, The step of determining the complexity of the analysis task based on the feature vector and the analysis task type includes: Obtain the attribute information of the feature vector, the attribute information including feature dimension and data volume; Based on the analysis task type, query the preset task complexity mapping table to obtain the baseline complexity coefficient corresponding to the analysis task type; The complexity of the analysis task is calculated based on the feature dimension and the amount of data, combined with the baseline complexity coefficient.

4. The method according to claim 3, characterized in that, The complexity of the analysis task is calculated based on the feature dimension and the data volume, combined with the baseline complexity coefficient, including: The basic complexity value is calculated based on the feature dimension and the amount of data. The intermediate complexity value is obtained by weighting the basic complexity value with the baseline complexity coefficient. Based on the model parameter scale of the target analysis model, the intermediate complexity value is corrected to obtain the complexity of the analysis task.

5. The method according to claim 1, characterized in that, The step of obtaining the corresponding target computing node from the computing resource pool based on the complexity of the analysis task includes: Obtain the current load status of each hardware computing node in the computing resource pool, wherein the current load status includes at least one of CPU utilization, memory usage and GPU utilization; Based on the complexity of the analysis task, determine the minimum resource configuration requirements required to execute the analysis task; Based on the current load status and the minimum resource configuration requirements, hardware computing nodes that meet the selection criteria are selected from the computing resource pool as the target computing nodes.

6. The method according to claim 5, characterized in that, The step of selecting hardware computing nodes that meet the selection criteria from the computing resource pool as the target computing nodes based on the current load status and the minimum resource configuration requirements includes: The current load status of each hardware computing node is compared with a preset load threshold, and hardware computing nodes whose load status exceeds the load threshold are eliminated to obtain a candidate node set. The available resources of each hardware computing node in the candidate node set are matched with the minimum resource configuration requirements, and hardware computing nodes whose available resources meet the minimum resource configuration requirements are selected to obtain the available node set. Select a hardware computing node from the set of available nodes as the target computing node.

7. The method according to claim 1, characterized in that, The step of loading the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance includes: A model deployment request is sent to the target computing node, the model deployment request carrying the model identifier of the target analysis model; The model parameter file corresponding to the target analysis model is transmitted to the target computing node. The model parameter file includes a model structure description file and a model weight file. The target computing node is controlled to complete the model loading and initialization based on the model parameter file, so that the target computing node runs the target analysis model and obtains the analysis model instance.

8. The method according to claim 1, characterized in that, The step of generating a diagnostic response based on the diagnostic conclusion and sending the diagnostic response to the diagnostic terminal includes: Obtain the fault type information and confidence level information from the diagnostic conclusion; Based on the fault type information, the corresponding maintenance suggestion information and risk level information are matched in the preset diagnostic knowledge base; Based on the fault type information, the confidence level information, the maintenance suggestion information, and the risk level information, the diagnostic response is generated and sent to the diagnostic terminal.

9. A diagnostic log processing apparatus, characterized in that, The device includes: The transceiver module is used to receive diagnostic log data packets sent by the diagnostic terminal and obtain the analysis task type; the diagnostic log data packets are collected by the diagnostic terminal on the vehicle; the analysis task type is either a fault prediction task or a diagnostic classification task. The generation module is used to preprocess the diagnostic log data packet to obtain standardized diagnostic data, and extract features from the standardized diagnostic data to generate a feature vector; The acquisition module is used to acquire the corresponding target analysis model from a plurality of pre-trained analysis models according to the analysis task type; the plurality of analysis models include a fault prediction model and a diagnostic classification model, wherein the fault prediction model corresponds to the fault prediction task and the diagnostic classification model corresponds to the diagnostic classification task. The determination module is used to determine the complexity of the analysis task based on the feature vector and the analysis task type, and to obtain the corresponding target computing node in the computing resource pool based on the complexity of the analysis task, wherein the computing resource pool includes multiple hardware computing nodes; The output module is used to load the model parameters of the target analysis model onto the target computing node to obtain an analysis model instance, and input the feature vector into the analysis model instance, and output the diagnostic conclusion from the analysis model instance; The transceiver module is also used to generate a diagnostic response based on the diagnostic conclusion and send the diagnostic response to the diagnostic terminal.

10. A cloud server, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the steps of the diagnostic log processing method as described in any one of claims 1 to 9.

Images