Battery management system interrupt task processing method, system, medium and product

Abstract

Embodiments of the present application provide a battery management system interrupt task processing method, system, medium and product, the method comprising: obtaining a plurality of interrupt requests in a preset time period; in the case that the frequency of the plurality of interrupt requests meets a preset condition, at least part of the plurality of interrupt requests is processed by merging to obtain at least one target interrupt request; at least one interrupt task corresponding to the at least one target interrupt request is generated according to the at least one target interrupt request; and the interrupt task is processed. In this way, the number of interrupt tasks that need to be processed can be reduced, thereby reducing the burden of task scheduling of the battery management system and improving the performance of the battery management system.

Description

Technical Field

[0001] This application relates to the field of battery management system technology, and in particular to an interrupt task handling method, system, medium and product for a battery management system. Background Technology

[0002] During the execution of tasks by the battery management system (BMS), task scheduling is crucial for the smooth execution of tasks and ensuring the performance of the BMS. However, in practical applications, factors such as hardware failures or external environmental interference may cause a large number of interrupt events to occur frequently in a short period of time. In this case, the BMS will receive a large number of interrupt requests in a short period of time, and each interrupt request will trigger a corresponding interrupt task. This will overwhelm the BMS's task scheduler and thus reduce system performance. Summary of the Invention

[0003] This application provides an interrupt task handling method, system, medium, and product for a battery management system, which can reduce the number of interrupt tasks that need to be processed, thereby alleviating the task scheduling burden of the battery management system and improving the performance of the battery management system.

[0004] In a first aspect, embodiments of this application provide a task processing method, the method comprising:

[0005] Retrieve multiple interruption requests within a preset time period;

[0006] If the frequencies of multiple interrupt requests meet a preset condition, at least some of the interrupt requests are merged to obtain at least one target interrupt request.

[0007] Generate at least one corresponding interrupt task based on at least one target interrupt request;

[0008] Handle interrupted tasks.

[0009] In this way, if the frequency of multiple interrupt requests within a preset time period meets preset conditions, at least some of the multiple interrupt requests can be merged to obtain at least one target interrupt request, which is fewer in number than the original multiple interrupt requests. Then, based on the at least one target interrupt request, at least one corresponding interrupt task is generated for processing. This reduces the number of interrupt tasks that need to be processed, thereby alleviating the task scheduling burden of the battery management system and improving its performance.

[0010] In some embodiments, when the frequencies of multiple interrupt requests meet a preset condition, at least some of the multiple interrupt requests are merged to obtain at least one target interrupt request, including:

[0011] In the case where multiple interrupt requests include multiple first interrupt requests, the interrupt frequency of the multiple first interrupt requests is determined; the first interrupt request is an interrupt request whose importance level is lower than a preset level threshold.

[0012] When the interrupt frequency is greater than or equal to a preset frequency threshold, first interrupt requests of the same type among multiple first interrupt requests are merged to obtain a second interrupt request.

[0013] At least one target interrupt request is obtained based on the second interrupt request, the first interrupt request that has not been merged, and the other interrupt requests other than the first interrupt request among the multiple interrupt requests.

[0014] This allows multiple interrupt requests with lower importance levels and the same type to be merged for processing, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This, in turn, reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0015] In some embodiments, after acquiring multiple interrupt requests within a preset time period and before generating at least one corresponding interrupt task based on at least one target interrupt request, the method further includes:

[0016] If the number of multiple interrupt requests exceeds a preset threshold, the multiple interrupt requests are sorted according to their timestamps to obtain an interrupt request sequence.

[0017] Based on the interruption request sequence, determine the third interruption request that ranks after a preset number threshold from multiple interruption requests;

[0018] The third interrupt request in the interrupt request sequence is temporarily stored or discarded to obtain at least one target interrupt request.

[0019] In this way, interrupt requests exceeding the preset threshold can be temporarily stored or discarded, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0020] In some embodiments, the third interrupt request in the interrupt request sequence is temporarily stored or discarded, including:

[0021] If the importance level of the third interrupt request is greater than or equal to the preset level threshold, or if the third interrupt request is an interrupt request that cannot be generated repeatedly, the third interrupt request will be temporarily stored.

[0022] If the importance level of the third interrupt request is less than the preset level threshold and the third interrupt request is a repeatable interrupt request, the third interrupt request will be discarded.

[0023] This allows for the temporary storage of interrupt requests that are of high importance or cannot be repeated, while interrupt requests that are of low importance and can be repeated are discarded. This reduces the number of interrupt requests while ensuring that important interrupt requests can be processed later, thereby guaranteeing the normal operation of the battery management system and improving its stability.

[0024] In some embodiments, processing interrupted tasks includes:

[0025] Get the priority of the interrupted task;

[0026] If the interrupt task has a higher priority than the target task being executed, terminate the target task and execute the interrupt task.

[0027] In this way, interrupt tasks can be handled by priority-based preemptive scheduling, ensuring that high-priority interrupt tasks can still be executed in a timely manner during periods of frequent interrupt events, thereby ensuring the normal operation of the battery management system and improving its stability.

[0028] In some embodiments, after executing the interrupt task, the method further includes:

[0029] Obtain the execution time slice of the interrupted task;

[0030] If the execution time of an interrupt task reaches its execution time slice, the interrupt task is terminated.

[0031] In this way, the processor's execution time slice can be reasonably allocated to interrupt tasks based on the task time slice rotation mechanism, preventing interrupt tasks from occupying the processor for a long time and causing other tasks to be unable to execute, thereby improving the utilization rate of battery management system resources.

[0032] In some embodiments, obtaining multiple interruption requests within a preset time period includes:

[0033] Get multiple initial interrupt requests within a preset time period. Each initial interrupt request carries the interrupt source that generated the initial interrupt request.

[0034] From multiple initial interrupt requests, identify the multiple interrupt requests whose interrupt source is a preset interrupt source.

[0035] This allows for verification of the validity of the interrupt source for the interrupt request, reducing the risk of task execution errors due to interrupt exceptions or errors, and improving the reliability of system operation.

[0036] In some embodiments, obtaining multiple interruption requests within a preset time period includes:

[0037] Receive multiple interrupt signals within a preset time period;

[0038] Identify multiple target interrupt signals, excluding noise signals, from a pool of interrupt signals;

[0039] Based on multiple target interrupt signals, obtain multiple interrupt requests;

[0040] The noise signal is at least one of the following:

[0041] An interrupt signal that becomes invalid after a preset jitter time;

[0042] Interruption signal with signal strength less than a preset strength threshold;

[0043] Other interrupt signals that are the same as the first interrupt signal received within the first time period, where the first time period is shorter than the preset time period, and the first interrupt signal is any interrupt signal.

[0044] This filters out noise signals in the interrupt signal, improving the accuracy of interrupt requests, reducing the risk of task execution errors due to interrupt exceptions or errors, and enhancing the reliability of system operation.

[0045] In some embodiments, after generating at least one corresponding interrupt task, the method further includes:

[0046] Perform a first hash operation on each interrupt task to obtain and store the first hash value of each interrupt task. The first hash value is a hash value of fixed length.

[0047] Handling interrupted tasks includes:

[0048] Perform a first hash operation on the interrupt task to be processed to obtain the second hash value of the interrupt task;

[0049] If the second hash value matches the third hash value, the interrupt task to be processed is processed, where the third hash value is the first hash value of the interrupt task to be processed.

[0050] In this way, during the interrupt task processing, the integrity of the interrupt task data can be verified to ensure the correctness and consistency of the interrupt task-related data and reduce the risk of interrupt task errors due to data loss.

[0051] In some embodiments, processing interrupted tasks includes:

[0052] Obtain the task code and handling function of the interrupt task; where the task code is the program code used to execute the interrupt task, and the handling function is the function used to handle the interrupt task in response to external input;

[0053] The task code and processing functions are security verified by a preset algorithm; the preset algorithm includes at least one of a checksum algorithm and an encryption algorithm.

[0054] If the security verification passes, the interrupted task will be handled.

[0055] In this way, during the interrupt task handling process, the task code and processing functions of the interrupt task can be securely verified to protect the task code and interrupt handling functions from malicious tampering, thereby reducing the risk of task execution abnormalities and improving the reliability of system operation.

[0056] In some embodiments, a preset algorithm is used to perform security verification on the task code and processing functions, including:

[0057] After generating at least one corresponding interrupt task, the task code and processing function of each interrupt task are processed using a preset algorithm to obtain and store the first check value corresponding to each interrupt task.

[0058] The task code and processing function of the interrupt task to be processed are calculated using a preset algorithm to obtain the second check value corresponding to the interrupt task to be processed.

[0059] The second check value is compared with the third check value; where the third check value is the first check value corresponding to the interrupt task to be processed.

[0060] If the security verification passes, the interrupted task is handled, including:

[0061] If the second check value matches the third check value, the interrupted task to be processed is processed.

[0062] In this way, during the interruption task processing, a checksum can be calculated using a preset algorithm to perform security verification on the task code and processing functions of the interrupted task, preventing the task code and processing functions from being maliciously tampered with, thereby reducing the risk of abnormal task execution.

[0063] Secondly, embodiments of this application also provide a battery management system, the device comprising:

[0064] A sampling circuit is used to acquire multiple interrupt requests within a preset time period;

[0065] Processor, used for:

[0066] If the frequencies of multiple interrupt requests meet a preset condition, at least some of the interrupt requests are merged to obtain at least one target interrupt request.

[0067] Generate at least one corresponding interrupt task based on at least one target interrupt request;

[0068] Handle interrupted tasks.

[0069] In this way, if the frequency of multiple interrupt requests within a preset time period meets preset conditions, at least some of the multiple interrupt requests can be merged to obtain at least one target interrupt request, which is fewer in number than the original multiple interrupt requests. Then, based on the at least one target interrupt request, at least one corresponding interrupt task is generated for processing. This reduces the number of interrupt tasks that need to be processed, thereby alleviating the task scheduling burden of the battery management system and improving its performance.

[0070] Thirdly, embodiments of this application provide a battery management system, the system including: a processor and a memory storing program instructions; the processor executes the program instructions to implement the method of the first aspect.

[0071] Fourthly, embodiments of this application provide a machine-readable storage medium storing program instructions, which, when executed by a processor, implement the method of the first aspect.

[0072] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the method of the first aspect.

[0073] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

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

[0075] Figure 1 One of the flowcharts of the task processing method provided in the embodiments of this application;

[0076] Figure 2A second schematic flowchart illustrating the task processing method provided in this application embodiment;

[0077] Figure 3 The third flowchart illustrating the task processing method provided in this application embodiment;

[0078] Figure 4 The fourth flowchart illustrating the task processing method provided in this application embodiment;

[0079] Figure 5 Fifth flowchart illustrating the task processing method provided in the embodiments of this application;

[0080] Figure 6 A flowchart illustrating the task processing method provided in this application embodiment is shown in Figure 6.

[0081] Figure 7 Seventh flowchart illustrating the task processing method provided in the embodiments of this application;

[0082] Figure 8 Eighth flowchart illustrating the task processing method provided in the embodiments of this application;

[0083] Figure 9 A flowchart illustrating the task processing method provided in this application embodiment is shown in Figure 9.

[0084] Figure 10 A flowchart illustrating the task processing method provided in this application embodiment is shown in Figure 10.

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

[0086] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

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

[0088] The embodiments of this application will be described in further detail below with reference to the accompanying drawings and examples. The detailed description of the following embodiments and the accompanying drawings are used to illustrate the principles of this application by way of example, but should not be used to limit the scope of this application, that is, this application is not limited to the described embodiments.

[0089] In the description of this application, it should be noted that, unless otherwise stated, "a plurality of" means two or more; the terms "upper," "lower," "left," "right," "inner," and "outer," etc., indicating orientation or positional relationships, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. Furthermore, the terms "first," "second," and "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. "Vertical" is not vertical in the strict sense, but within the allowable tolerance range. "Parallel" is not parallel in the strict sense, but within the allowable tolerance range.

[0090] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

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

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

[0093] Unless otherwise specified, all steps of this application may be performed sequentially or randomly, preferably sequentially. For example, the method includes steps (a) and (b), indicating that the method may include steps (a) and (b) performed sequentially, or it may include steps (b) and (a) performed sequentially. For example, the mention that the method may also include step (c) indicates 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.

[0094] 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.

[0095] It should be noted that the battery management system in this application can be integrated as a controller into the battery device, such as into the battery pack or energy storage box.

[0096] The battery management system in this application can also be integrated as a controller into electrical devices, such as in a vehicle or vehicle chassis.

[0097] The battery management system in this application can also be integrated into the charging device as a controller, such as into the charging device or the battery swapping device.

[0098] The battery management system in this application can also be deployed as control software on a server. The 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.

[0099] In related technologies, when a battery management system performs battery management tasks (such as battery status monitoring, power estimation, and equalization control), it needs to schedule the battery management tasks according to the execution status of each task. For example, when an interrupt event occurs, an interrupt request will be generated to trigger an interrupt task. The task scheduler of the battery management system needs to schedule the interrupt task, and the task executor of the battery management system will execute the interrupt task according to the scheduling result.

[0100] However, in practical applications, due to factors such as hardware failure or external environmental interference, there may be a situation where a large number of interrupt events occur frequently in a short period of time in the battery management system. In this case, the battery management system will receive a large number of interrupt requests in a short period of time, and each interrupt request will trigger a corresponding interrupt task. This will overwhelm the task scheduler of the battery management system, thereby reducing system performance.

[0101] It is evident that how to reduce the task scheduling burden of the battery management system and improve system performance when a large number of interruption events occur frequently in a short period of time is an urgent problem to be solved.

[0102] This application provides an interrupt task handling method, system, medium, and product for a battery management system to solve the aforementioned technical problems. The interrupt task handling method for a battery management system provided in this application is described below.

[0103] Please refer to Figure 1 This application provides an interrupt task handling method for a battery management system, which may include:

[0104] Step 101: Obtain multiple interruption requests within a preset time period.

[0105] In step 101, it can be understood that when a specific interrupt event occurs from an interrupt source such as an external device, an internal timer, or a program fault, requiring the attention of the Central Processing Unit (CPU), the interrupt request trigger of the interrupt source will be configured to the "1" state and will notify the CPU by sending an interrupt request.

[0106] Interrupt events are urgent or high-priority events triggered by hardware or software (i.e., interrupt sources) to respond in real time to abnormal battery conditions. For example, interrupt event types may include overvoltage, undervoltage, overtemperature, overcurrent, short circuit, battery depletion, and communication failure.

[0107] An interrupt request is a signal triggered by hardware or software (i.e., an interrupt source) to immediately notify the CPU to handle an interrupt event.

[0108] It can acquire multiple interrupt requests received by the CPU within a preset time period. The preset time period can be a relatively short period of time set according to actual needs, and is not specifically limited here.

[0109] Step 102: If the frequencies of multiple interrupt requests meet preset conditions, at least some of the interrupt requests are merged to obtain at least one target interrupt request.

[0110] In step 102, the fact that the frequency of multiple interrupt requests meets a preset condition can characterize that a large number of interrupt requests occur frequently in a short period of time.

[0111] At least some of the interrupt requests from multiple interrupt requests can be merged. For example, interrupt requests with lower importance levels and the same type from multiple interrupt requests can be merged.

[0112] It is understandable that the importance level of an interrupt request can be predefined by the battery management system. If the interrupt event corresponding to the interrupt request will affect the performance of the battery management system, the interrupt request can be considered to have a high importance level; otherwise, it can be considered to have a low importance level. The criteria for judging importance are mainly based on system requirements, task priorities, and considerations of safety and stability, and are not specifically limited here. For example, an interrupt request triggered by a battery short circuit can be determined as a high importance interrupt request, while an interrupt request triggered by a battery detection timeout can be determined as a low importance interrupt request.

[0113] Merging interrupt requests of the same type can be done in two ways: either retaining only the first interrupt request obtained from multiple interrupt requests of the same type, or integrating the differing information from multiple interrupt requests of the same type and removing duplicate information to obtain a new interrupt request.

[0114] At least one target interrupt request can be obtained after merging at least some interrupt requests, wherein the target interrupt request may include interrupt requests obtained after merging and interrupt requests that have not undergone merging. It is understood that because at least some interrupt requests are reduced in number after merging, the number of at least one target interrupt request is less than the number of multiple interrupt requests.

[0115] Step 103: Generate at least one corresponding interrupt task based on at least one target interrupt request.

[0116] In step 103, each target interrupt request can generate a corresponding interrupt task. The number of interrupt tasks can be equal to the number of at least one target interrupt request. It is understood that the number of interrupt tasks is reduced compared to the initial number.

[0117] Step 104: Handle the interrupted task.

[0118] In step 104, a priority-based preemptive scheduling algorithm can be used to process interrupted tasks. This algorithm ensures that high-priority tasks can immediately preempt low-priority tasks. For example, each interrupted task and the normally executing battery management task are assigned a priority. A high-priority task can interrupt a running low-priority task and immediately acquire CPU resources. This ensures that high-priority interrupted tasks can still be executed promptly even during periods of frequent interrupt events.

[0119] Furthermore, interrupt task handling can incorporate a time-slice round-robin mechanism. This mechanism is a time-sharing scheduling algorithm that allocates a fixed CPU execution time slice to each task. When the execution time slice is exhausted, the task is forcibly switched, ensuring that all tasks fairly share CPU resources. In other words, processor execution time slices can be allocated reasonably among interrupt tasks, preventing some interrupt tasks from occupying the processor for extended periods and causing other tasks to be unable to execute.

[0120] In this way, if the frequency of multiple interrupt requests within a preset time period meets preset conditions, at least some of the multiple interrupt requests can be merged to obtain at least one target interrupt request, which is fewer in number than the original multiple interrupt requests. Then, based on the at least one target interrupt request, at least one corresponding interrupt task is generated for processing. This reduces the number of interrupt tasks that need to be processed, thereby alleviating the task scheduling burden of the battery management system and improving its performance.

[0121] In some embodiments, such as Figure 2 As shown, when the frequencies of multiple interrupt requests meet preset conditions, at least some of the interrupt requests are merged to obtain at least one target interrupt request, which may include:

[0122] Step 201: In the case where multiple interrupt requests include multiple first interrupt requests, determine the interrupt frequency of the multiple first interrupt requests; the first interrupt request is an interrupt request whose importance level is lower than a preset level threshold.

[0123] Step 202: When the interrupt frequency is greater than or equal to a preset frequency threshold, merge the first interrupt requests of the same type among the multiple first interrupt requests to obtain the second interrupt request.

[0124] Step 203: Based on the second interrupt request, the first interrupt request that has not been merged, and the other interrupt requests other than the first interrupt request among the multiple interrupt requests, at least one target interrupt request is obtained.

[0125] In this embodiment, the first interrupt request can be an interrupt request with an importance level lower than a preset threshold. In other words, the first interrupt request can be an interrupt request with a lower importance level preset by the system, such as an interrupt request corresponding to periodic battery status checks or some low-priority warning signals in a battery management system.

[0126] If multiple interrupt requests include multiple first interrupt requests, the interrupt frequency can be calculated based on the number of multiple first interrupt requests and their corresponding times.

[0127] If the interrupt frequency is greater than or equal to a preset frequency threshold, first interrupt requests of the same type among multiple first interrupt requests are merged to obtain a second interrupt request. In other words, when interrupt requests of lower importance occur frequently in a short period of time, interrupt requests of the same type can be obtained from these lower-importance interrupt requests, and these interrupt requests of the same type can be merged to obtain a second interrupt request.

[0128] For example, multiple wheel speed sensors are connected to the same wheel speed detection hardware module. Each wheel speed sensor generates an interrupt request when it detects a wheel speed change exceeding a certain range. These interrupt requests all originate from the wheel speed detection hardware module and can be considered as the same type of interrupt request. By monitoring the interrupt frequency of these requests and comparing it with a preset frequency threshold, frequent but less important interrupt requests of the same type are selected and merged. This reduces the number of interrupt requests, thereby reducing the number of interrupt task processing operations and the system load.

[0129] At least one target interrupt request can be obtained from the second interrupt request, the first interrupt request that has not been merged, and other interrupt requests other than the first interrupt request among a plurality of interrupt requests. In other words, at least one target interrupt request may include the merged interrupt request, the interrupt request that is of low importance but has not been merged due to low interrupt frequency or the absence of an interrupt request of the same type, and the interrupt request of high importance.

[0130] This allows multiple interrupt requests with lower importance levels and the same type to be merged for processing, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This, in turn, reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0131] In some embodiments, such as Figure 3 As shown, after acquiring multiple interrupt requests within a preset time period, and before generating at least one corresponding interrupt task based on at least one target interrupt request, the method may further include:

[0132] Step 301: When the number of multiple interrupt requests exceeds a preset threshold, sort the multiple interrupt requests according to the timestamps corresponding to the multiple interrupt requests to obtain an interrupt request sequence.

[0133] Step 302: Based on the interruption request sequence, determine the third interruption request ranked after a preset number threshold from multiple interruption requests;

[0134] Step 303: Temporarily store or discard the third interrupt request in the interrupt request sequence to obtain at least one target interrupt request.

[0135] In this embodiment, the number of multiple interrupt requests obtained within a preset time period can also be counted. When the number of interrupt requests exceeds a preset number threshold, the multiple interrupt requests can be sorted by the timestamps corresponding to the multiple interrupt requests to obtain an interrupt request sequence, and the third interrupt request ranked after the preset number threshold can be determined from the interrupt request sequence.

[0136] In other words, taking the number of interrupt requests as A, the preset threshold as B, and A being greater than B as an example, the AB interrupt requests following the Bth interrupt request can be identified as the third interrupt requests, based on the order in which they are acquired. These third interrupt requests can then be temporarily stored or discarded.

[0137] In this way, interrupt requests exceeding the preset threshold can be temporarily stored or discarded, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0138] In some embodiments, such as Figure 4 As shown, temporarily storing or discarding the third interrupt request in the interrupt request sequence can include:

[0139] Step 401: If the importance level of the third interrupt request is greater than or equal to the preset level threshold, or if the third interrupt request is a non-repeatable interrupt request, the third interrupt request is temporarily stored.

[0140] Step 402: If the importance level of the third interrupt request is less than the preset level threshold and the third interrupt request is a repeatable interrupt request, the third interrupt request is discarded.

[0141] In this embodiment, third interrupt requests with an importance level greater than or equal to a preset threshold, or those that cannot be repeatedly generated, can be temporarily stored. Third interrupt requests with an importance level less than the preset threshold and that can be repeatedly generated can be discarded.

[0142] For example, if certain third-party interrupt requests are critical to the normal operation of the system, and their loss could lead to system instability or data loss, these third-party interrupt requests can be temporarily stored and processed after the system load decreases. If certain third-party interrupt requests are not necessary for the normal operation of the system, and can be regenerated through other means even if lost, these third-party interrupt requests can be discarded directly.

[0143] This allows for the temporary storage of interrupt requests that are of high importance or cannot be repeated, while interrupt requests that are of low importance and can be repeated are discarded. This reduces the number of interrupt requests while ensuring that important interrupt requests can be processed later, thereby guaranteeing the normal operation of the battery management system and improving its stability.

[0144] In some embodiments, such as Figure 5 As shown, handling interrupted tasks can include:

[0145] Step 501: Obtain the priority of the interrupted task;

[0146] Step 502: If the priority of the interrupt task is higher than that of the target task being executed, terminate the target task and execute the interrupt task.

[0147] In this embodiment, the target task can be an interrupted task that is currently being executed, or another normal task that is currently being executed. If the priority of the interrupted task is higher than that of the target task, the execution of the target task can be stopped, and the target task can be moved to a processing sequence of the same priority, with the higher-priority interrupted task being executed first.

[0148] Understandably, although the importance of interrupt tasks is initially set during system design, it can be adjusted during actual operation based on factors such as system status and external events. In other words, the priority of interrupt tasks is not fixed and can be adjusted according to actual needs. This ensures that interrupt requests for high-importance tasks, such as battery status monitoring and battery balancing control in the battery management system, are generated and processed promptly. For lower-importance interrupt tasks, such as periodic battery status checks or low-priority warning signals, their priority can be appropriately reduced to avoid them excessively interfering with the system.

[0149] In this way, interrupt tasks can be handled by priority-based preemptive scheduling, ensuring that high-priority interrupt tasks can still be executed in a timely manner during periods of frequent interrupt events, thereby ensuring the normal operation of the battery management system and improving its stability.

[0150] In some embodiments, such as Figure 6 As shown, after executing the interrupt task, the method may also include:

[0151] Step 601: Obtain the execution time slice of the interrupted task;

[0152] Step 602: If the execution time of the interrupt task reaches the execution time slice, terminate the interrupt task.

[0153] In this embodiment, when the battery management system allocates the processor to a task, it assigns an execution time slice to that task. After the execution time slice is used up, the battery management system allocates the processor to the next task.

[0154] Based on this, the priority of each interrupt task and its corresponding execution time slice can be obtained, and the corresponding interrupt tasks can be executed according to their priority. When the execution time slice of an interrupt task ends, the next task is processed, thus achieving a reasonable allocation of processor time.

[0155] In this way, the processor's execution time slice can be reasonably allocated to interrupt tasks based on the task time slice rotation mechanism, preventing interrupt tasks from occupying the processor for a long time and causing other tasks to be unable to execute, thereby improving the utilization rate of battery management system resources.

[0156] In some embodiments, such as Figure 7 As shown, obtaining multiple interruption requests within a preset time period can include:

[0157] Step 701: Obtain multiple initial interrupt requests within a preset time period. Each initial interrupt request carries the interrupt source that generated the initial interrupt request.

[0158] Step 702: From multiple initial interrupt requests, identify multiple interrupt requests whose interrupt source is a preset interrupt source.

[0159] In this embodiment, in order to ensure that the system can respond to interruption requests correctly and that task execution will not be affected by abnormal or incorrect interruption requests, interruption requests can be filtered and verified.

[0160] For example, multiple initial interrupt requests within a preset time period can be obtained, each initial interrupt request carrying the interrupt source that generated the initial interrupt request.

[0161] The interrupt source can be verified to determine whether the initial interrupt request comes from a preset interrupt source, which can include preset hardware or software sources. If the interrupt source is a preset interrupt source, the initial interrupt request can be considered an interrupt request that needs to be processed; if the interrupt source is not a preset interrupt source, the initial interrupt request can be filtered out.

[0162] This allows for verification of the validity of the interrupt source for the interrupt request, reducing the risk of task execution errors due to interrupt exceptions or errors, and improving the reliability of system operation.

[0163] In some embodiments, such as Figure 8 As shown, obtaining multiple interruption requests within a preset time period can include:

[0164] Step 801: Receive multiple interrupt signals within a preset time period;

[0165] Step 802: Identify multiple target interrupt signals, excluding noise signals, from multiple interrupt signals;

[0166] Step 803: Obtain multiple interrupt requests based on multiple target interrupt signals;

[0167] The noise signal is at least one of the following:

[0168] An interrupt signal that becomes invalid after a preset jitter time;

[0169] Interruption signal with signal strength less than a preset strength threshold;

[0170] Other interrupt signals that are the same as the first interrupt signal received within the first time period, where the first time period is shorter than the preset time period, and the first interrupt signal is any interrupt signal.

[0171] In this embodiment, the interrupt signal can be filtered to remove possible noise signals and ensure the authenticity of the interrupt request.

[0172] For example, when an interrupt signal is detected, instead of responding immediately, a debounce period is waited before confirming whether the interrupt signal is still valid. If the interrupt signal remains stable during the debounce period, it is considered a genuine target interrupt signal; otherwise, it can be considered a noise signal.

[0173] Noise signals can also be filtered by setting a preset strength threshold. For example, interrupt signals with a strength lower than the preset strength threshold can be identified as noise signals.

[0174] If the system receives the same interrupt signal multiple times within a short period of time, it can be assumed that only the first interrupt signal is valid, while subsequent identical interrupt signals may be noise signals.

[0175] This filters out noise signals in the interrupt signal, improving the accuracy of interrupt requests, reducing the risk of task execution errors due to interrupt exceptions or errors, and enhancing the reliability of system operation.

[0176] In some embodiments, such as Figure 9 As shown, after generating at least one corresponding interrupt task, the method may further include:

[0177] Step 901: Perform a first hash operation on each interrupt task to obtain and store the first hash value of each interrupt task. The first hash value is a hash value of fixed length.

[0178] Handling interrupted tasks includes:

[0179] Step 902: Perform a first hash operation on the interrupt task to be processed to obtain the second hash value of the interrupt task to be processed;

[0180] Step 903: If the second hash value and the third hash value are the same, process the interrupt task to be processed, wherein the third hash value is the first hash value of the interrupt task to be processed.

[0181] In this embodiment, integrity verification can also be performed on the data related to the interrupted task. For example, a hash function (Message Digest Algorithm 5, MD5) can be used to map the data related to the interrupted task to a first hash value of fixed length, such as a 128-bit hash value. This first hash value is then stored.

[0182] When processing this interrupted task, a second hash value for the relevant data of the interrupted task can be calculated using MD5 and compared with the pre-stored first hash value. If the hash values ​​match, the verification is considered successful, and the interrupted task can be processed. If the hash values ​​do not match, the relevant data of the interrupted task is considered incomplete and may have been lost; in this case, the interrupted task is considered an erroneous task.

[0183] In this way, during the interrupt task processing, the integrity of the interrupt task data can be verified to ensure the correctness and consistency of the interrupt task-related data and reduce the risk of interrupt task errors due to data loss.

[0184] In some embodiments, such as Figure 10 As shown, handling interrupted tasks can include:

[0185] Step 1001: Obtain the task code and processing function of the interrupt task; wherein, the task code is the program code used to execute the interrupt task, and the processing function is the function used to handle the interrupt task in response to external input;

[0186] Step 1002: Perform security verification on the task code and processing function using a preset algorithm; the preset algorithm includes at least one of a checksum algorithm and an encryption algorithm.

[0187] Step 1003: If the security verification passes, process the interrupted task.

[0188] In this embodiment, the task code and processing functions can also be securely verified using checksum algorithms and / or encryption algorithms.

[0189] For example, a secure hash algorithm (such as SHA-256) can be used to calculate a checksum for the task code and interrupt handler functions when compiling or deploying them. The calculated checksum is stored in a secure location, such as read-only memory (ROM) or encrypted storage. During relay task processing, the checksum for the task code and interrupt handler functions can be recalculated periodically or each time the task code is loaded, and compared with the stored checksum. If they do not match, it indicates that the task code and interrupt handler functions may have been tampered with. If they match, the security verification is considered successful, and the interrupt task can be processed.

[0190] Furthermore, task code and interrupt handlers can be encrypted using symmetric or asymmetric encryption algorithms before compilation or deployment. The encryption key can be securely stored in the system, ensuring that only authorized system components can access it. During relay task processing, the key can be used to decrypt the task code and interrupt handlers, checking for tampering.

[0191] In this way, during the interrupt task handling process, the task code and processing functions of the interrupt task can be securely verified to protect the task code and interrupt handling functions from malicious tampering, thereby reducing the risk of task execution abnormalities and improving the reliability of system operation.

[0192] In some embodiments, performing security verification on task code and processing functions using a preset algorithm may include:

[0193] After generating at least one corresponding interrupt task, the task code and processing function of each interrupt task are processed using a preset algorithm to obtain and store the first check value corresponding to each interrupt task.

[0194] The task code and processing function of the interrupt task to be processed are calculated using a preset algorithm to obtain the second check value corresponding to the interrupt task to be processed.

[0195] The second check value is compared with the third check value; where the third check value is the first check value corresponding to the interrupt task to be processed.

[0196] If the security verification passes, the interrupted task will be processed, which may include:

[0197] If the second check value matches the third check value, the interrupted task to be processed is processed.

[0198] In this embodiment, the task code and processing function of a certain interrupted task can also be security verified. For example, a checksum algorithm and / or encryption algorithm can be used to calculate the task code and processing function to obtain a first check value and store it.

[0199] When processing this interrupted task, a second checksum value for the task code and processing function can be calculated using the same algorithm—a checksum algorithm and / or encryption algorithm—and compared with a pre-stored first checksum value. If the checksum values ​​match, the verification is considered successful, and the interrupted task can be processed. If the checksum values ​​do not match, it can be assumed that the task code and processing function of the interrupted task may have been maliciously tampered with, and in this case, the interrupted task is an erroneous task.

[0200] In this way, during the interruption task processing, a checksum can be calculated using a preset algorithm to perform security verification on the task code and processing functions of the interrupted task, preventing the task code and processing functions from being maliciously tampered with, thereby reducing the risk of abnormal task execution.

[0201] Based on the task processing method provided in the above embodiments, this application can also provide an embodiment of a corresponding battery management system.

[0202] like Figure 11 As shown, the battery management system 1100 may also include:

[0203] Sampling circuit 1101 is used to acquire multiple interrupt requests within a preset time period;

[0204] Processor 1102, used for:

[0205] If the frequencies of multiple interrupt requests meet a preset condition, at least some of the interrupt requests are merged to obtain at least one target interrupt request.

[0206] Generate at least one corresponding interrupt task based on at least one target interrupt request;

[0207] Handle interrupted tasks.

[0208] In this way, if the frequency of multiple interrupt requests within a preset time period meets preset conditions, at least some of the multiple interrupt requests can be merged to obtain at least one target interrupt request, which is fewer in number than the original multiple interrupt requests. Then, based on the at least one target interrupt request, at least one corresponding interrupt task is generated for processing. This reduces the number of interrupt tasks that need to be processed, thereby alleviating the task scheduling burden of the battery management system and improving its performance.

[0209] In some embodiments, the processor 1102 may also be used for:

[0210] In the case where multiple interrupt requests include multiple first interrupt requests, the interrupt frequency of the multiple first interrupt requests is determined; the first interrupt request is an interrupt request whose importance level is lower than a preset level threshold.

[0211] When the interrupt frequency is greater than or equal to a preset frequency threshold, first interrupt requests of the same type among multiple first interrupt requests are merged to obtain a second interrupt request.

[0212] At least one target interrupt request is obtained based on the second interrupt request, the first interrupt request that has not been merged, and the other interrupt requests other than the first interrupt request among the multiple interrupt requests.

[0213] This allows multiple interrupt requests with lower importance levels and the same type to be merged for processing, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This, in turn, reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0214] In some embodiments, the processor 1102 may also be used for:

[0215] If the number of multiple interrupt requests exceeds a preset threshold, the multiple interrupt requests are sorted according to their timestamps to obtain an interrupt request sequence.

[0216] Based on the interruption request sequence, determine the third interruption request that ranks after a preset number threshold from multiple interruption requests;

[0217] The third interrupt request in the interrupt request sequence is temporarily stored or discarded to obtain at least one target interrupt request.

[0218] In this way, interrupt requests exceeding the preset threshold can be temporarily stored or discarded, thereby reducing the number of interrupt requests and the number of interrupt tasks that need to be processed. This reduces the task scheduling burden of the battery management system and improves the performance of the battery management system.

[0219] In some embodiments, the processor 1102 may also be used for:

[0220] If the importance level of the third interrupt request is greater than or equal to the preset level threshold, or if the third interrupt request is an interrupt request that cannot be generated repeatedly, the third interrupt request will be temporarily stored.

[0221] If the importance level of the third interrupt request is less than the preset level threshold and the third interrupt request is a repeatable interrupt request, the third interrupt request will be discarded.

[0222] This allows for the temporary storage of interrupt requests that are of high importance or cannot be repeated, while interrupt requests that are of low importance and can be repeated are discarded. This reduces the number of interrupt requests while ensuring that important interrupt requests can be processed later, thereby guaranteeing the normal operation of the battery management system and improving its stability.

[0223] In some embodiments, the processor 1102 may also be used for:

[0224] Get the priority of the interrupted task;

[0225] If the interrupt task has a higher priority than the target task being executed, terminate the target task and execute the interrupt task.

[0226] In this way, interrupt tasks can be handled by priority-based preemptive scheduling, ensuring that high-priority interrupt tasks can still be executed in a timely manner during periods of frequent interrupt events, thereby ensuring the normal operation of the battery management system and improving its stability.

[0227] In some embodiments, the processor 1102 may also be used for:

[0228] Obtain the execution time slice of the interrupted task;

[0229] If the execution time of an interrupt task reaches its execution time slice, the interrupt task is terminated.

[0230] In this way, the processor's execution time slice can be reasonably allocated to interrupt tasks based on the task time slice rotation mechanism, preventing interrupt tasks from occupying the processor for a long time and causing other tasks to be unable to execute, thereby improving the utilization rate of battery management system resources.

[0231] In some embodiments, the sampling circuit 1101 can also be used for:

[0232] Get multiple initial interrupt requests within a preset time period. Each initial interrupt request carries the interrupt source that generated the initial interrupt request.

[0233] From multiple initial interrupt requests, identify the multiple interrupt requests whose interrupt source is a preset interrupt source.

[0234] This allows for verification of the validity of the interrupt source for the interrupt request, reducing the risk of task execution errors due to interrupt exceptions or errors, and improving the reliability of system operation.

[0235] In some embodiments, the sampling circuit 1101 can also be used for:

[0236] Receive multiple interrupt signals within a preset time period;

[0237] Identify multiple target interrupt signals, excluding noise signals, from a pool of interrupt signals;

[0238] Based on multiple target interrupt signals, obtain multiple interrupt requests;

[0239] The noise signal is at least one of the following:

[0240] An interrupt signal that becomes invalid after a preset jitter time;

[0241] Interruption signal with signal strength less than a preset strength threshold;

[0242] Other interrupt signals that are the same as the first interrupt signal received within the first time period, where the first time period is shorter than the preset time period, and the first interrupt signal is any interrupt signal.

[0243] This filters out noise signals in the interrupt signal, improving the accuracy of interrupt requests, reducing the risk of task execution errors due to interrupt exceptions or errors, and enhancing the reliability of system operation.

[0244] In some embodiments, the processor 1102 may also be used for:

[0245] Perform a first hash operation on each interrupt task to obtain and store the first hash value of each interrupt task. The first hash value is a hash value of fixed length.

[0246] Perform a first hash operation on the interrupt task to be processed to obtain the second hash value of the interrupt task;

[0247] If the second hash value matches the third hash value, the interrupt task to be processed is processed, where the third hash value is the first hash value of the interrupt task to be processed.

[0248] In this way, during the interrupt task processing, the integrity of the interrupt task data can be verified to ensure the correctness and consistency of the interrupt task-related data and reduce the risk of interrupt task errors due to data loss.

[0249] In some embodiments, the processor 1102 may also be used for:

[0250] Obtain the task code and handling function of the interrupt task; where the task code is the program code used to execute the interrupt task, and the handling function is the function used to handle the interrupt task in response to external input;

[0251] The task code and processing functions are security verified by a preset algorithm; the preset algorithm includes at least one of a checksum algorithm and an encryption algorithm.

[0252] If the security verification passes, the interrupted task will be handled.

[0253] In this way, during the interrupt task handling process, the task code and processing functions of the interrupt task can be securely verified to protect the task code and interrupt handling functions from malicious tampering, thereby reducing the risk of task execution abnormalities and improving the reliability of system operation.

[0254] In some embodiments, the processor 1102 may also be used for:

[0255] After generating at least one corresponding interrupt task, the task code and processing function of each interrupt task are processed using a preset algorithm to obtain and store the first check value corresponding to each interrupt task.

[0256] The task code and processing function of the interrupt task to be processed are calculated using a preset algorithm to obtain the second check value corresponding to the interrupt task to be processed.

[0257] The second check value is compared with the third check value; where the third check value is the first check value corresponding to the interrupt task to be processed.

[0258] If the second check value matches the third check value, the interrupted task to be processed is processed.

[0259] In this way, during the interruption task processing, a checksum can be calculated using a preset algorithm to perform security verification on the task code and processing functions of the interrupted task, preventing the task code and processing functions from being maliciously tampered with, thereby reducing the risk of abnormal task execution.

[0260] It should be noted that the information interaction and execution process between the above-mentioned systems / devices / units are based on the same concept as the method embodiments of this application. They are devices corresponding to the detection method of the above-mentioned battery cell baking equipment. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section. It will not be repeated here.

[0261] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0262] Reference Figure 12 The electronic device 1200 may include a processor 1201 and a memory 1202 storing programs or instructions. When the processor 1201 executes the program, it implements the steps in any of the above method embodiments.

[0263] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 1202 and executed by processor 1201 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0264] Specifically, the processor 1201 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.

[0265] Memory 1202 may include mass storage for data or instructions. For example, and not limitingly, memory 1202 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1202 may include removable or non-removable (or fixed) media. Where appropriate, memory 1202 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1202 is non-volatile solid-state memory.

[0266] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) 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 is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0267] The processor 1201 implements any of the methods described above by reading and executing programs or instructions stored in the memory 1202.

[0268] In one example, the electronic device may also include a communication interface 1203 and a bus 1204. The processor 1201, memory 1202, and communication interface 1203 are connected via the bus 1204 and communicate with each other.

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

[0270] Bus 1204 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 1204 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.

[0271] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a machine-readable storage medium for implementation. This machine-readable storage medium stores a program or instructions; when executed by a processor, the program or instructions implement any of the methods in the above embodiments. This machine-readable storage medium can be read by a machine such as a computer.

[0272] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0273] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0274] This application provides a computer program product stored in a machine-readable storage medium. The program product is executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0275] 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.

[0276] The functional modules shown in the above-described 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 grids such as the Internet, intranets, etc.

[0277] 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.

[0278] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and 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 a computer program or instructions. These programs or 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.

[0279] 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 task handling method for a battery management system, characterized in that, The method includes: Retrieve multiple interruption requests within a preset time period; If the frequency of the plurality of interrupt requests meets a preset condition, at least some of the interrupt requests are merged to obtain at least one target interrupt request. Based on the at least one target interrupt request, generate at least one corresponding interrupt task; The interrupted task is processed.

2. The method according to claim 1, characterized in that, When the frequencies of the multiple interrupt requests meet a preset condition, at least some of the multiple interrupt requests are merged to obtain at least one target interrupt request, including: In the case where the plurality of interrupt requests include a plurality of first interrupt requests, the interrupt frequency of the plurality of first interrupt requests is determined; the first interrupt request is an interrupt request whose importance level is lower than a preset level threshold. If the interrupt frequency is greater than or equal to a preset frequency threshold, the first interrupt requests of the same type among the plurality of first interrupt requests are merged to obtain a second interrupt request; At least one target interrupt request is obtained based on the second interrupt request, the first interrupt request that has not been merged, and the other interrupt requests among the plurality of interrupt requests besides the first interrupt request.

3. The method according to claim 1 or 2, characterized in that, After acquiring multiple interrupt requests within a preset time period and before generating at least one corresponding interrupt task based on the at least one target interrupt request, the method further includes: If the number of multiple interruption requests exceeds a preset threshold, the multiple interruption requests are sorted according to the timestamps corresponding to the multiple interruption requests to obtain an interruption request sequence. Based on the interruption request sequence, determine the third interruption request ranked after the preset number threshold from the plurality of interruption requests; The third interrupt request in the interrupt request sequence is temporarily stored or discarded to obtain at least one target interrupt request.

4. The method according to claim 3, characterized in that, The process of temporarily storing or discarding the third interrupt request in the interrupt request sequence includes: If the importance level of the third interrupt request is greater than or equal to a preset level threshold, or if the third interrupt request is a non-repeatable interrupt request, the third interrupt request will be temporarily stored. If the importance level of the third interruption request is less than the preset level threshold and the third interruption request is a repeatable interruption request, the third interruption request shall be discarded.

5. The method according to any one of claims 1 to 4, characterized in that, The process of handling the interrupted task includes: Obtain the priority of the interrupted task; If the priority of the interrupted task is higher than that of the currently executing target task, the target task is terminated and the interrupted task is executed.

6. The method according to claim 5, characterized in that, After executing the interrupt task, the method further includes: Obtain the execution time slice of the interrupted task; If the execution time of the interrupted task reaches the execution time slice, the interrupted task is terminated.

7. The method according to any one of claims 1 to 6, characterized in that, The acquisition of multiple interruption requests within a preset time period includes: Acquire multiple initial interrupt requests within a preset time period, wherein each initial interrupt request carries an interrupt source that generated the initial interrupt request; From the plurality of initial interrupt requests, the interrupt source is determined to be a preset interrupt source.

8. The method according to any one of claims 1 to 7, characterized in that, The acquisition of multiple interruption requests within a preset time period includes: Receive multiple interrupt signals within a preset time period; From the plurality of interrupt signals, identify a plurality of target interrupt signals excluding noise signals; Based on the multiple target interrupt signals, multiple interrupt requests are obtained; The noise signal is at least one of the following: An interrupt signal that becomes invalid after a preset jitter time; Interruption signal with signal strength less than a preset strength threshold; Other interrupt signals that are the same as the first interrupt signal received within a first time period, wherein the first time period is shorter than the preset time period, and the first interrupt signal is any interrupt signal.

9. The method according to any one of claims 1 to 8, characterized in that, After generating at least one corresponding interrupt task, the method further includes: Perform a first hash operation on each interrupt task to obtain a first hash value for each interrupt task and store it. The first hash value is a hash value of fixed length. The process of handling the interrupted task includes: Perform the first hash operation on the interrupt task to be processed to obtain the second hash value of the interrupt task to be processed; If the second hash value and the third hash value are the same, the interrupt task to be processed is processed, wherein the third hash value is the first hash value of the interrupt task to be processed.

10. The method according to any one of claims 1 to 9, characterized in that, The process of handling the interrupted task includes: Obtain the task code and processing function of the interrupt task; wherein, the task code is program code for executing the interrupt task, and the processing function is a function for responding to external input and processing the interrupt task; The task code and the processing function are security verified by a preset algorithm; the preset algorithm includes at least one of a checksum algorithm and an encryption algorithm. If the security verification passes, the interrupted task will be processed.

11. The method according to claim 10, characterized in that, The security verification of the task code and the processing function using a preset algorithm includes: After generating at least one corresponding interrupt task, the task code and processing function of each interrupt task are processed using the preset algorithm to obtain and store the first verification value corresponding to each interrupt task. The task code and processing function of the interrupt task to be processed are calculated using the preset algorithm to obtain the second verification value corresponding to the interrupt task to be processed. The second check value is compared with the third check value; wherein the third check value is the first check value corresponding to the interrupt task to be processed; The process of handling the interrupted task after the security verification is passed includes: If the second check value matches the third check value, the interrupted task to be processed is processed.

12. A battery management system, characterized in that, The system includes: A sampling circuit is used to acquire multiple interrupt requests within a preset time period; Processor, used for: If the frequency of the plurality of interrupt requests meets a preset condition, at least some of the interrupt requests are merged to obtain at least one target interrupt request. Based on the at least one target interrupt request, generate at least one corresponding interrupt task; The interrupted task is processed.

13. A battery management system, characterized in that, The system includes: a processor and a memory storing programs or instructions; When the processor executes the program or instructions, it implements the method as described in any one of claims 1-11.

14. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-11.

Images