Log storage method and device, battery management system and storage medium

Abstract

The application belongs to the technical field of data storage, and relates to a log storage method and device, a battery management system and a storage medium. The to-be-stored data is encoded by analyzing rule information and a variable-length type length format to generate a log data record comprising a fixed-length data field and an extended data field. The fixed-length data field is arranged in a binary byte format, reducing data redundancy and improving storage space utilization efficiency; the extended data field is encoded in a variable-length type length format, improving the adaptability to different data record requirements. Meanwhile, the rule information is stored in association with the log data record, so that the log file contains corresponding analysis basis, facilitating subsequent data reading and analysis. Based on this, the application can improve the log data storage efficiency, record flexibility and analysis convenience, and solve the problem that the existing battery management system log storage cannot simultaneously consider storage efficiency, data adaptability and analysis convenience.

Description

Technical Field

[0001] This application belongs to the field of data storage technology, specifically relating to a log storage method, device, battery management system, and storage medium. Background Technology

[0002] A Battery Management System (BMS) is a crucial component of new energy battery systems, typically used to monitor and manage the system's operational status. During BMS operation, various operational data need to be continuously collected and recorded, such as battery voltage, current, temperature, state of charge, and system operating status. Simultaneously, when abnormal states occur in the battery system, relevant event information also needs to be recorded to facilitate subsequent status analysis, fault location, and operation and maintenance.

[0003] As the application scenarios of new energy equipment continue to expand, the types and amounts of data that BMS needs to monitor are gradually increasing. On the one hand, BMS is usually deployed in resource-constrained embedded environments, and its processing power and storage capacity are limited by hardware conditions. On the other hand, as the functions of battery systems continue to improve, the data content that needs to be recorded during actual operation may vary, and the data recording requirements may also change in different operating stages or application scenarios.

[0004] In existing technologies, BMS typically uses log recording to store data generated during operation. However, in practical applications, log data storage needs to simultaneously meet requirements such as reliable data preservation, efficient storage space utilization, and subsequent data retrieval and analysis. When the scale of data to be recorded increases or the data content changes, traditional log storage methods may struggle to balance storage resource consumption and data processing convenience, leading to limited log data retention periods or increased complexity in subsequent data management and analysis.

[0005] In the process of developing this application, the inventors discovered that the prior art has at least the following problems: the existing battery management system log storage method is difficult to balance log data storage efficiency, data recording flexibility and subsequent parsing convenience when facing different types of operational data recording needs. Summary of the Invention

[0006] To address the aforementioned issues, this application provides a log storage method, apparatus, battery management system, and storage medium to achieve efficient storage of battery management system log data and flexible adaptation to different data recording needs.

[0007] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a log storage method applied to a battery management system. The method includes: acquiring data to be stored, and determining parsing rule information corresponding to the data to be stored based on the data to be stored; encoding the data to be stored based on the parsing rule information and a preset variable-length format to generate log data records; wherein the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using a variable-length format; associating the parsing rule information with the log data records to generate a log file; and storing the log file in the storage medium of the battery management system.

[0008] In some embodiments, the parsing rule information includes a parsing rule row and a header row. The parsing rule row is used to describe the data type and field type of each fixed-length data field in the log data record, so as to determine the arrangement rule of each fixed-length data field in the log data record. The header row is used to describe the field attribute information corresponding to each fixed-length data field, so as to determine the physical meaning of each fixed-length data field. The parsing rule row and the header row are established in a corresponding relationship according to a preset field order.

[0009] In some embodiments, the parsing rule lines are stored in the log file in character encoding form; the parsing rule lines include multiple field type key-value pairs, each field type key-value pair includes a field type identifier and a rule symbol, and each field type key-value pair is distinguished by a first delimiter; wherein, the field type identifier is used to identify the field type of the corresponding fixed-length data field; the rule symbol is used to describe the data type of the corresponding fixed-length data field.

[0010] In some embodiments, the header row is stored in the log file in character encoding form; the header row includes multiple hierarchical key-value pairs, each hierarchical key-value pair includes a fixed-length data field name and field attribute information corresponding to the fixed-length data field name; wherein, the field attribute information includes multiple attribute dimension key-value pairs; each attribute dimension key-value pair includes an attribute dimension and a data value; wherein, each attribute dimension key-value pair is distinguished by a second delimiter, and each hierarchical key-value pair is distinguished by a first delimiter.

[0011] In some embodiments, encoding the data to be stored based on parsing rule information and a preset variable-length type length format to generate log data records includes: encoding fixed-length data in the data to be stored according to parsing rule information and a preset field order to generate a fixed-length data field arranged in binary byte format; encoding extended data in the data to be stored according to a variable-length type length format to generate an extended data field; and combining the fixed-length data field and the extended data field to generate log data records.

[0012] In some embodiments, the extended data field includes an identifier, a length field, and a data field. The identifier is used to identify the extended data type corresponding to the extended data field; the length field is used to indicate the data length of the data field in the extended data field; and the data field is used to store the data content corresponding to the extended data type. The identifier, length field, and data field are arranged in sequence to generate the extended data field.

[0013] In some embodiments, the method further includes: using variable-length encoding to represent the data length of the data field in the extended data field; wherein, when the data length of the data field meets a preset first length threshold range, a single-byte encoding is used to represent the length field; and when the data length of the data field meets a preset second length threshold range, a two-byte encoding is used to represent the length field.

[0014] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a log storage device applied to a battery management system. The device includes: a data acquisition module for acquiring data to be stored and determining parsing rule information corresponding to the data to be stored; a data encoding module for encoding the data to be stored based on the parsing rule information and a preset variable-length format to generate log data records; wherein the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using a variable-length format; a log file generation module for associating the parsing rule information with the log data records to generate a log file; and a log file storage module for storing the log file in the storage medium of the battery management system.

[0015] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a battery management system, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned method.

[0016] To solve the above-mentioned technical problems, another technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium that stores computer-executable instructions, which, when executed by the battery management system, cause the battery management system to perform the above-mentioned method.

[0017] Unlike related technologies, this application provides a log storage method, apparatus, battery management system, and storage medium. By acquiring the data to be stored and determining the corresponding parsing rule information, the data is further encoded based on the parsing rule information and a variable-length format to generate log data records including fixed-length data fields and extended data fields. This allows the log data to be stored according to a predetermined data organization method. Specifically, the fixed-length data fields are arranged in binary byte format according to the parsing rule information, reducing data redundancy caused by data format conversion or the introduction of additional descriptive information during data recording, and improving space utilization efficiency in log data storage. The extended data fields are encoded using a variable-length format, allowing recording according to the actual needs of different data content, enabling the log storage method to adapt to the recording requirements of different data types. Furthermore, by associating the parsing rule information with the log data records, the generated log file simultaneously contains the data content and the corresponding parsing basis. During subsequent reading and analysis of the log file, the log data records can be parsed according to the parsing rule information, thereby reducing parsing difficulties caused by unclear data record formats and improving the convenience of log data reading, analysis, and maintenance. Based on this, this application enables log data to be organized and stored more rationally under limited storage resources, improves the adaptability of log data recording methods to different data content, and enhances the convenience of subsequent data parsing and processing, thereby solving the problem that existing battery management systems cannot balance storage efficiency, data recording flexibility, and log parsing convenience in log storage. Attached Figure Description

[0018] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0019] Figure 1 This is a flowchart of a log storage method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a log storage device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware structure of a battery management system provided in an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0021] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0022] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more.

[0023] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application.

[0024] Please see Figure 1 , Figure 1 This is a flowchart of a log storage method provided in an embodiment of this application. For example... Figure 1 As shown, the method includes steps S1-S4: S1: Obtain the data to be stored, and determine the parsing rule information corresponding to the data to be stored based on the data to be stored.

[0025] The parsing rule information includes parsing rule rows and table header rows. The parsing rule rows describe the data type and field type of each fixed-length data field in the log data record to determine the arrangement rule of each fixed-length data field in the log data record. The table header rows describe the field attribute information corresponding to each fixed-length data field to determine the physical meaning of each fixed-length data field. The parsing rule rows and table header rows are established in a corresponding relationship according to the preset field order.

[0026] The parsing rule lines are stored in the log file in character encoding format. Each parsing rule line includes multiple field type key-value pairs. Each field type key-value pair includes a field type identifier and a rule symbol. Each field type key-value pair is distinguished by a first delimiter. The field type identifier is used to identify the field type of the corresponding fixed-length data field. The rule symbol is used to describe the data type of the corresponding fixed-length data field.

[0027] The table header row is stored in the log file in character encoding format. The table header row includes multiple hierarchical key-value pairs. Each hierarchical key-value pair includes a fixed-length data field name and the corresponding field attribute information. The field attribute information includes multiple attribute dimension key-value pairs. Each attribute dimension key-value pair includes the attribute dimension and the data value. Each attribute dimension key-value pair is separated by a second delimiter, and each hierarchical key-value pair is separated by a first delimiter.

[0028] In this embodiment, when the battery management system performs log storage operation, it first obtains the data to be stored and determines the corresponding parsing rule information based on the data to be stored.

[0029] The data to be stored refers to the data that the battery management system needs to record into the log file during operation. This data can include battery operating status data and event data. For example, the data to be stored can include operating parameters such as battery state of charge (SOC), battery voltage, battery current, and battery temperature, as well as event information such as fault codes and alarm messages generated by the battery management system when it detects abnormal conditions.

[0030] Since different types of data to be stored may have different data types, data lengths, and physical meanings, the battery management system determines the corresponding parsing rules based on the data composition of the data to be stored before storing it, so that the subsequently generated log data records can be encoded and parsed according to the parsing rules.

[0031] The parsing rule information describes the data organization method and meaning of each data field in the log data record. In this embodiment, the parsing rule information includes parsing rule rows and table header rows.

[0032] The parsing rule row describes the data type and field type of each fixed-length data field in the log data record, in order to determine the arrangement rules of each fixed-length data field in the log data record.

[0033] Fixed-length data fields refer to data fields with a fixed length in log data records. For example, time data can be stored using a fixed 4 bytes, SOC data can be stored using a fixed 1 byte, and voltage data can be stored using a fixed 2 bytes. These fixed-length data fields can be arranged consecutively according to a predefined data type, thereby reducing additional overhead during data storage.

[0034] The header row is used to describe the field attribute information corresponding to each fixed-length data field, so as to determine the physical meaning of each fixed-length data field.

[0035] Among them, the field attribute information is used to represent the actual business attributes corresponding to the fixed-length data field, such as field name, unit, precision, value range, alarm threshold, warning threshold, calculation formula, field description, data source, collection frequency, and storage strategy. This allows the actual physical quantity represented by the corresponding data field to be determined based on the field attribute information when reading the log file later.

[0036] Furthermore, the parsing rule rows and the table header rows are established in a corresponding relationship according to the preset field order.

[0037] The preset field order refers to the arrangement order of each fixed-length data field predetermined by the battery management system when generating parsing rule information. The parsing rule rows describe the data types of each fixed-length data field in sequence according to this preset field order, and the header rows describe the field attribute information corresponding to each fixed-length data field in sequence according to the same preset field order.

[0038] For example, when the first field in the parsing rule row describes the time data type, the first field in the header row corresponds to the field attribute describing the time field; when the second field in the parsing rule row describes the SOC data type, the second field in the header row corresponds to the field attribute describing the SOC field.

[0039] Through the above correspondence, the parsing rule rows and the table header rows together constitute complete parsing rule information.

[0040] In this embodiment, the parsing rule lines are stored in the log file in character encoding format. The character encoding format can be ASCII character encoding. The parsing rule lines include multiple field type key-value pairs. These field type key-value pairs describe the data type definition relationship of a fixed-length data field. Each field type key-value pair includes a field type identifier and a rule symbol. The field type identifier identifies the field type of the corresponding fixed-length data field. For example, different field type identifiers can be used to distinguish different types of data fields such as time fields, SOC fields, voltage fields, and current fields. The rule symbol describes the data type of the corresponding fixed-length data field. For example, as shown in Table 1, different rule symbols can be used to represent different data lengths and data types: t4 represents 4-byte time type data; u1 represents 1-byte unsigned integer type data; u2 represents 2-byte unsigned integer type data; s2 represents 2-byte signed integer type data; x1 represents 1-byte hexadecimal type data; c36 represents a maximum of 36 bytes of character type data (not shown in Table 1).

[0041] Table 1 - Rules

[0042] In addition, multiple field type key-value pairs are distinguished by a first delimiter. The first delimiter is used to indicate the boundary between adjacent field type key-value pairs. In this embodiment, the first delimiter is a comma ",".

[0043] Therefore, the parsing rule line can be in the following format: [Type1]:[Rule symbol 1],[Type2]:[Rule symbol 2],...,\r\n.

[0044] Where: "[Type1]" represents the field type identifier; "[Rule Symbol 1]" represents the rule symbol used to describe the data type; "," represents the first delimiter; and "\r\n" represents the end identifier of the parsing rule line.

[0045] For example, a set of parsing rule rows generated by the battery management system can be: 01:t4,02:u1,03:u2,04:s2,05:u1,06:x1,07:c36,\r\n. This includes key-value pairs of the following field types: 01:t4, 02:u1, 03:u2, 04:s2, 05:u1, 06:x1, 07:c36.

[0046] The above field type key-value pair representation: The field type identifier 01 corresponds to the rule symbol t4, therefore the field with the field type identifier 01 is 4 bytes of time data; The field type identifier 02 corresponds to the rule symbol u1, therefore the field with the field type identifier 02 is a 1-byte unsigned integer data; The field type identifier 03 corresponds to the rule symbol u2, therefore the field with the field type identifier 03 is a 2-byte unsigned integer data; The field type identifier 04 corresponds to the rule symbol s2, therefore the field with the field type identifier 04 is a 2-byte signed integer data; The field type identifier 05 corresponds to the rule symbol u1, therefore the field with the field type identifier 05 is a 1-byte unsigned integer data; The field type identifier 06 corresponds to the rule symbol x1, therefore the field with the field type identifier 06 is 1 byte of hexadecimal data; The field type identifier 07 corresponds to the rule symbol c36, therefore the field with the field type identifier 07 is a maximum of 36 bytes of character data.

[0047] The above method defines the data types and arrangement rules of each fixed-length data field in the log data record.

[0048] It's important to note that the parsing rule line only defines fixed-length data fields; extended data fields are not defined here but are dynamically added to the log data records using variable-length data types. This ensures the simplicity of the parsing rule line while leaving ample room for future expansion.

[0049] In this embodiment, the header row is also stored in the log file using character encoding (ASCII character encoding). The header row includes multiple hierarchical key-value pairs. These hierarchical key-value pairs describe a fixed-length data field and its corresponding field attribute information.

[0050] Specifically, each hierarchical key-value pair includes a fixed-length data field name and field attribute information.

[0051] The fixed-length data field name is used to represent the field name, such as DayTime, SOC, BatV, Curr, etc. Field attribute information describes the attribute content corresponding to the field. Field attribute information includes multiple attribute dimension key-value pairs. Each attribute dimension key-value pair includes the attribute dimension and the data value.

[0052] Table 2 - Attribute Dimension Definition Table

[0053] As shown in Table 2, attribute dimensions are used to represent the category of field attributes. For example: U represents the unit attribute; P represents the precision attribute; R represents the range attribute; A represents the alarm threshold attribute; W represents the warning threshold attribute; and D represents the descriptive attribute. Data values ​​are used to represent the specific content corresponding to the attribute dimension. For example: U:mV. Where: U is the attribute dimension, representing the unit; mV is the data value, indicating that the unit of this field is millivolts.

[0054] Multiple attribute dimension key-value pairs are distinguished by a second delimiter. This second delimiter represents the boundary between different attributes within the same field. In this embodiment, the second delimiter is a vertical bar "|". Multiple hierarchical key-value pairs are distinguished by a first delimiter, namely a comma ",".

[0055] Therefore, the header row can adopt the following format: Fixed-length data field name 1 [attribute dimension 1: data value 1|attribute dimension 2: data value 2|attribute dimension 3: data value 3], Fixed-length data field name 2 [attribute dimension 1: data value 1|attribute dimension 2: data value 2],...,\r\n. It can be understood that the hierarchical key-value pairs are "Fixed-length data field name 1 [attribute dimension 1: data value 1|attribute dimension 2: data value 2|attribute dimension 3: data value 3]"; where "[attribute dimension 1: data value 1|attribute dimension 2: data value 2|attribute dimension 3: data value 3]" represents the field attribute information; and "attribute dimension 1: data value 1" represents the attribute dimension key-value pair.

[0056] For example: DayTime[U:s|D:Storage time], SOC[U:%|P:0|R:0-100|D:Battery state of charge], BatV[U:mV|P:1|R:0-5000|A:4200|W:4000|D:Total battery voltage], Curr[U:A|P:2|R:-500-500|D:Charging and discharging current], SOH[U:%|P:0|R:0-100|D:Battery health], Temp[U:℃|P:1|R:-20-80|D:Battery temperature]\r\n.

[0057] In this context, SOC[U:%|P:0|R:0-100|D:Battery State of Charge] represents: a fixed-length data field named SOC; the data value corresponding to attribute dimension U is %, indicating that the SOC unit is percentage; the data value corresponding to attribute dimension P is 0, indicating a precision of 0; the data value corresponding to attribute dimension R is 0-100, representing the value range; and the data value corresponding to attribute dimension D is the battery state of charge, representing the physical meaning of the field. It should be noted that the data value corresponding to attribute dimension D (such as battery state of charge) needs to be converted to its corresponding ASCII code for storage.

[0058] For BatV[U:mV|P:1|R:0-5000|A:4200|W:4000|D:total battery voltage], it means: the fixed-length data field name is BatV; the unit is mV; the precision is 1; the range is 0-5000; the alarm threshold is 4200; the warning threshold is 4000; and the field description is total battery voltage.

[0059] The analysis results of the above examples are shown in Table 3 below: Table 3 - Analysis Results

[0060] In this embodiment, the parsing rule row and the table header row together constitute the parsing rule information. The parsing rule row is used to determine the data parsing method for each fixed-length data field in the log data record, including the field type, data length, and arrangement order; the table header row is used to determine the actual physical meaning and attribute information corresponding to the parsed data fields.

[0061] Since the parsing rule rows and header rows are established in a corresponding relationship according to the preset field order, when the host computer reads the log file, it can: first, determine the reading length and data type of each fixed-length data field based on the field type identifier and rule symbol in the parsing rule row; then, determine the fixed-length data field name and field attribute information corresponding to the field based on the hierarchical key-value pair in the header row; and finally achieve accurate parsing of each fixed-length data field in the log data record.

[0062] For example, the parsing rule behavior is: 01:t4, 02:u1, 03:u2; the header behavior is: DayTime[U:s|D:Storage Time], SOC[U:%|D:Battery State of Charge], BatV[U:mV|D:Total Battery Voltage]. Then: field type identifier 01 corresponds to the DayTime field; field type identifier 02 corresponds to the SOC field; and field type identifier 03 corresponds to the BatV field.

[0063] In this embodiment, by acquiring the data to be stored and determining the corresponding parsing rule information based on the data, the parsing rule information includes parsing rule rows describing the data type and arrangement rules of fixed-length data fields, and header rows describing the physical meaning of fixed-length data fields. This allows each data field in the data to be stored to establish an association with its corresponding parsing rule. Furthermore, by establishing a correspondence between the parsing rule rows and header rows according to a preset field order, the data type description and field attribute description of the same field are kept consistent, thereby improving the accuracy and consistency of log data organization. Simultaneously, by using field type key-value pairs to describe the data type of the fixed-length data fields and using hierarchical key-value pairs to describe the corresponding field attribute information, the parsing rule information can be represented in a structured manner, facilitating subsequent encoding and parsing of log data records based on this parsing rule information. Therefore, this embodiment provides a clear data description basis for the standardized storage of log data and subsequent data reading and analysis, reducing data parsing difficulties caused by unclear data field definitions and improving the reliability and maintainability of log data processing.

[0064] S2: Based on the parsing rule information and the preset variable-length type length format, the data to be stored is encoded to generate log data records; wherein, the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using variable-length type length format.

[0065] Specifically, based on parsing rule information and a preset variable-length type length format, the data to be stored is encoded to generate log data records. This includes: encoding fixed-length data in the data to be stored according to parsing rule information and a preset field order to generate fixed-length data fields arranged in binary byte format; encoding extended data in the data to be stored according to the variable-length type length format to generate extended data fields; and combining the fixed-length data fields and the extended data fields to generate log data records.

[0066] The extended data field includes an identifier, a length field, and a data field. The identifier is used to identify the extended data type corresponding to the extended data field; the length field is used to indicate the data length of the data field in the extended data field; and the data field is used to store the data content corresponding to the extended data type. The identifier, length field, and data field are arranged in sequence to generate the extended data field.

[0067] The method further includes: the length field in the extended data field uses variable-length encoding to represent the data length of the data field; wherein, when the data length of the data field meets the preset first length threshold range, the length field is represented by single-byte encoding; and when the data length of the data field meets the preset second length threshold range, the length field is represented by two-byte encoding.

[0068] After acquiring the data to be stored and determining the parsing rule information corresponding to the data to be stored, the battery management system encodes the data to be stored based on the parsing rule information and the preset variable length format to generate the corresponding log data record.

[0069] The data to be stored can be understood as data collected or generated by the battery management system during operation and requiring recording. Based on the characteristics of data generation and data recording requirements, the data to be stored can include periodically generated operational data and event data generated when specific events occur. Operational data is typically data continuously collected during the operation of the battery management system, such as time information, state of charge (SOC), battery voltage, current, state of health (SOH), and temperature. This type of data is characterized by high generation frequency, relatively fixed field types, and usually fixed data length; therefore, in this embodiment, it is processed as fixed-length data. Event data is typically data generated by the battery management system during operation based on abnormal states, diagnostic needs, or specific business requirements, such as fault codes, fault names, fault levels, individual cell voltage arrays, equalization status information, device serial numbers, and diagnostic data. Since this type of data is not generated in every operation, and the data content and length corresponding to different events may differ, in this embodiment, it is processed as extended data.

[0070] Furthermore, to achieve unified recording of different types of data to be stored, this implementation adopts a data organization method that combines fixed-length data fields and extended data fields. Specifically, for fixed-length data with fixed field types and determined data lengths, a binary compact arrangement is used to generate fixed-length data fields; for extended data with variable lengths or dynamically generated based on actual events, a variable-length type length format is used for encoding to generate extended data fields.

[0071] Specifically, when encoding the data to be stored based on the parsing rule information and the preset field order, the data type and arrangement order of each fixed-length data in the data to be stored are first determined according to the parsing rule information, and the fixed-length data is encoded according to the preset field order to generate a fixed-length data field arranged in binary byte format.

[0072] The preset field order is used to define the arrangement of each fixed-length data field in the log data record, corresponding to the field definition order in the aforementioned parsing rule information. For example, if the data size field, time field, SOC field, voltage field, current field, and SOH field are defined sequentially in the parsing rule information, the corresponding generated fixed-length data fields will be arranged in the above order. For example, when the parsing rule information is defined as: t4,u1,u2,s2,u1, it means that the fixed-length data fields in the log data record include, in sequence: t4 type field; u1 type field; u2 type field; s2 type field; u1 type field. Where: t4 represents a 4-byte data type; u1 represents a 1-byte unsigned data type; u2 represents a 2-byte unsigned data type; and s2 represents a 2-byte signed data type.

[0073] Therefore, during encoding, the battery management system converts the corresponding data into binary bytes that match the field type according to the above parsing rules, and arranges them continuously according to the preset field order to form a fixed-length data field.

[0074] After completing the encoding of the fixed-length data fields, the battery management system continues to encode the extended data in the data to be stored.

[0075] The extended data fields are encoded using a variable-length type length format. This format dynamically determines the data length of the extended data field based on its actual content, avoiding the waste of data space that would result from using fixed-length fields. For example, extended data fields are encoded using a variable-length type length (VTL) format. Each extended data field consists of three parts: an identifier, a length field, and a data field.

[0076] An identifier is set at the beginning of an extended data field to indicate the extended data type corresponding to the current extended data field. By setting different identifiers, the host computer can determine the data content represented by subsequent data fields when reading log data records.

[0077] The length field, set after the identifier, indicates the length of the data field in the current extended data field. When the host computer reads the extended data field, it can first read the length field and determine the number of data bytes to be read subsequently based on the length field.

[0078] The data field is set after the length field and is used to store the actual data content corresponding to the identifier.

[0079] Therefore, the complete data structure of an extended data field is: [Identifier][Length Field][Data Field]. The identifier, length field, and data field are arranged in the order described above.

[0080] With the above structure, since the extended data field itself carries data type information and data length information, even if the extended data content in different log data records is different, the host computer can still complete the reading of the corresponding data based on the identifier and length field in the extended data field.

[0081] After the fixed-length data field and the extended data field are encoded, the fixed-length data field and the extended data field are combined according to a preset arrangement to generate log data records.

[0082] Specifically, the log data records adopt a hybrid structure of "fixed-length data fields arranged compactly + dynamically expanded data fields".

[0083] That is: [fixed-length data field length (N)][fixed-length data field 1][fixed-length data field 2]……[fixed-length data field N][fixed-length data field CRC][extended data field 1][extended data field 2]……[extended data field M][end character].

[0084] Among them, the fixed-length data field length N is used to represent the data length of the fixed-length data field part in the current log data record; fixed-length data fields 1 to N are used to store the core running data after being encoded according to the parsing rules; the fixed-length data field CRC is used to verify the fixed-length data field part; extended data fields 1 to M correspond to the extended data fields after being encoded using the variable-length type length format; the end character is used to indicate the end of the current log data record.

[0085] In this way, the battery management system can simultaneously save both fixed-structure operational data and dynamically generated event data in the same log data record.

[0086] Understandably, for core operational data continuously generated during operation, compact arrangement using fixed-length data fields can reduce the data space occupied by field description information; for data of uncertain length generated during fault or diagnosis, dynamic recording using extended data fields allows log data records to add corresponding information according to actual needs.

[0087] It should be noted that, in this embodiment, the data records in the log file are actually stored in binary byte format.

[0088] Since binary data is inconvenient to read and explain when displayed directly, in the relevant examples below the embodiments of this application, the actual stored binary bytes are represented in hexadecimal form to facilitate the explanation of the data arrangement relationship between each field and the parsing process.

[0089] For example, 40, 09DE, and FFFE represent the actual stored data byte sequence, not the direct storage of the ASCII characters "40", "09DE", and "FFFE" in the log file. Specifically, "40" corresponds to one byte actually stored, with a binary form of 01000000; "09DE" corresponds to two bytes actually stored; and "FFFE" corresponds to two bytes actually stored.

[0090] Therefore, the hexadecimal data representations in the subsequent specific examples are only for illustration and parsing, and do not change the fact that the log data is actually stored in binary bytes.

[0091] Table 4 - Examples of Identifier Definitions

[0092] In one specific implementation, as shown in Table 4, the identifier is defined using a preset range.

[0093] The identifiers in the range 0x01 to 0x7F are reserved for future expansion; the identifiers in the range 0x80 to 0xFE are used as identifiers for extended data fields to represent different types of extended data; and 0xFF is a reserved identifier for special purposes. Since the identifiers for extended data fields are located in the range 0x80 to 0xFE (i.e., the highest bit of the identifier is 1), the host computer can quickly identify whether the currently read data belongs to extended data by judging the highest bit of the identifier during log parsing.

[0094] For example, when the host computer reads an identifier with a value of 0x80, 0x81, etc., since the value is greater than or equal to 0x80, it determines that the current data belongs to dynamically extended data and further reads the subsequent length field and data field. When data less than 0x80 is read, it can be considered an exception or an end marker (which will not occur in actual design). If an unknown identifier is encountered, the corresponding data field is skipped based on the length field, and the parsing of the next extended data field continues. When the end marker 0D0A is encountered, the parsing of this extended data is complete.

[0095] In this embodiment, multiple dynamic extension block identifiers can be predefined for common extended data types in battery management systems.

[0096] For example, when the identifier in the extended data field is 0x81, it means that the current extended data field is used to record fault codes; when the identifier is 0x82, it means that the current extended data field is used to record fault names; and when the identifier is 0x84, it means that the current extended data field is used to record the voltage of multiple individual batteries.

[0097] Furthermore, to reduce the storage space occupied by the length description information in the extended data field, in this embodiment, the length field uses a variable-length encoding method to represent the data length of the data field. Specifically, the variable-length encoding method selects an encoding method with different numbers of bytes based on the actual length of the data field.

[0098] When the data length of the data field falls within the first length threshold range, a single-byte encoding method is used to represent the length field. In one embodiment, the first length threshold range is 0 to 127. In this case, the length field is represented by 1 byte. The highest bit of this 1-byte length field is set to 0, and the remaining 7 bits are used to store the actual length value. Therefore, the single-byte length encoding can represent: 0 to 2^7-1, that is, the data length within the range of 0 to 127. For example, when the data field length is 5 bytes, since 5 is within the range of 0 to 127, the length field is encoded as: 0x05, that is: length field = 05, data field length = 5 bytes.

[0099] When the data length of the data field is within the second length threshold range, a two-byte encoding method is used to represent the length field. In one implementation, the second length threshold range is 128 to 16383. In this case, the length field is represented by two bytes. The highest bit of the first byte is set to 1 to indicate that the current length field includes subsequent bytes; the remaining bits of the first byte and the second byte are used together to store the actual length value. For example, when the data field length is 200 bytes, since 200 is greater than 127, a single-byte length encoding cannot be used, and a two-byte length encoding is required. The encoding result is: 0x80 0xC8. The first byte 0x80 indicates that there are still length bytes to follow; the second byte 0xC8 participates in representing the actual length value.

[0100] Using the above method, when the data length is small, only one byte is needed to describe the length; when the data length is large, additional bytes are added to describe the length. Compared to fixed-length fields, this implementation can reduce the length description overhead in a large number of short extended data fields.

[0101] For example, for data such as fault codes that typically only occupy a few bytes, if a fixed 2-byte length field is used, each extended data field will occupy an extra 1 byte of space; however, by using the variable-length encoding method described above, short-length data only needs 1 byte of length for description, thereby reducing the log storage space occupied.

[0102] Furthermore, to illustrate the specific encoding method of the above log data recording, the following explanation is provided with specific examples.

[0103] It should be noted that the data in the following examples is represented in hexadecimal form. Since log data is actually stored in binary bytes, hexadecimal is only used as a display format for binary data to facilitate explaining the field arrangement and parsing process. For example, hexadecimal 40 actually corresponds to one byte: 01000000; hexadecimal 09DE actually corresponds to two bytes: 00001001 11011110. Therefore, the hexadecimal data in the examples is not stored as characters, but rather as a readable representation of binary byte data.

[0104] Example 1: In one implementation, when the battery management system is in normal operation, only core operating data needs to be recorded, and no extended data is generated.

[0105] At this point, the log data record can be represented as: 0B 640EE3FD 40 09DE FFFE 40 B3 0D0A.

[0106] Where: 0B represents the length of the fixed-length data section; 640EE3FD represents the time field; 40 represents the SOC field; 09DE represents the voltage field; FFFE represents the current field; 40 represents the SOH field; B3 represents the CRC check field; 0D0A represents the end character.

[0107] Based on the parsing rules: x1, t4, u1, u2, s2, u1, we determine that: data field length x1 is 1 byte, time t4 is 4 bytes, SOC u1 is 1 byte, voltage u2 is 2 bytes, current s2 is 2 bytes, and SOH u1 is 1 byte. Therefore, the total length of the fixed-length data fields is: 1 + 4 + 1 + 2 + 2 + 1 = 11 bytes, i.e., N = 11.

[0108] The parsing process is as follows: As shown in Table 5, for 0B, based on 1 byte of data, it represents a fixed-length data length of 11 bytes; for 640EE3FD, based on 4 bytes of data, it is converted to decimal: 1678697469. This value is used as a Unix timestamp for further conversion. It can be understood that after being converted to the decimal number 1678697469, it is parsed as 2023-03-13 16:51:09 via timestamp-to-date conversion. The specific conversion process is as follows: For 1678697469, 1678697469 ÷ 86400 (seconds in a day) = 19429 days with a remainder of 41229 seconds; 41229 seconds = 11 hours 27 minutes 9 seconds (41229 ÷ 3600 = 11 hours, 41229 - 11 × 3600 = 1629 seconds, 1629 ÷ 60 = 27 minutes with a remainder of 9 seconds); Therefore, the UTC time is: 11:27:09 19429 days after 1970-01-01; UTC time: 2023-03-13 08:51:09; that is, Beijing time (East Eight Zone): 2023-03-13 16:51:09.

[0109] For 40, converted to decimal: 0x40 = 64. Therefore, SOC = 64%. For 09DE, converted to decimal: 2526. Therefore, voltage = 2526mV. For FFFE, according to signed data parsing: FFFE = -2. Therefore, current = -2A. For 40, similarly converted, SOH = 64%. Additionally, B3 is the CRC check bit, i.e., CRC = 179. Since the end-of-line character 0D0A is directly read after parsing the fixed-length data field, it indicates that this log record does not contain dynamically extended data. This log record contains only: 11 bytes of fixed-length data + 1 byte of CRC + 2 bytes of end-of-line character, occupying only 14 bytes, recording 6 core parameters.

[0110] Table 5 - Analysis Results of Example 1

[0111] Example 2: In another implementation, when a fault event is detected during the operation of the battery management system, in addition to recording the core operating data under normal operating conditions, it is also necessary to record extended data related to the fault event, such as fault codes and fault names.

[0112] At this point, since fault data does not exist in every log record, and the data lengths corresponding to different faults may be different, fault-related information is treated as extended data and encoded according to the extended data field format.

[0113] The corresponding generated log data record can be represented as: 0B 640EE3FD 40 09DE FFFE 40 B3 81 0201 2C 82 05 46 61 75 6C 74 0D0A.

[0114] The first part, 0B 640EE3FD 40 09DE FFFE 40 B3, corresponds to a fixed-length data field. The second part, 81 02 01 2C 82 05 46 61 75 6C 74 0D0A, corresponds to an extended data field.

[0115] First, based on the parsing rules, the fixed-length data fields in the log data records are parsed. The parsing process for fixed-length fields is the same as in Example 1, and will not be repeated here.

[0116] After parsing the fixed-length data field, the system continues reading subsequent data. Since the subsequent data is not terminated by 0D0A, but by 81, and 0x81 is greater than 0x80, the host computer determines that the subsequent data is a dynamically extended data field and continues parsing it according to the VTL format. The parsing process for this extended data field is as follows: (1) Parsing of extended data field for fault code: For 81 02 01 2C, parsing is performed according to the VTL format ([identifier][length field][data field]). Here, 81 is the identifier, and according to the identifier mapping relationship defined in Table 4 above, 0x81 is the fault code. Therefore, the current extended data field is determined to be used to record the fault code. Next, the length field 02 is read. Since 0x02 < 0x80, according to the variable-length encoding rule, the current length field is determined to use single-byte encoding. The conversion yields: data field length = 2 bytes. Subsequently, the data field 01 2C is read. Since the data format corresponding to the fault code identifier 0x81 is 2 bytes, 2 bytes of data are read. 0x012C is converted to decimal as 300. Therefore, the fault code = 300.

[0117] (2) Parsing the extended data field of the fault name: Continue reading the next dynamic extended data field: 82 05 46 6175 6C 74. Similarly, according to the VTL format, we get: 82 corresponds to the fault name; data field length = 5 bytes; for the data field 46 61 75 6C 74, this data field uses ASCII character encoding. After conversion, we get: Fault. Therefore, the fault name = Fault. Finally, as shown in Table 6, the parsing result of this log data record is: time = 2023-03-13 16:51:09, SOC = 64%, voltage = 2526mV, current = -2A, SOH = 64%; dynamic extended data: fault code = 300, fault name = Fault. In addition, the fixed-length data field (fixed-length 11 bytes + 1 CRC check bit) + extended data field 1 (1+1+2) + extended data field 2 (1+1+5) = 23 bytes, for a total of 23 bytes. Compared to recording all data using fixed fields, this implementation method uses 12 more bytes than pure fixed-length data, but only adds corresponding extended data fields when a fault occurs, recording complete fault information and providing key data for fault analysis, thereby avoiding reserving fixed storage space for non-existent data under normal operating conditions.

[0118] Table 6 - Parsing Results of Extended Data Fields in Example 2

[0119] Example 3: In another implementation, when the battery management system needs to record voltage information for multiple individual cells, since the number of cells may vary with battery specifications, this type of data is suitable for recording as extended data.

[0120] For example, a log record might look like this: 0B 640EE3FD 40 09DE FFFE 40 B3 84 08 09DE0A1F 0B2C 0C3D 0D0A. The first part, 0B 640EE3FD 40 09DE FFFE 40 B3, is a fixed-length data field, as explained in Example 1, and will not be repeated here. The second part, 84 08 09DE 0A1F 0B2C 0C3D, is an extended data field.

[0121] According to the VTL format parsing, identifier 84 is read first. As shown in Table 4 above, 0x84 corresponds to the individual cell voltage array, indicating that the current extended data field records multiple individual cell voltages. Next, the length field 08 is read. Since 0x08 < 0x80, single-byte length encoding is used, resulting in a data field length of 8 bytes. Then, the data fields 09DE 0A1F 0B2C 0C3D are read. Because the individual cell voltage array data format is defined as N×2 bytes, each two bytes correspond to one individual cell voltage value. Through base conversion, we obtain: 09DE = 2526; 0A1F = 2591; 0B2C = 2860; 0C3D = 3133, as shown in Table 7. Therefore, this log entry, based on the core operating data, simultaneously records the voltage information of four individual cells, which can be used for subsequent battery balancing analysis and fault diagnosis.

[0122] Table 7 - Parsing Results of Extended Data Fields in Example 3

[0123] Example 4: In another implementation, when the battery management system generates multiple event data simultaneously, multiple extended data fields can be added consecutively to the same log data record.

[0124] For example: 0B 640EE3FD 40 09DE FFFE 40 B3 81 02 01 2C 82 05 46 61 75 6C 7483 01 02 86 02 00 03 0D0A. This includes: fault code, fault name, fault level, and balance status.

[0125] The analysis of 0B 640EE3FD 40 09DE FFFE 40 B3 has been explained in Example 1, and the analysis of fault code 81 0201 2C and fault name 82 05 46 61 75 6C 74 has been explained in Example 2, and will not be repeated here.

[0126] For the fault level extended data field, identifier 83 represents the fault level, and the length field is 01, indicating that the data field length = 1 byte. For data field 02, according to the fault level definition: 0: Warning; 1: Critical; 2: Fatal. Therefore, the fault level = Fatal fault.

[0127] As shown in Table 8, for the balanced state extended data field, identifier 86 represents the balanced state, the length field is 02, and the data field length is 2 bytes. For the data field 00 03, its hexadecimal representation is 0x0003. Since the balanced state is represented using a bitmap, it is further converted to binary, i.e., 0000 0000 0000 0011. The lowest two bits are: bit0=1, bit1=1. This indicates that the first and second individual cells are in a balanced state. For example, if the data field is 00 0B, then 0x000B is converted to binary, i.e., 0000 0000 0000 1011. Here, bit0, bit1, and bit3 are all 1. Therefore, this indicates that the first, second, and fourth individual cells are in a balanced state. Through the above analysis, it can be seen that this example fully records the detailed information when the fault occurs, including the fault code, name, level, and current balanced state.

[0128] Table 8 - Parsing Results of Extended Data Fields in Example 4

[0129] In this embodiment, the data to be stored is encoded based on parsing rules and a preset variable-length format, enabling the generated log data records to adopt matching data organization methods according to different data types. Specifically, for operational data collected frequently in the battery management system with fixed field lengths, the corresponding data type and field arrangement order can be determined according to the parsing rules, and fixed-length data fields are generated using binary byte format. This allows the fixed data to be compactly arranged according to a preset structure, reducing data redundancy caused by field description information and additional format conversions, thus improving the storage and parsing efficiency of log data records. Simultaneously, for extended data such as fault information and diagnostic information with variable lengths or types, extended data fields are generated using a variable-length format. This allows the extended data to be self-describingly stored through identifiers, length fields, and data fields. Without changing the existing fixed-length data field structure, different types of data content can be added according to actual needs, improving the adaptability of the log recording method to different application scenarios and data changes.

[0130] Furthermore, by combining fixed-length data fields with extended data fields to generate log data records, a single log record can simultaneously carry basic operational data and dynamically changing data. This ensures efficient storage of core data while enabling flexible recording of abnormal events or additional diagnostic information. Specifically, the length field in the extended data field uses variable-length encoding to represent the data length, allowing the space occupied by the length information to be adjusted according to the actual data length. Shorter encoding is used for shorter data, and multi-byte encoding is used for longer data, thus avoiding the space waste caused by fixed-length fields and improving the utilization rate of log storage space. Therefore, this application, through the above encoding method, enables log data records to balance efficient storage of fixed data and flexible recording of extended data, solving the problem that existing log storage methods struggle to simultaneously satisfy storage efficiency, data scalability, and subsequent parsing convenience.

[0131] S3: Associate and store the parsing rule information with log data records to generate a log file.

[0132] S4: Store the log file in the storage medium of the battery management system.

[0133] After completing the encoding process of the data to be stored and generating log data records, the parsing rule information is further associated with the log data records for storage to generate log files.

[0134] Specifically, when generating log files, the battery management system can first determine whether a new log file needs to be created. If it detects that there is no target log file for storing log data records, or that a new log file needs to be created, the battery management system initializes the log file.

[0135] In one implementation, during the initialization of the log file, the battery management system first writes parsing rule information into the log file. This parsing rule information includes parsing rule lines and header lines. The parsing rule lines describe the data type and field type of each fixed-length data field in the log data record, while the header lines describe the field attribute information corresponding to each fixed-length data field. Both the parsing rule lines and header lines are stored in character encoding and serve as the rule description and field attribute description sections in the log file, respectively.

[0136] Furthermore, when writing the parsing rule lines and header lines, the battery management system can write the parsing rule lines as rule description lines in the log file and the header lines as field description lines in the log file, according to ASCII format. A preset terminator is used to distinguish between the parsing rule lines and header lines, as well as between the parsing rule lines / header lines and subsequent log data records. In this embodiment, the terminator can be a carriage return and line feed character "\r\n", meaning each line of log content ends with "\r\n" to form a line-based log file structure.

[0137] For example, a log file may include: the first line: a parsing rule line, which describes the data type and field type of fixed-length data fields that may appear in the log data record; the second line: a header line, which describes the physical meaning and field attributes of each fixed-length data field; and the third to Nth lines: log data records, which store the data content actually collected by the battery management system.

[0138] By using the above method, the log file not only contains the actual collected data content, but also the parsing basis used to interpret the data content, thus enabling the log file to have corresponding data parsing information.

[0139] It should be noted that once the log file has been initialized and the corresponding parsing rule information has been stored, the battery management system does not need to repeatedly write the parsing rule information and header row. Instead, it directly writes the subsequently generated log data records into the log file. For example, while continuously recording the battery's operating status in the same log file, the parsing rule row and header row are only written once when the log file is created. Subsequently collected data is simply used to generate log data records according to the corresponding data format and appended to the log file.

[0140] Furthermore, during the process of generating log data records, the battery management system can determine whether it is necessary to add extended data fields based on the current collection status.

[0141] Understandably, while collecting battery operating data, the battery management system can determine whether additional data needs to be recorded in the current log entry based on the current operating status. For example: When the battery management system is in normal operation, the current log record usually only includes fixed-length data fields to record fixed operating parameters such as time, SOC, voltage, current, and temperature. When a battery system malfunction is detected, the current log record can further include extended data fields to record fault-related information such as fault code, fault name, and fault level. When the battery management system is in debug mode, the current log records can further include debug-related data; When a special event is detected, the current log record can further include event data corresponding to that event.

[0142] After determining the data content of the current log record, the battery management system constructs a data buffer corresponding to the log data record. This data buffer is used to temporarily store log data records to be written to the log file. The battery management system determines the order of fixed-length data fields based on parsing rules and writes the corresponding data content sequentially into the data buffer according to the preset field order. Simultaneously, when extended data fields exist, these extended data fields, generated according to a variable-length data type format, are appended to the data buffer.

[0143] For example, log data records can be arranged in the following order: fixed-length data field section → fixed-length data field validation information → extended data field section → end marker. The fixed-length data field section stores a fixed length of runtime data, while the extended data field section stores data that is dynamically added based on actual events.

[0144] After the data buffer is constructed, the battery management system writes the log data records in the data buffer to the storage medium. This storage medium can be the flash memory within the battery management system or other storage media used to store the log data. The battery management system can write the entire data buffer, including the terminator, to the storage medium, allowing a complete log data record to be stored at once.

[0145] For example, during a log writing process, after the battery management system completes the construction of the current log data record, it writes the corresponding data buffer to the Flash storage area. When the next acquisition cycle arrives, the battery management system repeats the process of data acquisition, extended data judgment, data buffer construction, and writing to the storage medium, thereby forming the 2nd, 3rd, ... Nth line of log data records in the log file in sequence.

[0146] Through the above methods, the battery management system can associate and store parsed rule information with actual log data records, and continuously write them to the storage medium in the order of generation. This ensures that the log files completely preserve the data content and corresponding parsing basis, facilitating subsequent reading and parsing. Simultaneously, by performing overall writing based on a data buffer, multiple write operations are reduced, improving the stability and reliability of the log data storage process.

[0147] To further understand the implementation process of the log storage method provided in this application, the method is illustrated by taking the recording of state data during battery operation by a battery management system and the parsing of the generated log file by a host computer.

[0148] During BMS operation, the BMS collects real-time operational data of the battery system. This data can include information reflecting the battery's operating status, such as state of charge (SOC), battery voltage, current, and temperature. Simultaneously, when the BMS detects an abnormal state or meets preset log trigger conditions, it can generate corresponding event data, such as fault codes, fault names, fault levels, and diagnostic information. The log trigger conditions can be configured according to actual application requirements; for example, log recording can be triggered at preset time intervals or upon detecting an abnormal event.

[0149] When the BMS needs to save the collected data, it first determines the corresponding parsing rule information based on the data to be stored. The parsing rule information describes the data organization method of each field in the log data record, including parsing rule rows that describe the data type and data format of fixed-length data fields, and header rows that describe the physical meaning of fixed-length data fields.

[0150] When a log file is created for the first time, the BMS first writes the parsing rule information into the log file, that is, it writes the parsing rule line and the table header line into the log file. The parsing rule line is used to record the data type definition of each fixed-length data field, and the table header line is used to record the field name and attribute information corresponding to each fixed-length data field, so that the log file itself has the basis for data parsing.

[0151] Subsequently, the BMS encodes the collected data according to the parsing rules. For fixed-type, high-frequency collected operational data such as SOC, voltage, current, and temperature, the BMS encodes the data according to a preset field order, converting the corresponding data into fixed-length data fields arranged in binary byte format. For data with variable length, such as fault codes, fault names, and diagnostic data, the BMS encodes the data according to a variable-length format to form corresponding extended data fields.

[0152] The extended data field adopts a structure consisting of an identifier, a length field, and a data field. The BMS determines the corresponding identifier based on the type of extended data, generates a length field based on the actual length of the extended data, and writes the specific data content into the data field, thereby forming a data structure that can represent different types of extended information.

[0153] After data encoding is completed, the BMS combines fixed-length data fields and extended data fields according to a preset arrangement to generate corresponding data rows, and combines the parsing rule rows, header rows, and multiple data rows into a log file.

[0154] Furthermore, the BMS writes the generated log file to a storage medium, such as a Flash memory, to complete the local storage of the log data. During subsequent operation, the BMS can continuously collect new operational data or event data in the above manner and sequentially generate new data rows to be appended to the log file, thereby forming a complete log file containing multiple log records.

[0155] When it is necessary to analyze the BMS operating status, the BMS can upload log files from the storage medium to a host computer (such as a backend server) or send them to field diagnostic equipment via a wireless communication module or other data transmission methods. After obtaining the log files, the host computer first reads the parsing rule information in the log files.

[0156] Specifically, the host computer parsing software first reads the parsing rule lines in the log file. Based on the field type identifiers and corresponding rule symbols in the parsing rule lines, it determines the data type and data length of each fixed-length data field. For example, based on the field type definitions in the parsing rule lines, it can be determined that a certain field uses a 4-byte time data format, a certain field uses a 1-byte unsigned data format, a certain field uses a 2-byte signed data format, etc., thereby determining the parsing method for each field in subsequent data rows.

[0157] Subsequently, the host computer continues to read the header rows of the log file and determines the physical meaning of each parsed field based on the field names and attribute information recorded in the header rows. For example, a certain field may correspond to battery state of charge, total voltage, charging / discharging current, or battery temperature, thus enabling the parsed data to be displayed in a way that engineers can understand.

[0158] After loading the parsing rules, the host computer parses the log data according to the data line order in the log file. Specifically, the host computer first determines the arrangement of fixed-length data fields in the data line based on the parsing rule lines, and then reads the fixed-length data fields byte by byte according to the corresponding data types. At the same time, the host computer can verify the integrity of the read data based on the data length information and verification information in the data line.

[0159] After parsing the fixed-length data field, the host computer continues to determine whether there is an extended data field in the subsequent data. When an extended data field is detected, the host computer reads the identifier in the extended data field and determines the corresponding extended data type based on the identifier; then it reads the length field, determines the data length of the data field based on the length field, and reads the corresponding data content.

[0160] For example, when an extended data field with identifier 0x81 is read, the host computer can determine the fault code information corresponding to the extended data field according to the identifier mapping relationship, and read the corresponding data content according to the length field; when an extended data field with identifier 0x82 is read, it can determine the fault name information corresponding to the extended data field, and parse the data content according to the corresponding data format.

[0161] After parsing all data fields, the host computer converts the parsed data into corresponding physical quantities based on the field attribute information in the header row, and generates data tables, curves, or text information for engineers to view the BMS operating status and perform fault analysis.

[0162] For example, for the time field in the log file, after the host computer reads the corresponding time data, it can convert it into the actual time according to the timestamp conversion rules; for operating data such as SOC, voltage, and current, it can be converted into the corresponding engineering parameters for display according to the unit, precision and other information in the field attributes; for extended data such as fault codes and fault names, it can be parsed and the corresponding fault information can be displayed according to the extended field identifier.

[0163] Through the above process, the BMS side only needs to organize and store the collected data according to the parsing rules, while the host computer side can restore and parse the data based on the parsing rule information saved in the log file, thereby realizing the complete process from data collection, log generation, storage and transmission to data parsing and display.

[0164] This application provides a log storage method. It acquires data to be stored, determines corresponding parsing rules based on the data, and further encodes the data based on the parsing rules and a preset variable-length format to generate log data records including fixed-length data fields and extended data fields. This allows data collected by the battery management system to be stored according to a preset data organization method. The fixed-length data fields are arranged in binary byte format according to the parsing rules, eliminating the need for separators between fields and the need to convert raw values ​​to character format for storage. This reduces format conversion overhead and the use of additional descriptive information during data storage, improving the space utilization efficiency of the log data. For example, in typical application scenarios, for log records containing core operating parameters such as time, SOC, voltage, current, and SOH, the solution proposed in this application can use a compact binary method for storage, and the single data record can be controlled within a small byte range. When calculated with a single log line length of 90 bytes, the storage space occupied by 10,000 log records is approximately 900,000 bytes, or about 0.86 MByte. Approximately 11,600 log records can be stored in 1 MB of storage space, thereby extending the log retention period with limited Flash storage capacity and providing more historical data for subsequent status analysis and fault tracing.

[0165] Furthermore, by employing a data organization method that combines fixed-length data fields and extended data fields, fixed-length data fields can be used for continuous storage of frequently generated operational data such as SOC, voltage, current, and temperature, ensuring data recording efficiency. For data with variable lengths, such as fault codes, fault names, diagnostic information, and individual voltage arrays, or data generated only during specific events, a variable-length encoding format is used to form extended data fields, allowing them to be stored according to the actual data length. The extended data field includes an identifier, a length field, and a data field. The identifier identifies the extended data type, the length field indicates the data length of the data field, and the data field stores the actual data content. Since extended data fields do not require reserving fixed-length space for different data types but dynamically adjust storage space based on the actual data content, space waste during variable-length data storage is reduced, and the log storage structure's adaptability to different data types is improved.

[0166] Furthermore, by associating parsing rule information with log data records, the log file simultaneously stores the basis for data parsing and the actual log data. The parsing rule information includes parsing rule rows describing field types and data formats, and header rows describing the physical meaning of fields. When the host computer subsequently reads the log file, it first reads the parsing rule rows to determine the data type, length, and arrangement of each field in the log data record; then it reads the header rows to determine the physical meaning of the corresponding fields based on the field attribute information, thus achieving automatic parsing and display of the log data. Therefore, compared to methods that rely solely on fixed program code or external configuration files for parsing, this solution endows the log file with its own data description capabilities, reducing the problem of historical logs being unparseable due to data format changes, software version upgrades, or missing parsing configurations, and improving the maintainability and version compatibility of the log data.

[0167] Furthermore, by decoupling the parsing rule information from the log data records, the data storage format does not need to completely depend on a fixed data structure definition. When the battery management system needs to add new record fields or new event data types, the data format can be adjusted by updating the parsing rule information and the corresponding extended field definitions, without having to redesign the entire data storage structure. Therefore, compared to fixed-structure storage schemes that are prone to incompatibility issues between old and new versions due to the addition, deletion, or adjustment of fields, this application can reduce the maintenance cost during the log format iteration process and improve the compatibility of log files between different software versions.

[0168] Furthermore, this application uses character encoding to store parsing rule information and binary compact format to store log data records, enabling log files to possess both good readability and high storage efficiency. The parsing rule information is stored in character format, facilitating engineers' direct viewing of field definitions and data meaning; the log data records are stored in binary format, reducing the overhead of character conversion and field separators. In typical application scenarios, compared to solutions using entirely character-based storage, this application avoids data bloat caused by converting raw data to ASCII characters. For example, character storage solutions typically require approximately 200-300 bytes to record a single log entry, while this application typically requires only about 90 bytes. Compared to fixed-structure binary storage solutions, this application maintains storage efficiency at approximately 80-100 bytes while improving data format expansion capabilities through parsing rule information and dynamically expanded fields. Therefore, under the same Flash storage capacity, this application can store more log records while balancing data storage efficiency, format expansion capabilities, and subsequent parsing convenience.

[0169] Based on this, this application achieves efficient, flexible, and parsable data storage of battery management system logs under limited storage resources by associating parsing rule information with log data records, combining fixed-length data fields with extended data fields, and using variable-length data encoding. In typical application scenarios, this application's solution reduces storage space usage compared to all-character storage solutions, improves log format scalability compared to fixed-structure storage solutions, and enhances log data reading and analysis convenience through a self-describing parsing mechanism. This solves the problem of existing battery management system log storage systems struggling to simultaneously balance storage space utilization, data scalability, and log parsing convenience.

[0170] Based on the log storage method provided in the above embodiments, this application further provides a log storage device. Please refer to... Figure 2 , Figure 2 This is a schematic diagram of the log storage device. (For example...) Figure 2 As shown, the log storage device 100 includes: a data acquisition module 110, a data encoding module 120, a log file generation module 130, and a log file storage module 140.

[0171] The system includes a data acquisition module 110 for acquiring data to be stored and determining parsing rule information corresponding to the data; a data encoding module 120 for encoding the data to be stored based on the parsing rule information and a preset variable-length format to generate log data records; wherein the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using a variable-length format; a log file generation module 130 for associating the parsing rule information with the log data records to generate a log file; and a log file storage module 140 for storing the log file in the storage medium of the battery management system.

[0172] It should be noted that the above-described log storage device can execute the log storage method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the log storage device embodiments can be found in the log storage method provided in the embodiments of this application.

[0173] This application also provides a battery management system 200, please refer to... Figure 3 This diagram illustrates the hardware structure of a battery management system 200 capable of executing the methods described in the embodiments above. The battery management system 200 includes: at least one processor 210; and a memory 220 communicatively connected to the at least one processor 210. Figure 3Taking a processor 210 as an example, the memory 220 stores instructions executable by at least one processor 210. These instructions, when executed by at least one processor 210, enable the at least one processor 210 to perform the log storage method described in the above embodiment. The processor 210 and the memory 220 can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0174] The memory 220, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the log storage method in the embodiments of this application. The processor 210 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 220, thereby implementing the log storage method of the above embodiments.

[0175] Memory 220 may include a stored program area and a stored data area, wherein the stored program area may store the operating system and applications required for at least one function; the stored data area may store data created based on the use of the computing device, etc. Furthermore, memory 220 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 220 may optionally include memory remotely located relative to processor 210, and these remote memories may be connected to the computing device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0176] One or more modules are stored in memory 220, and when executed by one or more processors 210, the log storage method of the above embodiment is executed.

[0177] The above-described product can execute the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the methods. Technical details not described in detail in this embodiment can be found in the log storage method of the embodiments of this application.

[0178] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions. These instructions are executed by one or more processors to enable at least one processor to perform the log storage method described in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0179] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A log storage method, characterized in that, Applied to a battery management system, the method includes: Obtain the data to be stored, and determine the parsing rule information corresponding to the data to be stored based on the data to be stored; Based on the parsing rule information and the preset variable-length type length format, the data to be stored is encoded to generate log data records; wherein, the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using the variable-length type length format; The parsing rule information is associated with the log data records and stored to generate a log file; The log file is stored in the storage medium of the battery management system.

2. The log storage method according to claim 1, characterized in that, The parsing rule information includes parsing rule rows and table header rows. The parsing rule line is used to describe the data type and field type of each fixed-length data field in the log data record, so as to determine the arrangement rule of each fixed-length data field in the log data record; The header row is used to describe the field attribute information corresponding to each of the fixed-length data fields, so as to determine the physical meaning of each of the fixed-length data fields. The parsing rule row and the table header row are established in a corresponding relationship according to a preset field order.

3. The log storage method according to claim 2, characterized in that, The parsing rule line is stored in the log file in character encoding form; the parsing rule line includes multiple field type key-value pairs, each field type key-value pair includes a field type identifier and a rule character, and each field type key-value pair is distinguished by a first delimiter; wherein, the field type identifier is used to identify the field type of the corresponding fixed-length data field; the rule character is used to describe the data type of the corresponding fixed-length data field.

4. The log storage method according to claim 2, characterized in that, The header row is stored in the log file in character encoding format; the header row includes multiple hierarchical key-value pairs, each hierarchical key-value pair including a fixed-length data field name and field attribute information corresponding to the fixed-length data field name; wherein, the field attribute information includes multiple attribute dimension key-value pairs; each attribute dimension key-value pair includes an attribute dimension and a data value; wherein, each attribute dimension key-value pair is distinguished by a second delimiter, and each hierarchical key-value pair is distinguished by a first delimiter.

5. The log storage method according to claim 2, characterized in that, The process of encoding the data to be stored based on the parsing rule information and the preset variable-length format to generate log data records includes: Based on the parsing rule information and the preset field order, the fixed-length data in the data to be stored is encoded to generate a fixed-length data field arranged in binary byte format; The extended data in the data to be stored is encoded according to the variable length type format to generate an extended data field; The fixed-length data field and the extended data field are combined to generate the log data record.

6. The log storage method according to claim 5, characterized in that, The extended data field includes an identifier, a length field, and a data field. The identifier is used to identify the extended data type corresponding to the extended data field. The length field is used to indicate the data length of the data field in the extended data field. The data field is used to store the data content corresponding to the extended data type. The identifier, the length field, and the data field are arranged in sequence to generate the extended data field.

7. The log storage method according to claim 6, characterized in that, The method further includes: The length field in the extended data field uses variable-length encoding to represent the data length of the data field. Specifically, when the data length of the data field meets the preset first length threshold range, the length field is represented by a single-byte encoding method; when the data length of the data field meets the preset second length threshold range, the length field is represented by a two-byte encoding method.

8. A log storage device, characterized in that, Applied to a battery management system, the device includes: The data acquisition module is used to acquire data to be stored and determine the parsing rule information corresponding to the data to be stored based on the data to be stored. The data encoding module is used to encode the data to be stored based on the parsing rule information and the preset variable length format to generate log data records; wherein, the log data records include fixed-length data fields arranged in binary byte format according to the parsing rule information, and extended data fields encoded using the variable length format; The log file generation module is used to associate and store the parsing rule information with the log data records to generate a log file; The log file storage module is used to store the log file in the storage medium of the battery management system.

9. A battery management system, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by the battery management system, cause the battery management system to perform the method described in any one of claims 1-7.

Images