Energy storage data encoding and storing method, decoding method and terminal

Abstract

This application discloses an energy storage data encoding and storage method, a decoding method, and a terminal. The method includes: determining the storage mode identifier of the energy storage system at the current moment and obtaining a set of target monitoring parameters to be recorded; searching in a pre-set protocol dictionary for the field index identifier and the length attribute corresponding to each target monitoring parameter in the target monitoring parameter set; serializing the storage mode identifier to obtain the parameter value of the target monitoring parameter; and serializing the field index identifier and parameter value corresponding to each target monitoring parameter sequentially according to the length attribute to generate a storage data packet. This application constructs a static consensus through a pre-set dictionary, forcibly omits the length prefix for fixed-length parameters, eliminates redundancy in explicit metadata, and, combined with dynamic verification and a direct addressing mechanism based on address offset, significantly improves the proportion of effective data and storage space utilization while ensuring the reliability of parsing.

Description

Technical Field

[0001] This invention relates to the field of energy storage system data management technology, and in particular to an energy storage data encoding and storage method, decoding method and terminal. Background Technology

[0002] Energy storage products are primarily used for temporary power needs in scenarios such as home emergency backup power, outdoor camping, and travel. During after-sales maintenance of these products, engineers rely on historical fault data for root cause analysis; therefore, reliable recording of fault information is crucial.

[0003] Currently, the commonly used storage formats for recording data in energy storage systems include binary array format, CSV log format, JSON format, and TLV (Type-Length-Value) format.

[0004] However, all of the above formats have significant limitations in practical applications. While binary arrays offer compact storage, field expansion requires a complete restructuring of the storage system, lacking flexibility and unable to express nested relationships. Text formats such as CSV and JSON, while universal, have enormous storage overhead, high redundancy due to repeated key name transmission, and require substantial computational resources for lexical analysis during parsing, making them unsuitable for high-frequency write scenarios in embedded systems.

[0005] Furthermore, while traditional TLV formats offer some scalability, they suffer from high metadata redundancy. For nested structures common in energy storage systems, such as total voltage and multiple cell voltages in series, each sub-field requires a type identifier and length description, limiting storage efficiency. Additionally, these formats generally lack native, configurable reliability verification mechanisms, making it difficult to guarantee data integrity should bit flips occur during data storage or transmission. Moreover, some formats require traversal to locate specific fields (such as timestamps) during parsing, resulting in low addressing efficiency. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide an energy storage data encoding and storage method, a decoding method and a terminal, which significantly improves the effective data ratio and storage space utilization while ensuring the reliability of parsing.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for encoding and storing energy storage data, comprising: Determine the storage mode identifier of the energy storage system at the current moment, and obtain the set of target monitoring parameters to be recorded; Search in the preset protocol dictionary for the field index identifier corresponding to each target monitoring parameter in the target monitoring parameter set, as well as the length attribute corresponding to the field index identifier; After serializing the storage mode identifier, the parameter values ​​of the target monitoring parameters are obtained. Based on the length attribute, the field index identifier corresponding to each target monitoring parameter and the parameter value are serialized sequentially to generate a storage data packet.

[0008] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A method for decoding energy storage data, characterized in that it includes: Obtain the storage data packet obtained according to any one of the energy storage data encoding and storage methods described above; The target monitoring parameters corresponding to the field index identifier in the stored data packet are obtained according to the preset protocol dictionary, and the storage address of the parameter value in memory is located according to the position of the field index identifier in the stored data packet. Read the parameter value based on the storage address; The target monitoring parameters and their values ​​are displayed together.

[0009] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A terminal is characterized by comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement each step of any of the energy storage data encoding and storage methods described above.

[0010] The beneficial effects of this invention are as follows: By establishing a storage mode identifier and introducing a protocol dictionary mapping mechanism, redundancy removal is performed on fixed-length monitoring parameters during serialization writing. This involves directly establishing a structure that tightly concatenates the field index identifier and parameter value, and forcibly omitting the length description field. The effective data ratio of a storage system depends on the ratio of effective data payload to protocol metadata overhead. In high-frequency sampling applications of energy storage systems, traditional explicit metadata (such as the Length field in TLV format) appears repeatedly in every record, resulting in significant waste of storage resources. This invention internalizes the length attribute into system consensus through a pre-defined dictionary, transforming explicit metadata in data packets into implicit definitions in the dictionary. This ensures that only necessary indexes and parameter values ​​are retained in the binary data stream, thereby eliminating redundant metadata usage at the physical storage level. This mechanism significantly improves storage space utilization within limited storage space while ensuring accurate and parseable data structures. Attached Figure Description

[0011] Figure 1 A flowchart illustrating the steps of an energy storage data encoding and storage method provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the steps of an energy storage data decoding method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a terminal provided in an embodiment of the present invention. Detailed Implementation

[0012] To make the technical problems, technical solutions, and beneficial effects to be solved by 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 are not intended to limit the scope of this application.

[0013] To address the aforementioned problems, this application provides an energy storage data encoding and storage method, a decoding method, and a terminal. The energy storage data encoding and storage method of this application is described in detail below.

[0014] The energy storage data encoding and storage method disclosed in this application can be used to store fault snapshots and operating status data in portable energy storage systems. The terminal in this application can be a terminal with battery management and data logging functions, such as a home emergency backup power supply, an outdoor camping power bank, or a portable energy storage device for travel.

[0015] The following describes in detail an energy storage data encoding and storage method of the present invention, with reference to the appendix. Figure 1 This includes steps 110-130.

[0016] Step 110: Determine the storage mode identifier of the energy storage system at the current moment, and obtain the set of target monitoring parameters to be recorded.

[0017] The system first detects the current triggering environment and determines a storage mode identifier to define subsequent data structures and verification rules. For example, according to the preset protocol definition, 0x01 represents a local verification mode where each data block is independently appended with a CRC-8 checksum, 0x02 represents a global verification mode where all data blocks are concatenated and then a CRC-16 checksum is calculated, and 0x03 represents a mode without appended checksums. Simultaneously, the system collects all physical quantities or state quantities that need to be persistently recorded at the current moment. These physical quantities constitute the target monitoring parameter set, including timestamps, total voltage, current, and cell temperature.

[0018] Step 120: Search in the preset protocol dictionary for the field index identifier and the length attribute corresponding to each target monitoring parameter in the target monitoring parameter set.

[0019] The system accesses a protocol dictionary pre-stored in memory. For each target monitoring parameter in the set, the system retrieves its unique field index identifier (DictID, e.g., 0x00 represents a timestamp, 0x02 represents total voltage) by searching the dictionary, and simultaneously reads the predefined length attribute of this identifier in the dictionary (e.g., 0x00 corresponds to a fixed 4-byte length, 0xD0 corresponds to a variable length indicated by a prefix). The search dictionary stores the correspondence between monitoring parameters and field indices. After obtaining the set of target monitoring parameters, the system searches for the target parameters in the target monitoring parameter set from all monitoring parameters stored in the search dictionary to obtain the corresponding field index identifier.

[0020] Step 130: After serializing the storage mode identifier, obtain the parameter values ​​of the target monitoring parameters. Based on the length attribute, serialize the field index identifier and parameter value corresponding to each target monitoring parameter in sequence to generate a storage data packet.

[0021] The system first constructs the header of the storage data packet by writing the storage mode identifier determined in step 110 (e.g., writing 0x01). Then, the system obtains the actual readings of each sensor as parameter values ​​(e.g., reading a total voltage parameter value of 16000mV). Based on the length attribute obtained in step 120, the system sequentially writes the field index identifier (e.g., 0x02) and parameter values ​​(e.g., 0x3E80) into the storage buffer. Through this streaming serialization operation, the construction of the storage data packet is completed.

[0022] This application establishes a storage mode identifier and introduces a protocol dictionary mapping mechanism to perform redundancy removal for fixed-length monitoring parameters during serialization writing. Specifically, it directly establishes a structure that tightly concatenates the field index identifier and parameter value, and forcibly omits the length description field. The effective data ratio of a storage system depends on the ratio of effective data payload to protocol metadata overhead. In high-frequency sampling applications of energy storage systems, traditional explicit metadata (such as the Length field in TLV format) appears repeatedly in every record, resulting in significant waste of storage resources. This invention internalizes the length attribute into system consensus through a pre-defined dictionary, transforming explicit metadata in data packets into implicit definitions in the dictionary. This ensures that only necessary indexes and parameter values ​​are retained in the binary data stream, thereby eliminating redundant metadata usage at the physical storage level. This mechanism significantly improves storage space utilization within limited storage space while ensuring accurate and parseable data structures.

[0023] In one embodiment of this application, the serialization process of data in step 150 includes steps 210 to 220.

[0024] Step 210: If the length attribute is variable length, generate the length description prefix for the corresponding parameter value, and serialize the field index identifier, length description prefix and parameter value in sequence.

[0025] When the protocol dictionary indicates that the current field is of variable length (e.g., an extended field of DictID in the range of 0xD0-0xFF, or 0x08 cell voltage group), the system first calculates or counts the current parameter value and generates a length description prefix (e.g., 1 byte). Subsequently, the system writes these three parts sequentially into the storage data packet in the order of [ID][Length][Value].

[0026] Step 220: If the length attribute is of fixed length, the field index identifier and parameter value are serialized, and the length description data is not included in the stored data packet.

[0027] When the protocol dictionary indicates that the current field is of fixed length (e.g., a common field with DictID in the range of 0x00-0xCF, such as 0x02 where the total voltage is fixed at 2 bytes), the system performs a redundancy removal operation. The system directly writes the field index identifier and parameter value sequentially into the storage data packet, forming the physical structure [ID][Value]. During this process, the system does not write any data indicating the length between the two, because the parser can determine the length by consulting the same dictionary.

[0028] In this way, by introducing conditional branches into the serialization logic, differentiated encoding strategies are adopted for data of different properties. For frequently occurring fixed-length parameters, this method eliminates the redundant byte of the length description prefix at the physical layer, making the packet structure more compact than the traditional TLV format; while for necessary variable-length parameters, the length description is retained to maintain the protocol's universality. This design reduces the storage overhead of non-payload while ensuring protocol flexibility.

[0029] In one embodiment of this application, the length description prefix of the generated parameter value in step 210 includes steps 310 to 320.

[0030] Step 310: When the field index identifier corresponds to the extended definition partition defined in the protocol dictionary, calculate the actual total number of bytes of the parameter value as the length description prefix.

[0031] The protocol dictionary divides certain ID ranges (such as 0xD0-0xFF) into extended definition partitions to store non-standard data that may be added in the future. For such parameters, the system calculates the actual size in bytes occupied by the parameter value and writes this value as a length description prefix.

[0032] Step 320: When the field index identifier corresponds to the structured array attribute defined in the protocol dictionary, the number of array elements contained in the statistical parameter value is used as the length description prefix.

[0033] For parameters defined as structured arrays in the protocol dictionary (such as cell voltage groups), the length of their sub-elements (individual cell voltages) is known (e.g., 2 bytes). In this case, the system does not record the total number of bytes, but instead counts the number of elements contained in the array (VarLen), and uses this count as the prefix for the length description. For example, if there are 5 voltage groups, the prefix would be recorded as 0x05.

[0034] In this way, different length description semantics are defined for different variable-length data types. For extended data, byte counting is used to ensure that the boundaries of unknown data are identifiable; for homogeneous arrays, element counting is used. This differentiation strategy not only enhances the semantic expressiveness of the data and avoids computational redundancy when recording byte counts, but also provides the parser with more intuitive array dimension information, optimizing the expression efficiency of complex structures.

[0035] In one embodiment of this application, after confirming the storage mode identifier in step 110, steps 410 to 420 are further included.

[0036] Step 410: If the storage mode identifier indicates a local check mode, then calculate the checksum independently for each written field index identifier and parameter value, and write the checksum after the parameter value.

[0037] When the system recognizes that it is currently in local verification mode (e.g., Scene=0x01), the serialization process becomes segmented verification. After each parameter is written, the system immediately uses a CRC algorithm (e.g., CRC-8) to calculate the current check value of [ID][Value] and writes it immediately after the parameter value, forming multiple independent verification loops.

[0038] Step 420: If the storage mode identifier indicates global check mode, after writing all parameter values, calculate the global checksum for all written field index identifiers and all parameter values, and write the global checksum to the end of the storage data packet.

[0039] When the system detects that it is currently in global check mode (e.g., Scene=0x02), no check bits are inserted during serialization. After the main content of the entire data packet is constructed, the system performs a one-time CRC calculation (e.g., CRC-16) on the entire payload and appends the result to the end of the packet.

[0040] In this way, by introducing a dynamic verification mechanism bound to the storage mode, flexible configuration of data integrity protection strategies is achieved. The local verification mode gains fine-grained data protection by adding a small amount of redundancy, preventing the propagation of single-point errors; the global verification mode minimizes verification overhead through a one-time calculation. The system can select the verification strategy according to actual needs, solving the problem of the rigidity of traditional format verification mechanisms.

[0041] In one embodiment of this application, determining the energy storage system storage mode identifier in step 110 includes steps 510 to 530.

[0042] Step 510: Identify the trigger type of the current data record.

[0043] The system monitors the interrupt source or event flag of the data logging task to determine whether the logging is triggered by a system fault (such as overcurrent or overtemperature) or by a timer (such as once per second).

[0044] Step 520: If the data record trigger type is a trigger type that indicates high business importance, then generate a storage mode identifier for the local verification mode.

[0045] When the trigger type is a high business-important event such as a fault snapshot, the system considers data integrity to take precedence over storage space, and therefore generates an identifier indicating the local verification mode (e.g., Scene=0x01).

[0046] Step 530: If the data record trigger type is a trigger type indicating high space occupancy, then generate a storage mode identifier for the global verification mode.

[0047] When the trigger type is a high-frequency, high-space-occupancy event such as a periodic log, the system considers saving flash memory lifespan and space as the top priority, and therefore generates an identifier indicating the global verification mode (e.g., Scene=0x02).

[0048] In this way, by identifying the business attributes (importance vs. space consumption) of the trigger type, the system automatically selects the optimal encoding mode. This ensures that critical fault data has extremely strong anti-interference and recovery capabilities, while massive amounts of historical log data can be stored at the lowest cost, thus achieving an optimal balance between data reliability and storage space consumption.

[0049] In one embodiment of this application, steps 610 to 630 are included before obtaining the target monitoring parameter set in step 110.

[0050] Step 610: Pre-set the protocol dictionary in the memory of the energy storage system.

[0051] During system manufacturing or firmware upgrades, a protocol dictionary containing all parameter definitions is written into the system's non-volatile memory (such as flash memory) and loaded at runtime.

[0052] Step 620: Establish a mapping relationship between field index identifiers and parameter semantics in the protocol dictionary.

[0053] The dictionary explicitly defines the physical meaning (the semantics of the value) of each field index identifier. For example, 0x00 represents the timestamp, 0x01 represents the fault type, 0x02 represents the total voltage, and 0x08 represents the cell voltage group.

[0054] Step 630: For field index identifiers with a length attribute of fixed length type, specify the corresponding preset byte length.

[0055] For parameters of fixed length, the dictionary specifies their fixed length. For example, DictID=0x00 is specified as 4 bytes, DictID=0x01 as 1 byte, and DictID=0x02 as 2 bytes.

[0056] In this way, by pre-setting a protocol dictionary in memory, the system establishes a static contract for the data structure. This pre-set protocol allows the dictionary to be configured so that data packets do not need to carry self-descriptive information during transmission and storage, thereby compressing the physical size of the data packets to the limit, stripping metadata from the transport layer to the storage layer, and retaining only the parameter values ​​that cannot be omitted.

[0057] The following describes in detail an energy storage data decoding method of the present invention, referring to... Figure 2 This includes steps 710 to 740.

[0058] Step 710: Obtain the storage data packet obtained according to any one of the energy storage data encoding and storage methods.

[0059] The decoding end reads binary stored data packets from the storage medium.

[0060] Step 720: Parse the field index identifier from the stored data packet.

[0061] The decoding end reads specific bytes in the data packet and identifies the field index identifier (such as DictID=0x02, which represents the total voltage in the dictionary).

[0062] Step 730: Obtain the target monitoring parameters corresponding to the field index identifier according to the preset protocol dictionary, and locate the storage address of the parameter value in memory according to the position of the field index identifier in the storage data packet.

[0063] The decoding end uses a pre-built protocol dictionary to look up the semantics (target monitoring parameters) corresponding to the identifier. At the same time, based on the current position of the identifier and the length definition in the dictionary, the decoding end calculates the starting address in memory of the parameter value (Value) corresponding to the identifier.

[0064] Step 740: Read parameter values ​​based on storage address; display target monitoring parameters and parameter values ​​in association.

[0065] The decoding end reads binary data from the calculated storage address as a parameter value and combines it with the parameter semantics for display. For example, 0x3E80 is converted to a voltage value of 16000mV.

[0066] In this way, by reverse-engineering a dictionary, the semantics and structural location of the data are restored using a pre-defined dictionary. Complex text parsing steps are omitted, and the decoding process is transformed into efficient memory address calculation and reading operations, achieving efficient data rereading.

[0067] In one embodiment of this application, step 730, which locates the storage address of the parameter value based on the position of the field index identifier, includes steps 810 to 840.

[0068] Step 810: Obtain the base address pointer of the stored data packet in memory.

[0069] The system obtains the starting physical address (ptr) of the data packet in memory.

[0070] Step 820: Identify the position of the field index identifier in the stored data packet according to the protocol dictionary, and determine the field offset of the field index identifier relative to the base address pointer based on the position.

[0071] The system queries a predefined mapping table (such as dictId_table) to directly obtain the offset (DictID_offset) of the current field index identifier (ID) relative to the packet header.

[0072] Step 830: Determine the header length occupied by the field index identifier and the optional length description prefix.

[0073] The system calculates the length of the metadata preceding the data based on the dictionary definition. If the length is fixed, the header length is the ID length; if the length is variable, the header length is the ID length plus the prefix length.

[0074] Step 840: Add the base address pointer, field offset, and header length to obtain the storage address of the parameter value corresponding to the field index identifier.

[0075] The system performs the operation: storage address = ptr + DictID_offset + Length_size. This address is the absolute physical address of the parameter value.

[0076] In this way, by obtaining the memory base address pointer of the stored data packet and combining it with the predefined field offsets in the protocol dictionary and the header overhead length, linear address operations (base address + offset + header length) are performed. From the perspective of computer addressing principles, this mechanism transforms the traditional sequential parsing process based on streaming scanning or delimiter matching (O(n) time complexity) into a direct positioning process based on pointer arithmetic (O(1) time complexity). This allows the system to skip unnecessary metadata areas and directly hit the physical storage unit of any target parameter value. Thus, instantaneous random access to key monitoring data is achieved without traversing the entire data packet, significantly reducing the computational resource consumption and access latency of embedded systems when performing high-frequency data readback.

[0077] In one embodiment of this application, after the storage data packet obtained in step 710, steps 910 to 930 are further included.

[0078] Step 910: When parsing the storage data packet, obtain the verification mode type corresponding to the storage mode identifier.

[0079] The decoding end reads the packet header to identify whether it is a local verification mode or a global verification mode.

[0080] Step 920: If it is a local verification mode, then perform verification independently for each parameter value; when a local verification of the current parameter value is detected... When the verification fails, the current parameter value is marked as invalid data, and the end position of the current parameter value is determined according to the protocol dictionary or length description prefix to skip invalid data.

[0081] In local verification mode, if a parameter fails verification, the decoder uses the dictionary length or prefix length to calculate the span of the parameter, skips the corrupted area, and continues to parse subsequent parameters.

[0082] Step 930: If it is a global verification mode, a global verification is performed on the payload of the entire storage data packet before or after parsing all parameter values. If the verification fails, the storage data packet is discarded.

[0083] Under global verification, if the total verification (CRC-16) fails, the entire data packet is deemed untrustworthy and discarded.

[0084] In this way, by identifying the verification type indicated by the storage mode identifier, integrity verification is performed on independent parameter values ​​in local verification mode. When verification fails, the offset is calculated using the protocol dictionary or length description prefix to perform a skip operation. This leverages the logical decoupling between the data's structural definition (length metadata) and content data (parameter value payload), ensuring that the physical boundaries of data fields are independent of the integrity of the data content. Through this fault isolation mechanism, even in the event of partial data corruption on the physical storage medium, the decoding end can still pinpoint the damaged area and block the propagation of errors, thereby maximizing the recovery of subsequent undamaged critical monitoring parameters and improving the system's parsing robustness and data availability under harsh operating conditions.

[0085] In one embodiment of this application, the serialization process for a specific target monitoring parameter (such as cell voltage group) is described in detail for the variable length processing in step 210, including steps 1010-1030.

[0086] Step 1010: Identify the target monitoring parameters as structured array attributes.

[0087] The system finds the field index identifier (e.g., 0x08) corresponding to "cell voltage group" in the preset protocol dictionary. The dictionary defines this field index identifier as having a structured array attribute, which indicates that its sub-elements are 2 bytes long and the physical unit is mV.

[0088] Step 1020: Count the number of array elements and generate a length description prefix.

[0089] The system collects current cell voltage data, assuming the current battery pack has a 5-cell structure (Cell1~Cell5). The system counts the number of array elements as 5. At this point, the system directly generates a length description prefix (VarLen) with the value 0x05, instead of calculating the total number of bytes (5). 2 = 10 bytes).

[0090] Step 1030: Serialize and write the field index identifier, length description prefix, and consecutive parameter values.

[0091] The system sequentially writes the following to the stored data packet: 0x08 (field index identifier), 0x05 (length description prefix), and 5 consecutive 2-byte voltage values ​​(e.g., hexadecimal values ​​corresponding to 3200, 3180, 3220, 3190, and 3210).

[0092] For homogeneous high-frequency data (such as multi-cell voltages), a length-based prefix strategy based on the number of elements is adopted. From a data structure perspective, since the type and length of sub-elements are known in the dictionary, recording the number of elements is more semantically intuitive than recording the total number of bytes. Furthermore, the number of iterations can be determined during decoding without performing a division operation of "total length / individual cell length." Compared to traditional TLVs that add a Tag and Length for each cell voltage, only a single-byte field index identifier is needed to describe the entire array structure, significantly reducing storage redundancy in nested data.

[0093] In one embodiment of this application, the storage mode identifier in step 110 above further includes steps 1110-1120 indicating the value of the no-check mode (e.g., 0x03).

[0094] Step 1110: Determine that the storage mode identifier is in no-check mode.

[0095] When the system is in a high-frequency data acquisition scenario, the storage mode identifier is determined to be 0x03.

[0096] Step 1120: Perform unchecked serialization.

[0097] The system writes 0x03 into the packet header. Subsequently, for all target monitoring parameters, only the field index identifier and parameter value (and necessary variable-length prefixes) are written sequentially. Throughout the serialization process, the system does not perform any CRC calculations or write any checksums.

[0098] In this way, by removing the verification calculation step, the system eliminates the CPU's clock cycle consumption for CRC operations and the storage space occupied by the checksum. This is suitable for scenarios where the data itself is fault-tolerant or where the subsequent transport layer already has strong verification, giving the system a high degree of flexibility, allowing it to dynamically balance computational performance and data reliability according to the application scenario (such as data fault tolerance or secondary verification).

[0099] In one embodiment of this application, to illustrate the encoding result more intuitively, a specific fault snapshot storage data packet is shown below.

[0100] Scenario setting: The system detects a fault and triggers local verification mode (storage mode identifier = 0x01).

[0101] Data stream content: 01 00 60 83 6F 31 X1 01 03 X2 02 3E 80 X3 03 04 B0 X4 Analysis: 1. 01: Header. Storage mode identifier, indicating local verification.

[0102] 2.00 60 83 6F 31: First set of data.

[0103] 00: Field index identifier (timestamp).

[0104] 60 83 6F 31: Parameter value (Unix timestamp). Since the dictionary definition of 0x00 is a fixed 4 bytes, there is no length prefix.

[0105] 3. X1: The checksum (CRC-8) of the first set of data, calculated for 00 60 83 6F 31.

[0106] 4. 01 03: Second set of data.

[0107] 01: Field index identifier (fault type).

[0108] 03: Parameter value (e.g., overcurrent fault). Fixed at 1 byte.

[0109] 5. X2: Check code for the second set of data.

[0110] 6. Subsequent fields are similar, with each parameter value followed by an independent checksum.

[0111] This demonstrates the physical storage structure in local parity mode. Each parameter value is followed by its independent checksum, forming physical isolation islands. This structure allows the decoder to accurately determine the specific damaged field (such as total voltage or current) when a storage medium bit flip occurs, thus discarding only the damaged field while retaining key information such as the timestamp and fault type. This achieves the function that damage to a single field does not affect the parsing of other fields.

[0112] In one embodiment of this application, to illustrate the encoding result more intuitively, a specific periodic log storage data packet is shown below.

[0113] Scenario setting: The system records logs, triggering global verification mode (storage mode identifier = 0x02).

[0114] Data stream content: 02 00 60 83 6F 31 03 04 B0 05 2D 06 01 XX XX Analysis: 1.02: Header. Storage mode identifier, indicating the global verification mode.

[0115] 2. 00 60 83 6F 31: Timestamp (Field Index Identifier DictID + Parameter Value) 00: Field index identifier (timestamp).

[0116] 60 83 6F 31: Parameter value (Unix timestamp).

[0117] 3. 03 04 B0: Current (Field Index Identifier DictID + Parameter Value).

[0118] 03: Field index identifier (current).

[0119] 04 B0: Parameter value (1200mA). Since the dictionary definition of 0x03 is a fixed 2 bytes, there is no length description prefix, and there is no local checksum here.

[0120] 4.05 2D: Maximum temperature (field index identifier + parameter value).

[0121] 05: Field index identifier (highest temperature).

[0122] 2D: Parameter value (45℃). Fixed at 1 byte.

[0123] 5.06 01: Charging MOS status (field index identifier + parameter value).

[0124] 06: Field Index Identifier (Charging MOS State).

[0125] 01: Parameter value (closed). Fixed at 1 byte.

[0126] 6. XX XX: Packet end. Global checksum (CRC-16). Calculated for all data from 00 (first field index identifier) ​​to 01 (last parameter value).

[0127] This approach demonstrates the physical storage structure under global verification mode. It removes the intermediate local checksum and retains the global checksum only at the end, minimizing storage overhead. This approach is suitable for log recording scenarios that require high data density and allow for occasional packet loss.

[0128] To facilitate understanding of the embodiments of this application, the energy storage data encoding rules involved in this application are explained. These encoding rules are used to implement the above-mentioned energy storage data encoding and storage method and decoding method:

[0129] Data packet structure: [S]: Scene (1 byte): Storage mode identifier, used to indicate the verification strategy used for the currently stored data packet; [D]: Field index identifier DictID (1 byte), used as an index to look up the semantics (such as "timestamp", "current") and length attributes of the corresponding target monitoring parameters in the preset protocol dictionary; [L]?: Length description prefix (optional field). The suffix "?" indicates that the field exists based on the length attribute condition: the field exists when the length attribute indicates a variable length; the field is omitted (i.e., it does not contain length description data) when the attribute indicates a fixed length. [V]: Parameter value, i.e., the actual binary value of the target monitoring parameter. Its length is predefined by the protocol dictionary or specified by a length description prefix; [C]?: Checksum (optional field). The suffix "?" indicates that the field exists based on the indication conditions of the storage mode identifier: if it indicates a local checksum mode, the field follows each parameter value; if it indicates a global checksum mode, the field is located at the end of the stored data packet.

[0130] The storage mode identifier [S] field supports three validation modes, and the rules can be further expanded in the future.

[0131] The field index identifier and parameter value [D][V] are mapped to parameter semantics and format information in the protocol dictionary through the field index identifier DictID, and the field index identifier DictID space is divided into a normal area and an extended area. In the extended area, the length attribute corresponding to all field index identifiers DictID is variable length, implicitly including a length description prefix (e.g., 1 byte) before the parameter value [V]. In the normal area, the length of the parameter value [V] is predefined by the protocol dictionary (usually a fixed length), and in this case, no length description prefix is ​​included. The protocol dictionary is pre-installed in the system, and its specific definition is shown in the table below:

[0132] Example 1: SDV storage format (HEX form): 02 / / Scene: Global CRC16 00 61 27 D3 80 / / D=0x00, timestamp 02 3E 80 / / D=0x02, Total pressure = 16000mV 08 05 0C 80 0C 74 0C 94 0C 7A 0C 8A / / D=0x08, VarLen=5, V=[3200,3180,3220,3190,3210] D0 01 F6 / / D=0xD0, Extended temperature sensing 1 Total size: 1 + (1+4) + (1+2) + (1+1+10) + 3 = 24 bytes Example 2: Record a fault snapshot (Scene=0x01, each block of CRC-8, hereinafter referred to as CRC8) 01 00 60 83 6F 31 X1(42) 01 03 X2(1C) 02 0A 00 X3(54) 03 04 B0 X4(F0) 01 indicates S=0x01: each block has an independent CRC8 00 60 83 6F 31 indicates that D=0x00 (timestamp) and V=0x60836F31. X1(42) represents CRC8 of [00 60 83 6F 31] 01 03 indicates that D=0x01 (fault type) and V=0x03 (overcurrent). X2(1C) represents CRC8 of [01 03] 02 3E 80 indicates that D=0x02 (total pressure) and V=0x3E80 (16000mV). X3(54) represents CRC8 of [02 0A 00] 03 04 B0 indicates that D=0x03 (current) and V=0x04B0 (1200mA). X4(F0) represents CRC8 of [03 04 B0] Example 3: Record a fault snapshot (Scene = 0x02, global CRC-16 (ModBus), hereinafter referred to as CRC16) 02 00 60 83 6F 31 03 04 B0 05 2D 06 01 XX XX(67 35) 02 indicates S=0x02: Global CRC16 00 60 83 6F 31 represents a timestamp. 03 04 B0 indicates current. 05 2D indicates a maximum temperature of 45°C. 06 01 indicates MOS closed. XX XX(67 35) indicates CRC-16 / MODBUS (low byte first) of [00 60 83 ...2D 06 01] Please refer to Figure 3The present invention also provides a terminal 300, including a memory 301 and a processor 302, and a computer program stored on the memory 301 and running on the processor 302. When the processor 302 executes the computer program, it implements the various steps in the energy storage data encoding and storage method described above.

[0133] The beneficial effects of the terminal of the present invention are the same as those of the method described above, and will not be repeated here.

[0134] In summary, this application defines a global verification context by establishing a storage mode identifier and introduces a pre-defined protocol dictionary to map target monitoring parameters to short-byte field index identifiers. During serialization, differential encoding is performed based on the length attribute, especially for fixed-length parameters where the length description prefix is ​​forcibly omitted, directly establishing a compact physical structure where the identifier is adjacent to the parameter value. A static consensus between the encoder and decoder is constructed through the pre-defined dictionary, and the frequently repeated explicit metadata in the data stream (such as the Length field in TLV) is stripped into implicit rules, thereby eliminating the information entropy redundancy of non-effective payload at the physical level. Combined with a dynamic verification strategy based on storage mode and a direct addressing mechanism with O(1) complexity based on base address offset, the load efficiency and parsing reliability of energy storage data are improved, solving the technical problems of storage resource waste and low processing efficiency caused by excessive metadata overhead and complex addressing logic in traditional storage formats.

[0135] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for encoding and storing energy storage data, characterized in that, include: Determine the storage mode identifier of the energy storage system at the current moment, and obtain the set of target monitoring parameters to be recorded; Search in the preset protocol dictionary for the field index identifier corresponding to each target monitoring parameter in the target monitoring parameter set, as well as the length attribute corresponding to the field index identifier; After serializing the storage mode identifier, the parameter values ​​of the target monitoring parameters are obtained. Based on the length attribute, the field index identifier corresponding to each target monitoring parameter and the parameter value are serialized sequentially to generate a storage data packet.

2. The energy storage data encoding and storage method according to claim 1, characterized in that, Based on the length attribute, the field index identifier corresponding to each target monitoring parameter and the parameter value are sequentially serialized, including: If the length attribute is variable length, then a length description prefix corresponding to the parameter value is generated, and the field index identifier, the length description prefix, and the parameter value are serialized sequentially. If the length attribute is of fixed length, then the field index identifier and the parameter value are serialized, and the length description data is not included in the stored data packet.

3. The energy storage data encoding and storage method according to claim 2, characterized in that, The generation of the length description prefix corresponding to the target monitoring parameters includes: When the field index identifier corresponds to the extended definition partition defined in the protocol dictionary, the actual total number of bytes of the parameter value is calculated as the length description prefix; When the field index identifier corresponds to the structured array attribute defined in the protocol dictionary, the number of array elements contained in the parameter value is counted as the length description prefix.

4. The energy storage data encoding and storage method according to claim 1, characterized in that, Also includes: If the storage mode identifier indicates a local verification mode, then a checksum is calculated independently for each written field index identifier and parameter value, and the checksum is written after the parameter value. If the storage mode identifier indicates a global check mode, then after all parameter values ​​have been written, a global checksum is calculated for all written field index identifiers and all parameter values, and the global checksum is written to the end of the storage data packet.

5. The energy storage data encoding and storage method according to claim 4, characterized in that, The determination of the storage mode identifier of the energy storage system at the current moment includes: Identify the trigger type of the current data record; If the trigger type of the data record is a trigger type that indicates high business importance, then a storage mode identifier for the local verification mode is generated; If the data record trigger type is a trigger type indicating high space usage, then a storage mode identifier for the global verification mode is generated.

6. The energy storage data encoding and storage method according to claim 1, characterized in that, Also includes: The protocol dictionary is pre-loaded in the memory of the energy storage system; The protocol dictionary stores the mapping relationship between the field index identifiers and the monitoring parameters; For the field index identifier whose length attribute is of type fixed length, specify the corresponding preset byte length.

7. A method for decoding energy storage data, characterized in that, include: Obtain the storage data packet obtained by the energy storage data encoding and storage method according to any one of claims 1 to 6; The target monitoring parameters corresponding to the field index identifier in the stored data packet are obtained according to the preset protocol dictionary, and the storage address of the parameter value in memory is located according to the position of the field index identifier in the stored data packet. Read the parameter value based on the storage address; The target monitoring parameters and their values ​​are displayed together.

8. The energy storage data decoding method according to claim 7, characterized in that, The step of locating the memory address of the parameter value based on the position of the field index identifier in the stored data packet includes: Obtain the base address pointer of the stored data packet in memory; The position of the field index identifier in the stored data packet is identified according to the protocol dictionary, and the field offset of the field index identifier relative to the base address pointer is determined according to the position. Determine the header length occupied by the field index identifier and the optional length description prefix; The base address pointer, the field offset, and the header length are added together to obtain the storage address of the parameter value corresponding to the field index identifier.

9. The energy storage data decoding method according to claim 7, characterized in that, Also includes: When parsing the stored data packet, the verification mode type corresponding to the storage mode identifier is obtained. If it is a local verification mode, the verification is performed independently for each parameter value. When the local checksum verification of the current parameter value fails, the current parameter value is marked as invalid data, and the end position of the current parameter value is determined according to the protocol dictionary or the length description prefix to skip the invalid data; In global verification mode, the payload of the stored data packet is verified before or after parsing all parameter values. If the verification fails, the stored data packet is discarded.

10. An energy storage data encoding and storage terminal, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement each step of the energy storage data encoding and storage method according to any one of claims 1 to 6.

Images