A method and system for rapid disaster recovery management of vehicle-mounted controller

Abstract

The present application relates to a method and system for rapid disaster recovery management of an on-board controller, and to the technical field of on-board controllers, wherein the method comprises: obtaining the operating parameters of the on-board controller in real time; the operating parameters include: CPU usage, memory usage, and network delay; comparing the obtained operating parameters with a threshold to determine whether the operating parameters exceed the threshold; when it is determined that the operating parameters exceed the threshold, marking the on-board controller as an abnormal state, starting an abnormal detection model to analyze the cause of the abnormality and generating an abnormality report; and starting a disaster recovery process based on the abnormality report. The technical solution of the present application can automatically analyze the specific cause of the abnormality and start a disaster recovery process based on the abnormality report to restore the normal operation of the system as soon as possible.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle-mounted controllers, and in particular to a method and system for rapid disaster recovery management of vehicle-mounted controllers. Background Art

[0002] With the development of the automotive industry, especially the popularization of intelligent connected vehicles (ICV), the stability and reliability of vehicle controllers as the core components of vehicle electronic systems are crucial to ensure driving safety. Traditional vehicle control systems often lack effective self-diagnosis and recovery mechanisms when facing emergencies or system abnormalities, which may lead to further expansion of system failures and even affect driving safety.

[0003] Currently, once an abnormality in the on-board controller is detected, the existing solution is often to achieve disaster recovery by restarting the system or switching to a backup system. This approach not only has a long response time, but also cannot accurately locate the cause of the fault, thus affecting the system's recovery efficiency. Summary of the invention

[0004] In order to at least partially solve the above technical problems, the present application provides a method and system for rapid disaster recovery management of a vehicle-mounted controller.

[0005] The present application provides a method for rapid disaster recovery management of an on-board controller using the following technical solution.

[0006] A method for rapid disaster recovery management of a vehicle-mounted controller, comprising:

[0007] Obtaining the operating parameters of the vehicle controller in real time; the operating parameters include: CPU usage, memory usage and network delay;

[0008] comparing the acquired operating parameter with a threshold value to determine whether the operating parameter exceeds the threshold value;

[0009] When it is determined that the operating parameters exceed the threshold, the on-board controller is marked as abnormal, the abnormality detection model is started to analyze the cause of the abnormality and generate an abnormality report;

[0010] The disaster recovery process is initiated based on the abnormal report.

[0011] By adopting the above technical solution, the vehicle-mounted system will compare the operating parameters obtained in real time with the corresponding thresholds. Once it is detected that the operating parameters exceed the threshold, the system will automatically mark the vehicle-mounted controller as an abnormal state and start the anomaly detection model to analyze the specific cause of the anomaly; the anomaly detection model generates an anomaly report, and the system can start the disaster recovery process to restore the normal operation of the system as soon as possible.

[0012] Optionally, the threshold is adjusted dynamically, and the step of adjusting the threshold includes:

[0013] S21. Obtaining predicted values ​​of future operating parameters based on current operating parameters;

[0014] S22, judging whether the current threshold needs to be adjusted based on the predicted value and the current threshold;

[0015] S23. If it is determined that adjustment is required, a new threshold is set based on a threshold setting formula; wherein the threshold setting formula is: ; is the preset upper threshold value; is the preset lower threshold; and are adjustment factors, corresponding to the influence weights of the predicted value and the current threshold respectively;

[0016] S24: Apply the new threshold.

[0017] Optionally, obtaining predicted values ​​of future operating parameters based on current operating parameters includes:

[0018] S31, selecting a time window of length n;

[0019] S32, calculating an average value based on the most recent n operating parameters;

[0020] S33, taking the average value as the predicted value corresponding to the current n operating parameters;

[0021] S33. Every time a new operating parameter is obtained, the earliest operating parameter in the current time window is removed, and the newly obtained operating parameter is used as the latest operating parameter to obtain n operating parameters in the time window again; return to S32.

[0022] Optionally, the anomaly detection model can be configured by:

[0023] Obtain device information of the vehicle controller to obtain computing resources of the vehicle controller;

[0024] Matching the number of layers of the preliminary model based on the computing resources and obtaining the preliminary model;

[0025] Using the training set data to train the preliminary model, and using the validation set to evaluate whether the preliminary model is overfitting or underfitting;

[0026] If overfitting exists, the model complexity is adjusted by reducing the number of neural network layers, lowering the polynomial order, or regularization penalty weight value; if underfitting exists, the model complexity is adjusted by increasing the number of neural network layers, increasing the polynomial order, or adding more feature engineering.

[0027] The adjusted preliminary model is retrained using the training set data, and the validation set is used to evaluate whether the adjusted preliminary model is overfitting or underfitting; if not, the anomaly detection model is obtained.

[0028] Optionally, judging whether the current threshold needs to be adjusted based on the predicted value and the current threshold includes:

[0029] Compare the predicted value with the current threshold value, and if the ratio of the difference between the predicted value and the current threshold value is greater than the preset ratio and the first difference between the current threshold value and the upper threshold value and the second difference between the current threshold value and the lower threshold value are both less than the preset difference, it is determined that the current threshold value needs to be adjusted;

[0030] After determining that the current threshold value needs to be adjusted, the method further includes: determining a frequency of threshold value adjustment according to a change speed of the current operating parameter; the frequency of threshold value adjustment is less than an upper limit of the adjustment frequency;

[0031] The formula for determining the frequency of threshold adjustment based on the change speed of the current operating parameters is: ;in To adjust the frequency cap; ; is the preset parameter change speed, v is the parameter change speed, and k is a constant.

[0032] Optionally, start the anomaly detection model to analyze the cause of the anomaly and generate an anomaly report, including:

[0033] Start the anomaly detection model of the vehicle controller;

[0034] Inputting the collected operating parameters into the anomaly detection model, the anomaly detection model outputs the anomaly cause and probability;

[0035] An anomaly report is generated based on the output of the anomaly detection model; the anomaly report includes: a timestamp of the anomaly occurrence and current operating parameters and their deviation from the threshold.

[0036] Optionally, starting a disaster recovery process based on the abnormal report includes:

[0037] Parse information from exception reports;

[0038] Develop disaster recovery strategies based on the abnormal causes and probabilities in abnormal reports;

[0039] Initiate a disaster recovery process based on the disaster recovery strategy;

[0040] Monitor the execution of the disaster recovery process and adjust the disaster recovery strategy based on the execution.

[0041] Optionally, formulate a disaster recovery strategy based on the abnormal causes and probabilities in the abnormality report, including:

[0042] Compare all possible abnormal causes and their probabilities, sort all abnormal causes from high to low according to probability, and identify the abnormal cause with the highest probability;

[0043] Identify disaster recovery measures that can address multiple causes of anomalies;

[0044] Evaluate the feasibility of disaster recovery measures, score each disaster recovery measure, and select the one with the highest score;

[0045] The selected disaster recovery measure is executed and combined with the real-time acquired operation parameters to determine whether the currently selected disaster recovery measure is effective; if not, the next rated disaster recovery measure is selected.

[0046] Optionally, identify disaster recovery measures that can address multiple causes of anomalies, including:

[0047] Determine the cause of the anomaly that each disaster recovery measure can resolve;

[0048] Construct a relationship matrix between disaster recovery measures and abnormal causes;

[0049] Identify disaster recovery measures that can solve multiple abnormal causes based on the elements in the relationship matrix;

[0050] Evaluate the feasibility of disaster recovery measures, including:

[0051] Assess the difficulty of implementing disaster recovery measures ;

[0052] Assess the impact of disaster recovery measures on other parts of the system ;

[0053] Determine the time required to implement disaster recovery measures ;

[0054] Determine the system resources required to implement disaster recovery measures ;

[0055] based on Get a feasibility score ; Where a, b, c and d are coefficients; is the maximum allowed execution time.

[0056] In a second aspect, the present application also provides a vehicle-mounted controller rapid disaster recovery management system, including:

[0057] The first processing module is used to obtain the operating parameters of the vehicle controller in real time; the operating parameters include: CPU usage, memory usage and network delay;

[0058] A second processing module is used to: compare the acquired operating parameter with the threshold to determine whether the operating parameter exceeds the threshold;

[0059] The third processing module is used to: when it is determined that the operating parameter exceeds the threshold, mark the vehicle controller as an abnormal state, start the abnormality detection model to analyze the abnormality cause and generate an abnormality report;

[0060] The fourth processing module is used to start a disaster recovery process based on the abnormal report. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 This is a flow chart of a method for rapid disaster recovery management of a vehicle-mounted controller according to an embodiment of the present application;

[0062] Figure 2 This is a system block diagram of a vehicle-mounted controller rapid disaster recovery management system according to an embodiment of the present application;

[0063] In the figure, 201 is a first processing module; 202 is a second processing module; 203 is a third processing module; 204 is a fourth processing module. DETAILED DESCRIPTION

[0064] The following is combined with Figure 1-Figure 2 The present application is further described with specific embodiments:

[0065] First of all, it should be noted that in the description of this application, if the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inside", "outside" and other directional words appear, the orientation or position relationship indicated is based on the orientation or position relationship shown in the drawings, which is only for the convenience of description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on this application; in addition, if the terms "first", "second", "third" and other numerical quantifiers appear, they are only used for descriptive purposes and cannot be understood as indicating or implying relative importance. In addition, in this application, unless otherwise clearly specified and limited, if the terms "installed", "connected", and "connected" appear, they should be understood in a broad sense, for example, it can be a fixed connection, or a detachable connection, a limited connection such as an interference fit, a transition fit, or an integral connection; it can be directly connected or indirectly connected through an intermediate medium; therefore, for ordinary technicians in this field, the specific meanings of the above terms in this application can be understood according to the specific circumstances.

[0066] The present application embodiment discloses a method for rapid disaster recovery management of a vehicle-mounted controller. Figure 1 As an implementation method of a vehicle controller rapid disaster recovery management method, a vehicle controller rapid disaster recovery management method includes the following steps:

[0067] Step 101, obtaining the operating parameters of the vehicle controller in real time; the operating parameters include: CPU usage, memory usage and network delay.

[0068] Specifically, usually, the system tool provided by the vehicle system can obtain the above operating parameters. In addition, the operating parameters can also be obtained by setting a specific monitoring tool.

[0069] Step 102: Compare the acquired operating parameter with a threshold to determine whether the operating parameter exceeds the threshold.

[0070] Step 103: When it is determined that the operating parameter exceeds the threshold, the vehicle controller is marked as abnormal, and the abnormality detection model is started to analyze the cause of the abnormality and generate an abnormality report.

[0071] Specifically, the vehicle-mounted system compares the operating parameters acquired in real time with the corresponding thresholds. Once it detects that the operating parameters exceed the thresholds, the system will automatically mark the vehicle-mounted controller as abnormal and start the anomaly detection model to analyze the specific cause of the abnormality.

[0072] Step 104: Start the disaster recovery process based on the abnormal report.

[0073] Specifically, based on the anomaly report generated by the anomaly detection model, the system can initiate a disaster recovery process to restore the normal operation of the system as soon as possible.

[0074] The following examples are given for illustration. It should be understood that the following specific numerical values ​​are exemplary.

[0075] The vehicle system monitors the following parameters in real time: CPU usage: normal range is 10% to 80%; memory usage: normal range is 10% to 75%; network delay: normal range is 0ms to 200ms. The vehicle system obtains real-time operating parameters from the vehicle controller once a second, for example: CPU usage: 85%; memory usage: 80%; network delay: 250ms. Compare the real-time operating parameters with the preset thresholds: CPU usage: 85%>80%; memory usage: 80%>75%; network delay: 250ms>200ms; all three parameters exceed their respective thresholds, and the system determines that the vehicle controller is in an abnormal state. At this time, the vehicle controller is marked as abnormal, and the anomaly detection model is started to analyze the cause of the anomaly, and the anomaly causes are: CPU overload (probability 70%), memory leak (probability 20%), and network congestion (probability 10%). The system generates an exception report: the timestamp of the exception: 2024-09-0917:00:00, current operating parameters: CPU usage 85%, memory usage 80%, network delay 250ms; possible causes of the exception: CPU overload (probability 70%), memory leak (probability 20%) and network congestion (probability 10%). After that, the system starts the disaster recovery process according to the exception report. Through the above steps, the vehicle controller can quickly identify and take effective disaster recovery measures when an abnormal state occurs.

[0076] As a specific implementation of a method for rapid disaster recovery management of a vehicle-mounted controller, the threshold is dynamically adjusted, and the threshold adjustment steps include:

[0077] S21. Obtain predicted values ​​of future operating parameters based on current operating parameters.

[0078] Based on the current operating parameters, the predicted values ​​of future operating parameters are obtained, including:

[0079] S31, selecting a time window of length n;

[0080] S32, calculating an average value based on the most recent n operating parameters;

[0081] S33, taking the average value as the predicted value corresponding to the current n operating parameters;

[0082] S33. Every time a new operating parameter is obtained, the earliest operating parameter in the current time window is removed, and the newly obtained operating parameter is used as the latest operating parameter to obtain n operating parameters in the time window again; return to S32.

[0083] By selecting a time window of fixed length, the system only focuses on the n operating parameters in the most recent period of time; by calculating the average of the most recent n operating parameters, a smooth operating parameter trend can be obtained to reduce the impact of noise; by using the average as the predicted value, the system can make predictions based on the current operating status, thereby identifying potential problems in advance. Every time a new operating parameter is obtained, the earliest operating parameter in the current time window is removed, and the newly obtained operating parameter is used as the latest operating parameter to regain the n operating parameters in the time window. By continuously updating the data in the time window, the system can maintain the freshness of the data and ensure that the prediction results always reflect the latest operating status.

[0084] The following is an example:

[0085] Assume that the length of the selected time window is 5, that is, n = 5. In the initial state, the first five operating parameters obtained are: CPU usage: 70%, 72%, 75%, 73%, 74%; memory usage: 60%, 62%, 65%, 63%, 64%; network delay: 140ms, 145ms, 150ms, 146ms, 148ms; the average CPU usage is 72.8%; the average memory usage is 63%; the average network delay is 145.8ms; the above average values ​​are used as prediction values ​​to obtain: CPU usage prediction value: 72.8%, memory usage prediction value: 63% and network delay prediction value: 145.8ms. Assume that the system obtains a new operating parameter every second: the newly obtained CPU usage is 76%, the newly obtained memory usage is 66%, and the newly obtained network delay is 152ms; remove the earliest data: CPU usage: 70% is removed, and the remaining data are 72%, 75%, 73%, and 74%; memory usage: 60% is removed, and the remaining data are 62%, 65%, 63%, and 64%; network delay: 140ms is removed, and the remaining data are 145ms, 150ms, 146ms, and 148ms. Add the newly obtained operating parameters to the time window: CPU usage: 72%, 75%, 73%, 74%, and 76%; memory usage: 62%, 65%, 63%, 64%, and 66%; network delay: 145ms, 150ms, 146ms, 148ms, and 152ms; recalculate the average value and use the new average value as the new prediction value.

[0086] S22: Determine whether the current threshold needs to be adjusted based on the predicted value and the current threshold.

[0087] S23. If it is determined that adjustment is required, a new threshold is set based on a threshold setting formula; wherein the threshold setting formula is: ; is the preset upper threshold value; is the preset lower threshold; and are adjustment factors, corresponding to the influence weights of the predicted value and the current threshold respectively.

[0088] S24: Apply the new threshold.

[0089] Specifically, the predicted values ​​of future operating parameters are obtained based on the current operating parameters; by comparing the predicted values ​​with the current thresholds, the system can dynamically adjust the thresholds according to the threshold setting formula; by applying new thresholds, the system can respond to changing operating conditions in a timely manner, thereby performing disaster recovery warnings more accurately.

[0090] As a specific implementation method of a fast disaster recovery management method for a vehicle controller, a configuration method of an anomaly detection model includes:

[0091] The device information of the vehicle controller is obtained to obtain the computing resources of the vehicle controller. Specifically, by obtaining the device information of the vehicle controller, the device resource situation of the vehicle controller is understood so as to reasonably configure the complexity of the model, so that the model is neither too complex to cause inability to run or occupy too many computing resources, nor too simple to lose detection capability.

[0092] The number of layers of the preliminary model is matched based on the computing resources to obtain the preliminary model. Specifically, the number of layers of the preliminary model is matched according to the computing resources of the vehicle controller to ensure that the model can run under limited computing resources.

[0093] The preliminary model is trained using the training set data, and the preliminary model is evaluated through the validation set to see whether it is overfitting or underfitting. Specifically, by training the preliminary model and evaluating its performance, it is possible to check whether the model is overfitting or underfitting.

[0094] If overfitting exists, the model complexity is adjusted by at least one of reducing the number of neural network layers, lowering the polynomial order, and regularization penalty weight value; if underfitting exists, the model complexity is adjusted by at least one of increasing the number of neural network layers, increasing the polynomial order, and adding more feature engineering.

[0095] The adjusted preliminary model is retrained using the training set data, and the validation set is used to evaluate whether the adjusted preliminary model is overfitting or underfitting; if not, an anomaly detection model is obtained.

[0096] Specifically, by obtaining the device information of the vehicle controller, the complexity of the model is reasonably configured to ensure that the model can run under limited computing resources; by training and evaluating the model, it is checked whether the model is overfitting or underfitting, and the model has good generalization ability. By adjusting the complexity of the model, the overfitting or underfitting problem can be solved, and the learning ability and generalization ability of the model can be improved.

[0097] The following is an example.

[0098] Assume that the computing resources of the vehicle controller obtained are as follows: CPU: 4 cores, memory: 2GB

[0099] and storage: 16GB SSD. Based on the computing resources, a model with appropriate complexity is preliminarily matched, for example: input layer: 3 nodes (CPU usage, memory usage, network delay); hidden layer: 2 layers, 10 nodes per layer; output layer: 1 node (indicates whether it is abnormal). Use the training set data to train the preliminary model, and use the validation set to evaluate whether the preliminary model is overfitting or underfitting. Assume that there are the following training set and validation set data: training set size: 1000 records and validation set size: 200 records. After the preliminary training model, evaluate its performance: for example, the accuracy on the validation set is 75%. Due to the low accuracy, it is preliminarily judged that there may be underfitting.

[0100] If underfitting exists, the model complexity is adjusted by increasing the number of neural network layers, increasing the polynomial order, and adding more feature engineering. For example, increase the number of hidden layers: increase the number of hidden layers to 3 layers, with 10 nodes per layer. Retrain the adjusted preliminary model using the training set data. After retraining the adjusted model, evaluate its performance. The accuracy on the validation set has increased to 90%. Since the accuracy has increased significantly and there is no obvious sign of overfitting, it is preliminarily judged that the model has reached the judgment result and obtained an anomaly detection model.

[0101] As a specific implementation of a method for rapid disaster recovery management of a vehicle-mounted controller, judging whether the current threshold needs to be adjusted based on the predicted value and the current threshold includes:

[0102] Compare the predicted value with the current threshold value, and if the ratio of the difference between the predicted value and the current threshold value is greater than the preset ratio and the first difference between the current threshold value and the upper threshold value and the second difference between the current threshold value and the lower threshold value are both less than the preset difference, it is determined that the current threshold value needs to be adjusted;

[0103] After determining that the current threshold value needs to be adjusted, the method further includes: determining a frequency of threshold value adjustment according to a change speed of the current operating parameter; the frequency of threshold value adjustment is less than an upper limit of adjustment frequency;

[0104] The formula for determining the frequency of threshold adjustment based on the change speed of the current operating parameters is: ;in To adjust the frequency cap; ; is the preset parameter change speed, v is the parameter change speed, and k is a constant.

[0105] Specifically, the predicted value is compared with the current threshold. If the ratio of the difference between the predicted value and the current threshold is greater than the preset ratio and the first difference between the current threshold and the upper limit of the threshold, and the second difference between the current threshold and the lower limit of the threshold are both less than the preset difference, it is determined that the current threshold needs to be adjusted. By comparing the gap between the predicted value and the current threshold, and the gap between the current threshold and the upper and lower limits, the system can determine whether the current threshold needs to be adjusted, ensuring that the threshold is adjusted only when necessary, avoiding system instability caused by frequent adjustments. The frequency of threshold adjustment is determined according to the speed of change of the current operating parameters. By determining the frequency of threshold adjustment based on the speed of change of the current operating parameters, the system can better adapt to rapidly changing environments while avoiding excessive adjustments.

[0106] As one implementation method of a fast disaster recovery management method for an on-board controller, an abnormality detection model is started to analyze the abnormality cause and generate an abnormality report, including:

[0107] Start the anomaly detection model of the vehicle controller;

[0108] The collected operating parameters are input into the anomaly detection model, and the anomaly detection model outputs the anomaly cause and probability;

[0109] Generate an anomaly report based on the output of the anomaly detection model; the anomaly report includes: the timestamp of the anomaly occurrence and the current operating parameters and their deviation from the threshold.

[0110] Specifically, by starting the anomaly detection model of the vehicle controller, the operating status of the vehicle controller can be monitored in real time and potential anomalies can be identified. By inputting the collected operating parameters into the anomaly detection model, the model can output the cause of the anomaly and the probability of its occurrence. An anomaly report containing the timestamp of the anomaly, the current operating parameters and their deviation from the threshold is generated, which can provide detailed anomaly information and facilitate subsequent troubleshooting and analysis.

[0111] As one implementation method of a fast disaster recovery management method for an on-board controller, a disaster recovery process is started based on an abnormality report, including:

[0112] Parse information from exception reports;

[0113] Develop disaster recovery strategies based on the abnormal causes and probabilities in abnormal reports;

[0114] Start the disaster recovery process based on the disaster recovery strategy;

[0115] Monitor the execution of the disaster recovery process and adjust the disaster recovery strategy based on the execution status.

[0116] Specifically, by parsing the information in the exception report, the system can obtain the timestamp of the exception, the current operating parameters and their deviation from the threshold, as well as the cause of the exception and its probability. By analyzing the cause of the exception and its probability, the system can formulate a corresponding disaster recovery strategy based on the severity and possibility of the exception. By starting the corresponding disaster recovery process according to the formulated disaster recovery strategy, the abnormal situation can be quickly responded to and the impact of the abnormality on the system can be reduced. By monitoring the execution of the disaster recovery process in real time and adjusting the disaster recovery strategy according to the execution situation, the system can flexibly respond to changing situations. This method can improve the adaptability and effectiveness of the disaster recovery process and ensure that the disaster recovery measures can achieve the best results.

[0117] As one implementation method of a fast disaster recovery management method for a vehicle controller, a disaster recovery strategy is formulated according to the abnormal cause and probability in the abnormal report, including:

[0118] Compare all possible abnormal causes and their probabilities, sort all abnormal causes from high to low according to probability, and identify the abnormal cause with the highest probability;

[0119] Identify disaster recovery measures that can address multiple causes of anomalies;

[0120] Evaluate the feasibility of disaster recovery measures, score each disaster recovery measure, and select the one with the highest score;

[0121] The selected disaster recovery measure is executed and combined with the real-time acquired operation parameters to determine whether the currently selected disaster recovery measure is effective; if not, the next rated disaster recovery measure is selected.

[0122] Specifically, by sorting all possible abnormal causes and their probabilities, the most likely cause of the current abnormality can be quickly identified. By identifying disaster recovery measures that can solve multiple abnormal causes, multiple problems can be solved in one operation, improving the efficiency and effectiveness of disaster recovery measures.

[0123] By evaluating and scoring the disaster recovery measures, the system can select the most feasible disaster recovery measure.

[0124] Monitor the effectiveness of disaster recovery measures in real time and adjust disaster recovery strategies based on the results.

[0125] Assume that the currently generated exception report is as follows: timestamp: XXX; operating parameters: CPU usage: 85%, memory usage: 80% and network delay: 220ms. Deviation: CPU usage deviates by 5%

[0126] Memory usage rate deviates by 5%; network delay deviates by 20ms. Abnormal causes and probabilities: CPU overload: probability 0.75, memory leak: probability 0.60, and network congestion: probability 0.80. According to the probability sorting, the abnormal cause with the highest probability is identified as: network congestion. The system identifies the following disaster recovery measures:

[0127] Measure A: Restart related services or applications to release the occupied memory; Measure B: Switch to the backup network path to relieve the network traffic pressure; Measure C: Shut down non-critical tasks or services to reduce the CPU load; Measure D: Restart the network interface to release network resources. Each disaster recovery measure is evaluated and scored: Measure A: Feasibility score 8; Measure B: Feasibility score 7; Measure C: Feasibility score 9; Measure D: Feasibility score 8. Considering that Measure D has the highest score, the system executes Measure D: Restart the network interface to release network resources. After restarting the network interface, the real-time operating parameters are as follows: CPU usage: 82%, memory usage: 78% and network delay: 205ms. Evaluate the effect of Measure D: The network delay has improved slightly, but it has not yet fully returned to the normal range. The memory usage has decreased slightly, but it is still higher than the normal range. Since Measure D did not completely solve the problem, the system selects the next rated disaster recovery measure, namely Measure C: Shut down non-critical tasks or services to reduce the CPU load. Execute and monitor again. After implementing measure C, the real-time operating parameters are as follows: CPU usage: 75%, memory usage: 70% and network delay: 190ms. Evaluate the effect of measure C: CPU usage and memory usage have both dropped to normal ranges, and network delay is also close to normal ranges. Since measure C effectively solved the abnormal problem, it is confirmed that the system has returned to normal.

[0128] As one implementation of a method for rapid disaster recovery management of a vehicle controller, disaster recovery measures that can solve multiple abnormal causes are identified, including:

[0129] Determine the cause of the anomaly that each disaster recovery measure can resolve;

[0130] Construct a relationship matrix between disaster recovery measures and abnormal causes;

[0131] Based on the elements in the relationship matrix, disaster recovery measures that can solve multiple abnormal causes are identified.

[0132] As one of the implementation methods of a fast disaster recovery management method for an on-board controller, the feasibility of disaster recovery measures is evaluated, including:

[0133] Assess the difficulty of implementing disaster recovery measures ;

[0134] Assess the impact of disaster recovery measures on other parts of the system ;

[0135] Determine the time required to implement disaster recovery measures ;

[0136] Determine the system resources required to implement disaster recovery measures ;

[0137] based on Get a feasibility score ; Where a, b, c and d are coefficients; is the maximum allowed execution time.

[0138] Assume the following disaster recovery measures: Measure A: Restart related services or applications to release occupied memory; Measure B: Switch to an alternate network path to relieve network traffic pressure; Measure C: Shut down non-critical tasks or services to reduce CPU load; Measure D: Restart the network interface to release network resources. Assume the implementation difficulty score (total score 10) is as follows: Measure A: 2; Measure B: 3; Measure C: 4; Measure D: 5. Assume the time required is as follows: Measure A: 5S; Measure B: 10S; Measure C: 3S

[0139] ;Measure D: 8S. Determine the system resources required to implement the disaster recovery measures. Assume that the required system resources are as follows:

[0140] Measure A: 10% CPU, 20MB memory; Measure B: 15% CPU, 30MB memory; Measure C: 5% CPU, 10MB memory; Measure D: 20% CPU, 40MB memory. Assume that the current system available resources are:

[0141] CPU: 20%, memory: 100MB. Coefficients a, b, c, and d represent the weights of implementation difficulty, impact, required time, and required resources, respectively. Assume that the weights are: implementation difficulty coefficient a=0.2; impact coefficient b=0.3; required time coefficient c=0.2; required resource coefficient d=0.3.

[0142] Specifically, by evaluating the difficulty of implementation, the system can understand the difficulty of disaster recovery measures in actual operation. By evaluating the impact of disaster recovery measures on other parts of the system, the system can identify those measures that may have side effects or affect the overall stability of the system. By determining the time required to complete disaster recovery measures, the system can estimate the implementation cycle of the measures. By determining the required system resources, the system can evaluate the feasibility of disaster recovery measures under current resource conditions. By comprehensively evaluating factors such as implementation difficulty, impact, required time and required resources, and giving a comprehensive score, the measure with the highest score is selected, thereby improving the overall effect of disaster recovery measures.

[0143] Reference Figure 2 The present application also provides a vehicle-mounted controller rapid disaster recovery management system, including:

[0144] The first processing module 201 is used to obtain the operating parameters of the vehicle controller in real time; the operating parameters include: CPU usage, memory usage and network delay;

[0145] The second processing module 202 is used to compare the acquired operating parameter with the threshold to determine whether the operating parameter exceeds the threshold;

[0146] The third processing module 203 is used to: when it is determined that the operating parameter exceeds the threshold, mark the vehicle controller as an abnormal state, start the abnormality detection model to analyze the abnormality cause and generate an abnormality report;

[0147] The fourth processing module 204 is used to start a disaster recovery process based on the abnormal report.

[0148] It should be noted that the above embodiments are only used to illustrate the present application and are not intended to limit the technical solutions described in the present application. Although the present application has been described in detail in this specification with reference to the above embodiments, a person of ordinary skill in the art should understand that a person of ordinary skill in the art can still modify or make equivalent substitutions to the present application, and all technical solutions and improvements thereof that do not depart from the spirit and scope of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for rapid disaster recovery management of a vehicle-mounted controller, characterized in that: include: Obtain the operating parameters of the vehicle controller in real time; The operating parameters include: CPU usage, memory usage and network delay; comparing the acquired operating parameter with a threshold value to determine whether the operating parameter exceeds the threshold value; When it is determined that the operating parameters exceed the threshold, the on-board controller is marked as abnormal, the abnormality detection model is started to analyze the cause of the abnormality and generate an abnormality report; Initiate a disaster recovery process based on the abnormal report; The threshold is adjusted dynamically, and the step of adjusting the threshold includes: S21. Obtaining predicted values ​​of future operating parameters based on current operating parameters; S22, judging whether the current threshold needs to be adjusted based on the predicted value and the current threshold; S23. If it is determined that adjustment is required, a new threshold is set based on a threshold setting formula; wherein the threshold setting formula is: ; is the preset upper threshold value; is the preset lower threshold; and are adjustment factors, corresponding to the influence weights of the predicted value and the current threshold respectively; S24, applying the new threshold; Based on the current operating parameters, the predicted values ​​of future operating parameters are obtained, including: S31, selecting a time window of length n; S32, calculating an average value based on the most recent n operating parameters; S33, taking the average value as the predicted value corresponding to the current n operating parameters; S33. Every time a new operating parameter is obtained, the earliest operating parameter in the current time window is removed, and the newly obtained operating parameter is used as the latest operating parameter to obtain n operating parameters in the time window again; return to S32.

2. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 1, characterized in that: The configuration methods of the anomaly detection model include: Obtain device information of the vehicle controller to obtain computing resources of the vehicle controller; Matching the number of layers of the preliminary model based on the computing resources and obtaining the preliminary model; Using the training set data to train the preliminary model, and using the validation set to evaluate whether the preliminary model is overfitting or underfitting; If overfitting exists, the model complexity is adjusted by reducing the number of neural network layers, lowering the polynomial order, or regularization penalty weight value; if underfitting exists, the model complexity is adjusted by increasing the number of neural network layers, increasing the polynomial order, or adding more feature engineering. The adjusted preliminary model is retrained using the training set data, and the adjusted preliminary model is evaluated through the validation set to determine whether it is overfitting or underfitting; if not, the anomaly detection model is obtained.

3. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 2, characterized in that: Determining whether the current threshold needs to be adjusted based on the predicted value and the current threshold includes: Compare the predicted value with the current threshold value, and if the ratio of the difference between the predicted value and the current threshold value is greater than the preset ratio and the first difference between the current threshold value and the upper threshold value and the second difference between the current threshold value and the lower threshold value are both less than the preset difference, it is determined that the current threshold value needs to be adjusted; After determining that the current threshold value needs to be adjusted, the method further includes: determining a frequency of threshold value adjustment according to a change speed of the current operating parameter; the frequency of threshold value adjustment is less than an upper limit of the adjustment frequency; The formula for determining the frequency of threshold adjustment based on the change speed of the current operating parameters is: ;in To adjust the frequency cap; ; is the preset parameter change speed, v is the parameter change speed, and k is a constant.

4. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 3, characterized in that: Start the anomaly detection model to analyze the cause of the anomaly and generate an anomaly report, including: Start the anomaly detection model of the vehicle controller; Inputting the collected operating parameters into the anomaly detection model, the anomaly detection model outputs the anomaly cause and probability; An anomaly report is generated based on the output of the anomaly detection model; the anomaly report includes: a timestamp of the anomaly occurrence and current operating parameters and their deviation from the threshold.

5. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 4, characterized in that: The disaster recovery process is initiated based on the abnormal report, including: Parse information from exception reports; Develop disaster recovery strategies based on the abnormal causes and probabilities in abnormal reports; Initiate a disaster recovery process based on the disaster recovery strategy; Monitor the execution of the disaster recovery process and adjust the disaster recovery strategy based on the execution.

6. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 5, characterized in that: Develop a disaster recovery strategy based on the abnormal causes and probabilities in the abnormality report, including: Compare all possible abnormal causes and their probabilities, sort all abnormal causes from high to low according to probability, and identify the abnormal cause with the highest probability; Identify disaster recovery measures that can address multiple causes of anomalies; Evaluate the feasibility of disaster recovery measures, score each disaster recovery measure, and select the one with the highest score; The selected disaster recovery measure is executed and combined with the real-time acquired operation parameters to determine whether the currently selected disaster recovery measure is effective; if not, the next rated disaster recovery measure is selected.

7. A method for rapid disaster recovery management of a vehicle-mounted controller according to claim 6, characterized in that: Identify disaster recovery measures that can address multiple causes of anomalies, including: Determine the cause of the anomaly that each disaster recovery measure can resolve; Construct a relationship matrix between disaster recovery measures and abnormal causes; Identify disaster recovery measures that can solve multiple abnormal causes based on the elements in the relationship matrix; Evaluate the feasibility of disaster recovery measures, including: Assess the difficulty of implementing disaster recovery measures ; Assess the impact of disaster recovery measures on other parts of the system ; Determine the time required to implement disaster recovery measures ; Determine the system resources required to implement disaster recovery measures ; based on Get a feasibility score ; Where a, b, c and d are coefficients; is the maximum allowed execution time.

8. A vehicle-mounted controller rapid disaster recovery system, characterized in that: include: The first processing module is used to: obtain the operating parameters of the vehicle controller in real time; The operating parameters include: CPU usage, memory usage and network delay; A second processing module is used to: compare the acquired operating parameter with the threshold to determine whether the operating parameter exceeds the threshold; The third processing module is used to: when it is determined that the operating parameter exceeds the threshold, mark the vehicle controller as an abnormal state, start the abnormality detection model to analyze the abnormality cause and generate an abnormality report; A fourth processing module is used to: start a disaster recovery process based on the abnormal report; The threshold is adjusted dynamically, and the step of adjusting the threshold includes: S21. Obtaining predicted values ​​of future operating parameters based on current operating parameters; S22, judging whether the current threshold needs to be adjusted based on the predicted value and the current threshold; S23. If it is determined that adjustment is required, a new threshold is set based on a threshold setting formula; wherein the threshold setting formula is: ; is the preset upper threshold value; is the preset lower threshold; and are adjustment factors, corresponding to the influence weights of the predicted value and the current threshold respectively; S24, applying the new threshold; Based on the current operating parameters, the predicted values ​​of future operating parameters are obtained, including: S31, selecting a time window of length n; S32, calculating an average value based on the most recent n operating parameters; S33, taking the average value as the predicted value corresponding to the current n operating parameters; S33. Every time a new operating parameter is obtained, the earliest operating parameter in the current time window is removed, and the newly obtained operating parameter is used as the latest operating parameter to obtain n operating parameters in the time window again; return to S32.

Images