Electric vehicle central control system local abnormity safety protection method and device, vehicle and storage medium

Abstract

The invention provides a local abnormity safety protection method for an electric vehicle central control system, and belongs to the technical field of vehicle safety control, and the method comprises the steps: obtaining various local state information of a vehicle in real time, carrying out the fusion processing and risk quantification through a predefined risk evaluation model, and obtaining a comprehensive risk score; determining whether the comprehensive risk score reaches a first risk threshold, and determining whether to generate and execute a first security policy, such as limiting power output of the vehicle; and judging whether the comprehensive risk score reaches a second risk threshold higher than the first risk threshold, and determining whether to generate and execute a second security policy, such as cutting off motor power and triggering an alarm, so that the system can automatically trigger a corresponding grading security policy based on different risk intervals in which the score is located, thereby improving the safety of the system without cloud intervention. Localized autonomous safety protection from warning to forced forbidding is realized.

Description

Technical Field

[0001] This invention relates to the field of vehicle safety control technology, and in particular to a method, device, vehicle, and storage medium for local anomaly protection of an electric vehicle central control system. Background Technology

[0002] With the increasing popularity of shared electric bikes and smart electric motorcycles, the functions of vehicle central control systems are becoming more and more complex, including battery management, anti-theft, fault diagnosis, and driving access control. Currently, many security strategies rely on cloud servers for decision-making, enabling remote control of vehicle functions.

[0003] In existing technologies, such as the "method, device, and system for controlling vehicle functions" disclosed in CN119342476A, the solution uses a vehicle cloud server to determine whether the vehicle's real-time location is within a preset whitelist area, and combines this with network communication status to control the activation and deactivation of vehicle application functions. This method mainly addresses the management and control of cross-regional vehicle sales, and its core technology lies in compliance judgment based on location information. However, this existing technology has the following obvious drawbacks: 1. Lack of comprehensive risk assessment of the vehicle's physical condition: Focusing only on location compliance and network connectivity, the system completely ignores the monitoring and assessment of the actual operating status of critical components such as the battery, motor, and load. When the vehicle is within a compliant area but experiences serious safety hazards such as battery thermal runaway or motor overheating, the system cannot respond in a timely manner.

[0004] 2. The security strategy is simplistic and outdated: It adopts a simple binary judgment logic (in / out of the whitelist area, communication is normal / abnormal), which cannot quantify and classify risks. This results in security responses that are either too lenient (only warning) or too strict (directly disabling), lacking a graded control strategy based on risk level.

[0005] 3. Over-reliance on cloud-based decision-making: All judgment logic is concentrated on the cloud server. When the network is interrupted or communication is abnormal, the vehicle lacks autonomous safety decision-making capabilities, resulting in obvious safety blind spots.

[0006] 4. Inability to handle complex local anomalies: This solution is completely incapable of detecting and handling local anomalies such as sensor failures, operational logic conflicts, and component aging.

[0007] Therefore, there is an urgent need in this field for an intelligent, comprehensive, and hierarchical anomaly protection solution that can be implemented locally on the vehicle in the event of network outages or partial system anomalies. This solution should be capable of real-time risk assessment based on multi-dimensional state information and executing corresponding hierarchical security strategies.

[0008] The embodiments of the present invention are improvements made to solve the above problems. Summary of the Invention

[0009] In view of this, the purpose of this invention is to provide a local anomaly protection scheme for the central control system of electric vehicles, which solves the problems of excessive reliance on cloud decision-making, lack of comprehensive assessment of the vehicle's status, and single and lagging safety response mechanism in the existing technology, and realizes localized, intelligent and hierarchical safety protection in the event of network outage or system anomaly.

[0010] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: Firstly, this invention provides a method for local anomaly protection in an electric vehicle central control system. This method acquires various local vehicle status information in real time, such as battery status information, motor status information, load status information, and operation logic status information. Based on these information, a predefined risk assessment model is used for fusion processing and risk quantification to obtain a comprehensive risk score. The predefined risk assessment model is used to fuse and assess the risk of multi-source heterogeneous vehicle status data. Its implementation methods include, but are not limited to, weighted summation models, fuzzy logic-based inference models, neural network-based prediction models, or decision tree-based classification models. Those skilled in the art can select an appropriate model type according to actual needs.

[0011] In response to the comprehensive risk score reaching a first risk threshold, a first safety policy is generated and executed, which includes limiting the vehicle's power output. In response to the comprehensive risk score reaching a second risk threshold higher than the first risk threshold, a second safety policy is generated and executed, which includes cutting off the motor power and triggering an alarm. To this end, the system can automatically trigger corresponding graded safety policies based on the different risk ranges in which the score is located, thereby achieving localized autonomous safety protection from warning to mandatory prohibition without cloud intervention.

[0012] In a second aspect, the present invention provides an apparatus corresponding to the above method, which includes an information acquisition module for acquiring battery status information, motor status information, load status information and operation logic status information of a vehicle. The risk assessment module used for risk assessment is configured to perform data fusion processing and risk quantification based on the battery status information, motor status information, load status information and operation logic status information, and obtain a comprehensive risk score through a predefined risk assessment model. The safety policy execution module for executing the safety policy is configured to: generate and execute a first safety policy in response to the above-mentioned comprehensive risk score reaching a first risk threshold, the first safety policy including limiting vehicle power output; and generate and execute a second safety policy in response to the above-mentioned comprehensive risk score reaching a second risk threshold higher than the above-mentioned first risk threshold, the second safety policy including cutting off motor power and triggering an alarm.

[0013] Thirdly, the present invention provides a vehicle comprising the above-described device.

[0014] Fourthly, the present invention provides a storage medium storing a computer program that, when executed, can implement the above-described method.

[0015] The technical solution of this invention can bring the following beneficial effects: it realizes local autonomous safety decision-making of vehicles in the event of network outage, communication abnormality or partial abnormality of central control software, improves the accuracy and reliability of risk judgment by fusing multi-dimensional physical state information into a quantifiable risk indicator, realizes the closed loop of automated technology from risk perception to safe execution, avoids malfunctions caused by false alarms from a single sensor, and significantly improves the safety and reliability of the vehicle itself by taking into account user experience while ensuring safety through a hierarchical response mechanism.

[0016] Furthermore, the above summary does not enumerate all the features required for embodiments of the present invention, and other combinations of these feature groups may also constitute embodiments of the present invention. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the accompanying drawings used in the embodiments of the present invention or the background art will be described below.

[0018] Figure 1 This is a flowchart of a local anomaly protection method for an electric vehicle central control system provided in an embodiment of the present invention.

[0019] Figure 2 This is a detailed flowchart of the risk assessment steps provided in an embodiment of the present invention.

[0020] Figure 3 This is a structural block diagram of a local anomaly safety protection device for an electric vehicle central control system provided in an embodiment of the present invention.

[0021] Figure 4 This is a schematic diagram of the hardware structure of a vehicle provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the technical means, creative features, objectives and effects of the embodiments of the present invention easier to understand, the embodiments of the present invention are further described below in conjunction with the figures and specific embodiments. It should be understood that the specific embodiments described herein are merely for explaining the embodiments of the present invention and are not intended to limit the embodiments of the present invention.

[0023] In the description of the embodiments of the present invention, it should be noted that, unless otherwise expressly specified and limited, for those skilled in the art, the terms "first," "second," "third," "fourth," etc. (if present) are used to distinguish objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "first," "second," "third," "fourth," etc. (if present) are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. The terms "comprising" and "having," and any variations thereof, in the specification and claims are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. The following embodiments are used to illustrate the present invention, but are not intended to limit the scope of the present invention.

[0025] In one feasible implementation, refer to Figure 1 This document illustrates the flowchart of a local anomaly protection method for an electric vehicle central control system according to an embodiment of the present invention. The method can be executed by the vehicle's onboard control unit and includes the following steps: S101: System initialization and data acquisition.

[0026] After the vehicle is powered on, the onboard control unit completes a self-test. Subsequently, the system collects (i.e., "reads" and "detects") various status information at fixed intervals (e.g., 50ms) through corresponding sensors and controllers, including but not limited to: Battery status information: Reads battery voltage, current, and temperature data from the battery management system.

[0027] Motor status information: Read motor temperature and drive abnormality flags from the motor controller.

[0028] Load status information: Load data is detected by pressure sensors under the seat cushion.

[0029] Operation logic status information: Listen to the signals from the brake and accelerator sensors and calculate the failure rate of sensor data reading.

[0030] This data is stored in a circular buffer in real time for subsequent analysis.

[0031] For example, in a specific implementation scenario, after system initialization, the system first reads the battery voltage as 39.2V, current as 12.5A, and temperature as 45°C from the BMS; the motor temperature is obtained from the motor controller as 65°C, indicating no drive abnormalities; the pressure sensor detects a seat cushion load of 75kg; simultaneously, it monitors that the brake and throttle sensors each failed to read once within the last 10 sampling periods, with no logical conflict signals. All data is stored in a circular buffer with timestamps, the buffer size being 100 sets of data, with new data overwriting the oldest data to ensure data real-time performance.

[0032] This setup, by periodically collecting multi-source heterogeneous vehicle status data and storing it in a circular buffer, provides a real-time, continuous, and reliable data foundation for subsequent risk assessments, ensuring the timeliness and accuracy of safety decisions. At the same time, the circular buffer design prevents data overflow and optimizes memory usage.

[0033] Based on the battery status information, motor status information, load status information, and operation logic status information collected by the aforementioned sensors and controllers, a predefined risk assessment model is used for calculation. This predefined risk assessment model is used to fuse and assess the risks of multi-source heterogeneous vehicle status data. Its implementation methods include, but are not limited to, weighted summation models, fuzzy logic-based inference models, neural network-based prediction models, or decision tree-based classification models. Those skilled in the art can choose the appropriate model type according to actual needs. In this application embodiment, a weighted summation model is preferred for calculation, and the calculation method is as follows: S102: Risk assessment calculation.

[0034] The system inputs the data collected in S101 into a predefined risk assessment model to calculate a comprehensive risk score. For example... Figure 2 As shown, this process can be further refined as follows: S201: Calculate the battery risk sub-score (BMS_risk).

[0035] Specifically, the system detects battery voltage (V), current (I), and temperature (T). In response to any of these parameters exceeding their corresponding safe range, the battery risk sub-score is set to the value representing the highest risk. For example, if V < 35V or V > 43V, or I > 25A, or T > 80°C, then BMS_risk is directly set to 100. Otherwise, based on the voltage, current, and temperature values, voltage, current, and temperature scores are calculated using a linear mapping method. These scores are then weighted to obtain the battery risk sub-score. For instance, score_V, score_I, and score_T are calculated using a linear mapping function (e.g., linearly mapping voltage between 35V-36V and 42V-43V to 0-60 points), and then calculated according to the formula BMS_risk = round(0.4*score_V + 0.35*score_I + 0.25*score_T).

[0036] For example, in a specific implementation scenario, the general formula for linear interpolation is: y = y1 + ((x - x1) *(y2 - y1) / (x2 - x1)), where: x is the known input value, y is the output value (risk score) we want to calculate, (x1, y1) is the lower limit of the interval, and (x2, y2) is the upper limit of the interval. The system reads that the current battery voltage V = 41.5V (within the safe range), current I = 18A (safe), and temperature T = 52°C (safe). According to the preset linear mapping relationship: voltage in the 40V-42V range is mapped to 0-30 points, and in this example, 41.5V is mapped to a score of 10 points; current in the 15A-20A range is mapped to 0-25 points, and 18A is mapped to a score of 12 points; temperature in the 45°C-55°C range is mapped to 0-20 points, and 52°C is mapped to a score of 14 points. Substituting into the weighted formula: BMS_risk = round(0.4* 10 + 0.35 * 12 + 0.25 *14) = round(4 + 4.2 + 3.5) = 12. This low score indicates that the current battery condition is good, no veto item has been triggered, and the weighted calculation shows it is at a low risk level.

[0037] This setup, which combines a "one-vote veto" system with weighted scoring to assess battery risk, can provide an instantaneous and most severe response to extreme dangerous situations (such as short circuits or precursors to thermal runaway) and can also quantitatively assess critical abnormal states. This avoids misjudgments caused by slight fluctuations in a single parameter and significantly improves the intelligence and reliability of battery safety management.

[0038] S202: Calculate the motor risk sub-score (Motor_risk).

[0039] The system monitors the motor temperature (Tm) and controller error signals. If the controller reports an error, Motor_risk is directly set to 100. Otherwise, the temperature score score_Tm is calculated (e.g., 70°C-80°C linearly mapped to 0-80 points), and then calculated using the formula Motor_risk = round(0.6*score_Tm + 0.4*score_ctrl), where score_ctrl is assigned a value based on the severity of the error.

[0040] For example, in a specific implementation scenario, the system detects a motor temperature Tm = 73°C, and the motor controller reports no error signal (score_ctrl = 0). According to the preset linear mapping relationship (using S201: the general formula for linear interpolation in calculating the battery risk sub-score): temperatures in the 70°C-80°C range are linearly mapped to a score of 0-80, and 73°C scores 24 points. Substituting into the weighted formula: Motor_risk = round(0.6*24 + 0.4*0) = round(14.4 + 0) = 14. This score is relatively low, indicating that although the motor currently has a certain temperature rise, it is still within a controllable range, and the control system is working normally. Overall, the assessment is a low-risk state.

[0041] This setup combines the motor hardware status (temperature) with the control system status (errors) for risk assessment. When the control system itself malfunctions, it is directly identified as high-risk, ensuring that safety is prioritized and preventing vehicle loss of control even if the control logic may fail.

[0042] S203: Calculate the load risk sub-score (Load_risk).

[0043] The system detects the seat pressure (P). If P > 100kg, Load_risk is directly set to 100. Otherwise, Load_risk is calculated through a linear mapping (e.g., 80kg-100kg mapped to 0-70).

[0044] For example, in a specific implementation scenario, the system detects a current load P=88kg via a seat pressure sensor. Based on a preset linear mapping relationship, the load is within the 80kg-100kg range, and the score is calculated using the linear interpolation formula: Score = (P-80) * (70-0) / (100-80). Substituting P=88kg into the formula: Score = (88-80) * 70 / 20 = 28. Since 88kg does not exceed the 100kg threshold, it does not trigger a "veto," therefore Load_risk = 28. This score indicates that the vehicle is under moderate load; although not overloaded, it exceeds the normal weight for a single rider, and the system incorporates this as a risk factor into the comprehensive assessment.

[0045] By detecting loads, illegal overloading or multiple riders can be effectively identified and prohibited. This not only avoids structural and stability risks to vehicles caused by overloading, but also complies with the operation and management standards for shared electric vehicles and other scenarios, achieving a balance between safety and management.

[0046] S204: Calculate the operational logic risk sub-score (Control_risk).

[0047] The system detects the sensor data read failure rate. Specifically, it calculates the sensor read failure rate (fail%) and determines whether the brake and accelerator signals are simultaneously high (logical conflict). Based on the read failure rate and the presence or absence of the logical conflict, the system calculates the operational logic risk sub-score using the formula Control_risk = round(0.3*fail +0.2*conflict), where conflict is 100 when a logical conflict occurs.

[0048] For example, in a specific implementation scenario, the system counted 5 sensor data reading failures in the last 100 sampling periods, resulting in a failure rate of 5%. Simultaneously, both brake and accelerator signals were detected as high in this period, indicating a logical conflict (conflict = 100). Substituting into the calculation formula: Control_risk = round(0.3 * 5 + 0.2 * 100) = round(1.5 + 20) = 22. This score indicates that although the sensor reading stability is acceptable, the system still determines a significant operational logic risk due to a serious operational logic conflict (such as the user potentially pressing the brake and accelerator simultaneously).

[0049] By monitoring the health status of sensors and the rationality of operating signal logic, potential risks such as abnormal hardware connections, sensor aging, or user misoperation (such as pressing the brake and accelerator pedals simultaneously) can be effectively identified, improving the system's fault tolerance to hardware and software failures and its ability to intervene in abnormal operations.

[0050] S205: Calculate the overall risk score (RiskScore).

[0051] The weighted sum of the above battery risk sub-score, motor risk sub-score, load risk sub-score, and operation logic risk sub-score yields the comprehensive risk score: RiskScore = 0.4*BMS_risk + 0.3*Motor_risk +0.2*Load_risk + 0.1*Control_risk.

[0052] For example, following the previous steps, the following values ​​have been calculated: BMS_risk = 12 (low battery risk), Motor_risk = 14 (low motor risk), Load_risk = 28 (medium load risk), and Control_risk = 22 (medium operating logic risk). Substituting these values ​​into the comprehensive risk score formula: RiskScore = 0.4*12 + 0.3*14 + 0.2*28 + 0.1*22 = 4.8 + 4.2 + 5.6 + 2.2 = 16.8, which is rounded to 17. The first risk threshold (e.g., 30) and the second risk threshold (e.g., 60) are pre-calibrated by the system based on vehicle safety specifications and a large amount of test data. Since the current comprehensive risk score (17) is much lower than the first risk threshold (30), the system determines that the vehicle is currently in a safe state and maintains normal operation of all functions.

[0053] The weighted fusion algorithm organically unifies the four independent risk assessments into a single comprehensive risk index. This design allows for the allocation of different weights based on the importance of different risk sources (e.g., battery and motor risks have the highest weights), making the final comprehensive score more scientific and comprehensive in reflecting the overall safety status of the vehicle, and providing an accurate and reliable basis for subsequent classification decisions.

[0054] In response to whether the comprehensive risk score reaches a first risk threshold, the system determines whether to generate and execute a first safety strategy, which includes limiting vehicle power output; in response to whether the comprehensive risk score reaches a second risk threshold higher than the first risk threshold, the system determines whether to generate and execute a second safety strategy, which includes cutting off motor power and triggering an alarm.

[0055] S103: Implementation of hierarchical security policies.

[0056] The system responds to the calculated RiskScore and executes different security policies: If RiskScore < 30, the vehicle is being ridden normally.

[0057] If 30 ≤ RiskScore < 60, the first safety strategy is implemented: a warning is issued by short beeping of the buzzer and display on the screen, and the maximum output power of the motor can be selectively limited.

[0058] If the RiskScore is ≥ 60, the second safety strategy is implemented: immediately cut off the motor power, the buzzer will sound continuously, and detailed warning information will be displayed on the screen.

[0059] In a specific implementation scenario, let's assume three typical scenarios: Scenario A (Low Risk): As in the above S205 embodiment, when the comprehensive risk score RiskScore is 17 (lower than the first risk threshold of 30), the system does not trigger any active safety restrictions, the vehicle remains in normal riding condition, and the user is unaware of it. Scenario B (Medium Risk): Assuming that the calculated RiskScore is 45 under a certain state (between 30 and 60), the system immediately executes the first safety strategy: the buzzer emits an intermittent "beep-beep-beep" alarm, the dashboard displays "Risk Warning, Please Ride Safely", and at the same time the motor controller limits the maximum output power to 60% of the normal, and the vehicle enters speed-limited mode.

[0060] Scenario C (High Risk): Assuming a sudden battery failure causes the RiskScore to spike to 72 (above the second risk threshold of 60), the system immediately executes the strictest second safety strategy: instantly cutting off the motor power output, emitting a long alarm, displaying a warning message on the dashboard that reads "Serious malfunction, please stop immediately!", and forcing the vehicle to a safe stop.

[0061] These three scenarios together illustrate how the system implements tiered and intelligent security responses based on quantified risk levels.

[0062] A tiered response system based on a quantitative comprehensive risk score overcomes the drawbacks of traditional "one-size-fits-all" protection. Warnings and speed limits are issued for medium-risk situations, alerting users while ensuring a basic riding experience; high-risk situations are addressed with decisive and strongest braking measures. This tiered safety strategy significantly enhances the user experience and system friendliness while ensuring personal and vehicle safety.

[0063] In one feasible implementation, refer to Figure 3 The illustration shows an embodiment of an apparatus 300 for implementing the above method. The apparatus includes: The information acquisition module 310 is configured to execute step S101 to collect various status information, specifically, to acquire the vehicle's battery status information, motor status information, load status information, and operation logic status information.

[0064] The risk assessment module 320 is configured to execute step S102, calculating a comprehensive risk score. Specifically, it is configured to perform the calculation based on the aforementioned battery status information, motor status information, load status information, and operating logic status information, using a predefined risk assessment model. It may further include a battery risk assessment unit 321, a motor risk assessment unit 322, a load risk assessment unit 323, an operating logic risk assessment unit 324, and a weighted calculation unit 325.

[0065] The safety policy execution module 330 is configured to execute step S103, which executes a graded policy based on the score. Specifically, in response to the comprehensive risk score reaching a first risk threshold, a first safety policy is generated and executed, which includes limiting the vehicle's power output; and in response to the comprehensive risk score reaching a second risk threshold higher than the first risk threshold, a second safety policy is generated and executed, which includes cutting off the motor power and triggering an alarm.

[0066] In this embodiment, the virtual device modularizes the process flow, clearly defining the boundaries and collaborative relationships of each functional module. This architecture not only facilitates system implementation, testing, and maintenance but also provides a clear logical framework for software deployment on the in-vehicle computing platform, ensuring the engineering feasibility of the solution.

[0067] In another feasible implementation, refer to Figure 4 The diagram illustrates the hardware architecture of a vehicle 400 including the aforementioned device 300. The vehicle 400 includes: a processor 410, a memory 420 (for storing programs and data), a battery management system 430, a motor controller 440, a pressure sensor 450, a brake / accelerator sensor 460, an alarm device 470 (buzzer / screen), and a communication module 480. A computer-readable storage medium is provided in the vehicle, on which a computer program is stored. When the processor 410 executes the program stored in the memory 420, the aforementioned method is implemented.

[0068] This embodiment clarifies the hardware carrier on which the invention can operate, demonstrating that it does not rely on specific dedicated hardware and can be implemented by upgrading the existing vehicle hardware system through software. This greatly reduces deployment costs and application barriers, and is conducive to the rapid promotion and industrial application of the technology.

[0069] It should be noted that the weighting coefficients, thresholds, linear mapping intervals, etc. mentioned above can all be calibrated according to specific vehicle models and safety requirements. Different embodiments may use different values, which does not affect the scope of protection of this invention.

[0070] It should be understood that the terms "one embodiment," "an embodiment," "a feasible implementation," or "some implementations" used throughout the specification mean that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of the present invention. Therefore, "one embodiment," "an embodiment," "a feasible implementation," or "some implementations" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Those skilled in the art should also recognize that the embodiments described in the specification are optional embodiments, and the actions and modules involved are not necessarily essential to the embodiments of the present invention.

[0071] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for local anomaly protection in an electric vehicle central control system, characterized in that, Includes the following steps: Acquire various status information of the vehicle, including battery status information, motor status information, load status information, and operation logic status information; Based on the battery status information, motor status information, load status information and operation logic status information, a comprehensive risk score is obtained by fusing and quantifying the risk through a predefined risk assessment model. In response to the comprehensive risk score reaching a first risk threshold, a first safety strategy is generated and executed, the first safety strategy including limiting vehicle power output; In response to the comprehensive risk score reaching a second risk threshold higher than the first risk threshold, a second safety policy is generated and executed, the second safety policy including cutting off motor power and triggering an alarm.

2. The method according to claim 1, characterized in that, The process involves fusing and quantifying multiple state information sources using a predefined risk assessment model to obtain a comprehensive risk score, including: Calculate the battery risk sub-score based on the battery status information; Calculate the motor risk sub-score based on the motor status information; Calculate the load risk sub-score based on the load status information; Calculate the operation logic risk sub-score based on the operation logic state information; Based on the battery risk sub-score, the motor risk sub-score, the load risk sub-score, and the operation logic risk sub-score, the comprehensive risk score is obtained through a data fusion strategy.

3. The method according to claim 2, characterized in that, Based on the battery state information, a battery risk sub-score is calculated, including: Detect the battery's voltage, current, and temperature; In response to any of the voltage, current or temperature parameters exceeding their corresponding safe range, the battery risk sub-score is set to a value characterizing the highest risk. Otherwise, based on the values ​​of voltage, current and temperature, voltage score, current score and temperature score are calculated respectively through linear mapping, and the voltage score, current score and temperature score are fused to obtain the battery risk sub-score.

4. The method according to claim 2, characterized in that, The calculation of the operation logic risk sub-score based on the operation logic state information includes: Detect the failure rate of sensor data reading; Detect whether there is a logical conflict between the brake signal and the accelerator signal; Based on the read failure rate and the presence or absence of the logical conflict, the operation logic risk sub-score is calculated.

5. The method according to claim 1, characterized in that, The method further includes: The battery status information, motor status information, load status information, and operation logic status information are continuously collected at a preset period and stored in a circular buffer.

6. A local anomaly protection device for an electric vehicle central control system, characterized in that, include: The information acquisition module is configured to acquire the vehicle's battery status information, motor status information, load status information, and operation logic status information. The risk assessment module is configured to perform fusion processing and risk quantification based on the battery status information, motor status information, load status information and operation logic status information through a predefined risk assessment model to obtain a comprehensive risk score. The safety policy execution module is configured to: generate and execute a first safety policy in response to the comprehensive risk score reaching a first risk threshold, wherein the first safety policy includes limiting vehicle power output; In addition, in response to the comprehensive risk score reaching a second risk threshold higher than the first risk threshold, a second safety policy is generated and executed, the second safety policy including cutting off motor power and triggering an alarm.

7. The apparatus according to claim 6, characterized in that, The risk assessment module includes: The battery risk assessment unit is configured to calculate a battery risk sub-score based on the battery state information; The motor risk assessment unit is configured to calculate a motor risk sub-score based on the motor status information; The load risk assessment unit is configured to calculate a load risk sub-score based on the load status information; The operation logic risk assessment unit is configured to calculate an operation logic risk sub-score based on the operation logic state information. The data fusion unit is configured to obtain the comprehensive risk score by using a data fusion strategy on the battery risk sub-score, the motor risk sub-score, the load risk sub-score, and the operation logic risk sub-score.

8. The apparatus according to claim 6, characterized in that, The information acquisition module is further configured to continuously collect the various status information at a preset period and store it in a circular buffer.

9. A vehicle, characterized in that, include: The local anomaly protection device for the electric vehicle central control system as described in any one of claims 6 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 5.

Images