An OTA upgrade log management system and method based on big data

Abstract

The application discloses an OTA upgrade log management system and method based on big data, and relates to the technical field of software upgrading. The method comprises the following steps: monitoring and acquiring the connection signal strength sequence of the power equipment and the cloud within a preset time range before OTA, performing OTA failure prediction, and obtaining an OTA failure rate; according to the OTA failure rate, configuring error log prediction resources, and predicting and acquiring a plurality of predicted upgrade error logs on the cloud; when the connection signal strength of the power equipment and the cloud meets the requirements after the OTA is completed, sending the plurality of predicted upgrade error logs to the power equipment for consistency verification, and obtaining a consistency coefficient; according to the consistency coefficient and the OTA failure rate, making a repeated OTA decision, performing repeated OTA on the power equipment, and generating a repeated OTA log for log management. The application effectively improves the success rate of the OTA upgrading technology and the log management efficiency.

Description

Technical Field

[0001] This invention relates to the field of software upgrade technology, and specifically to an OTA upgrade log management system and method based on big data. Background Technology

[0002] Over-the-Air (OTA) technology is a technology that allows for remote management and updates of devices via wireless communication networks. This technology enables the download and installation of new software or system versions, thus updating the device's firmware, without requiring the device to be connected to a computer or data cable.

[0003] In existing technologies, when using traditional methods to remotely upgrade the software of power equipment, in cases of severe weather or equipment failure leading to unstable network signals, the upgrade package download may be interrupted or verification may fail, resulting in OTA upgrade failures. This affects OTA operation and maintenance, log management, and the intelligent monitoring of power equipment. Summary of the Invention

[0004] This application provides an OTA upgrade log management system and method based on big data, aiming to solve the technical problems of high OTA upgrade failure rate and low log management efficiency in the prior art.

[0005] In view of the above problems, this application provides an OTA upgrade log management system and method based on big data.

[0006] Firstly, this application provides an OTA upgrade log management system based on big data, including:

[0007] The OTA failure prediction module is used to monitor and obtain the connection signal strength sequence between the power equipment and the cloud within a preset time range before OTA, perform OTA failure prediction, and obtain the OTA failure rate.

[0008] The error log prediction module is used to configure error log prediction resources based on the OTA failure rate and to predict and obtain multiple upgrade error logs in the cloud.

[0009] The consistency verification module is used to send the multiple predicted upgrade error logs to the power equipment for consistency verification and obtain the consistency coefficient when the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements.

[0010] The repeated OTA decision module is used to make repeated OTA decisions based on the consistency coefficient and OTA failure rate, perform repeated OTA on the power equipment, generate repeated OTA logs, and perform log management.

[0011] Secondly, this application provides a big data-based OTA upgrade log management method, including:

[0012] The system monitors and acquires the connection signal strength sequence between power equipment and the cloud within a preset time range before OTA, performs OTA failure prediction, and obtains the OTA failure rate.

[0013] Based on the OTA failure rate, configure error log prediction resources to predict and obtain multiple predicted upgrade error logs in the cloud.

[0014] When the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements, the multiple predicted upgrade error logs are sent to the power equipment for consistency verification to obtain the consistency coefficient.

[0015] Based on the consistency coefficient and OTA failure rate, a decision is made to perform repeated OTA, repeated OTA is performed on the power equipment, and repeated OTA logs are generated for log management.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0017] This application provides an OTA upgrade log management system and method based on big data. By collecting the connection signal strength sequence of power equipment before OTA, and combining OTA characteristics with a machine learning model to predict the failure rate, the system achieves early risk quantification. Log prediction resources are dynamically configured based on the failure rate, and cloud-based log prediction branches are invoked to generate multiple possible upgrade error logs, improving resource utilization. After OTA is completed and the communication signal meets requirements, the predicted logs are compared with the actual equipment logs for consistency verification. Similarity is calculated based on the proportion of repeated characters to obtain a consistency coefficient, thereby quantifying the degree of matching between prediction and reality. Finally, the consistency coefficient and failure rate are combined to calculate the OTA supplement coefficient, and repeated OTA and log management are automatically performed based on threshold judgment. This not only reduces the OTA failure rate of power equipment and improves the reliability and stability of upgrades, but also achieves full-process log collection, storage, and traceability, providing data support for subsequent model iteration and system optimization. Overall, it has the advantages of high intelligence, excellent resource utilization, and strong scalability, making it particularly suitable for large-scale equipment management scenarios such as the power Internet of Things. Attached Figure Description

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

[0019] Figure 1A schematic diagram of the structure of an OTA upgrade log management system based on big data, provided for an embodiment of this application;

[0020] Figure 2 A flowchart illustrating a big data-based OTA upgrade log management method provided in this application embodiment;

[0021] The components represented by each number in the attached diagram are explained below:

[0022] OTA failure prediction module 11, error log prediction module 12, consistency verification module 13, and repeated OTA decision module 14. Detailed Implementation

[0023] This application provides an OTA upgrade log management system and method based on big data, which is used to address the technical problems of high OTA upgrade failure rate and low log management efficiency in the prior art.

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0025] It should be noted that the terms "comprising" and "having" are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to these processes, methods, products, or devices.

[0026] Example 1, as Figure 1 As shown, this application provides an OTA upgrade log management system based on big data, the system comprising:

[0027] The OTA failure prediction module 11 is used to monitor and acquire the connection signal strength sequence between the power equipment and the cloud within a preset time range before OTA, perform OTA failure prediction, and obtain the OTA failure rate.

[0028] In this embodiment of the application, the past connection signal strength of the power equipment is collected to predict the failure rate of OTA. The worse the signal strength, the greater the failure rate of OTA.

[0029] In one embodiment, the OTA failure prediction module 11 is further configured to:

[0030] Continuously monitor the signal strength of the connection between power equipment and the cloud;

[0031] During OTA, the connection signal strength within a preset time range before OTA is retrieved to obtain the connection signal strength sequence, and the average connection signal strength is calculated.

[0032] Obtain the OTA characteristics of the current OTA, input the OTA characteristics and the average connection signal strength into the OTA failure rate predictor, and output the OTA failure rate.

[0033] In this embodiment, the connection signal strength between the power equipment and the cloud is continuously monitored. The connection signal strength refers to the quality index of the wireless communication link when the power equipment communicates with the cloud, and is usually quantified using parameters such as Received Signal Strength Indicator (RSSI) and Signal-to-Noise Ratio (SNR). For example, in the 10 seconds before an OTA (Over-The-Air) test, the RSSI value of a power equipment is collected every 2 seconds, resulting in a signal strength sequence: [-75dBm, -73dBm, -77dBm, -76dBm, -74dBm]. This sequence can be used for subsequent averaging calculations and input prediction.

[0034] During OTA (Over-The-Air) testing, the connection signal strength within a preset time range before the OTA is retrieved to obtain a connection signal strength sequence, and the average connection signal strength is calculated. Signal strength at a single moment may fluctuate due to instantaneous interference, failing to reflect the true communication quality. Calculating the average connection signal strength over a certain period provides a more accurate reflection of the current communication quality of the power equipment and improves the accuracy of subsequent prediction models in assessing link stability. For example, if the preset time range before the OTA is 10 seconds, and the signal strength sequence is [-75dBm, -73dBm, -77dBm, -76dBm, -74dBm], the average signal strength is calculated as (-75-73-77-76-74) / 5 = -75dBm. This value represents the average connection signal strength for the 10 seconds before the OTA.

[0035] The OTA characteristics of the current OTA are obtained, and these characteristics, along with the average connection signal strength, are input into the OTA failure rate predictor to output the OTA failure rate. OTA characteristics refer to a set of parameters related to the current OTA task, such as OTA file size, number of OTA packet fragments, transmission protocol type, device hardware model, and hardware version. The OTA failure rate predictor is a predictor trained based on a machine learning model. It can use a regression model to predict specific risk probabilities or a classification model to predict whether it is high-risk or low-risk. The reasons for OTA failures are not only related to link quality but also to the characteristics of the OTA itself. For example, the larger the file, the longer the transmission time, and the higher the requirement for signal stability. Inputting both OTA characteristics and the average connection signal strength simultaneously makes the prediction results more comprehensive and improves the accuracy of failure rate prediction. For example, assuming the current OTA file size is 20MB, using the HTTP protocol, the device model is A1, and the average signal strength is -75dBm, these parameters can be input as a vector into the OTA failure rate predictor, such as: [file size = 20MB, protocol = HTTP, device model = A1, average signal strength = -75dBm]. The vector is then input into the OTA failure rate predictor, the numerical features are standardized, and weighted calculations are performed based on the machine learning regression model to finally obtain the OTA failure rate, for example, the OTA failure rate F=15%.

[0036] The training steps for the OTA failure rate predictor include:

[0037] Based on historical OTA data, a set of sample connection signal strengths and a set of sample OTA features were collected. The percentage of OTA failures under different sample connection signal strengths and OTA features was also collected and labeled as the sample OTA failure rate set. The sample connection signal strength set includes, for example, data within different dBm value ranges; the sample OTA feature set includes, for example, file size, technical protocol, and device model; the sample OTA failure rate set statistically analyzes the percentage of OTA failures under different connection signal strengths and OTA features. For example, with a signal strength of -75dBm and a file size of 50MB, the failure rate is 70%.

[0038] Based on machine learning, an OTA failure rate predictor is built. A suitable machine learning algorithm, such as linear regression, random forest, or neural network, is selected to build a prediction model to be trained.

[0039] The OTA failure rate predictor is trained under supervised supervision using the sample connection signal strength set, sample OTA feature set, and sample OTA failure rate set, iteratively until test convergence. The model is trained using collected data, and the model parameters are optimized by minimizing the error between the predicted failure rate and the actual failure rate. The model accuracy is verified through cross-validation or independent test sets until convergence, resulting in a stable and reliable predictor. The trained predictor can provide personalized failure rate predictions for different devices, environments, and tasks. For example, in an experiment that collected 10,000 historical OTA data points, the predicted error of the trained predictor on the test set was less than 5%. In application, assuming an average signal strength of -75dBm and an OTA file size of 20MB, inputting these into the OTA failure rate predictor yields a predicted failure rate of 42%. Assuming that the true failure rate range in historical statistics is 40%~45%, the model's predicted failure rate of 42% falls within this range, indicating that the predictor's result matches the actual situation, verifying the model's effectiveness.

[0040] The error log prediction module 12 is used to configure error log prediction resources according to the OTA failure rate and to predict and obtain multiple upgrade error logs in the cloud.

[0041] In this embodiment, after predicting the OTA failure rate, it is necessary to configure cloud log prediction resources using the prediction results to generate potential OTA upgrade error logs in advance, providing data support for subsequent consistency verification and duplicate OTA decisions. By introducing log prediction branch groups and branch quantity configuration, dynamic generation of prediction error logs is achieved, ensuring more comprehensive error prediction under high-risk OTAs and saving resources under low-risk OTAs. Multiple error logs can be actually output for subsequent consistency verification.

[0042] In one embodiment, the error log prediction module 12 is further configured to:

[0043] Obtain the log prediction branch group configured in the cloud;

[0044] The number of configuration branches to be obtained is calculated and determined based on the OTA failure rate and the number of log prediction branches.

[0045] Obtain the equipment characteristics and OTA time of the power equipment, randomly select the log prediction branch of the configured branch number, input the equipment characteristics, OTA time and OTA characteristics, and output multiple predicted upgrade error logs.

[0046] Log prediction branches are independent prediction models trained on historical data. They are used to output potential error logs after inputting device characteristics, OTA time, and OTA features. A log prediction branch cluster is a collection of multiple log prediction branches, similar to model ensemble. A single log prediction model may have biases, especially when device characteristics are diverse and OTA conditions are complex. By constructing multiple prediction branches and forming a branch cluster, the diversity and robustness of predictions can be improved, ensuring that predicted logs cover more possibilities, reducing omissions, and improving the accuracy of subsequent consistency verification. For example, 20 log prediction branches are built in the cloud, each obtained from a different training subset. Some branches are better at predicting file transfer errors, while others are better at predicting device compatibility errors. This branch cluster can comprehensively cover all possible error types.

[0047] Based on the predicted OTA failure rate and the total number of log prediction branches, the number of log prediction branches to be invoked can be calculated. This allows for on-demand allocation of computing resources, ensuring comprehensive prediction in high-risk scenarios while avoiding excessive resource consumption in low-risk tasks. When the OTA failure rate is high, more branches need to be invoked for log prediction to cover as many error types as possible; when the OTA failure rate is low, fewer branches can be invoked to save computing resources. For example, assuming the predicted OTA failure rate is 60%, and there are 20 log prediction branches in the cloud, the configured branch count = total number of branches × failure rate, meaning 20 × 0.6 = 12 branches would be invoked for prediction.

[0048] The system acquires the device characteristics and OTA (Over-The-Air) timing of power equipment, randomly selects the configured number of log prediction branches, and inputs the device characteristics, OTA timing, and OTA features to output multiple predicted upgrade error logs. Device characteristics refer to the power equipment's hardware model, memory capacity, processor type, firmware version, historical upgrade records, etc. OTA timing refers to the specific time point when OTA is executed, which is related to network congestion and power dispatch cycles. Predicted upgrade error logs are possible error log entries output by the system based on the input characteristics, such as connection timeouts, sharding verification failures, and insufficient device memory. The operating environment of different devices varies greatly at different times, affecting the distribution of error types. By combining device characteristics and timing information, error logs can be predicted more accurately, improving the matching degree between predicted and actual logs and providing more reliable data for subsequent consistency verification. For example, a device model D1000 with 128MB of memory and an OTA file size of 30MB is executed during the evening peak at 19:00. The system randomly selects 12 log prediction branches, resulting in the following predicted logs: Branch 1: Connection timeout, probability 35%; Branch 4: Insufficient memory, probability 28%; Branch 7: Shard loss, probability 22%; Branch 9: File verification error, probability 15%. After integration, multiple sets of predicted upgrade error logs are output for subsequent consistency verification.

[0049] This includes obtaining the log prediction branch group configured in the cloud, including:

[0050] Based on the historical records of OTA failures, a set of sample device features, a set of sample OTA times, and a set of sample OTA features are collected, along with a set of sample upgrade error logs. The sample device feature set includes factors such as different models, memory size, and CPU frequency; the sample OTA times are collected across different time periods, such as early morning or peak hours; the sample OTA features include factors such as file size and protocol type; and the sample upgrade error logs contain actual error log records. Based on machine learning, multiple log prediction branches are constructed, such as random forests and neural networks. The sample device feature set, sample OTA times, sample OTA features, and sample upgrade error logs are randomly divided multiple times to obtain multiple sets of log prediction training data. Multiple log prediction branches are trained using each set of training data, and after convergence, they are integrated to form a log prediction branch cluster. Each set of training data is used to independently train a log prediction branch until convergence. The multiple converged log prediction branches are then integrated to form a log prediction branch cluster.

[0051] Obtaining a log prediction branch cluster configured in the cloud can improve the generalization ability and robustness of predictions, avoid overfitting a single model, and cover error patterns under different data distributions. For example, collecting 10,000 OTA upgrade records, including 2,000 failure logs, randomly dividing the data 10 times, training one log prediction branch each time, will eventually result in 10 log prediction branches, which can be integrated to form a log prediction branch cluster.

[0052] The consistency verification module 13 is used to send the multiple predicted upgrade error logs to the power equipment for consistency verification and obtain the consistency coefficient when the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements.

[0053] In this embodiment, the predicted upgrade error log is essentially a potentially erroneous log generated by the log prediction branch. It needs to be compared with the actual log to determine the reliability of the prediction. Consistency verification quantifies the degree of agreement between the predicted log and the actual log, thereby evaluating the accuracy of the prediction model and providing reliable input parameters for subsequent repeated OTA decisions.

[0054] Specifically, step S300 includes the following sub-steps:

[0055] After the OTA is completed, monitor and determine whether the connection signal strength between the power equipment and the cloud is greater than or equal to the connection signal strength threshold;

[0056] If so, the multiple predicted upgrade error logs are sent to the power equipment, and the consistency of the logs at the OTA time in the power equipment is verified. The similarity of multiple logs is obtained, and the average value is calculated to obtain the consistency coefficient.

[0057] If not, continue monitoring the connection signal strength.

[0058] In this embodiment of the application, after generating multiple predicted upgrade error logs, the present invention needs to determine the degree of matching between these predicted logs and the real logs generated by the power equipment during the actual OTA process, so as to obtain a consistency coefficient and provide a reference for subsequent repeated OTA decisions.

[0059] After an OTA update, the connection signal strength between the power equipment and the cloud is monitored to determine if it is greater than or equal to a preset connection signal strength threshold. The connection signal strength threshold is the minimum signal strength required to ensure stable log transmission between the device and the cloud. For example, if the threshold is set to -80dBm, communication quality is reliable when the actual signal strength is ≥ -80dBm, and unreliable when the actual signal strength is < -80dBm. If the signal is too weak, log transmission may be interrupted or lost, leading to distorted consistency verification results. Verification must only be performed when the signal strength meets the requirements. This process ensures the reliability of log transmission and the accuracy of verification results. For example, after an OTA update for a power device, the real-time monitored signal strength is -72dBm, and the threshold is set to -80dBm. Since -72dBm > -80dBm, the signal strength meets the requirements, and the consistency verification process can proceed.

[0060] If the signal strength meets the standard (i.e., the connection signal strength is greater than or equal to the connection signal strength threshold), multiple predicted upgrade error logs are sent to the power equipment for consistency verification with its locally recorded OTA logs. Multiple log similarity scores are obtained, and the average is calculated to obtain a consistency coefficient. Actual OTA logs refer to the logs recorded in real time by the power equipment during the upgrade process, including connection status, file verification, and packet loss information. Log similarity is used to measure the degree of matching between predicted and actual logs, and can be based on text similarity algorithms or event tag-based matching.

[0061] To improve computational efficiency and adapt to the resource constraints of power equipment, this embodiment uses the proportion of duplicate characters in the logs as a similarity metric. For example, the predicted log is string P with length |P|; the actual log is string A with length |A|; the two are compared character by character, and the number of identical characters is counted as C. Then, the similarity = C / max(|P|, |A|). The denominator takes the maximum of the two lengths to avoid unfairly suppressing shorter logs with longer logs; the value range is [0,1], with larger values ​​indicating higher consistency. A similarity of 0 indicates complete inconsistency; a similarity of 1 indicates complete consistency. For example, the predicted log shows connection timeout and data fragment loss; the actual log shows connection timeout, data fragment loss, and file verification failure. The lengths of the two logs are |P|=11 and |A|=17 respectively, and the number of identical characters C=11. Therefore, the similarity = 11 / max(11,17) ≈ 0.65. Character repetition rate analysis only requires scanning character by character, which is low in complexity and suitable for environments with limited power equipment resources. It can quickly capture similarity for common key fields in logs.

[0062] If multiple prediction logs exist, their similarity is calculated separately, and the average is taken to obtain the consistency coefficient. Different prediction branches may output multiple sets of prediction logs, and a single similarity is insufficient to fully reflect the overall consistency. By averaging multiple similarities, the reliability of the prediction results can be reflected more objectively. This yields a stable consistency metric, which can be easily combined with the OTA failure rate to guide subsequent repeated OTA decisions.

[0063] If the signal strength is insufficient (i.e., the connection signal strength is below the connection signal strength threshold), consistency verification is not performed immediately. Instead, the system continues to wait and monitor the connection signal strength until the condition is met. For example, if a device's signal strength is -85dBm after OTA completion, which is less than the threshold of -80dBm, the signal strength does not meet the requirement. After a 5-second delay, the system monitors again. If the signal strength recovers to -75dBm, then consistency verification begins. This step effectively prevents packet loss or delays when transmitting logs under weak signal conditions, avoids distortion of consistency verification results, and further improves the stability and accuracy of consistency verification.

[0064] The repeated OTA decision module 14 is used to make repeated OTA decisions based on the consistency coefficient and OTA failure rate, perform repeated OTA on the power equipment, generate repeated OTA logs, and perform log management.

[0065] In this embodiment, after completing consistency verification and obtaining the consistency coefficient, the present invention, in conjunction with the OTA failure rate, makes a decision on whether power equipment needs to undergo repeated OTA updates and performs corresponding log management. Introducing an OTA supplement coefficient comprehensively considers both the failure rate and consistency, improving the rationality of the decision; deciding whether to repeat OTA updates avoids unnecessary repeated upgrades and reduces system burden; complete log management ensures the comprehensiveness and traceability of logs regardless of whether repeated OTA updates occur, providing data support for subsequent optimization.

[0066] In one embodiment, the repeat OTA decision module 14 is further configured to:

[0067] The OTA supplementation coefficient is calculated based on the consistency coefficient and the OTA failure rate.

[0068] Determine if the OTA supplement coefficient is greater than or equal to the supplement coefficient threshold. If so, perform repeated OTA for the power equipment and generate repeated OTA logs. Combine the logs from the power equipment's OTA times for log management.

[0069] If not, then the power equipment will not be subjected to repeated OTA updates. Instead, logs of the OTA updates within the power equipment will be obtained and managed.

[0070] In this embodiment, an OTA supplementation coefficient is calculated based on the consistency coefficient and the OTA failure rate. The OTA supplementation coefficient (S) is an indicator that comprehensively considers the device's OTA risk and the consistency between predicted and actual logs. For example, if the consistency coefficient is C and the OTA failure rate is F, then the OTA supplementation coefficient S = α·F + β·C, where the failure rate F ranges from 0 to 1; the consistency coefficient C ranges from 0 to 1; and α and β represent weighting parameters used to adjust the proportions of failure rate and consistency in the supplementation coefficient. A larger supplementation coefficient S indicates a lower reliability of OTA success, requiring more frequent OTA repetitions. Relying solely on the OTA failure rate or consistency coefficient for judgment is insufficient. If the OTA failure rate is high, but the actual logs are highly consistent with the prediction, repeated OTA repetitions may not be necessary; conversely, if the OTA failure rate is low, but log consistency is poor, repeated OTA repetitions may still be required. By introducing the supplementation coefficient and combining the two, a more accurate decision-making basis can be obtained. This step avoids unnecessary repetitive operations and reduces the omission of situations requiring supplementary OTA updates.

[0071] The system determines whether the OTA supplementation coefficient is greater than or equal to the supplementation coefficient threshold. If so, it performs a repeated OTA update on the power equipment and generates a repeated OTA log. This log is then used for log management in conjunction with the OTA logs from the power equipment at each OTA time. If not, it does not perform a repeated OTA update, but instead retrieves the OTA logs from the power equipment and manages them. The supplementation coefficient threshold T is a value set based on experience or simulation, such as 0.6 or 0.7, used to determine whether a repeated OTA update is necessary. For example, if the supplementation coefficient S ≥ the supplementation coefficient threshold T, a repeated OTA update is performed; if the OTA supplementation coefficient S < the supplementation coefficient threshold T, a repeated OTA update is not performed, and only log management is performed. This step avoids frequent repeated OTA updates, ensuring OTA success rates in high-risk situations and saving network and computing resources in low-risk situations. For example, if a device has an OTA failure rate of F=0.55, a consistency coefficient of C=0.65, and weight parameters α=0.6 and β=0.4, then the supplementary coefficient S=0.6×0.55+0.4×0.65=0.59. If the supplementary coefficient threshold T=0.5 is set, then S=0.59>0.5, and it is determined that repeated OTA needs to be performed.

[0072] If repeated OTA is performed, a repeated OTA log is generated and merged with the original OTA log for management. If repeated OTA is not performed, the logs from the power equipment at the OTA time are directly collected, stored, and managed. Recording repeated OTA logs can help optimize OTA strategies later. Even if repeated OTA is not needed, logs must be retained to ensure their integrity and traceability. Establishing a comprehensive OTA end-to-end log archive provides data support for subsequent machine learning model updates. For example, if a power device performs repeated OTA, the log management system stores two records: the original OTA log and the repeated OTA log. These two records are merged into a single log set for subsequent statistics and analysis.

[0073] Example 2, as Figure 2 As shown, this application provides a method for managing OTA upgrade logs based on big data, the method comprising:

[0074] S100: Monitors and acquires the connection signal strength sequence between power equipment and the cloud within a preset time range before OTA, performs OTA failure prediction, and obtains the OTA failure rate.

[0075] Specifically, step S100 includes the following sub-steps:

[0076] Continuously monitor the signal strength of the connection between power equipment and the cloud;

[0077] During OTA, the connection signal strength within a preset time range before OTA is retrieved to obtain the connection signal strength sequence, and the average connection signal strength is calculated.

[0078] Obtain the OTA characteristics of the current OTA, input the OTA characteristics and the average connection signal strength into the OTA failure rate predictor, and output the OTA failure rate.

[0079] The training steps for the OTA failure rate predictor include:

[0080] Based on historical OTA data, a set of sample connection signal strengths and a set of sample OTA features were collected, and the percentage of OTA TA failures under different sample connection signal strengths and sample OTA features was collected and labeled as the sample OTA failure rate set.

[0081] Build an OTA failure rate predictor based on machine learning;

[0082] The OTA failure rate predictor is trained under supervision using the sample connection signal strength set, sample OTA feature set, and sample OTA failure rate set, and the training is iteratively trained until the test converges.

[0083] S200: Based on the OTA failure rate, configure error log prediction resources and obtain multiple predicted upgrade error logs in the cloud.

[0084] Specifically, step S200 includes the following sub-steps:

[0085] Obtain the log prediction branch group configured in the cloud;

[0086] The number of configuration branches to be obtained is calculated and determined based on the OTA failure rate and the number of log prediction branches.

[0087] Obtain the equipment characteristics and OTA time of the power equipment, randomly select the log prediction branch of the configured branch number, input the equipment characteristics, OTA time and OTA characteristics, and output multiple predicted upgrade error logs.

[0088] This includes obtaining the log prediction branch group configured in the cloud, including:

[0089] Based on the historical records of OTA failures, collect sample device feature sets, sample OTA time sets, sample OTA feature sets, and sample upgrade error log sets;

[0090] Based on machine learning, multiple log prediction branches are constructed;

[0091] The sample device feature set, sample OTA time set, sample OTA feature set and sample upgrade error log set are randomly divided multiple times to obtain multiple log prediction training data;

[0092] Multiple log prediction training data are used to train multiple log prediction branches, which are then integrated after convergence to obtain a log prediction branch cluster.

[0093] S300: When the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements, the multiple predicted upgrade error logs are sent to the power equipment for consistency verification to obtain the consistency coefficient.

[0094] Specifically, step S300 includes the following sub-steps:

[0095] After the OTA is completed, monitor and determine whether the connection signal strength between the power equipment and the cloud is greater than or equal to the connection signal strength threshold;

[0096] If so, the multiple predicted upgrade error logs are sent to the power equipment, and the consistency of the logs at the OTA time in the power equipment is verified. The similarity of multiple logs is obtained, and the average value is calculated to obtain the consistency coefficient.

[0097] If not, continue monitoring the connection signal strength.

[0098] S400: Based on the consistency coefficient and OTA failure rate, make a decision on repeated OTA, perform repeated OTA on the power equipment, generate repeated OTA logs, and perform log management.

[0099] Specifically, step S400 includes the following sub-steps:

[0100] The OTA supplementation coefficient is calculated based on the consistency coefficient and the OTA failure rate.

[0101] Determine if the OTA supplement coefficient is greater than or equal to the supplement coefficient threshold. If so, perform repeated OTA for the power equipment and generate repeated OTA logs. Combine the logs from the power equipment's OTA times for log management.

[0102] If not, then the power equipment will not be subjected to repeated OTA updates. Instead, logs of the OTA updates within the power equipment will be obtained and managed.

[0103] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0104] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0105] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and modifications fall within the scope of this application and its equivalents, this application intends to include such modifications and modifications.

Claims

1. An OTA upgrade log management system based on big data, characterized in that, The system includes: The OTA failure prediction module is used to monitor and obtain the connection signal strength sequence between the power equipment and the cloud within a preset time range before OTA, perform OTA failure prediction, and obtain the OTA failure rate. The error log prediction module is used to configure error log prediction resources based on the OTA failure rate and to predict and obtain multiple upgrade error logs in the cloud. The consistency verification module is used to send the multiple predicted upgrade error logs to the power equipment for consistency verification and obtain the consistency coefficient when the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements. The repeated OTA decision module is used to make repeated OTA decisions based on the consistency coefficient and OTA failure rate, perform repeated OTA on the power equipment, generate repeated OTA logs, and perform log management. The OTA failure prediction module is also used for: continuously monitoring the connection signal strength between the power equipment and the cloud; during OTA, retrieving the connection signal strength within a preset time range before OTA, obtaining the connection signal strength sequence, and calculating the average connection signal strength; acquiring the OTA characteristics of the current OTA, inputting the OTA characteristics and the average connection signal strength into the OTA failure rate predictor, and outputting the OTA failure rate. The error log prediction module is further configured to: obtain a log prediction branch group configured in the cloud; calculate and determine the number of configuration branches based on the OTA failure rate and the number of log prediction branches; obtain the equipment characteristics and OTA time of the power equipment, randomly select the log prediction branches of the number of configuration branches, input the equipment characteristics, OTA time and OTA characteristics, and output multiple predicted upgrade error logs. The log prediction branch is a prediction model built on machine learning, which is used to output one or more predicted upgrade error logs based on the device characteristics, OTA time and OTA characteristics of the input power equipment; the log prediction branch group is a model set composed of multiple log prediction branches.

2. The OTA upgrade log management system based on big data according to claim 1, characterized in that, The training steps for the OTA failure rate predictor include: Based on historical OTA data, a set of sample connection signal strengths and a set of sample OTA features were collected, and the percentage of OTA failures under different sample connection signal strengths and sample OTA features was collected and labeled as the sample OTA failure rate set. Build an OTA failure rate predictor based on machine learning; The OTA failure rate predictor is trained under supervision using the sample connection signal strength set, sample OTA feature set, and sample OTA failure rate set, and the training is iteratively trained until the test converges.

3. The OTA upgrade log management system based on big data according to claim 1, characterized in that, Obtain the log prediction branch group configured in the cloud, including: Based on the historical records of OTA failures, collect sample device feature sets, sample OTA time sets, sample OTA feature sets, and sample upgrade error log sets; Based on machine learning, multiple log prediction branches are constructed; The sample device feature set, sample OTA time set, sample OTA feature set and sample upgrade error log set are randomly divided multiple times to obtain multiple log prediction training data; Multiple log prediction training data are used to train multiple log prediction branches, which are then integrated after convergence to obtain a log prediction branch cluster.

4. The OTA upgrade log management system based on big data according to claim 1, characterized in that, When the OTA (Over-The-Air) update is completed and the connection signal strength between the power equipment and the cloud meets the requirements, the multiple predicted upgrade error logs are sent to the power equipment for consistency verification to obtain a consistency coefficient, including: After the OTA is completed, monitor and determine whether the connection signal strength between the power equipment and the cloud is greater than or equal to the connection signal strength threshold; If so, the multiple predicted upgrade error logs are sent to the power equipment, and the consistency of the logs at the OTA time in the power equipment is verified. The similarity of multiple logs is obtained, and the average value is calculated to obtain the consistency coefficient. If not, continue monitoring the connection signal strength.

5. The OTA upgrade log management system based on big data according to claim 1, characterized in that, Based on the consistency coefficient and OTA failure rate, a decision is made to perform repeated OTA updates on the power equipment, and repeated OTA logs are generated and managed, including: The OTA supplementation coefficient is calculated based on the consistency coefficient and the OTA failure rate. Determine if the OTA supplement coefficient is greater than or equal to the supplement coefficient threshold. If so, perform repeated OTA for the power equipment and generate repeated OTA logs. Combine the logs from the power equipment's OTA times for log management. If not, then the power equipment will not be subjected to repeated OTA updates. Instead, logs of the OTA updates within the power equipment will be obtained and managed.

6. A method for managing OTA upgrade logs based on big data, characterized in that, Applied to the implementation of the big data-based OTA upgrade log management system according to any one of claims 1-5, the method includes: The system monitors and acquires the connection signal strength sequence between power equipment and the cloud within a preset time range before OTA, performs OTA failure prediction, and obtains the OTA failure rate. Based on the OTA failure rate, configure error log prediction resources to predict and obtain multiple predicted upgrade error logs in the cloud. When the OTA ends and the connection signal strength between the power equipment and the cloud meets the requirements, the multiple predicted upgrade error logs are sent to the power equipment for consistency verification to obtain the consistency coefficient. Based on the consistency coefficient and OTA failure rate, a decision is made to perform repeated OTA, repeated OTA is performed on the power equipment, and repeated OTA logs are generated for log management.

Images