Battery management system and energy storage system

Abstract

The embodiment of the application provides a battery management system and an energy storage system, relates to the technical field of battery management, and the battery management system is configured to: load a predefined JSON configuration file, the JSON configuration file comprising a plurality of storage units, a plurality of storage blocks and a plurality of storage files, any one of the plurality of storage blocks being associated with at least one of the plurality of storage units, any one of the plurality of storage files being associated with at least one of the plurality of storage blocks, and any one of the plurality of storage units corresponding to a single data point; parsing the JSON configuration file to obtain storage configuration information; and storing target collected data based on the storage configuration information, the target collected data at least comprising battery operation data of a battery cluster and environment data of a dynamic ring device. Through the embodiment of the application, the technical problem that the data storage configuration scheme of the energy storage battery management system in the prior art has insufficient configuration flexibility and is prone to generating redundant data is solved.

Description

Technical Field

[0001] This application relates to the field of battery management technology, and in particular to battery management systems and energy storage systems. Background Technology

[0002] During operation, energy storage battery management systems continuously collect operating parameters such as cell voltage, temperature, and charging / discharging current, and need to store the data according to the actual needs of different energy storage projects. However, traditional energy storage battery management systems suffer from insufficient configuration flexibility, making it difficult to adapt to the differentiated storage requirements of various projects and easily generating redundant data.

[0003] For at least one of the above-mentioned technical problems, the relevant technologies have not yet proposed an effective solution. Summary of the Invention

[0004] This application provides a battery management system and an energy storage system to solve one or more of the above-mentioned technical problems.

[0005] As one aspect of this application embodiment, this application embodiment provides a battery management system, which is communicatively connected to a battery cluster and an environmental monitoring device. The battery management system is configured to: load a predefined JSON configuration file, wherein the JSON configuration file includes a plurality of storage units, a plurality of storage blocks, and a plurality of storage files, wherein any storage block is associated with at least one of the plurality of storage units, and any storage file is associated with at least one of the plurality of storage blocks, and any storage unit corresponds to a single data point; parse the JSON configuration file to obtain storage configuration information; and store target collected data based on the storage configuration information, wherein the target collected data includes at least the battery operation data of the battery cluster and the environmental data of the environmental monitoring device.

[0006] As one aspect of the embodiments of this application, this application provides an energy storage system, including: the above-mentioned battery management system, battery cluster, and dynamic environment device, wherein the battery management system is communicatively connected to the battery cluster and the dynamic environment device.

[0007] The technical solution described in this application proposes a three-level configuration system from storage unit (i.e., a single data point) to storage block (i.e., a logical data group formed by combining multiple storage units), and then from storage block to storage file. That is, the storage configuration is clearly hierarchical from fine-grained to coarse-grained, and each level can be defined through a JSON configuration file. Users can flexibly add or delete storage fields and adjust the data structure according to the actual needs of the project without modifying any program code, realizing "zero-code" customization of the storage solution. This solves the technical problem that the data storage configuration scheme of the existing energy storage battery management system has insufficient configuration flexibility and is prone to generating redundant data.

[0008] 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, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0009] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0010] Figure 1 A schematic diagram of an energy storage system structure provided in an embodiment of this application;

[0011] Figure 2 A schematic diagram of the structure of a battery cell provided in an embodiment of this application is shown;

[0012] Figure 3 A flowchart illustrating a data storage method for a battery management system provided in an embodiment of this application is shown.

[0013] Figure 4 A structural block diagram of the controller used to implement the embodiments of this application is shown. Detailed Implementation

[0014] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0015] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0016] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0017] Figure 1 This is a schematic diagram of an energy storage system structure provided in an embodiment of this application. The energy storage system includes an environmental monitoring device, multiple parallel-connected battery clusters, and a battery management system. The battery management system is the top-level control unit in the three-level battery management system of the energy storage system. Multiple parallel-connected battery clusters form an energy storage battery array, serving as the main energy storage component of the energy storage system, completing the storage and release of electrical energy, and realizing the system's charging and discharging operation. The environmental monitoring device is an auxiliary device for the energy storage system, such as a liquid cooling unit, refrigeration equipment, and temperature control equipment, used to regulate the internal operating environment of the energy storage compartment, and simultaneously generating equipment operating status data. The battery management system communicates with each battery cluster and the environmental monitoring device. On one hand, it collects battery operating data from each battery cluster, such as individual cell voltage, individual cell temperature, cluster current, cluster power, and battery SOH, etc. On the other hand, it collects operating data from the environmental monitoring device, such as equipment operating status, temperature, and operating power, etc. The battery management system processes the acquired battery cluster data and environmental monitoring device data uniformly, executing the flexible configuration method for storing data in the energy storage battery management system of this embodiment of the application.

[0018] It should be noted that the embodiments of this application do not impose any special limitations on the geometry of the battery cell 400, which can be cylindrical, square, or other arbitrary shapes. For example, Figure 2 The image shows a square-structured battery cell 400. The battery cell 400 typically includes a housing 410, a cell 430, and a cover assembly 420. The housing 410 houses the cell 430, and the cover assembly has at least one positive electrode post and at least one negative electrode post. The cell 430 includes one or more electrode assemblies, which are formed by stacking or winding positive electrode sheets, negative electrode sheets, and a separator. The battery cell 400 is the basic unit constituting a battery, capable of storing chemical energy and controllably converting it into electrical energy. In recyclable battery cells, the active materials can be reactivated by charging after discharge for continued use. Battery cells 400 can be further combined into battery packs, which contain multiple battery cells, the specific number of which can be adjusted according to the actual application scenario and capacity requirements.

[0019] This application provides an optimization of the battery management system described above, which will be explained in detail below.

[0020] like Figure 3 As shown, the battery management system described above can be configured to: load a predefined JSON configuration file, wherein the JSON configuration file includes several storage units, several storage blocks, and several storage files, any storage block among the several storage blocks is associated with at least one of the several storage units, any storage file among the several storage files is associated with at least one of the several storage blocks, and any storage unit among the several storage units corresponds to a single data point; parse the JSON configuration file to obtain storage configuration information; and store target acquisition data based on the storage configuration information, wherein the target acquisition data includes at least the battery operation data of the battery cluster and the environmental data of the environmental monitoring device.

[0021] Optionally, the aforementioned storage unit is the smallest configuration unit for data acquisition and storage, corresponding to an independent data point in shared memory. The definition of each storage unit is described through a JSON configuration file. A storage block is composed of one or more storage units, forming a logical data group. A storage file references one or more storage blocks, ultimately generating an independent data file.

[0022] Each of the aforementioned storage units includes a first target field and the value of the first target field, wherein the first target field includes at least one of the following fields: data title name, data unit, data type, data source, offset address of data in shared memory, data scaling factor, data offset, and number of decimal places to retain.

[0023] Optionally, the data title name shall include at least a Chinese title and an English title; the data type shall include at least an integer type, a floating-point type, and a bit field type.

[0024] For example, a storage unit may include the following fields:

[0025] |Field Name|Description|

[0026] |titleName| Data title name, supports multilingual configuration (Chinese and English), separated by line breaks|

[0027] |unit| Data unit, such as (mV), (°C), (A)|

[0028] |dataType| Data type, including int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, float, double, and bits (bit field type)|

[0029] |dataSrc| Data source types, including rack (cluster data), bank (heap data), env (environmental data)|

[0030] |dataAddr| The address of the data in shared memory, supporting concatenation of up to 4 register addresses|

[0031] |factor| Data scaling factor, used for converting raw values ​​to engineered values|

[0032] |offset|Data offset|

[0033] |decimalPlaces|Keep decimal places|

[0034] Each of the aforementioned storage blocks includes a second target field and the value of the second target field, wherein the second target field includes at least one of the following fields: block name identifier, associated storage unit list, and batch quantity control parameter.

[0035] It is understandable that the batch quantity control parameter mentioned above is used to control the quantity of batch data. For example, for batch data such as cell voltage and cell temperature, when the batch quantity control parameter is set to 24, 24 independent data instances can be generated based on the storage unit template, each corresponding to the cell voltage data of 24 battery cells.

[0036] Each of the aforementioned storage files includes a third target field and the value of the third target field, wherein the third target field includes at least one of the following fields: logical device type, file prefix name, first storage period, second storage period, and associated storage block list, wherein the first storage period is longer than the second storage period.

[0037] Optionally, in this embodiment, the storage file can be a comma-separated values ​​(CSV) file and its storage strategy, representing the highest level of configuration. For example, each storage file contains at least the following configurations:

[0038] |Field Name|Description|

[0039] |Logical Device|Logical device types: rack (cluster), bank (heap), env (environmental device)|

[0040] |filePrefix|File Prefix Name|

[0041] |staticStorageCycle|Storage cycle under static conditions (unit: seconds)|

[0042] |dynamicStorageCycle|Storage cycle under dynamic operating conditions (unit: seconds)|

[0043] |storageBlocks|List of referenced storage blocks|

[0044] The battery management system provided in this application proposes a three-level configuration system from storage unit to storage block, and then from storage block to storage file. That is, the storage configuration is clearly hierarchical from fine-grained to coarse-grained, and each level can be defined through JSON configuration files. Users can flexibly add or delete storage fields and adjust data structures according to the actual needs of the project without modifying any program code, thus realizing "zero-code" customization of the storage solution. This solves the technical problem that the data storage configuration scheme of the existing energy storage battery management system has insufficient configuration flexibility and is prone to generating redundant data.

[0045] In an optional implementation, when the above data type is a bit field type, the target acquisition data can be stored based on the storage configuration information in the following way: the target acquisition data is decomposed according to the mask to obtain the decomposed bit field data; the decomposed bit field data is mapped to the storage area corresponding to the shared memory.

[0046] Understandably, bit-field data types define the start bit, bit length, and name suffix for each bit segment, enabling the split storage of multiple independent bit segments within a single register address. This application's embodiment features targeted optimizations to the underlying read / write mechanism, employing register bitmask direct read and zero-copy mapping techniques. After configuring the bit-field parameters at the application layer, the underlying driver directly decomposes and maps the data to shared memory according to the mask, avoiding the additional Central Processing Unit (CPU) overhead caused by bitwise shift operations in the application layer software. This approach maintains high-concurrency acquisition performance for massive data points while ensuring extremely fine-grained configuration, and supports automatic concatenation of up to four register addresses, compatible with reading wide-range composite data.

[0047] For example, suppose a 16-bit register address contains two status signals: the first status signal occupies bits 0-3 of the register, and the second status signal occupies bits 4-7. The storage configuration bit field parameters define the start bit, bit length, and name suffix of the two bit segments. The underlying driver generates a corresponding mask based on the bit field parameters, performs mask decomposition on the 16-bit target acquisition raw data read from the register, and separates the first and second status signal into two independent bit field data segments. Then, the two decomposed bit field data segments are mapped to their respective storage areas in shared memory.

[0048] Considering the discrepancies in the acquisition clocks of different clusters and auxiliary devices in multi-device concurrent acquisition scenarios, which can easily lead to timing misalignment of acquisition data from different devices within the same acquisition cycle and interfere with subsequent battery consistency analysis, this application proposes a cross-cluster timing alignment processing scheme at the storage block level. Optionally, storing the target acquisition data based on the storage configuration information can be achieved in the following way: after storing the target acquisition data based on the storage unit configuration in the storage configuration information, the target storage block is determined based on the storage block configuration in the storage configuration information; for the multi-source acquisition data belonging to the same acquisition cycle in the target storage block, a global microsecond-level timestamp and an incrementing sequence number are assigned; based on the timestamp and the incrementing sequence number, the multi-source acquisition data is combined and stored according to the storage file configuration information in the storage configuration information.

[0049] Understandably, the aforementioned global microsecond-level timestamp is uniformly generated by the battery management system, with the unit being microseconds. It is a unified time stamp for the entire energy storage system, not the local device clock of each battery cluster or environmental device.

[0050] For example, within the same acquisition cycle, cluster 1 battery data, cluster 2 battery data, and dynamic environment data from the liquid cooling device are simultaneously acquired. These multi-source acquired data are grouped into the same target storage block. All multi-source acquired data in this cycle are assigned the same global microsecond-level timestamp and a corresponding incrementing sequence number. Even if the local clocks of cluster 1, cluster 2, and the liquid cooling device are inconsistent, after being written to disk and stored, they can be identified as belonging to the same acquisition time based on the unified global timestamp. Here, the incrementing sequence number is used to determine the data arrangement order within this batch, facilitating the subsequent parsing process to restore the correct timing sequence and avoid timing misalignment.

[0051] In one optional implementation, the value of the batch quantity control parameter can be determined by: obtaining the database field name, row index, and table name configured in the storage block to obtain query information; reading the hardware configuration value stored in the installation parameter database based on the query information; and setting the hardware configuration value as the value of the batch quantity control parameter.

[0052] It should be noted that, in the embodiments of this application, the above-mentioned installation parameter database is usually deployed locally on the battery management system and is used to store the hardware configuration values ​​of the energy storage system. The hardware configuration values ​​include, but are not limited to, hardware configuration information such as the number of individual battery cells, the number of battery clusters, and the number of environmental monitoring devices.

[0053] For example, the installation parameter database contains a table named `cluster_param`, which records the hardware configuration information of each battery cluster. The first row of this table records the configuration data of battery cluster number 1, and this row contains a database field named `Cell-count`. This field stores a hardware configuration value of 24, indicating that battery cluster number 1 contains 24 individual battery cells. The table name, row index, and database field name can be pre-configured in the storage block. The battery management system reads this query information, locates the `cluster_param` table based on the table name, locates the first row of the table based on the row index, and then reads the hardware configuration value of 24 based on the `Cell-count` database field name. This value is then used as the batch quantity control parameter. Subsequently, based on this value, the storage unit template corresponding to the individual cell voltage is instantiated to generate 24 channels of individual cell voltage data.

[0054] Optionally, in this embodiment, a default batch quantity can also be configured. When loading the storage configuration, the actual configured quantity in the installation parameter database can be read first. If the field in the installation parameter database does not exist or fails to be read, a static default value is used as a fallback. When the number of modules in the battery cluster changes, only the corresponding field in the installation parameter database needs to be updated to automatically adapt to the new batch quantity, without modifying the storage configuration file or restarting the service. That is, through the dynamic referencing mechanism of the installation parameter database, the batch quantity and the installation parameter database are synchronized in real time.

[0055] While dynamically acquiring the quantity, this application also proposes a topology adaptive processing scheme. In an optional implementation, the target acquisition data is stored based on the storage configuration information, including: when it is found that the value of the batch quantity control parameter does not match the actual number of online devices, identifying the missing acquisition channel; for the generated storage file, writing an offline identifier at the corresponding position of the missing acquisition channel, and writing the corresponding acquisition data after the missing acquisition channel is restored.

[0056] Understandably, the number of batch data read from the installation parameter database represents the total number of data channels expected to be collected at the configuration level. However, during the actual data collection process, the system monitors the online status of each device in real time. Some battery clusters or environmental monitoring devices may temporarily go offline, resulting in fewer actual measurement points than the expected number of batch data points. In this case, the battery management system identifies these missing collection channels and, instead of directly omitting the corresponding data location in the storage file, fills in a NaN identifier and an offline status code at the corresponding location in the storage file. On one hand, the NaN identifier marks the location as having no valid value; on the other hand, the offline status code records the channel's offline anomaly attribute. This process ensures that the data matrix in the output storage file is neat and uniform, preventing missing data columns or misaligned rows and columns due to device downtime. This facilitates direct reading and parsing by subsequent data analysis software, avoids parsing errors caused by incomplete data matrices, and ensures the normal operation of post-processing tasks such as battery consistency analysis.

[0057] For example, the batch quantity control parameter is set to 4, and it is expected to output 4 channels of individual cell voltage data. If the acquisition channel corresponding to one of the individual cells is missing, the positions of the 4 data channels will still be retained in the CSV storage file. The position of the missing channel will be filled with a NaN identifier and the corresponding offline status code, and the remaining normal channels will be filled with the actual acquired individual cell voltage values. As shown in Table 1:

[0058] Table 1

[0059]

[0060] Of course, in this embodiment of the application, if the device is restored, seamless continuity can be achieved, that is, the actual collected single-unit voltage value can be filled in the single-unit voltage #100 column.

[0061] The above optional implementation methods ensure the absolute regularity of the data matrix during topology changes, preventing subsequent analysis software from reporting errors or parsing anomalies due to row and column misalignment.

[0062] This application embodiment configures two independent storage cycles for the storage file. Optionally, the target acquisition data is stored based on the storage configuration information, including: reading the charge / discharge status flag bit in the shared memory according to a preset query interval; when the charge / discharge status flag bit is in standby state, storing the target acquisition data using the first storage cycle; when the charge / discharge status flag bit switches from standby state to charge / discharge state, switching the next storage cycle of the current storage cycle to the second storage cycle, and storing the target acquisition data using the second storage cycle.

[0063] In other words, when the energy storage system is in a static standby state (without charging or discharging), the cycle can be set to be longer to reduce the amount of data stored. When the energy storage is in a charging or discharging state, the cycle can be set to be shorter to capture detailed operating data.

[0064] In this embodiment, uv_sleep is used to implement timed polling. The query interval is controlled via the uv_sleep interface. The thread sleeps for a preset duration and then wakes up to read the charge / discharge status flags in shared memory. This method does not require hardware interrupts and captures flag changes periodically, thus avoiding continuous CPU resource consumption by the thread.

[0065] Optionally, in this embodiment of the application, during the operation of the energy storage system, the battery management system can read the system operating status in real time through shared memory and automatically switch seamlessly between two sets of storage cycles.

[0066] When a switching operation between the first storage cycle and the second storage cycle is triggered, such as switching from the first storage cycle to the second storage cycle, or switching from the second storage cycle to the first storage cycle, the historical data of the previous N seconds in the circular buffer in memory can be read, where N is greater than 0; and the historical data can be written back to the storage file.

[0067] In other words, in the specific execution of the operating condition switching, this application embodiment uses the concept of variable sampling rate and adopts a switching mechanism based on interrupt triggering and state machine driving. During standby, low-frequency timed polling is used. When the charge / discharge status flag in shared memory flips, an interrupt is immediately triggered to switch to a high-frequency cycle. Simultaneously, at the moment of switching, the historical data of the previous N seconds (e.g., 1 second) in the circular buffer in memory is forcibly written back to ensure that critical transition data during the operating condition switching moment (such as the moment a relay operates) is not lost, achieving a good balance between saving storage space and data integrity.

[0068] The storage period in this embodiment also supports dynamic referencing of the installation parameter database. The period value can be adjusted in real time through a specified field in the installation parameter database to achieve hot parameter updates during operation. Optionally, in this embodiment, updating the first storage period and the second storage period may include: reading a specified field in the installation parameter database to obtain a period configuration value; and updating the first storage period and the second storage period based on the period configuration value.

[0069] This application embodiment also proposes an automatic archiving and management strategy for stored files. Optionally, the battery management system is further configured to: compress the obtained original stored file to obtain a first stored file; store the first stored file according to a preset directory structure, and delete the original stored file, wherein the preset directory structure has a storage root directory as the top-level directory, and the storage root directory has at least a subdirectory divided by month, and the original stored file name includes the following fields: cabin identifier, logical device number, file prefix, number of times installation parameters have been changed, time information, and file index field.

[0070] The installation parameter change count is embedded in the filename of the generated storage file. This count records the number of times the hardware installation parameters of the energy storage system have been modified. When the hardware configuration, such as the battery cluster configuration or environmental monitoring equipment configuration, is adjusted at the energy storage site, the installation parameter change count is updated accordingly. Different installation parameter change counts correspond to different hardware configuration versions. Embedding this information in the filename allows for the differentiation and isolation of storage files generated under different hardware configuration versions. When viewing and parsing historical storage files later, the installation parameter change count in the filename can quickly identify the hardware configuration version corresponding to the storage file's generation, facilitating data traceability, avoiding data confusion between old and new hardware scales, and providing convenience for battery performance backtesting analysis.

[0071] For example, during a hardware modification of the cabin, the number of battery cells is changed, and the number of installation parameter changes is updated from 0 to 1. The filename of the newly generated CSV storage file carries the number of changes, 1, which distinguishes it from the historical file with a number of changes of 0 before the modification, thus achieving the isolation and traceability of data from different hardware versions.

[0072] In addition, in this embodiment, the naming format of the storage file can be `{cabin ID}_{logical device}{logical device number}{file prefix}{number of installation parameter changes}_{year-month-day}_{file index}.csv`, ensuring the global uniqueness and traceability of the file name. The directory format can be ` / storage root directory / {YYYYMM} / {logical device}{number} / `.

[0073] The battery management system automatically compresses the day's CSV file into a `.tar.gz` format every day, stores the compressed package in a separate archive directory (such as ` / storage root directory / tar / `), and deletes the original CSV file after compression, significantly saving storage space.

[0074] In an optional implementation, the battery management system is further configured to: generate a cyclic redundancy check code for each data block when compressing the obtained original storage file, and append the cyclic redundancy check code to the end of the original storage file to obtain a second storage file; and write data from the second storage file to the first storage sector and the second storage sector, respectively.

[0075] Optionally, a Cyclic Redundancy Check (CRC) code can be used to verify whether an error has occurred during storage. Depending on the number of bits used to generate the check value, it can be classified as CRC8, CRC16, CRC32, etc. In this embodiment, a 32-bit CRC check can be used.

[0076] Understandably, in the above optional implementation, when compressing and archiving the CSV file, the system generates a CRC32 checksum for each data block and appends it to the end of the file. At the media writing level, a dual-sector atomic write alternation mechanism is adopted, so even if a power failure occurs at the moment of archiving, the data state of the previous complete cycle can be automatically restored after restarting based on the checksum tail frame, effectively reducing the risk of data corruption of the storage medium.

[0077] Optionally, in this embodiment of the application, before loading the predefined JSON configuration file, the battery management system is further configured to: receive a user instruction, which is used to instruct the adjustment of fields in any storage unit, any storage block, and any storage file in the predefined JSON configuration file, including adding fields, deleting fields, and modifying fields; and in response to the instruction, determine the adjusted JSON configuration file as the predefined JSON configuration file.

[0078] Through the above optional implementation methods, users can flexibly add or delete fields in the JSON configuration file according to the actual needs of the project, and build new configurations without modifying any program code, thus achieving "zero-code" customization of the storage solution.

[0079] In an optional implementation, loading a predefined JSON configuration file includes: generating a configuration instance corresponding to the predefined JSON configuration file in a memory backup area; and performing an atomic pointer swap to switch the running pointer to the configuration instance.

[0080] In other words, regarding the hot reload mechanism, this application's embodiment adopts a lock-free switching design based on atomic operations. When a user modifies the JSON configuration, triggering a hot update, the system builds a new configuration in the memory backup area. After construction, it instantly switches to the production area using atomic pointer swapping technology. The write thread does not need to lock and wait during this process, avoiding potential file deadlocks or data tearing during configuration changes. This makes the dynamic loading of configurations smoother and truly achieves seamless hot customization without the business's awareness.

[0081] This application also provides an energy storage system, including a battery management system, a battery cluster, and an environmental monitoring device, wherein the battery management system is communicatively connected to the battery cluster and the environmental monitoring device.

[0082] This application also provides an electronic device, such as... Figure 4 As shown, the electronic device 40 includes a memory 401 and a processor 402. The memory 401 stores a computer program that can run on the processor 402. When the processor 402 executes the computer program, it implements the method described in the above embodiments. The number of memories 401 and processors 402 can be one or more.

[0083] The electronic device also includes:

[0084] Communication interface 403 is used to communicate with external devices and exchange and transmit data.

[0085] If the memory 401, processor 402, and communication interface 403 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0086] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0087] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0088] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0089] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0090] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0091] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0092] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0093] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0094] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0095] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0096] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0097] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0098] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0099] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A battery management system, characterized in that, The battery management system is communicatively connected to the battery clusters and environmental monitoring equipment, and the battery management system is configured as follows: Load a predefined JSON configuration file, wherein the JSON configuration file includes several storage units, several storage blocks and several storage files, any storage block in the several storage blocks is associated with at least one of the several storage units, any storage file in the several storage files is associated with at least one of the several storage blocks, and any storage unit in the several storage units corresponds to a single data point. Parse the JSON configuration file to obtain the storage configuration information; The target acquisition data is stored based on the storage configuration information, wherein the target acquisition data includes at least the battery operation data of the battery cluster and the environmental data of the dynamic environment device.

2. The battery management system according to claim 1, characterized in that, Each of the storage units includes a first target field and the value of the first target field, wherein the first target field includes at least one of the following fields: data title name, data unit, data type, data source, offset address of data in shared memory, data scaling factor, data offset, and number of decimal places to retain in the data. Each storage block includes a second target field and the value of the second target field, wherein the second target field includes at least one of the following fields: block name identifier, associated storage unit list, and batch quantity control parameter; Each storage file includes a third target field and the value of the third target field, wherein the third target field includes at least one of the following fields: logical device type, file prefix name, first storage period, second storage period, and associated storage block list, wherein the first storage period is greater than the second storage period.

3. The battery management system according to claim 2, characterized in that, The data title name shall include at least a Chinese title and an English title; the data type shall include at least an integer type, a floating-point type and a bit field type.

4. The battery management system according to claim 2 or 3, characterized in that, When the data type is a bit field type, the target acquisition data is stored based on the storage configuration information, including: The target acquisition data is decomposed according to the mask to obtain the decomposed bit field data; The disassembled bit-field data is mapped to the corresponding storage area of ​​the shared memory.

5. The battery management system according to claim 1, characterized in that, Storing the target acquisition data based on the storage configuration information includes: After storing the target collected data based on the storage unit configuration in the storage configuration information, the target storage block is determined based on the storage block configuration in the storage configuration information; For multi-source acquired data belonging to the same acquisition cycle in the target storage block, a global microsecond-level timestamp and an incrementing sequence number are assigned; Based on the timestamp and the incrementing sequence number, the multi-source collected data is combined and stored according to the storage file configuration information in the storage configuration information.

6. The battery management system according to claim 2, characterized in that, Determining the value of the batch quantity control parameter includes: Obtain the database field names, row indexes, and table names configured in the storage block to obtain query information; Based on the query information, read the hardware configuration values ​​stored in the installation parameter database; Set the hardware configuration value to the value of the batch quantity control parameter.

7. The battery management system according to claim 2, characterized in that, Storing the target acquisition data based on the storage configuration information includes: When it is detected that the value of the batch quantity control parameter does not match the actual number of online devices, the missing acquisition channel is identified; For the generated storage file, an offline identifier is written at the corresponding position of the missing acquisition channel, and the corresponding acquisition data is written after the missing acquisition channel is restored.

8. The battery management system according to claim 2, characterized in that, Storing the target acquisition data based on the storage configuration information includes: Read the charge / discharge status flags in the shared memory according to the preset query interval; When the charge / discharge status flag is in standby mode, the target acquisition data is stored using the first storage cycle; When the charge / discharge status flag switches from the standby state to the charge / discharge state, the next storage cycle of the current storage cycle is switched to the second storage cycle, and the target acquisition data is stored using the second storage cycle.

9. The battery management system according to claim 8, characterized in that, When the switching operation between the first storage cycle and the second storage cycle is triggered, the battery management system is also configured to: Read the historical data from the circular buffer in memory for the past N seconds, where N is greater than 0; The historical data is written back to the storage file.

10. The battery management system according to claim 2, characterized in that, Updating the first storage cycle and the second storage cycle includes: Read the specified field from the installation parameter database to obtain the periodic configuration value; The first storage period and the second storage period are updated based on the period configuration value.

11. The battery management system according to claim 1, characterized in that, The battery management system is also configured to: The original storage file is compressed to obtain the first storage file; The first storage file is stored according to a preset directory structure, and the original storage file is deleted. The preset directory structure has a storage root directory as its top-level directory, and the storage root directory has at least one subdirectory divided by month. The original storage file name includes the following fields: The fields include: cabin identifier, logical device number, file prefix, number of installation parameter changes, time information, and file index.

12. The battery management system according to claim 11, characterized in that, The battery management system is also configured to: When compressing the obtained original storage file, a cyclic redundancy check code is generated for each data block, and the cyclic redundancy check code is appended to the end of the original storage file to obtain a second storage file. The data in the second storage file is written to the first storage sector and the second storage sector, respectively.

13. The battery management system according to claim 1, characterized in that, Before loading the predefined JSON configuration file, the battery management system is also configured as follows: Receive user instructions, which are used to instruct field adjustments to any storage unit, any storage block, and any storage file in a predefined JSON configuration file. The field adjustments include adding, deleting, and modifying fields. In response to the instruction, the adjusted JSON configuration file is determined to be the predefined JSON configuration file.

14. The battery management system according to claim 13, characterized in that, Load the predefined JSON configuration file, including: Generate a configuration instance corresponding to the predefined JSON configuration file in the memory backup area; Perform an atomic pointer swap to switch the run pointer to the configuration instance.

15. An energy storage system, characterized in that, include: The battery management system, battery cluster, and environmental monitoring device as described in any one of claims 1 to 14, wherein the battery management system is communicatively connected to the battery cluster and the environmental monitoring device.

Images