Lithium battery edge state estimation method and device, computer equipment and storage medium

Abstract

The application relates to a lithium battery edge state estimation method and device, computer equipment and a storage medium. The method comprises the following steps: obtaining a state estimation model of at least one battery to be deployed, constructing a calculation graph of the state estimation model, and performing data flow feature analysis on each network layer in the calculation graph to extract the calculation density and data multiplexing degree of each network layer; each network layer is divided into a calculation mode, and the type of the calculation mode at least comprises a dense mode in which the calculation density is higher than a first preset threshold; according to the division result of the calculation mode, the calculation graph is cut into a plurality of task nodes to generate a task-level dependency graph; and according to the task-level dependency graph, the task nodes corresponding to the dense mode are scheduled to an acceleration calculation layer for execution. The method can improve the real-time performance and calculation energy efficiency of battery state estimation, and realize multi-task collaborative acceleration.

Description

Technical Field

[0001] This application relates to the field of lithium battery technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for estimating the edge state of a lithium battery. Background Technology

[0002] The battery management system (BMS) is the core component ensuring the safe, reliable, and efficient operation of a battery pack. Accurate estimation of the State of Charge (SOC) is one of the key tasks of the BMS, directly impacting energy management strategies and overall system safety.

[0003] Currently, battery state estimation methods are mainly divided into two categories. The first category is traditional model-driven methods, such as the Extended Kalman Filter (EKF) based on the equivalent circuit model. These methods recursively estimate the state by establishing a mathematical / electrical model of the battery. However, their model parameters are easily affected by factors such as battery aging and temperature changes, leading to drift and a decrease in estimation accuracy. At the same time, the complex electrochemical models built to improve accuracy involve huge computational loads, making it difficult to meet the real-time requirements of the automotive environment. The second category is data-driven neural network methods, which directly learn nonlinear mappings from historical data through models such as Long Short-Term Memory Networks (LSTM) or Convolutional Neural Networks (CNN), and their accuracy is usually better than traditional methods. However, the powerful performance of neural networks comes with massive multiplication and accumulation calculations. Running such algorithms on general-purpose microcontrollers (MCUs) results in severe computational latency due to the architectural limitations of sequential execution of devices, making it difficult to meet real-time requirements; deployment on graphics processing units (GPUs) results in excessive power consumption, which contradicts the stringent low-power requirements of battery management systems.

[0004] Therefore, there is an urgent need for a lithium battery edge state estimation method, device, computer equipment, computer-readable storage medium, and computer program product that can improve the real-time performance and computational efficiency of battery state estimation and achieve multi-task collaborative acceleration. Summary of the Invention

[0005] Therefore, it is necessary to provide a lithium battery edge state estimation method, device, computer equipment, computer-readable storage medium, and computer program product that can improve the real-time performance and computational efficiency of battery state estimation and achieve multi-task collaborative acceleration, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for estimating the edge state of a lithium battery, including:

[0007] Obtain a state estimation model for at least one battery to be deployed, construct a computational graph of the state estimation model, and perform data flow feature analysis on each network layer in the computational graph to extract the computational density and data reuse of each network layer.

[0008] Each network layer is divided into computational modes, and the types of computational modes include at least dense modes with computational density higher than a first preset threshold.

[0009] Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph;

[0010] Based on the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution.

[0011] In one embodiment, the data flow feature analysis of each network layer in the computation graph includes:

[0012] Extract the computational density, data reuse, parallelism, storage access patterns, and inter-layer data dependencies for each network layer;

[0013] Based on the results of the data flow feature analysis, a directed acyclic graph representation of the computation graph is constructed, providing a classification basis for the division of the computation patterns; wherein, the computation density is used to characterize the number of multiply-accumulate operations required per unit of input data, and the data reuse degree is used to characterize the average number of times the weight parameters are used in the inference process.

[0014] In one embodiment, the computation mode type further includes vector mode and control mode; the method further includes:

[0015] When the computation mode of the task node is vector mode, it is determined whether the accelerated computing layer supports time-sharing multiplexing. If it does, the accelerated computing layer executes the task in a time-sharing manner; otherwise, the task is executed by the general-purpose processor.

[0016] When the computation mode of the task node is control mode, it is executed by a general-purpose processor.

[0017] In one embodiment, the method further includes:

[0018] When the state estimation model of the at least one battery includes multiple models, a computational graph of each model is constructed, and a graph matching algorithm is used to identify the shared subgraphs between the computational graphs. The shared subgraphs are the network layer sequences shared by multiple models.

[0019] A shared feature cache area is partitioned in the on-chip memory of the accelerated computing layer, and the shared feature cache area is used to store the output feature map of the shared subgraph;

[0020] The usage count of the output feature map is tracked, and when all tasks that depend on the output feature map have been completed, the cache space storing the output feature map in the shared feature cache is released.

[0021] In one embodiment, scheduling the task nodes corresponding to the intensive mode to the accelerated computing layer for execution according to the task-level dependency graph includes:

[0022] Acquire real-time operating condition data of the battery, wherein the real-time operating condition data includes at least one of voltage, current and temperature;

[0023] The priority of each estimation task is dynamically adjusted based on the changing trend of the real-time operating data.

[0024] Select the highest priority task node from the ready queue and dispatch it for execution.

[0025] In one embodiment, scheduling the task node corresponding to the intensive mode to the accelerated computing layer for execution further includes:

[0026] Based on the computing mode corresponding to the task node, configure the computing unit of the accelerated computing layer as the corresponding hardware pipeline structure;

[0027] Input data is transmitted to the input buffer of the computing unit via direct memory access.

[0028] The computing unit is activated to perform a multiply-accumulate array operation, and the result is returned after the calculation is completed.

[0029] Secondly, this application also provides a lithium battery edge state estimation device, comprising:

[0030] The offline analysis module is used to obtain the state estimation model of at least one battery to be deployed, construct the computation graph of the state estimation model, and perform data flow feature analysis on each network layer of the computation graph to extract the computation density and data reuse of each network layer.

[0031] The pattern partitioning module is used to partition each network layer into computational patterns, wherein the types of computational patterns include at least dense patterns with computational density higher than a first preset threshold.

[0032] The task segmentation module is used to segment the computation graph into multiple task nodes according to the division result of the computation mode, and generate a task-level dependency graph.

[0033] The scheduling and execution module is used to schedule the task nodes corresponding to the intensive mode to the accelerated computing layer for execution according to the task-level dependency graph.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0035] Obtain a state estimation model for at least one battery to be deployed, construct a computational graph of the state estimation model, and perform data flow feature analysis on each network layer in the computational graph to extract the computational density and data reuse of each network layer.

[0036] Each network layer is divided into computational modes, and the types of computational modes include at least dense modes with computational density higher than a first preset threshold.

[0037] Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph;

[0038] Based on the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution.

[0039] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0040] Obtain a state estimation model for at least one battery to be deployed, construct a computational graph of the state estimation model, and perform data flow feature analysis on each network layer in the computational graph to extract the computational density and data reuse of each network layer.

[0041] Each network layer is divided into computational modes, and the types of computational modes include at least dense modes with computational density higher than a first preset threshold.

[0042] Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph;

[0043] Based on the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution.

[0044] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0045] Obtain a state estimation model for at least one battery to be deployed, construct a computational graph of the state estimation model, and perform data flow feature analysis on each network layer in the computational graph to extract the computational density and data reuse of each network layer.

[0046] Each network layer is divided into computational modes, and the types of computational modes include at least dense modes with computational density higher than a first preset threshold.

[0047] Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph;

[0048] Based on the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution.

[0049] The aforementioned lithium battery edge state estimation method, apparatus, computer equipment, computer-readable storage medium, and computer program product acquire a battery state estimation model and construct a computational graph. They then perform data flow feature analysis on each network layer to extract computational density and data reuse. Network layers with computational density exceeding a preset threshold are classified as intensive modes, and the computational graph is divided into multiple task nodes to generate a task-level dependency graph. Finally, based on this dependency graph, the task nodes corresponding to the intensive modes are scheduled to be executed in the accelerated computation layer. Compared to traditional solutions where all neural network computation tasks are executed sequentially by a general-purpose processor, resulting in large computational latency and poor real-time performance, this solution offloads computationally intensive network layer tasks to an accelerated computation layer with parallel computing capabilities. This utilizes a hardware parallel pipeline to significantly shorten the time required for a single inference iteration, meeting the real-time requirements of automotive environments. Furthermore, compared to high-power solutions using graphics processing units (GPUs) for acceleration, the general-purpose processor in this solution only handles control operations such as task scheduling and data flow management, without handling massive multiplication and accumulation operations, thus significantly reducing the overall system power consumption. Therefore, this method achieves high real-time performance and high energy efficiency in battery state estimation at the edge of the battery management system, effectively balancing the deployment requirements of complex algorithms with the resource constraints of embedded platforms. Attached Figure Description

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

[0051] Figure 1 This is a flowchart illustrating a lithium battery edge state estimation method in one embodiment;

[0052] Figure 2 This is a flowchart illustrating the lithium battery edge state estimation method in yet another embodiment;

[0053] Figure 3 This is a flowchart illustrating the lithium battery edge state estimation method in another embodiment;

[0054] Figure 4 This is a structural block diagram of a lithium battery edge state estimation device in one embodiment;

[0055] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0057] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0058] In one exemplary embodiment, such as Figure 1 As shown, a method for estimating the edge state of a lithium battery is provided. Taking the application of this method to a server as an example, the method includes the following steps S102 to S108. Wherein:

[0059] Step S102: Obtain the state estimation model of at least one battery to be deployed, construct the computation graph of the state estimation model, and perform data flow feature analysis on each network layer in the computation graph to extract the computation density and data reuse of each network layer.

[0060] Specifically, first, at least one battery state estimation model to be deployed is obtained. This model can be a single neural network model (e.g., a long short-term memory network model or a convolutional neural network model for state of charge estimation) or a combination of multiple models (e.g., two independent models used for both state of charge estimation and temperature estimation). Then, for the obtained model, its corresponding computation graph is constructed. This computation graph represents the data flow relationships and computational dependencies between the network layers in the model in the form of a directed graph. Based on this, data flow feature analysis is performed on each network layer in the computation graph, focusing on extracting two key indicators: computational density and data reuse. Computational density measures the computational intensity of the network layer, specifically defined as the ratio of the total number of multiply-accumulate operations required to complete the inference of that layer to the amount of input data (in bytes), i.e., the number of multiply-accumulate operations per byte of input data. A higher value indicates a more computationally intensive layer. Data reuse is used to characterize the average number of times the weight parameters in a single forward inference process in the network layer. That is, the ratio of the total number of times the weights are accessed to the total number of weights. The higher the value, the higher the degree to which the weights can be reused, and the more suitable it is to be accelerated by hardware parallelism.

[0061] Step S104: Divide each network layer into computational modes. The types of computational modes include at least dense modes with computational density higher than a first preset threshold.

[0062] Specifically, after analyzing the data flow characteristics of each network layer in the computation graph and extracting quantitative indicators such as computational density and data reuse for each layer, each network layer is divided into different computational modes based on preset thresholds. Specifically, a first preset threshold is set to measure the computational density. This threshold can be dynamically adjusted during deployment based on the resource availability of the target reconfigurable hardware platform (such as the number of available multiply-accumulate units, on-chip storage capacity, and data bit width). For a given network layer, its computational density is compared with the first preset threshold: if the computational density of the layer is higher than the first preset threshold, the layer is classified as a dense mode. A dense mode is characterized by a layer requiring a much larger number of multiply-accumulate operations than its input data volume, belonging to a type of network layer with high computational intensity suitable for acceleration through hardware parallel pipelines. In typical neural network models for battery state estimation, convolutional layers and fully connected layers usually meet the conditions for a dense mode because these two types of layers need to perform repetitive multiply-accumulate operations on a large amount of input data and weight parameters, and their computational density is often significantly higher than other types of layers. When dividing the data, multiple indicators such as computational density, data reuse, parallelism, and storage access patterns of each layer can be used for comprehensive judgment. However, computational density is the core basis for dividing the data into intensive modes and has the highest weight.

[0063] Step S106: Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph.

[0064] Specifically, after dividing the computational patterns of each network layer in the computation graph, the original computation graph is task-segmented based on the segmentation results. Specifically, multiple network layers with the same computational pattern and arranged consecutively in the original computation graph are merged into a single task node. Each task node can contain one or more consecutive layers of the same pattern, thus aggregating fine-grained network layer-level operations into several coarse-grained task nodes. This segmentation method reduces runtime scheduling overhead and matches the computational granularity of each task node with the processing power of the underlying hardware resources. Based on the task node segmentation, the dependency relationships between task nodes are constructed according to the original data dependencies between network layers (i.e., the flow and sequence constraints of input-output feature maps between layers), thereby generating a task-level dependency graph. This dependency graph is represented as a directed acyclic graph, where each node represents a segmented task node, and the directed edges represent data dependency constraints between task nodes. That is, when the output of one task node is used as the input of another task node, the former must be completed before the latter begins execution. While generating the task-level dependency graph, it is also necessary to label each task node with relevant information, including the computation mode to which the node belongs (e.g., intensive mode, vector mode, or control mode), the expected computational cost of the node (e.g., the number of multiply-accumulate operations or execution cycles required), and the amount of input and output data of the node (e.g., the storage space occupied by the feature map). This labeled information will serve as input to the runtime scheduler for scheduling decisions and resource allocation.

[0065] Step S108: Based on the task-level dependency graph, schedule the task nodes corresponding to the intensive mode to the accelerated computing layer for execution.

[0066] Specifically, during runtime, the control layer, run by the general-purpose processor, obtains the task-level dependency graph generated in the aforementioned steps. Each task node in this dependency graph is labeled with its corresponding computation mode. The control layer maintains a ready queue, which stores task nodes whose current dependency conditions are met (i.e., all preceding task nodes have been completed) and are waiting to be executed. When a task node corresponding to a dense mode exists in the ready queue, the control layer removes the task node from the ready queue and schedules it to the accelerated computing layer for execution. The characteristics of dense modes include high computational density (>100 MAC / Byte), high data reuse, and large parallel potential; typical layers include convolutional layers and fully connected layers, mapped to parallel arrays in reconfigurable computing units. Specifically, the control layer first checks if the accelerated computing layer is idle. If the accelerated computing layer is currently busy executing other intensive task nodes, the task node is returned to the ready queue or waiting queue and scheduled again when the accelerated computing layer becomes idle. If the accelerated computing layer is idle, the control layer configures the hardware computing unit corresponding to the task node, including setting parameters such as parallelism, data bit width, and computing array structure according to the intensive mode of the task node, adapting it to the computational characteristics of the network layer corresponding to the task node. After configuration, the control layer transfers the input data (e.g., feature map data) required by the task node from system memory to the input buffer of the accelerated computing layer via direct memory access. Simultaneously, the weight parameters involved in the task node have been pre-loaded into the weight memory of the accelerated computing layer during the offline phase, so they do not need to be reloaded during execution. After the input data transmission is complete, the control layer sends a start signal to the accelerated computing layer, triggering the accelerated computing layer to perform multiply-accumulate array operations on the task node, completing all multiply-accumulate operations corresponding to the network layer in a hardware parallel pipeline manner. After the accelerated computing layer completes its execution, it stores the calculation results (e.g., output feature maps) in a designated location and returns a completion signal to the control layer. Upon receiving the completion signal, the control layer updates the dependency state of relevant task nodes according to the task-level dependency graph, adds subsequent task nodes whose dependency conditions have been met to the ready queue, and continues to schedule the next task node. In this way, task nodes corresponding to intensive modes are scheduled to be executed in an orderly manner by the accelerated computing layer, thereby leveraging hardware parallelism to accelerate the computationally intensive parts of the battery state estimation model, while the control layer is only responsible for control-intensive operations such as task scheduling, state management, and data transmission.

[0067] In the aforementioned lithium battery edge state estimation method, a battery state estimation model is acquired and a computation graph is constructed. Data flow feature analysis is performed on each network layer to extract computational density and data reuse. Network layers with computational density exceeding a preset threshold are then classified as intensive modes. The computation graph is further divided into multiple task nodes to generate a task-level dependency graph. Finally, based on this dependency graph, the task nodes corresponding to the intensive modes are scheduled to the accelerated computation layer for execution. Compared to the traditional approach where all neural network computation tasks are executed sequentially by a general-purpose processor, resulting in large computational latency and poor real-time performance, this approach offloads computationally intensive network layer tasks to an accelerated computation layer with parallel computing capabilities. This utilizes a hardware parallel pipeline to significantly shorten the time required for a single inference iteration, meeting the real-time requirements of an automotive environment. Furthermore, compared to high-power solutions using graphics processing units (GPUs) for acceleration, the general-purpose processor in this approach only handles control operations such as task scheduling and data flow management, without undertaking massive multiplication and accumulation operations, thus significantly reducing the overall system power consumption. Therefore, this method achieves high real-time performance and high energy efficiency in battery state estimation at the edge of the battery management system, effectively balancing the deployment requirements of complex algorithms with the resource constraints of embedded platforms.

[0068] In one exemplary embodiment, such as Figure 2 As shown, data flow characteristic analysis is performed on each network layer in the computation graph, including:

[0069] Step S202: Extract the computational density, data reuse, parallelism, storage access pattern, and inter-layer data dependencies for each network layer;

[0070] Step S204: Construct a directed acyclic graph representation of the computation graph based on the results of data flow feature analysis, and provide a classification basis for the division of computation patterns; wherein, computation density is used to characterize the number of multiply-accumulate operations required per unit of input data, and data reuse is used to characterize the average number of times the weight parameters are used in the inference process.

[0071] Specifically, firstly, for a given neural network model, it is converted into a computational graph representation, which describes the data flow relationships between network layers in the form of a directed graph. Based on this, multiple data flow feature information is extracted for each network layer.

[0072] First, we extract computational density, a feature used to measure the computational intensity of a network layer. Specifically, it is defined as the ratio of the total number of multiply-accumulate operations required to complete the inference of that layer to the total amount of input data (in bytes), i.e., the number of multiply-accumulate operations per byte of input data. A higher computational density indicates a more computationally intensive layer, making it more suitable for acceleration through hardware parallelism.

[0073] Second, data reuse is extracted. This feature characterizes the average number of times a weight parameter in a network layer is used in a single forward inference process. Specifically, it is defined as the ratio of the total number of accesses to the total number of weight parameters. The higher the data reuse, the more the weight data is reused during the computation process, which is more conducive to reducing external storage access through data caching or on-chip storage, thereby improving computational efficiency.

[0074] Third, extract the parallelism, a feature used to characterize the maximum number of parallel execution paths within a network layer. The value of parallelism is determined by parameters such as the number of input and output channels, kernel size, and stride of the layer. For example, for a convolutional layer, its parallelism can be reflected in the parallel computing capability in the output channel direction and the parallel accumulation capability in the input channel direction.

[0075] Fourth, extract the storage access pattern. This feature describes the access patterns of weight parameters and feature map data in the storage system, including but not limited to sequential access, random access, and sliding window access. Different storage access patterns correspond to different data prefetching and caching strategies, which is instructive for the storage interface design of hardware accelerators.

[0076] Fifth, extract the data dependencies between layers. This feature is used to characterize the data flow and sequential execution constraints between network layers. Specifically, it represents which preceding layers' outputs the input feature map of each network layer originates from, and which subsequent layers its output feature map will serve as the input to. These dependencies constitute the topology of the computation graph.

[0077] After extracting the five data flow features mentioned above, a directed acyclic graph (DAG) representation of the computation graph is constructed using the results of these feature analyses. Nodes represent network layers, and directed edges represent data dependencies between layers. Simultaneously, the extracted quantitative indicators such as computational density and data reuse provide direct classification criteria for subsequent computational pattern division: for example, network layers with computational density exceeding a preset threshold are suitable for classification as intensive patterns; network layers with low data reuse and moderate computational density may be classified as vector patterns; and network layers with extremely low computational density that include branch decisions or simple operations are suitable for classification as control patterns.

[0078] In this embodiment, by extracting computational density, data reuse, parallelism, storage access patterns, and inter-layer dependencies, the computational characteristics of each network layer are quantitatively characterized. This analysis enables computationally intensive layers to be accurately identified, thereby scheduling them to hardware acceleration units for execution, avoiding the real-time bottlenecks and power consumption overhead caused by general-purpose processors performing high-density computations.

[0079] In one exemplary embodiment, the computation mode types also include vector mode and control mode; the method further includes:

[0080] When the computation mode of the task node is vector mode, determine whether the accelerated computing layer supports time-sharing multiplexing. If it does, the accelerated computing layer will execute it in time-sharing mode; otherwise, the general-purpose processor will execute it.

[0081] When the task node's computation mode is control mode, it is executed by a general-purpose processor.

[0082] Specifically, for vector-based patterns, the computational density is moderate, the data flow is regular, and the weight reuse rate is generally low, typically corresponding to small-scale fully connected layers or element-wise operation layers. When these task nodes run, they first determine whether the accelerated computing layer supports time-sharing multiplexing: if the accelerated computing layer has time-sharing capabilities (e.g., multiple vector-based tasks can be executed sequentially on the same hardware unit via time-sharing), the task node is scheduled to the accelerated computing layer for execution in a time-sharing manner, thus making full use of hardware resources; if the accelerated computing layer does not support time-sharing multiplexing, the task node is handed over to a general-purpose processor for execution, which completes the computation in software. For control-based patterns, the computational density is low, involving branch judgments or simple operations, typically corresponding to activation function layers, pooling layers, or normalization layers. These task nodes do not involve large-scale multiplication-accumulation operations, therefore they do not need to be scheduled to the accelerated computing layer, but are directly executed by the general-purpose processor, utilizing the control capabilities of the general-purpose processor to quickly complete judgments and simple calculations.

[0083] In this embodiment, the optimal allocation of computing resources is achieved through the differentiated execution strategies for different computing modes: the accelerated computing layer focuses on processing intensive tasks with high computing density and high parallelism, as well as vector tasks where conditions permit, while the general-purpose processor undertakes control tasks and some vector tasks that are not suitable for hardware acceleration, thereby improving the overall execution efficiency and hardware utilization of the battery state estimation task.

[0084] In one exemplary embodiment, such as Figure 3 As shown, the method also includes:

[0085] Step S302: When the state estimation model of at least one battery includes multiple models, the computation graph of each model is constructed respectively, and the shared subgraph between the computation graphs is identified by the graph matching algorithm. The shared subgraph is the network layer sequence shared by multiple models.

[0086] Step S304: Divide the on-chip memory of the accelerated computing layer into a shared feature cache area, which is used to store the output feature map of the shared subgraph;

[0087] Step S306: Track the usage count of the output feature map. When all tasks that depend on the output feature map have been completed, release the cache space in the shared feature cache area that stores the output feature map.

[0088] Specifically, when the battery state estimation model to be deployed includes multiple models (e.g., two independent neural network models that need to estimate state of charge and temperature simultaneously), this method also performs multi-task collaborative processing. Specifically, firstly, each model's own computational graph is constructed, with each computational graph independently representing the network layer structure and data flow of its corresponding model. Then, a graph matching algorithm is used to compare and analyze the computational graphs, identifying the shared network layer sequences among multiple models; these shared sequences are called shared subgraphs. For example, the first few convolutional layers of two models may be identical, and these layers constitute a shared subgraph. After identifying the shared subgraph, a dedicated storage area, the shared feature cache, is allocated in the on-chip memory of the accelerated computation layer to store the output feature map generated after the shared subgraph is executed. Since multiple models share this subgraph, its output feature map can be reused by multiple subsequent tasks, avoiding the repeated execution of the same computation. To manage the lifecycle of the shared feature cache, the usage count of the output feature map also needs to be tracked, i.e., recording how many tasks dependent on this feature map have not yet been completed. When a task consumes the feature map, the usage count is decremented accordingly. When the usage count drops to zero, meaning all tasks that depend on the feature map have been completed, the cache space used to store the output feature map in the shared feature cache is released for use by other shared features later.

[0089] In this embodiment, through the above method, multiple battery state estimation models can reuse intermediate features on the accelerated computing layer, eliminate redundant calculations, reduce the number of accesses to off-chip memory, thereby reducing overall computing latency and improving hardware resource utilization.

[0090] In an exemplary embodiment, according to the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution, including:

[0091] Acquire real-time operating data of the battery, including at least one of voltage, current and temperature;

[0092] The priority of each estimation task is dynamically adjusted based on the changing trends of real-time operating data.

[0093] Select the highest priority task node from the ready queue and dispatch it for execution.

[0094] Specifically, during the process of scheduling task nodes corresponding to intensive modes to the accelerated computing layer, dynamic priority scheduling is further combined with real-time battery operating conditions. Specifically, firstly, real-time battery operating condition data is acquired, including at least one or more of the battery's voltage, current, and temperature. This data is collected in real-time by sensors in the battery management system and provided to the scheduler after preprocessing. Then, the scheduler dynamically adjusts the priority of each estimation task based on the changing trends of the real-time operating condition data. For example, when an abnormal upward trend in battery temperature is detected, the priority of the temperature estimation task is increased accordingly to ensure that the task can be scheduled for timely execution; when voltage or current fluctuates drastically, the priority of the state of charge estimation task can be increased to update the remaining charge information more frequently. Priority adjustments can be implemented according to preset rules or dynamic calculation models, and the specific adjustment range and triggering conditions can be configured according to application requirements during deployment. After completing the priority update, the scheduler selects the task node with the highest current priority from the ready queue for dispatch and execution. The ready queue stores all task nodes whose dependencies are met and are waiting to be executed, sorted by priority, with the head node being retrieved each time scheduling occurs.

[0095] In this embodiment, the dynamic priority scheduling mechanism described above can prioritize the response to estimation tasks most relevant to battery safety and reliability under limited computing resources, thereby improving the response timeliness and overall robustness of the battery management system under abnormal operating conditions.

[0096] In an exemplary embodiment, scheduling the task node corresponding to the intensive mode to the accelerated computing layer for execution further includes:

[0097] Based on the computing mode corresponding to the task node, configure the computing unit of the accelerated computing layer as the corresponding hardware pipeline structure.

[0098] Input data is transferred to the input buffer of the computing unit via direct memory access.

[0099] The computation unit is started to perform the multiply-accumulate array operation, and the result is returned after the calculation is completed.

[0100] Specifically, scheduling task nodes corresponding to intensive modes to the accelerated computing layer for execution further includes the following operations. First, based on the computing mode (i.e., intensive mode) of the task node to be executed, the computing units of the accelerated computing layer are configured in hardware to adapt to the computing characteristics of the network layer corresponding to the task node. Specifically, the configuration includes, but is not limited to, the parallelism of the computing units (i.e., the number of processing units in the multiply-accumulate array), the data bit width, and the hardware pipeline structure for different network layer types (such as convolutional layers or fully connected layers). For example, for convolutional layers, parameters such as the convolution kernel size, the number of input and output channels, and the stride need to be configured, and the corresponding sliding window buffer structure needs to be set; for fully connected layers, a parallel multiply-accumulate array mode is configured. The configuration operation is usually completed by the control layer through a dedicated configuration interface (such as the AXI Lite register). Second, after the configuration is completed, the input data required by the task node is transferred from the system memory to the input buffer of the computing unit through direct memory access. Direct memory access transfer does not require the intervention of a general-purpose processor in the data transfer process, which can efficiently complete the transfer of large blocks of data and reduce the burden on the control layer. Input data typically includes the input feature map of the current layer, while the weight parameters of this layer are pre-loaded into the weight memory of the computation unit during the offline phase, thus eliminating the need for repeated transmission during runtime. Next, the control layer sends a start signal to the computation unit, triggering it to execute multiply-accumulate array operations. The computation unit completes all multiply-accumulate operations involved in this network layer in parallel according to a pre-configured hardware pipeline structure, processing multiple multiply-accumulate operations per clock cycle, thereby significantly reducing computation latency. During computation execution, the control layer can handle other control tasks or wait for computation to complete. Finally, after the computation unit completes all operations, it stores the computation result (i.e., the output feature map) in a designated location (such as system memory or an on-chip shared buffer) and returns a completion signal or interrupt to the control layer. Upon receiving the completion signal, the control layer can retrieve the computation result for subsequent tasks or final output.

[0101] In this embodiment, the complete process of configuration, transmission, execution and return described above enables the efficient execution of intensive task nodes on the accelerated computing layer.

[0102] The most detailed embodiment of this application is as follows:

[0103] This embodiment uses a Xilinx Zynq series FPGA as a reconfigurable hardware platform to detail the specific implementation process of the lithium battery edge state estimation method. This platform integrates an ARM Cortex-A processor (as the control layer) and programmable logic (as the acceleration computing layer). This embodiment uses the co-estimation of lithium battery state of charge (SOC) and temperature as an example, assuming that two neural network models share the first two convolutional layers, followed by different fully connected layers.

[0104] First, configurable computing units are designed on the hardware platform. The fully connected computing unit employs a parallel multiply-accumulate array, composed of multiple digital signal processing (DSP) units. Each clock cycle, input data is broadcast from the input bus to all processing units (PEs), while weights are simultaneously read in parallel from multiple block random access memories (BRAMs), enabling parallel computation across multiple output channels. The degree of parallelism (i.e., the number of PEs) can be dynamically adjusted via configuration registers to accommodate fully connected layers of different sizes. The convolutional computing unit includes an input buffer, weight memory, PE array, addition tree, and activation / pooling modules. The input buffer implements a sliding window buffer, supporting convolution kernels of various sizes such as 1×1, 3×3, and 5×5. The PE array processes all multiplication operations within a sliding window each clock cycle. The addition tree is used to accumulate the results of each multiplication accumulation. The post-processing pipeline can select activation functions and pooling operations. All parameters (including convolution kernel size, number of input / output channels, stride, etc.) can be configured via AXI Lite registers.

[0105] The implementation process is divided into three stages: offline analysis, weight loading, and real-time scheduling.

[0106] Offline Analysis Phase: Obtain the lithium battery SOC estimation model and temperature estimation model to be deployed, and construct their respective computational graphs. Perform data flow feature analysis on each network layer in the computational graph, extracting the computational density, data reuse, parallelism, storage access pattern, and inter-layer data dependencies of each layer. Analysis results show that the computational density of the first two convolutional layers (denoted as Conv1 and Conv2) is higher than the first preset threshold, belonging to the intensive mode; at the same time, the graph matching algorithm identifies Conv1 and Conv2 as network layer sequences shared by the two models, forming a shared subgraph. The computational density of the two fully connected layers (denoted as FC_soc and FC_temp) is moderate, belonging to the vector mode. Based on the above division results, the original computational graph is divided into multiple task nodes: Conv1 and Conv2 are each a intensive task node, and FC_soc and FC_temp are each a vector task node. Generate a task-level dependency graph, where the output of Conv1 serves as the input of Conv2, and the output of Conv2 serves as the input of both FC_soc and FC_temp.

[0107] Weight loading stage: The ARM processor loads the weight parameters of Conv1 and Conv2 into the BRAM of the convolutional computation unit via the high-speed bus, and loads the weight parameters of FC_soc and FC_temp into the BRAM of the fully connected computation unit. Simultaneously, a shared feature cache is allocated in the on-chip memory of the programmable logic to store the output feature maps of the shared subgraphs later.

[0108] Real-time scheduling phase: After a new frame of real-time battery operating data (including voltage, current, and temperature) arrives, the scheduler adds the Conv1 task to the ready queue. At this time, the convolutional computation unit is idle. The ARM processor configures the parameters of the convolutional computation unit (e.g., 3×3 convolutional kernel, 16 output channels, etc.), and then initiates DMA transfer to transfer the input data from system memory to the input buffer of the convolutional computation unit. After the transfer is completed, the ARM sends a start signal to the convolutional computation unit, which performs multiply-accumulate array operations to complete the forward inference of Conv1. After Conv1 is completed, its output feature map is stored in the shared feature buffer, and the usage count of the feature map is set to 2 (because Conv2 and another branch need to rely on this feature map, the output of Conv1 is actually only used as the input of Conv2; here, "the usage count is set to 2" is understood as the counting management of the shared buffer; more accurately, the feature map is reused by the FC layer after Conv2 is completed). The scheduler then dispatches the Conv2 task, which is also executed by the convolutional computation unit, and the output feature map is stored in the shared feature buffer after completion. At this point, the shared subgraph has been completed, and both subsequent tasks, FC_soc and FC_temp, are ready.

[0109] Since there is only one fully connected computing unit on the hardware platform, the scheduler executes tasks in a time-sharing manner based on their current priorities. Initially, both the SOC estimation and temperature estimation tasks have normal priorities. The scheduler first executes the FC_soc task: the ARM configures the parameters of the fully connected computing unit, initiates DMA to transfer input data (i.e., the output feature map of Conv2), starts computation, and reads and sends the SOC estimation result to the SOC estimation module upon completion. Then, the FC_temp task is executed, and the predicted temperature value is sent to the temperature estimation module upon completion. During operation, if the scheduler detects an abnormal upward trend in battery temperature (e.g., the rate of temperature change exceeds a preset threshold), the priority of the temperature estimation task is dynamically increased. In subsequent scheduling cycles, the scheduler prioritizes the FC_temp task, and reduces the execution frequency of the SOC task when necessary (e.g., SOC estimation is performed every two scheduling cycles, while temperature estimation is performed every cycle), thereby ensuring a rapid response to abnormal conditions such as battery thermal runaway.

[0110] Through the above methods, this embodiment schedules computationally intensive convolutional layer tasks to be executed in an accelerated computing layer composed of programmable logic, significantly shortening inference latency by utilizing hardware parallel pipelines; simultaneously, by reusing the feature cache of the shared subgraph, redundant computation of Conv1 and Conv2 is avoided; and through dynamic priority scheduling, priority is given to critical tasks under resource-constrained conditions. This embodiment fully implements the lithium battery edge state estimation method proposed in this invention.

[0111] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0112] Based on the same inventive concept, this application also provides a lithium battery edge state estimation device for implementing the lithium battery edge state estimation method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the lithium battery edge state estimation device provided below can be found in the limitations of the lithium battery edge state estimation method described above, and will not be repeated here.

[0113] In one exemplary embodiment, such as Figure 4 As shown, a lithium battery edge state estimation device is provided, comprising:

[0114] The offline analysis module 402 is used to obtain the state estimation model of at least one battery to be deployed, construct the computation graph of the state estimation model, and perform data flow feature analysis on each network layer in the computation graph to extract the computation density and data reuse of each network layer.

[0115] The pattern partitioning module 404 is used to partition each network layer into computational patterns. The types of computational patterns include at least dense patterns with computational density higher than a first preset threshold.

[0116] The task partitioning module 406 is used to partition the computation graph into multiple task nodes based on the partitioning results of the computation mode, and generate a task-level dependency graph.

[0117] The scheduling and execution module 408 is used to schedule the task nodes corresponding to the intensive mode to the accelerated computing layer for execution based on the task-level dependency graph.

[0118] In an exemplary embodiment, the offline analysis module 402 is specifically used to extract the computation density, data reuse, parallelism, storage access pattern, and inter-layer data dependencies of each network layer; construct a directed acyclic graph representation of the computation graph based on the results of data flow feature analysis, and provide a classification basis for the division of computation patterns; wherein, the computation density is used to characterize the number of multiply-accumulate operations required per unit of input data, and the data reuse is used to characterize the average number of times the weight parameters are used in the inference process.

[0119] In an exemplary embodiment, the computing mode types also include vector mode and control mode; the scheduling execution module 408 is further configured to determine whether the accelerated computing layer supports time-sharing when the computing mode of the task node is vector mode, and if it does, the accelerated computing layer executes it in a time-sharing manner, otherwise, the general-purpose processor executes it; when the computing mode of the task node is control mode, the general-purpose processor executes it.

[0120] In an exemplary embodiment, the scheduling execution module 408 is further configured to: construct computational graphs for each model when the state estimation model of at least one battery includes multiple models; identify shared subgraphs between the computational graphs using a graph matching algorithm, wherein the shared subgraphs are network layer sequences shared by multiple models; partition a shared feature cache area in the on-chip memory of the accelerated computing layer, wherein the shared feature cache area is used to store the output feature maps of the shared subgraphs; track the usage count of the output feature maps; and release the cache space in the shared feature cache area storing the output feature maps when all tasks that depend on the output feature maps have been completed.

[0121] In an exemplary embodiment, the scheduling execution module 408 is specifically used to acquire real-time operating condition data of the battery, including at least one of voltage, current and temperature; dynamically adjust the priority of each estimation task according to the changing trend of the real-time operating condition data; and select the task node with the highest current priority from the ready queue for dispatch and execution.

[0122] In an exemplary embodiment, the scheduling execution module 408 is further configured to configure the computing unit of the accelerated computing layer as the corresponding hardware pipeline structure according to the computing mode corresponding to the task node; transmit the input data to the input buffer of the computing unit through direct memory access; start the computing unit to perform multiply-accumulate array operation, and return the result after the calculation is completed.

[0123] Each module in the aforementioned lithium battery edge state estimation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0124] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network. When executed by the processor, the computer program implements a lithium battery edge state estimation method.

[0125] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0126] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0127] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0128] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0129] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0130] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0131] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0132] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for estimating the edge state of a lithium battery, characterized in that, The method includes: Obtain a state estimation model for at least one battery to be deployed, construct a computational graph of the state estimation model, and perform data flow feature analysis on each network layer in the computational graph to extract the computational density and data reuse of each network layer. Each network layer is divided into computational modes, and the types of computational modes include at least dense modes with computational density higher than a first preset threshold. Based on the division results of the computation mode, the computation graph is divided into multiple task nodes to generate a task-level dependency graph; Based on the task-level dependency graph, the task nodes corresponding to the intensive mode are scheduled to the accelerated computing layer for execution.

2. The method according to claim 1, characterized in that, The data flow feature analysis of each network layer in the computation graph includes: Extract the computational density, data reuse, parallelism, storage access patterns, and inter-layer data dependencies for each network layer; Based on the results of the data flow feature analysis, a directed acyclic graph representation of the computation graph is constructed, providing a classification basis for the division of the computation patterns; wherein, the computation density is used to characterize the number of multiply-accumulate operations required per unit of input data, and the data reuse degree is used to characterize the average number of times the weight parameters are used in the inference process.

3. The method according to claim 1, characterized in that, The computational mode types also include vector-based mode and control mode; the method further includes: When the computation mode of the task node is vector mode, it is determined whether the accelerated computing layer supports time-sharing multiplexing. If it does, the accelerated computing layer executes the task in a time-sharing manner; otherwise, the task is executed by the general-purpose processor. When the computation mode of the task node is control mode, it is executed by a general-purpose processor.

4. The method according to claim 1, characterized in that, The method further includes: When the state estimation model of the at least one battery includes multiple models, a computational graph of each model is constructed, and a graph matching algorithm is used to identify the shared subgraphs between the computational graphs. The shared subgraphs are the network layer sequences shared by multiple models. A shared feature cache area is partitioned in the on-chip memory of the accelerated computing layer, and the shared feature cache area is used to store the output feature map of the shared subgraph; The usage count of the output feature map is tracked, and when all tasks that depend on the output feature map have been completed, the cache space storing the output feature map in the shared feature cache is released.

5. The method according to claim 1, characterized in that, The step of scheduling the task nodes corresponding to the intensive mode to the accelerated computing layer for execution according to the task-level dependency graph includes: Acquire real-time operating condition data of the battery, wherein the real-time operating condition data includes at least one of voltage, current and temperature; The priority of each estimation task is dynamically adjusted based on the changing trend of the real-time operating data. Select the highest priority task node from the ready queue and dispatch it for execution.

6. The method according to claim 1, characterized in that, The step of scheduling the task nodes corresponding to the intensive mode to the accelerated computing layer for execution also includes: Based on the computing mode corresponding to the task node, configure the computing unit of the accelerated computing layer as the corresponding hardware pipeline structure; Input data is transmitted to the input buffer of the computing unit via direct memory access. The computing unit is activated to perform a multiply-accumulate array operation, and the result is returned after the calculation is completed.

7. A lithium battery edge state estimation device, characterized in that, The device includes: The offline analysis module is used to obtain the state estimation model of at least one battery to be deployed, construct the computation graph of the state estimation model, and perform data flow feature analysis on each network layer of the computation graph to extract the computation density and data reuse of each network layer. The pattern partitioning module is used to partition each network layer into computational patterns, wherein the types of computational patterns include at least dense patterns with computational density higher than a first preset threshold. The task segmentation module is used to segment the computation graph into multiple task nodes according to the division result of the computation mode, and generate a task-level dependency graph. The scheduling and execution module is used to schedule the task nodes corresponding to the intensive mode to the accelerated computing layer for execution according to the task-level dependency graph.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images