Battery management system interrupt processing method, battery management system, and electric device

Abstract

The application discloses a battery management system interrupt processing method, a battery management system and a power utilization device. The method comprises the following steps: obtaining a target interrupt, wherein the target interrupt is at least one interrupt waiting for processing by the battery management system; obtaining an interrupt processing program of the target interrupt, an interrupt source triggering the target interrupt, and an access request of a system resource related to the target interrupt; and processing the target interrupt in the case that the interrupt processing program, the interrupt source and the access request satisfy a preset check condition. The application can enhance the safety of interrupt processing.

Description

Technical Field

[0001] This application relates to the field of batteries, and in particular to an interruption handling method for a battery management system, a battery management system, and an electrical device. Background Technology

[0002] In the field of battery management technology for new energy batteries, the battery management system needs to handle various interrupts. Interrupts are triggered by hardware or software anomalies. For example, excessively high battery temperature will trigger an over-temperature protection interrupt, requiring the battery management system to suspend its currently executing tasks and instead call the interrupt handler to process the interrupt. The interrupt handler is a program specifically designed by the operating system to handle interrupt events and is responsible for processing these events.

[0003] Currently, the main method for handling interrupts is to find the corresponding interrupt handler and then execute that interrupt handler to process the interrupt.

[0004] However, the current interrupt handling method has low security. Summary of the Invention

[0005] This application provides an interrupt handling method for a battery management system, a battery management system, and an electrical device, which can improve the security of interrupt handling.

[0006] In a first aspect, this application provides an interrupt handling method for a battery management system, comprising:

[0007] Acquire a target interrupt, wherein the target interrupt is at least one interrupt waiting to be processed by the battery management system;

[0008] Obtain the interrupt handler for the target interrupt, the interrupt source that triggered the target interrupt, and the access requests for system resources related to the target interrupt;

[0009] The target interrupt is processed if the interrupt handler, the interrupt source, and the access request meet the verification conditions.

[0010] In this solution, by verifying the access permissions of interrupt handlers, interrupt sources, and interrupt-related resources, the security of the target interrupt handling process can be improved, and the situation of invalid interrupt handlers can be avoided.

[0011] In one implementation of the first aspect, acquiring the target interrupt includes:

[0012] Obtain the preset priority for each interrupt;

[0013] The highest priority interrupt is selected from the at least one interrupt and determined as the target interrupt. The high-priority interrupt is processed by the battery management system before the low-priority interrupt.

[0014] In this scheme, by selecting high-priority interrupts as target interrupts, priority processing of high-priority interrupts can be achieved, improving the flexibility of interrupt handling.

[0015] In another implementation of the first aspect, obtaining the preset priority of each interrupt includes:

[0016] Obtain the type of each interrupt in the battery management system and the number of times the interrupt is triggered within a preset time period;

[0017] The preset priority of the interrupt is determined based on at least one of the interrupt type and the number of triggers.

[0018] In this solution, by prioritizing interrupts, the battery management system can be ensured to respond promptly to critical interrupt events while avoiding excessive impact of non-critical interrupt events on system performance. This helps improve system responsiveness and stability, thereby ensuring the safe and efficient operation of the battery.

[0019] In another implementation of the first aspect, determining the preset priority of the interrupt based on the type of interrupt includes:

[0020] Obtain a first priority and a second priority, where the first priority is higher than the second priority;

[0021] In the case of the interrupt being a first type of interrupt, the first priority is determined as the preset priority of the interrupt; wherein, the first type of interrupt includes at least one of battery over-temperature interrupt, battery overcharge interrupt, and battery over-discharge interrupt;

[0022] In the case that the interrupt is of the second type, the second priority is determined as the preset priority of the interrupt; wherein, the second type of interrupt includes at least one of log recording interrupt, status update interrupt and system software upgrade interrupt.

[0023] In this solution, by classifying interrupts into a first-type interrupt with higher importance and a second-type interrupt with lower importance, the operating system can prioritize the processing of high-priority interrupts, avoiding delays in processing battery overheating interrupts, battery overcharging interrupts, and battery over-discharging interrupts that affect battery safety. At the same time, it also avoids the excessive impact of non-critical interrupts such as log recording interrupts, status update interrupts, and system software upgrade interrupts on system performance.

[0024] In another implementation of the first aspect, acquiring the target interrupt includes:

[0025] Obtain the priority of the first interrupt, which is the interrupt being processed by the battery management system;

[0026] The interrupt with a higher priority than the first interrupt is selected from the at least one interrupt and determined as the target interrupt.

[0027] In this solution, the interrupt nesting mechanism enables the battery management system to respond promptly to various sudden high-priority interrupts, ensuring timely response to high-priority interrupts, guaranteeing battery safety and stable system operation, and improving the battery management system's ability to handle sudden emergency events.

[0028] In another implementation of the first aspect, determining that the interrupt source meets a preset verification condition includes:

[0029] Obtain the interrupt vector number corresponding to the target interrupt, the stored data in the target register, and the preset interrupt whitelist. The interrupt vector number is used to identify the interrupt source, the target register is the register of the hardware device that triggered the target interrupt, and the preset interrupt whitelist includes at least one interrupt source.

[0030] If the interrupt source of the target interrupt is in the preset interrupt whitelist, the interrupt source identified by the interrupt vector number corresponding to the target interrupt matches the interrupt source of the target interrupt, and the stored data matches the preset fault data, then the interrupt source is determined to meet the preset verification conditions.

[0031] In this solution, by detecting the legitimacy of the interrupt source, determining whether the interrupt source is in the preset interrupt whitelist, whether there is a correspondence between the interrupt vector number and the interrupt source, and whether the stored data matches the preset fault data, the security of the interrupt handling process can be ensured and the stability of the battery management system can be guaranteed.

[0032] In another implementation of the first aspect, determining that the interrupt handler satisfies a preset verification condition includes:

[0033] Obtain the preset mapping relationship and the program code of the interrupt handler, wherein the preset mapping relationship is used to characterize the mapping relationship between the interrupt handler and the interrupt vector number;

[0034] Based on the preset mapping relationship, determine whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt;

[0035] If there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, and the program code of the interrupt handler has not been tampered with, then the interrupt handler is determined to meet the preset verification condition.

[0036] In this solution, by verifying whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, and at the same time verifying whether the program code in the interrupt handler has been tampered with, interrupt security can be guaranteed, and the stability and reliability of the battery management system can be further improved.

[0037] In another implementation of the first aspect, determining that the interrupt handler satisfies a preset verification condition includes:

[0038] Obtain the target data accessed by the interrupt handler and the target memory region accessed by the interrupt handler;

[0039] If the target data is the same as the preset data and the target memory region is the same as the preset region, the interrupt handler is determined to meet the preset verification conditions.

[0040] In this solution, by checking the data access and memory access of the interrupt handler, it is possible to prevent the interrupt handler from accessing illegal memory addresses or out-of-bounds access, ensuring that the interrupt handler runs in a safe environment, thereby maintaining the reliability and security of the system.

[0041] In another implementation of the first aspect, determining that an access request for system resources related to the target interrupt meets a preset verification condition includes:

[0042] Obtain a pre-created resource access control list and the access permissions of the access request, wherein the resource access control list includes at least one resource access subject and the access permissions corresponding to the resource access subject;

[0043] If the access permission for the access request exists in the resource access control list, it is determined that the access request meets the preset verification conditions.

[0044] In this solution, by verifying the access permissions of access requests, the code and data in interrupt-related resources can be protected, preventing unauthorized access or malicious modification of interrupt settings and handlers, thereby further improving interrupt security.

[0045] Another implementation of the first aspect also includes:

[0046] The interrupt response time, processing time, and system performance of the battery management system when processing the target interrupt are obtained; wherein, the interrupt response time is the duration between the first moment when the target interrupt is triggered and the second moment when the battery management system begins processing the target interrupt, the processing time is the time consumed from the start of processing the target interrupt to the completion of processing the target interrupt, and the system performance includes at least one of processor utilization and memory utilization;

[0047] The priority of the target interrupt is adjusted based on at least one of the interrupt response time, the processing time, and the system performance.

[0048] In this solution, by focusing on the interrupt response time, processing time, and system performance of the battery management system during the interrupt handling process, and dynamically adjusting the priority of each interrupt, the flexibility of interrupt handling can be improved, which helps to improve the responsiveness and stability of the battery management system and ensure the safe and efficient operation of the battery.

[0049] In another implementation of the first aspect, adjusting the priority of the target interrupt based on the interrupt response time includes:

[0050] If the interrupt response time is greater than the preset response time, the priority of the target interrupt is increased to a level greater than the preset priority of the target interrupt.

[0051] If the system performance is higher than a preset performance threshold or the processing time is longer than a preset processing time, the priority of the target interrupt will be lowered to less than the preset priority.

[0052] Secondly, this application provides a battery management system, including:

[0053] An interrupt acquisition module is used to acquire a target interrupt, wherein the target interrupt is any one of at least one interrupt waiting to be processed by the battery management system;

[0054] The data acquisition module is used to acquire the interrupt handler of the target interrupt, the interrupt source that triggers the target interrupt, and the access requests for system resources related to the target interrupt;

[0055] An interrupt handling module is used to process the target interrupt if the interrupt handler, the interrupt source, and the access request meet the verification conditions.

[0056] Fourthly, this application provides an electrical device including the battery management system described above. Attached Figure Description

[0057] The features, advantages, and technical effects of exemplary embodiments of this application will now be described with reference to the accompanying drawings.

[0058] Figure 1 A flowchart illustrating the interrupt handling method provided in an embodiment of this application;

[0059] Figure 2 This is a schematic diagram of the interrupt priority configuration method provided in an embodiment of this application;

[0060] Figure 3 This is a schematic flowchart of a priority configuration method provided in another embodiment of this application;

[0061] Figure 4 A schematic flowchart illustrating the legality check method for interruption sources provided in this application embodiment;

[0062] Figure 5 This is a schematic flowchart of the interrupt handler checking method provided in an embodiment of this application;

[0063] Figure 6 A schematic flowchart of an interrupt handler checking method provided in another embodiment of this application;

[0064] Figure 7 This is a schematic diagram of the access permission verification process for system resources provided in an embodiment of this application;

[0065] Figure 8 This is a schematic diagram of the system architecture of the battery management system provided in an embodiment of this application;

[0066] Figure 9 This is a schematic diagram of the battery management system provided in an embodiment of this application;

[0067] Figure 10 This is a schematic diagram of the hardware structure of the electrical equipment provided in the embodiments of this application;

[0068] Figure 11 The flowchart of the interrupt handling process provided in this application.

[0069] The accompanying drawings are not necessarily drawn to scale. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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 some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0071] The Battery Management System (BMS) of this application is used to perform at least one of the following functions for individual battery cells: state monitoring, state analysis, charge / discharge control, safety protection, information management, thermal management, and high-voltage power distribution. In addition, the BMS of this application can also implement the functions of a controller in an electrical device, such as a vehicle control unit (VCU) or a motor control unit (MCU), etc., and this application does not impose any limitations on this. It should be noted that the BMS of this application can be integrated as a controller into a battery device, such as into a battery pack or energy storage box; the BMS of this application can also be integrated as a controller into an electrical device, such as into a vehicle or vehicle chassis; the BMS of this application can also be integrated as a controller into a charging device, such as into a charging device or battery swapping device; the BMS of this application can also be deployed as control software on a server. A server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, such as vehicle networking cloud, APP backend, etc.

[0072] In practical applications, various interrupts in the battery management system are mainly handled by the processor. Different types of processors have different operating systems, and different operating systems handle interrupts in different ways. When an interrupt is triggered during task execution, the processor needs to respond to the interrupt by calling the interrupt handler and perform the corresponding operation. However, current interrupt handlers may have the following problems: (1) access to shared resources is not properly synchronized, resulting in data inconsistency in shared resources; (2) access to illegal memory addresses or out-of-bounds access; (3) interrupt nesting is not properly handled, resulting in chaotic interrupt handling.

[0073] Shared resources refer to resources in the battery management system that can be accessed and modified simultaneously by multiple tasks or interrupt service routines, such as global variables, data buffers, and hardware registers. These resources can be used to store battery status information such as remaining charge, temperature, and voltage. Synchronization control ensures that multiple interrupt handlers or tasks can coordinate and agree when accessing shared resources, avoiding data conflicts and inconsistencies. Illegal memory address access and out-of-bounds access refer to the processor attempting to access memory regions that have not been allocated permissions to it.

[0074] To address the aforementioned issues, this application provides an interrupt handling scheme. By identifying the priority of each interrupt, the operating system can process interrupts in priority order, improving the orderliness of interrupt handling and preventing confusion. Furthermore, by verifying the access permissions of interrupt handlers, interrupt sources, and interrupt-related resources, the security of the interrupt handling process can be improved, preventing the occurrence of illegal interrupt handlers.

[0075] The technical solution of this application will now be described in detail through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0076] Figure 1 This is a flowchart illustrating a stack space allocation method in a battery management system provided in an embodiment of this application. This method can be applied to a battery management system whose processor carries an compatible operating system. Taking this operating system as the execution entity as an example... Figure 1 As shown, the method may include the following steps:

[0077] Step S110: Obtain the target interrupt. The target interrupt is at least one interrupt awaiting processing by the battery management system.

[0078] In this embodiment, interrupts in the battery management system can be categorized into several types, such as sensor interrupts, fault alarm interrupts, and hardware fault interrupts. Sensor interrupts can include interrupts generated when sensors for battery voltage, current, temperature, etc., malfunction or become abnormal. Fault alarm interrupts include those for battery over-discharge, overcharge, and over-temperature. Hardware fault interrupts include interrupts for chip faults, battery faults, and memory faults; these hardware faults can affect the normal functioning of the battery management system.

[0079] For example, when the operating system in the battery management system is performing a battery temperature monitoring task, if it detects that the current battery temperature is greater than the battery temperature threshold, it will trigger a battery over-temperature interrupt.

[0080] In this embodiment, after an interrupt is triggered, the operating system may not process the interrupt immediately. For example, under high load or emergency conditions, when an interrupt is triggered, the operating system receives the interrupt request, but due to the limitations of high load, the operating system needs to delay processing the interrupt, which will cause the interrupt processing to be postponed.

[0081] High load refers to a system processing a large number of tasks or data, causing its resource utilization (such as CPU and memory) to approach or reach its limit. This results in a slower response time to interruptions and reduced efficiency. An emergency situation refers to an unexpected event or malfunction encountered by the battery management system, requiring immediate action to prevent serious damage to the battery or the entire system. For example, in a battery management system, emergencies might include battery overcharging, over-discharging, short circuits, and overheating.

[0082] This can be recorded as the response time of the interrupt, from the start time of the interrupt being triggered to the time taken for the operating system to begin processing the interrupt.

[0083] For example, in some embodiments, when the operating system receives multiple interrupts, the operating system can determine which interrupt to process first based on the priority of each interrupt, that is, identify the target interrupt and postpone the processing of other interrupts.

[0084] Step S120: Obtain access permissions to the interrupt handler of the target interrupt, the interrupt source that triggered the target interrupt, and the system resources related to the target interrupt.

[0085] In this embodiment, the interrupt handler is a special function called by the operating system when an interrupt occurs, used to handle the corresponding interrupt event. The interrupt handler is a pre-written piece of code. When an interrupt request occurs, the operating system needs to stop the execution of the current task and call the interrupt handler to handle the corresponding interrupt event.

[0086] In this embodiment, the interrupt source can refer to a signal source capable of triggering an interrupt. For example, the battery management system includes a battery temperature monitoring circuit and a current monitoring circuit. Both the battery temperature monitoring circuit and the current monitoring circuit can be connected to an interrupt controller. When the battery temperature monitoring circuit detects that the battery is overheating, the interrupt controller can trigger a battery overheating interrupt. Similarly, when the current monitoring circuit detects that the battery is overcharged, the interrupt controller can also trigger a battery overcharge interrupt.

[0087] In this embodiment, interrupt-related resources can be divided into two categories: hardware resources and software resources. Hardware resources may include battery status monitored in real time by sensors, such as voltage, current, and temperature. Software resources may include code in interrupt service routines. The code in the interrupt service routines differs for different interrupts.

[0088] Access permissions are used to ensure the security of interrupt-related resources. Access permissions determine which resources need to be protected and which tasks or threads in the operating system can access these resources.

[0089] Step S130: If the interrupt handler, interrupt source, and access permissions meet the verification conditions, process the target interrupt.

[0090] In this embodiment, before processing the target interrupt, the operating system needs to verify the target interrupt to determine whether the access permissions of its corresponding interrupt handler, interrupt source, and interrupt-related resources meet the security requirements.

[0091] For example, the interrupt handler can be checked for illegal code; if illegal code is found, the check fails. Similarly, the interrupt source can be checked for legitimacy; if the interrupt source is not legitimate, the check also fails. Furthermore, the access permissions can be checked to ensure they are set appropriately, preventing unauthorized tasks or threads from accessing interrupt-related resources.

[0092] In this embodiment, the operating system can call the verified interrupt handler to process the target interrupt.

[0093] In this embodiment of the application, by verifying the access permissions of the interrupt handler, the interrupt source, and the interrupt-related resources, the security of the target interrupt handling process can be improved, and the situation of an illegal interrupt handler can be avoided.

[0094] In some embodiments, a preset priority can be configured for each interrupt. When configuring the priority, interrupts can be grouped by priority, dividing them into different priority groups. Interrupts in the same priority group have the same priority, while interrupts in different priority groups have different priorities. Dividing interrupts into different priority groups can ensure that interrupts in high-priority groups are processed first, while avoiding excessive delays for interrupts in low-priority groups.

[0095] In some embodiments, after configuring a preset priority for each interrupt, when the operating system faces multiple interrupts waiting to be processed, it can determine the target interrupt based on the priority of each interrupt.

[0096] For example, the highest priority interrupt can be selected from multiple waiting interrupts as the target interrupt. The higher the priority, the earlier the interrupt is processed; that is, higher priority interrupts are processed before lower priority interrupts.

[0097] In the embodiments of this application, by selecting a high-priority interrupt as the target interrupt, priority processing of high-priority interrupts can be achieved, thereby improving the flexibility of interrupt processing.

[0098] Furthermore, in some embodiments, Figure 2This is a schematic diagram of the interrupt priority configuration method provided in an embodiment of this application, such as... Figure 2 As shown, the method may specifically include the following steps:

[0099] Step S210: Obtain the type of each interrupt in the battery management system and the number of times the interrupt is triggered within a preset time period;

[0100] Step S220: Determine the preset priority of the interrupt based on at least one of the interrupt type and the number of triggers.

[0101] In this embodiment, multiple priorities can be set (e.g., 7 levels from 1 to 7, with level 7 being the highest priority and level 1 the lowest priority). The priority of each interrupt can be pre-configured before the system runs, i.e., a preset priority. For example, the priority of the battery over-temperature interrupt can be configured as level 6, and the priority of the battery balancing interrupt (used to balance the charge of individual battery cells within the battery pack) can be configured as level 3.

[0102] Priority can be used to characterize the importance or urgency of an interrupt; the higher the priority, the more urgently the interrupt needs to be handled. For example, when the operating system receives a first interrupt (priority level 6) and a second interrupt (priority level 3), the operating system can prioritize handling the first interrupt, that is, take the first interrupt as the target interrupt.

[0103] Furthermore, as mentioned above, interrupt priorities can be pre-configured, and these pre-configured priorities remain fixed during operating system operation. However, in some embodiments, the pre-configured priorities can be dynamically adjusted. For example, if the second interrupt is pre-configured with a priority level of 3, in certain special cases, to ensure that the second interrupt is processed with priority, its priority can be dynamically adjusted, for example, to a priority level of 7.

[0104] After obtaining the priorities of the first and second interrupts, the operating system can first determine whether the priorities of the first and second interrupts are the pre-configured initial priorities or the dynamically adjusted priorities.

[0105] Specifically, if the priority of the first interrupt is pre-configured, for example, priority 6, while the priority of the second interrupt is dynamically adjusted, for example, the dynamically adjusted priority is 7, then the operating system can use the second interrupt as the target interrupt.

[0106] In addition, in some embodiments, if two interrupts have the same priority, the operating system can further compare the impact of the two interrupts on the safety and stability of the battery management system, and the interrupt with the greater impact will be the target interrupt.

[0107] In this embodiment, different types of interrupts have different functions. For example, when the battery temperature exceeds a threshold, an over-temperature interrupt will be triggered immediately. The battery over-temperature interrupt can be used to cut off the charging and discharging circuit, preventing serious safety accidents such as thermal runaway, combustion, or even explosion caused by high temperatures. As another example, during charging, if the battery continues to charge after reaching a full charge, a battery overcharge interrupt will be triggered promptly to stop the charging process and prevent overcharging. Furthermore, a status update interrupt can transmit the latest battery status information to the user interface or monitoring system in real time, and a log recording interrupt records detailed data such as relevant fault information, occurrence time, and fault codes.

[0108] By analyzing the functions of different interrupts, it can be found that they have varying degrees of impact on the battery. Some interrupts have a significant impact on battery safety (e.g., battery over-temperature interrupts), while others have a smaller impact (e.g., state update interrupts). Interrupts with a greater impact on battery safety are more important, while those with a smaller impact are less important. For example, interrupts with a greater impact on battery safety can be grouped into a high-priority group, while interrupts with a smaller impact on battery safety can be grouped into a low-priority group.

[0109] In this embodiment, the timeliness of different types of interrupts also varies. Timeliness refers to the length of the interrupt response time; a higher timeliness requirement necessitates a shorter response time, and a lower timeliness requirement results in a longer response time. For example, a higher timeliness requirement means a higher priority interrupt, requiring it to be assigned to a high-priority group, while a lower timeliness requirement means a lower priority interrupt, allowing it to be assigned to a low-priority group.

[0110] For example, priority group division rules can also be configured to configure the priority of each interrupt. The priority division rules can specifically include: (1) Based on the importance and urgency of the interrupt. Critical interrupts (such as battery overheating, overcharging and over-discharging) are divided into high priority groups, and non-critical interrupts (such as log recording, status updates, etc.) are divided into low priority groups. (2) Based on the timeliness requirements of interrupt handling. Interrupts that require fast response should be divided into high priority groups. Interrupts with low response time requirements are divided into low priority groups. (3) Based on the frequency of interrupts. Frequent interrupts, if their handling has little impact on the system, are divided into low priority groups; interrupts that occur less frequently but have a greater impact are divided into high priority groups.

[0111] Additionally, in some embodiments, when handling interrupts, high-priority interrupts should be given sufficient processing time when system resources are scarce. Low-priority interrupts should be processed when system resources are plentiful to avoid excessive delays.

[0112] In this embodiment of the application, by prioritizing interrupts, it can be ensured that the battery management system responds to critical interrupt events in a timely manner, while avoiding the excessive impact of non-critical interrupt events on system performance. This helps to improve the responsiveness and stability of the system, thereby ensuring the safe and efficient operation of the battery.

[0113] Furthermore, based on the above embodiments, in some embodiments, Figure 3 This is a schematic flowchart of a priority configuration method provided in another embodiment of this application, as shown below. Figure 3 As shown, the method may specifically include the following steps:

[0114] Step S310: Obtain the first priority and the second priority.

[0115] The first priority is higher than the second priority.

[0116] Step S320: In the case of an interrupt of type 1, the first priority is set as the preset priority of the interrupt.

[0117] The first type of interruption includes at least one of battery over-temperature interruption, battery overcharge interruption, and battery over-discharge interruption.

[0118] Step S330: In the case of an interrupt of type 2, the second priority is set as the preset priority of the interrupt.

[0119] The second type of interrupt includes at least one of the following: logging interrupt, status update interrupt, and system software upgrade interrupt.

[0120] In this embodiment, the interrupt sources in the battery management system can be analyzed and all interrupt sources in the battery management system can be classified. The importance of interrupts varies depending on the category of the interrupt source.

[0121] Each interrupt can be assigned an identifier to characterize its importance. For example, the importance identifier for the battery overheat interrupt is H1, the importance identifier for the battery overcharge interrupt is H2, and the importance identifier for the battery over-discharge interrupt is H3. These three interrupts have the same importance and are assigned to the same priority group. All three interrupts have the first priority.

[0122] In addition, the importance markers for logging interrupts are L1, status update interrupts are L2, and system software upgrade interrupts are L3. These three interrupts have the same importance and can be grouped into the same priority group, with all three having the second priority. If the operating system detects that an interrupt has an importance level of H1 to H3, then that interrupt has a higher priority, the first priority; conversely, if the interrupt has an importance level of L1 to L3, then that interrupt has a lower priority, the second priority.

[0123] In this embodiment of the application, by dividing interrupts into a first type of interrupt that is more important and a second type of interrupt that is less important, the operating system can prioritize the processing of high-priority interrupts, avoiding delays in processing battery overheating interrupts, battery overcharging interrupts, and battery over-discharging interrupts that affect battery safety. At the same time, it also avoids the excessive impact of non-important interrupts such as log recording interrupts, status update interrupts, and system software upgrade interrupts on system performance.

[0124] In some embodiments, an interrupt controller can be configured for the battery management system, and the relevant parameters of the interrupt controller can be configured according to the division of interrupt priority groups to realize priority arbitration and interrupt nesting functions, and prevent the operating system from not handling interrupt nesting correctly, resulting in interrupt handling chaos. Among them, the relevant parameters may include: ① interrupt priority, the priority assigned to each interrupt source, which determines the response order so that the operating system can determine which interrupt to process first according to the priority; ② interrupt nesting enable, the setting to allow or disable the interrupt nesting function. The specific parameter configuration process is as follows: (1) Set interrupt priority, according to system requirements, assign a priority to each interrupt source to ensure that high-priority interrupts can be processed first. (2) Configure interrupt nesting, through programming or hardware settings, allow the battery management chip to respond to higher-priority interrupt requests when responding to an interrupt.

[0125] In this embodiment, priority arbitration refers to determining which interrupt should be handled first based on its priority when multiple devices or processes trigger interrupts simultaneously. Interrupt nesting refers to an interrupt handler being interrupted by a higher-priority interrupt during execution, causing the processor to suspend the execution of the current interrupt handler and handle the new interrupt. Once the new interrupt is handled, execution returns to the original interrupt handler.

[0126] The interrupt controller is responsible for monitoring the status of each interrupt source. When an interrupt source meets the triggering conditions, the interrupt controller can detect and identify the type of interrupt in a timely manner.

[0127] In some embodiments, priority arbitration is implemented as follows: when multiple interrupts are triggered simultaneously in the battery management system, the interrupt with the highest priority is determined as the target interrupt from at least one interrupt.

[0128] In this embodiment, when multiple interrupts occur simultaneously, the interrupt controller determines the response order based on priority. High-priority interrupts are responded to first, and the operating system prioritizes processing high-priority interrupts to avoid interrupt handling chaos.

[0129] Furthermore, system resources in a battery management system (such as processor time slices and data transmission channels) are limited. When multiple interrupts occur simultaneously, responding to them in a fixed order may delay critical interrupt processing, thus affecting system safety and performance. By assigning priorities to each interrupt source, it can be ensured that critical interrupts are handled in a timely manner.

[0130] In this process, after the interrupt controller determines the interrupt priority, it responds to interrupts in descending order of priority. High-priority interrupts are sent to the operating system for processing first, and then lower-priority interrupts are processed in turn.

[0131] In this embodiment, interrupt handling code can be written, with corresponding interrupt handling code written for each interrupt source, and ensuring that the interrupt handling code of the high priority group has a higher execution priority.

[0132] In this embodiment of the application, by assigning a priority to each interrupt source and relying on the intelligent judgment of the interrupt controller, the battery management system can respond to multiple interrupts in an orderly and efficient manner, ensuring that high-priority critical interrupts can be processed in a timely manner, thereby ensuring the safe and stable operation of the battery system and improving overall efficiency.

[0133] In some embodiments, priority nesting is implemented as follows: the priority of the first interrupt is obtained; an interrupt with a higher priority than the first interrupt is selected from at least one interrupt and determined as the target interrupt. The first interrupt is the interrupt being processed by the battery management system.

[0134] In this embodiment, during the process of the interrupt controller responding to an interrupt and sending it to the operating system for processing, if a higher priority interrupt occurs, the operating system can interrupt the currently being processed interrupt, respond to the interrupt controller, process the higher priority interrupt, and then continue the original interrupt processing.

[0135] For example, if a battery overheating interrupt is suddenly triggered while the operating system is processing a logging interrupt, the interrupt controller will respond to the battery overheating interrupt, sending it to the operating system, which will then prioritize handling the battery overheating interrupt to prevent battery damage from overheating. Furthermore, after processing the higher-priority interrupt, the operating system will return to the point where the interrupt occurred and continue processing any unfinished interrupts.

[0136] In this embodiment, the interrupt nesting mechanism enables the battery management system to respond promptly to various sudden high-priority interrupts, ensuring timely response to high-priority interrupts, ensuring battery safety and stable system operation, and improving the battery management system's ability to handle sudden emergency events.

[0137] Furthermore, as mentioned above, a preset priority can be configured for each interrupt in advance, and this preset priority can be dynamically adjusted. For example, in some embodiments, the interrupt response time, processing time, and system performance of the battery management system when processing the target interrupt can also be obtained; then, the priority of the target interrupt can be dynamically adjusted based on at least one of the interrupt response time, processing time, and system performance.

[0138] The interrupt response time is the duration between the first moment when the target interrupt is triggered and the second moment when the battery management system begins to process the target interrupt.

[0139] The processing time is the time taken from when the battery management system begins processing the target interrupt to when it completes the processing. Processing time directly affects the real-time performance of the battery management system. If the processing time is too long, the system may not be able to respond promptly to changes in battery status, leading to battery safety issues or performance degradation. For example, in emergency situations such as overheating or overcharging, a long processing time may prevent timely protective measures from being taken, potentially causing a safety accident.

[0140] System performance includes at least one of processor utilization and memory utilization.

[0141] In addition, in some embodiments, the system stability of the battery management system can be obtained, and the priority of interrupts can be dynamically adjusted based on the system stability. System stability refers to whether the battery management system can accurately and reliably monitor the battery status, control the battery charging and discharging process, and ensure the battery operates safely and efficiently under various conditions.

[0142] For example, in some embodiments, if the interrupt response time is greater than the preset response time, the priority of the target interrupt can be increased to a level greater than the preset priority of the target interrupt; while if the system performance is higher than the preset performance threshold or the processing time is greater than the preset processing time, the priority of the target interrupt can be decreased to a level less than the preset priority.

[0143] In this embodiment, testing can be performed on actual hardware, and the test results can be analyzed to verify the effectiveness of the interrupt priority group division and the strategy of processing interrupts sequentially according to priority. Necessary optimizations and adjustments can be made based on the test results. For example, key indicators such as interrupt response time, processing time, system stability, and system performance can be monitored in the test results to identify any unexpected or poorly performing situations. Furthermore, for parts of the test results that perform poorly, the causes can be analyzed in depth, checking whether the interrupt priority settings are reasonable, whether there are priority conflicts, and evaluating the execution efficiency of the interrupt handling code to identify potential bottlenecks. Finally, interrupt priorities can be adaptively adjusted based on the test results.

[0144] For example, the interrupt priority can be reasonably adjusted by combining the system performance of the battery management system and the frequency of interrupts, so as to ensure that high-priority interrupts are processed first, while avoiding excessive delay of low-priority interrupts.

[0145] In addition, for example, in some embodiments, when the processing time is long, the code in the interrupt handler can be optimized to reduce the execution time of the interrupt handler, while adopting more efficient data structures and algorithms to improve the code execution speed.

[0146] In this embodiment, by focusing on the interrupt response time, processing time, and system performance of the battery management system during the interrupt handling process, and dynamically adjusting the priority of each interrupt, the flexibility of interrupt handling can be improved, which helps to improve the responsiveness and stability of the battery management system and ensure the safe and efficient operation of the battery.

[0147] In some embodiments, regarding the interrupt nesting mentioned above, a security check is required when entering interrupt nesting. This security check may include checking the legitimacy of the interrupt source, the integrity of the program code in the interrupt handler, and verifying whether the interrupt handler contains illegal code or data access to prevent malicious interrupt attacks. Specifically, this can be achieved by executing a series of legitimacy check codes before entering the interrupt handler. This code can check information such as the interrupt vector and the address range of the interrupt handler to ensure interrupt security.

[0148] For example, Figure 4 A schematic flowchart of the interrupt source legality check method provided in the embodiments of this application is shown below. Figure 4 As shown, it includes the following steps:

[0149] Step S410: Obtain the interrupt vector number corresponding to the target interrupt, the stored data in the target register, and the preset interrupt whitelist.

[0150] The interrupt vector number is used to identify the interrupt source, the target register is the register of the hardware device that triggered the target interrupt, and the preset interrupt whitelist includes at least one interrupt source.

[0151] Step S420: If the interrupt source of the target interrupt is in the preset interrupt whitelist, the interrupt source identified by the interrupt vector number corresponding to the target interrupt matches the interrupt source of the target interrupt, and the stored data matches the preset fault data, determine that the interrupt source meets the preset verification conditions.

[0152] In this embodiment, when an interrupt is triggered, the interrupt controller generates an interrupt vector number. This interrupt vector number is similar to an "address label," used to identify which specific event or device caused the interrupt. Different interrupt sources (such as hardware failures, external device requests, etc.) are assigned different interrupt vector numbers so that the operating system can accurately identify and handle the corresponding interrupts.

[0153] Regarding the verification of interrupt vector numbers, when determining whether an interrupt vector number corresponds to an interrupt source, since the interrupt controller provides an interrupt vector number corresponding to a specific interrupt source when an interrupt occurs, the operating system first checks whether this interrupt vector number is valid, that is, whether it corresponds to a known and configured interrupt source. If it corresponds to a known and configured interrupt source, then it is determined that the interrupt vector number corresponds to the interrupt source, meaning the interrupt source is valid.

[0154] In this embodiment, verifying whether the stored data matches the preset fault data primarily aims to check the interrupt source status. Specifically, when the operating system checks a hardware fault interrupt, it checks the corresponding hardware status register to confirm the fault. A hardware fault interrupt is a specific type of interrupt that indicates a fault or abnormal condition in a hardware component of the system. For hardware fault interrupts, it is necessary to further determine which specific hardware component is causing the problem, as well as the nature and severity of the fault. This requires obtaining detailed information about the hardware fault.

[0155] The operating system checks the corresponding hardware status register (i.e., the destination register). Since the destination register stores the status information of the hardware components, it can reflect the hardware's operating status, fault flags, and other information. If the data stored in the destination register contains fault flags or other information, it indicates that the interrupt triggered by that interrupt source is legitimate. The hardware components can include various types of sensors, such as current sensors, temperature sensors, and voltage sensors.

[0156] In this embodiment, a preset whitelist is used to implement interrupt blocking. For example, certain interrupts can be set to be disallowed, meaning that the interrupt sources that generate these interrupts will not be recorded in the preset whitelist. When the operating system checks the preset whitelist and finds that the interrupt source is not in it, and at the same time receives an interrupt triggered by that interrupt source, it determines that it is an illegal interrupt source.

[0157] In this embodiment, if the interrupt source is invalid, that is, the interrupt source does not meet the preset verification conditions, it cannot pass the preset verification conditions.

[0158] In this embodiment of the application, by detecting the legality of the interrupt source, determining whether the interrupt source is in the preset interrupt whitelist, whether there is a correspondence between the interrupt vector number and the interrupt source, and whether the stored data matches the preset fault data, the security of the interrupt handling process can be ensured and the stability of the battery management system can be guaranteed.

[0159] In some embodiments, Figure 5 This is a schematic flowchart of the interrupt handler checking method provided in the embodiments of this application, as shown below. Figure 5 As shown, it includes the following steps:

[0160] Step S510: Obtain the preset mapping relationship and the program code of the interrupt handler.

[0161] The preset mapping relationship is used to characterize the mapping relationship between interrupt handlers and interrupt vector numbers. For example, the preset mapping relationship can be at least one of an interrupt vector table and an interrupt descriptor table.

[0162] Step S520: Based on the preset mapping relationship, determine whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt;

[0163] Step S530: If there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, and the program code of the interrupt handler has not been tampered with, determine that the interrupt handler meets the preset verification conditions.

[0164] In this embodiment, the detection of interrupt handlers mainly includes the integrity detection of interrupt handlers and whether there is illegal code or illegal data access in the interrupt handlers.

[0165] The integrity checks for interrupt handlers mainly include: ① Interrupt handler entry point verification. The operating system verifies whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, that is, whether the interrupt vector number of the target interrupt points to a valid interrupt handler entry point (i.e., the interrupt handler entry point of the target interrupt). This can be done by checking the interrupt vector table or the interrupt descriptor table. ② Code integrity check. The operating system can use code signatures or hash values ​​to verify whether the interrupt handler code has been tampered with, preventing malicious code injection into the interrupt handler.

[0166] The interrupt descriptor table is a data structure that maps interrupt vector numbers to interrupt handler entry points. The interrupt handler entry point is the starting address of a block of code used to handle a specific interrupt. The operating system needs to ensure that this entry point is valid, meaning it points to a block of code that actually exists and can be executed correctly.

[0167] Code signing is used to verify the source and integrity of code. Code developers can sign the code using their private keys, and the operating system can use the corresponding public key to verify the authenticity of the signature. If the signature is valid, it means the code was indeed provided by a trusted code developer and has not been tampered with during transmission or storage. A hash value is a digest representation of the code content. By calculating the hash value of the code and comparing it with a pre-stored correct hash value, the operating system can determine whether the code has been modified.

[0168] In addition, in some embodiments, the interrupt handler can be encrypted. When verifying the interrupt handler, it can be determined whether a corresponding decryption key exists. If no decryption key exists or the encrypted interrupt handler cannot be decrypted, it cannot pass the preset verification conditions.

[0169] One can choose a suitable asymmetric encryption algorithm to encrypt the interrupt handler before it is loaded into memory.

[0170] In this embodiment of the application, by verifying whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, and at the same time verifying whether the program code in the interrupt handler has been tampered with, interrupt security can be guaranteed and the stability and reliability of the battery management system can be further improved.

[0171] Furthermore, based on the above embodiments, Figure 6 A schematic flowchart of an interrupt handler checking method provided in another embodiment of this application is shown below. Figure 6 As shown, it includes the following steps:

[0172] Step S610: Obtain the target data accessed by the interrupt handler and the target memory region accessed by the interrupt handler.

[0173] Step S620: If the target data is the same as the preset data and the target memory area is the same as the preset area, determine that the interrupt handler meets the preset verification conditions.

[0174] The preset data refers to the data that the interrupt handler can access under the set data access permissions. For example, the preset data may include real-time data such as voltage, current, and temperature.

[0175] The memory area can include the random access memory (RAM) and read-only memory (ROM) areas within the battery management system. The RAM can be used to temporarily store various real-time data, such as measurements of battery voltage, current, and temperature.

[0176] In this embodiment, data access permissions can be set for the interrupt handler. These permissions define the data the interrupt handler can and cannot access. In practical applications, the interrupt handler may illegally access data, accessing data beyond its permitted access rights, which would cause the target data to differ from the preset data. Furthermore, illegal access by the interrupt handler will be captured and recorded.

[0177] For example, interrupt handlers can access data including battery voltage, current, and temperature measurements. Data that interrupt handlers cannot access includes protected configuration parameters, such as battery pack design specifications and algorithm decryption keys.

[0178] In this embodiment, to prevent access to illegal memory addresses or out-of-bounds access, the operating system can also use a memory protection mechanism to prevent interrupt handlers from accessing unauthorized memory regions. This memory protection mechanism can be implemented by configuring memory access permissions. Memory access permissions refer to which memory regions an interrupt handler can and cannot access when it is invoked, i.e., preset regions.

[0179] Interrupt handlers can access memory regions including random access memory (RAM) and registers, while inaccessible memory regions include uninitialized or protected memory regions. Uninitialized memory regions contain random data; accessing these regions may lead to unpredictable behavior, potentially causing system crashes or data corruption. Protected memory regions contain critical system data or code (such as the operating system kernel and drivers). Furthermore, if the target memory region accessed by the interrupt handler in actual application includes any of the aforementioned inaccessible regions, then the target memory region will differ from the default region.

[0180] In this embodiment of the application, by checking the data access and memory access of the interrupt handler, it is possible to prevent the interrupt handler from accessing illegal memory addresses or out-of-bounds access, ensuring that the interrupt handler runs in a safe environment, thereby maintaining the reliability and security of the system.

[0181] Additionally, interrupt protection mechanisms can be used to prevent unauthorized access or malicious modification of interrupt handlers, and resource access control lists or permission management mechanisms can be used to restrict access to system resources related to the target interrupt. Specifically, in some embodiments, resource access control lists for system resources related to the target interrupt can be created; and resource access subjects and their corresponding access permissions can be configured in the resource access control lists.

[0182] In this embodiment, the system resources related to the target interrupt include hardware device registers, interrupt vector tables or interrupt descriptor tables, program code segments for interrupt handling, and data structures.

[0183] The entities accessing resources can be tasks or threads within the battery management system. Examples include voltage acquisition and monitoring threads, current acquisition and monitoring threads, temperature acquisition and monitoring threads, overcharge protection tasks, and over-discharge protection tasks.

[0184] Specifically, a resource access control list can be created for each protected system resource associated with the target interrupt. A resource access control list is a data structure used to store information about which tasks or threads can access which system resources associated with the target interrupt.

[0185] In this embodiment, the resource access control list can contain multiple resource access subjects. Furthermore, the access permissions corresponding to each resource access subject are used to characterize the access levels of different tasks or threads to system resources related to the target interrupt. For example, the first type of access permission includes read-only, read-write, and no access. If task A's access permission is read-only, it means that task A can read the system resources related to the target interrupt, but cannot perform editing or other operations.

[0186] Furthermore, Figure 7 This is a schematic diagram of the access permission verification process for system resources provided in the embodiments of this application, as shown below. Figure 7 As shown, it includes the following steps:

[0187] Step S710: Obtain the access permissions of the pre-created resource access control list and the access request.

[0188] The resource access control list includes at least one resource access subject and the access permissions corresponding to that resource access subject.

[0189] Step S720: If the access permission for the access request exists in the resource access control list, determine that the access request meets the preset verification conditions.

[0190] In this embodiment, interrupt-related resources refer to system resources associated with the target interrupt, specifically including interrupt handlers, interrupt priorities, and interrupt vector numbers corresponding to the interrupt source. An interrupt handler is a special piece of code that the processor automatically jumps to for execution when an interrupt occurs.

[0191] In this embodiment, by creating a resource access control list, when a task or thread related to the target interrupt needs to access interrupt-related resources, the access permissions of the task or thread can be verified. If the access permissions match those in the resource access control list, the access of the task or thread will not be restricted, thus satisfying the preset verification conditions.

[0192] For example, if the access control list stores the access permissions of task A and thread B, and thread C, which is related to the target interrupt, initiates an access request to the interrupt-related resource, thread C cannot access the interrupt-related resource because the access control list does not contain the access permission of thread C. That is, the access permission of the interrupt-related resource does not meet the preset verification conditions.

[0193] This requires defining access control policies for interrupt-related resources. This includes determining which interrupt-related resources need protection and which tasks or threads can access them. Additionally, a resource access control list needs to be created for each protected interrupt-related resource to store information about which tasks or threads can access that specific resource. Furthermore, different access permissions need to be configured for different tasks or threads within the resource access control list. Permissions can include read, write, or execute operations. Each task or thread can be assigned different permissions to control its access to interrupt-related resources.

[0194] When an interrupt occurs, the interrupt handler executes. Within the interrupt handler, access control logic needs to be implemented to ensure that only tasks or threads with the appropriate permissions can access interrupt-related resources. Access permissions for these resources are validated within the interrupt handler or any code segment attempting to access protected interrupt-related resources. Specifically, this involves checking whether the current task or thread's access permissions match the permissions defined in the resource access control list. If the current task or thread has sufficient permissions, the validation passes, and access to the interrupt-related resource is permitted.

[0195] Additionally, in some embodiments, resource access control lists can be dynamically updated in response to changes in system state or updates to security policies, under certain circumstances.

[0196] In this embodiment of the application, by verifying the access permissions of access requests, the code and data in interrupt-related resources can be protected, unauthorized access or malicious modification of interrupt settings and handlers can be prevented, and interrupt security can be further improved.

[0197] The interrupt security enhancement mechanism is described in detail below through a complete embodiment. The interrupt security enhancement mechanism verifies the access request limits of interrupt handlers, interrupt sources and interrupt-related resources. When the preset verification conditions are met, interrupt security can be enhanced.

[0198] The security enhancement mechanism can be implemented by enforcing interrupt isolation, access control, and permission management mechanisms for the battery management system within the operating system's software timer interrupts. This protects the battery management system's interrupt handling process from malicious attacks and prevents unauthorized code and service interruptions.

[0199] Firstly, when handling interrupts, the operating system needs to respond based on the importance and urgency of the interrupt event, which involves setting interrupt priorities. Specifically, interrupts in the battery management system may originate from various changes in battery state, such as overcharging, over-discharging, excessively high or low temperature, etc. These interrupt events have varying degrees of impact on battery safety and performance, therefore, different priorities need to be assigned according to their urgency.

[0200] Specifically, priority grouping can be implemented, dividing interrupts into different priority groups to ensure that high-priority interrupts are processed first, while avoiding excessive delays for low-priority interrupts. Within priority grouping, interrupt nesting needs to be implemented. That is, while responding to an interrupt, if a higher-priority interrupt occurs, the operating system can interrupt the current interrupt service, respond to the higher-priority interrupt, and then continue the original interrupt service.

[0201] Secondly, when entering interrupt nesting, a security check is required. This includes verifying the legitimacy of the interrupt source, the integrity of the interrupt handler, and checking for illegal code or data access within the interrupt handler to prevent malicious interrupt attacks. Simultaneously, an interrupt error detection mechanism can be established to promptly detect errors during interrupt handling. This includes detecting interrupt signal loss, interrupt timeouts, and abnormal interrupt handler returns. Once an error is detected, it should be reported immediately so that appropriate measures can be taken. This can be achieved by adding error detection code to the interrupt handler or by utilizing hardware interrupt error flags.

[0202] The implementation methods and approaches for judging various errors in the interrupt error detection set are as follows: (1) Interrupt vector number verification: When an interrupt occurs, the hardware (such as the interrupt controller) will provide an interrupt vector number, which corresponds to a specific interrupt source. The operating system first checks whether this interrupt vector number is valid, that is, whether it corresponds to a known and configured interrupt source. (2) Interrupt source status check: When the operating system checks a hardware fault interrupt, it will check the corresponding hardware status register to confirm the fault. (3) Interrupt masking and priority check: The operating system checks the current interrupt masking settings to determine whether the interrupt is allowed. At the same time, it checks the interrupt priority to ensure that high-priority interrupts can preempt low-priority interrupts.

[0203] Finally, an interrupt protection mechanism needs to be implemented to prevent unauthorized access or malicious modification of interrupt settings and handlers. Access control lists or permission management mechanisms should be used to restrict access to interrupt-related resources. In the battery management system, operating system security mechanisms, such as memory protection and access control, can be used to protect interrupt-related code and data. Simultaneously, interrupt handlers should be encrypted and their integrity verified to prevent tampering.

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

[0205] Figure 8 This is a schematic diagram of the system architecture of the battery management system provided in an embodiment of this application. The battery management system can be integrated into an electronic device, or it can be implemented independently of the electronic device but in collaboration with it. For example, the electronic device can be a power-consuming device. Figure 8 As shown, the battery management system 800 includes an interrupt acquisition module 810, a data acquisition module 820, and an interrupt processing module 830.

[0206] The interrupt acquisition module 810 is used to acquire the target interrupt. The target interrupt is any one of at least one interrupt awaiting processing by the battery management system. The data acquisition module 820 is used to acquire the interrupt handler of the target interrupt, the interrupt source that triggered the target interrupt, and the access request for system resources related to the target interrupt. The interrupt processing module 830 is used to process the target interrupt if the interrupt handler, interrupt source, and access request meet the set verification conditions.

[0207] The battery management system provided in this application embodiment can be used to execute the methods in the above embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0208] In some embodiments, to adjust interrupt priorities, a smart interrupt controller can be configured in the battery management system. This controller can identify the priorities of different interrupt sources and perform interrupt nesting and preemption control according to preset rules. For example, an interrupt controller with multiple interrupt priority levels (such as 8 priority levels) can be used.

[0209] For example, Figure 9 This is a schematic diagram of the battery management system provided in an embodiment of this application, such as... Figure 9 As shown, the battery management system 900 includes an interrupt controller 910. Various battery-related interrupt sources can be connected to the interrupt controller. For example, interrupt signals generated by the battery temperature sensor 920, current sensor 930, and voltage sensor 940 can be connected to different input pins of the interrupt controller.

[0210] Figure 10 This is a schematic diagram of the hardware structure of an electrical device provided in an embodiment of this application. This electrical device can be integrated into an electric vehicle and includes a battery management system. Figure 10 As shown, the electrical device 1000 may include a processor 1001 and a memory 1002 storing computer program instructions.

[0211] Specifically, the processor 1001 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0212] Memory 1002 may include mass storage for data or instructions. For example, and not as a limitation, memory 1002 may include a hard disk drive (HDD), a floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these.

[0213] Where appropriate, memory 1002 may include removable or non-removable (or fixed) media. Where appropriate, memory 1002 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1002 is a non-volatile solid-state memory.

[0214] Memory 1002 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 1002 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in any of the methods described in the above embodiments. Processor 1001 implements any of the methods in the above embodiments by reading and executing computer program instructions stored in memory 1002.

[0215] In one example, the electrical device 1000 may also include a communication interface 1003 and a bus 1004. For example, Figure 10 As shown, the processor 1001, memory 1002, and communication interface 1003 are connected through bus 1004 and complete communication with each other.

[0216] The communication interface 1003 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0217] Bus 1004 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1004 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0218] Figure 11 The flowchart of the interrupt handling completion process provided in this application is as follows: Figure 11 As shown, it includes the following steps:

[0219] Step S1100: Priority allocation. Step S1110: Interrupt nesting security check. Step S1120: Interrupt error detection and reporting. Step S1130: Interrupt protection.

[0220] In step S1100, each interrupt is divided into different priorities and grouped to ensure that interrupts in high-priority groups are processed first, while avoiding excessive delays in interrupts in low-priority groups. In the battery management system, interrupt priority can ensure that the system can respond to critical events in a timely manner, while avoiding excessive impact of non-critical events on system performance. Interrupts can be divided into different priority groups, and corresponding interrupt handling strategies can be designed. The specific process is as follows: (1) Analyze interrupt sources. Classify all interrupt sources in the battery management system and assign them to different priority groups according to their urgency and importance. (2) Configure interrupt controller. Configure the relevant parameters of the interrupt controller according to the division of interrupt priority groups to realize priority arbitration and interrupt nesting functions.

[0221] Specifically, step S1110 involves a security check that includes verifying the legitimacy of the interrupt source and the integrity of the interrupt handler. It also verifies whether the interrupt handler contains illegal code or data access, preventing malicious interrupt attacks. This is achieved by executing a series of legitimacy checks before entering the interrupt handler. This code checks information such as the interrupt vector and the address range of the interrupt handler, ensuring the security of the interrupt during processing.

[0222] The validity of the interrupt source is checked as follows: (1) Interrupt vector number verification. When an interrupt occurs, the hardware (such as the interrupt controller) provides an interrupt vector number, which corresponds to a specific interrupt source. First, check whether the interrupt vector number is valid, that is, whether it corresponds to a known and configured interrupt source. (2) Interrupt source status check. To check for a hardware fault interrupt, the corresponding hardware status register is checked to confirm the fault. (3) Interrupt masking and priority check. The current interrupt masking settings are checked to determine whether the interrupt is allowed. At the same time, the interrupt priority is checked to ensure that a high-priority interrupt can preempt a low-priority interrupt.

[0223] The integrity of the interrupt handler is checked as follows: (1) Interrupt handler entry point verification. Verify whether the interrupt vector number points to a valid interrupt handler entry point. This is done by checking the interrupt vector table or interrupt descriptor table. (2) Code integrity check. Code signatures or hash values ​​can be used to verify whether the interrupt handler code has been tampered with, thus preventing malicious code injection into the interrupt handler.

[0224] Verify that the interrupt handler has unauthorized code or data access, specifically as follows: (1) Access control. Strict access control policies ensure that the interrupt handler can only access the resources and data it needs. Any unauthorized access attempts will be captured and logged. (2) Memory protection. Memory protection mechanisms are used to prevent the interrupt handler from accessing unauthorized memory areas. If an attempt is made to access illegal memory, a memory protection exception will be triggered.

[0225] In step S1120, an interrupt error detection mechanism is established to promptly detect errors in the interrupt handling process. This includes detecting errors such as interrupt signal loss, interrupt timeout, and abnormal return of the interrupt handler. Once an error is detected, it is promptly reported to the system so that appropriate handling measures can be taken. This can be achieved by adding error detection code to the interrupt handler or by using the interrupt error flag in the hardware. The implementation methods and approaches for judging various errors in the interrupt error detection set are as follows: (1) Interrupt vector number verification. When an interrupt occurs, the hardware (such as the interrupt controller) will provide an interrupt vector number, which corresponds to a specific interrupt source. First, check whether the interrupt vector number is valid, that is, whether it corresponds to a known and configured interrupt source. (2) Interrupt source status check. Checking a hardware fault interrupt will check the corresponding hardware status register to confirm the fault. (3) Interrupt masking and priority check. Check the current interrupt masking settings to determine whether the interrupt is allowed. At the same time, check the interrupt priority to ensure that high-priority interrupts can preempt low-priority interrupts.

[0226] In step S1130, an interrupt protection mechanism is implemented to prevent unauthorized access or malicious modification of interrupt settings and handlers. Resource access control lists are used to restrict access to interrupt-related resources. Specifically, memory protection and access control can be used to protect interrupt-related code and data. At the same time, the interrupt handler is encrypted and its integrity is verified to prevent it from being tampered with. The specific implementation process is as follows: (1) Define access control policy. First, it is necessary to define the access control policy for interrupt-related resources. This includes determining which resources need to be protected and which tasks or threads can access these resources. (2) Create resource access control list. Create a resource access control list for each protected interrupt-related resource. (3) Configure permissions. Configure permissions for different tasks or threads in the resource access control list. Permissions can include read, write, or execute operations. Each task or thread can be given a different permission level to control their access to resources. (4) Access control in interrupt handlers. When an interrupt occurs, the interrupt handler executes. Within the interrupt handler, access control logic needs to be implemented to ensure that only tasks or threads with the appropriate permissions can access the interrupt-related resources. (5) Permission Check. Permission check logic is implemented in the interrupt handler or any code segment attempting to access protected resources. This typically involves checking whether the permissions of the current task or thread match the permissions defined in the resource access control list. (6) Access Decision. Based on the results of the permission check, an access decision is made. If the current task or thread has sufficient permissions, it is allowed to access the resource; otherwise, access is denied and a security event may be logged. (7) Dynamically Updating the Resource Access Control List. In some cases, it may be necessary to dynamically update the resource access control list in response to changes in system state or updates to security policies. This can be achieved by providing appropriate interfaces to modify the resource access control list at runtime.

[0227] The security mechanisms are as follows: (1) Interrupt handler entry point verification. Verify whether the interrupt vector number points to a valid interrupt handler entry point. This is done by checking the interrupt vector table or interrupt descriptor table. (2) Code integrity check. Code signatures or hash values ​​can be used to verify whether the interrupt handler code has been tampered with, preventing malicious code injection into the interrupt handler. Verify whether there is any illegal code or data access in the interrupt handler.

[0228] Furthermore, regarding access control, strict access control policies can be implemented, allowing interrupt handlers to access only the resources and data they require. Any unauthorized access attempts will be captured and logged. As for memory protection, memory protection mechanisms can be used to prevent interrupt handlers from accessing unauthorized memory regions. Attempts to access illegal memory will trigger a memory protection exception.

[0229] The specific process of encryption and integrity verification in the interrupt handler is as follows: (1) Select an encryption algorithm. Select a suitable RSA encryption algorithm. (2) Encrypt the interrupt handler. Before the interrupt handler is loaded into memory, encrypt it using the selected RSA encryption algorithm.

[0230] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement the methods in the above embodiments.

[0231] This application also provides a computer program product, including a computer program, which, when executed, implements any of the methods described in the above embodiments.

[0232] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0233] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0234] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0235] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0236] Unless otherwise specified, all embodiments and optional embodiments of this application can be combined to form new technical solutions.

[0237] Unless otherwise specified, all technical features and optional technical features of this application may be combined to form new technical solutions.

[0238] Unless otherwise specified, all steps of this application may be performed sequentially or randomly, preferably sequentially. For example, if the method includes steps (a) and (b), it means that the method may include steps (a) and (b) performed sequentially, or it may include steps (b) and (a) performed sequentially. For example, if the method may also include step (c), it means that step (c) may be added to the method in any order. For example, the method may include steps (a), (b), and (c), or it may include steps (a), (c), and (b), or it may include steps (c), (a), and (b), etc.

[0239] Although this application has been described with reference to preferred embodiments, various modifications can be made thereto and components can be replaced with equivalents without departing from the scope of this application. In particular, the technical features mentioned in the various embodiments can be combined in any manner, provided there is no structural conflict. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. An interrupt handling method for a battery management system, characterized in that, include: Acquire a target interrupt, wherein the target interrupt is at least one interrupt waiting to be processed by the battery management system; Obtain the interrupt handler for the target interrupt, the interrupt source that triggered the target interrupt, and the access requests for system resources related to the target interrupt; The target interrupt is processed if the interrupt handler, the interrupt source, and the access request meet the verification conditions.

2. The method according to claim 1, characterized in that, The acquisition of the target interrupt includes: Obtain the preset priority for each interrupt; The highest priority interrupt is selected from the at least one interrupt and determined as the target interrupt. The high-priority interrupt is processed by the battery management system before the low-priority interrupt.

3. The method according to claim 2, characterized in that, The process of obtaining the preset priority for each interrupt includes: Obtain the type of each interrupt in the battery management system and the number of times the interrupt is triggered within a preset time period; The preset priority of the interrupt is determined based on at least one of the interrupt type and the number of triggers.

4. The method according to claim 3, characterized in that, Based on the type of interrupt, a preset priority for the interrupt is determined, including: Obtain a first priority and a second priority, where the first priority is higher than the second priority; In the case of the interrupt being a first type of interrupt, the first priority is determined as the preset priority of the interrupt; wherein, the first type of interrupt includes at least one of battery over-temperature interrupt, battery overcharge interrupt, and battery over-discharge interrupt; In the case that the interrupt is of the second type, the second priority is determined as the preset priority of the interrupt; wherein, the second type of interrupt includes at least one of log recording interrupt, status update interrupt and system software upgrade interrupt.

5. The method according to any one of claims 1-4, characterized in that, The acquisition of the target interrupt includes: Obtain the priority of the first interrupt, which is the interrupt being processed by the battery management system; The interrupt with a higher priority than the first interrupt is selected from the at least one interrupt and determined as the target interrupt.

6. The method according to any one of claims 1-5, characterized in that, Determining that the interrupt source meets the preset verification conditions includes: Obtain the interrupt vector number corresponding to the target interrupt, the stored data in the target register, and the preset interrupt whitelist. The interrupt vector number is used to identify the interrupt source, the target register is the register of the hardware device that triggered the target interrupt, and the preset interrupt whitelist includes at least one interrupt source. If the interrupt source of the target interrupt is in the preset interrupt whitelist, the interrupt source identified by the interrupt vector number corresponding to the target interrupt matches the interrupt source of the target interrupt, and the stored data matches the preset fault data, then the interrupt source is determined to meet the preset verification conditions.

7. The method according to any one of claims 1-6, characterized in that, Determining that the interrupt handler meets preset verification conditions includes: Obtain the preset mapping relationship and the program code of the interrupt handler, wherein the preset mapping relationship is used to characterize the mapping relationship between the interrupt handler and the interrupt vector number; Based on the preset mapping relationship, determine whether there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt; If there is a mapping relationship between the interrupt vector number of the target interrupt and the interrupt handler of the target interrupt, and the program code of the interrupt handler has not been tampered with, then the interrupt handler is determined to meet the preset verification condition.

8. The method according to any one of claims 1-7, characterized in that, Determining that the interrupt handler meets preset verification conditions includes: Obtain the target data accessed by the interrupt handler and the target memory region accessed by the interrupt handler; If the target data is the same as the preset data and the target memory region is the same as the preset region, the interrupt handler is determined to meet the preset verification conditions.

9. The method according to any one of claims 1-8, characterized in that, Determining that access requests to system resources related to the target interrupt meet preset verification conditions includes: Obtain a pre-created resource access control list and the access permissions of the access request, wherein the resource access control list includes at least one resource access subject and the access permissions corresponding to the resource access subject; If the access permission for the access request exists in the resource access control list, it is determined that the access request meets the preset verification conditions.

10. The method according to any one of claims 2-5, characterized in that, Also includes: The interrupt response time, processing time, and system performance of the battery management system when processing the target interrupt are obtained; wherein, the interrupt response time is the duration between the first moment when the target interrupt is triggered and the second moment when the battery management system begins processing the target interrupt, the processing time is the time consumed from the start of processing the target interrupt to the completion of processing the target interrupt, and the system performance includes at least one of processor utilization and memory utilization; The priority of the target interrupt is adjusted based on at least one of the interrupt response time, the processing time, and the system performance.

11. The method according to claim 10, characterized in that, The step of adjusting the priority of the target interrupt based on the interrupt response time includes: If the interrupt response time is greater than the preset response time, the priority of the target interrupt is increased to a level greater than the preset priority of the target interrupt. If the system performance is higher than a preset performance threshold or the processing time is longer than a preset processing time, the priority of the target interrupt will be lowered to less than the preset priority.

12. A battery management system, characterized in that, include: An interrupt acquisition module is used to acquire a target interrupt, wherein the target interrupt is any one of at least one interrupt waiting to be processed by the battery management system; The data acquisition module is used to acquire the interrupt handler of the target interrupt, the interrupt source that triggers the target interrupt, and the access requests for system resources related to the target interrupt; An interrupt handling module is used to process the target interrupt if the interrupt handler, the interrupt source, and the access request meet the verification conditions.

13. An electrical appliance, characterized in that, Includes the battery management system as described in claim 12.

Images